The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 2)

In part one of this two-part series, I explored how organizations can more effectively automate security quality decisions and discard doing automation for automation’s sake. I shared why security scans need to be faster, more reliable and comprehensive. Only then can security be meaningfully automated into developer workflows without slowing them down.

But, the other part of this is understanding where these security scans should take place throughout the SDLC. Why? Because inserting security too early or too late in development and pre-production can have drastic impacts on remediation efficiency, developer productivity and more. 

Shifting Security as Far Left as Pull Requests

Identifying vulnerabilities once they’re in production is the riskiest, as well as the most time-consuming and expensive remediation. Working in pre-production test environments or builds reduces the risk, but not much of the time or efficiency in remediation. Conversely, inserting code analysis into developer IDE’s is too early. While in theory the IDE could be a good place for security feedback, in practice, it slows down the developer’s machine and comes at a huge cost of productivity.

Instead, commits and pull requests are the ideal place to insert security because it delivers the right vulnerability information to the right developer at the right time. Combine this with integrations into ticketing and other systems and the full developer workflow can be meaningfully automated.

Simply by getting the right developer, the right vulnerabilities information breaks down one of the biggest challenges in AppSec. Developers typically outnumber AppSec team members by 50-1 or more—hence a security scan that generates 100 vulnerabilities creates a tremendous amount of work for a single AppSec professional. However, assigned to the right developers, at an average of two per person, the challenge immediately becomes more manageable. Still accuracy matters because, while the burden may be spread out, developers triaging false positives is an expensive resource focusing on a low value task.

Getting developers security feedback at the right time is also vitally important. When developers get immediate security feedback, vulnerabilities become easier to fix because the code is still fresh in their mind. Furthermore, fixing vulnerabilities early has compounding benefits. Since insecure code never goes into production, not only is the attack surface reduced, but additional code that is dependent on the vulnerability never gets written. This minimizes the most expensive and time-consuming security fixes, which require not only fixing the underlying vulnerability, but also rewriting dependent code. Best of all, with immediate, regular, comprehensive and accurate security feedback, developers will ultimately learn and adopt more secure coding practices overtime.

Lastly, by inserting security at the commit or pull request, security and developers can establish a shared responsibility model on more realistic terms. When security can commit to accuracy and timely KPIs, developers can commit to triaging and fixing vulnerabilities faster. This reduces MTTR, puts a downward trend on defect density and reduces the application’s overall attack surface. It also reflects the realities that AppSec professionals have a limited ability to triage vulnerabilities, because they don’t know the code intimately and that only developers can fix the underlying vulnerabilities.

By solving the fundamental challenges of speed, accuracy and comprehensiveness to deliver the right vulnerability to the right developer at the right time, security earns the ability to ask more from developers, and CISOs and CTOs can jointly accept responsibility for protecting applications and data.

The rate at which software is being created and shipped isn’t slowing down, but many organizations have struggled to find where security most effectively fits into this process. By inserting security at the pull request, not only can developers identify and remediate vulnerabilities faster and more accurately, they can better automate security quality decisions. By taking this approach, organizations are fundamentally changing how engineering and security collaborate within enterprises.

— Chetan Conikee