5 Best Practices for Succeeding at Developer-First Application Security

Advances in developer tools, containers, code repositories, and more enable developer teams to deliver software at an unprecedented pace. However, application security teams are often understaffed, underfunded, and laboring to keep pace with software development. One demonstrated strategy that helps AppSec teams keep up and even provides them time for high-value security tasks is to shift security left in the development cycle. 

Creating a developer-first approach to security, or in other words, shifting security left requires that developers become accountable for producing secure code. Since security is not the typical developer's area of expertise, application security engineers assume the role of providing oversight and guidance needed to enable developers to succeed. 

This article outlines five best practices for building software with a developer-first approach to AppSec.

1. Gain a Deep Understanding of How Developers Work in Your Environment

Application security is deeply connected to the software development process. Because of this close relationship, security practitioners must understand how software is built in their organization. 

It is not enough for AppSec teams to run scanning tools to detect vulnerabilities. They need to know how software development teams work, what tools the organization uses, how developers conduct sprints, and how they allocate resources. It is crucial that security teams see the entire development picture so they can understand how their actions and decisions affect the efficiency and quality of the developer’s work product. Cross-functional teams of all types promote a collaborative culture. 

2. Integrate AppSec Deeply Into Developer Workflows

For an AppSec program to be effective, it must be an integral part of the software development life cycle. Armed with a thorough knowledge of the items discussed in step one above, AppSec and development leaders can put their heads together to determine when and how to conduct security risk assessments, threat model exercises, architecture review, and deploy their arsenal of security tools. 

For example, these team leaders may decide to conduct threat modeling exercises early in the design phase and then again after introducing significant changes to the code. This joint task force of team leaders may also construct policies and schedules to conduct risk assessments and architecture reviews strategically at various points in the life cycle while scanning for vulnerabilities throughout the process. 

This joint effort aims to avoid the necessity of going back to fix significant architectural flaws after the developers have finished and deployed the software. While it is easier to let security hold off until after the developers have completed their work before running their security tools and scanners, this sequential method will invariably cause friction between the two teams. 

When developers are involved in the security process and invested in the security outcome, fewer opportunities exist for inter-team friction and conflict. 

3. Empower the Individual Developer Teams To Be Security Self-sufficient

AppSec teams can not keep up with the pace of software development and are rapidly falling behind. It's little wonder. There are exponentially more developers than security engineers in a typical software development organization. Modern software development tools and code repositories enable developers to code faster than ever. 

The solution to the problem of AppSec teams falling behind and acting as a drag on the speed of software delivery is never going to be found in trying to scale the size of the security team to keep up. Instead, the solution is to scale the security functions and processes, empowering developers to build secure code. 

By shifting the responsibility for security left in the SDLC and vertically to the developers — supported by AppSec subject matter experts (SMEs) — the outcome of secure code becomes inextricably integrated into the development process. 

If organization leaders make it clear the software developers are responsible for the security posture of the code they build and then enable them to be successful, the challenge of AppSec's drag on the process virtually disappears. 

To achieve this scalable outcome, organizations must drive the adoption of the developer-first program by introducing modern tools designed for this type of environment. 

4. Empowerment Must Be Coupled With Accountability

Leaders should empower developers to make security decisions since they own the security posture of their code. However, policies should also hold them accountable by maintaining oversight and reporting on those decisions at various senior leadership levels.

For example, for any given security vulnerability, leaders can authorize a sufficiently senior person within a developer team to delay a fix or decide not to fix the issue at all, thereby enabling the developer team to make decisions. However, managers should ensure that such decisions are properly recorded, promptly reported and that there is visibility on how the business risk is distributed. 

5. Don’t Expect Developers To Be AppSec Experts

It is unreasonable to expect developers to be security experts in addition to being proficient in coding, reliability, scalability, and more. Software development is a discipline of specialists, not generalists. 

Organization leaders should enable developers to easily make the best decisions for producing secure code, not become security SMEs. AppSec teams should be charged with supporting developers by providing access to secure frameworks, secure libraries, and secure default code that makes choosing security the easiest option available. 

By building guardrails within developer processes and systems, leaders can ensure that developers will not unknowingly go off track and make dangerous decisions. When writing secure code is cumbersome and time-consuming, developers are incentivized to create shortcuts and bypass security policies. 

Conclusion

As security professionals, we should look to the developer-first principles discussed in this article as a pattern for building the AppSec programs of the future. By leveraging developer-first AppSec tools that make it easy for developers to integrate security into their development life cycle, we can free up security practitioners to engage in those high-value analytical and investigative tasks needed to keep organizations secure in today's threat ladened world. 

When security programs move away from being gates that act as a speed bump or roadblock for developers and more toward a model that empowers developers with security guardrails and support, we can alleviate the friction between these two essential groups. Only then can organizations scale development and security together.