The surface area of software is expanding at a rate well above our ability to secure it. The root cause is not a failure of security: it is the phenomenal productivity of developers, enabling software-native businesses to set new records for speed and scale.
Leaders defending high-growth companies must enable building fast to maintain a competitive edge, but their job is also to consider growing tail risks; low probability, high impact security failures will significantly damage customer trust.
Shift left
How do you speed software delivery and prevent security incidents at the same time?
The terms "DevSecOps" and "shift left" have been presented as a solution: moving security issues into the sphere of the developers. This provides critical leverage: we often see ratios of 100 developers to 1 security engineer.
But developers have no incentive to fix security issues–their incentives are around feature velocity. And chronic scanner issues like false positives erode the limited social capital between developers and security teams.
The 100-year backlog & the AppSec doom loop
This friction can create an "AppSec doom loop." Even if engineers are given visibility into vulnerabilities in CI/CD, without credible accuracy, context, and actionable remediation advice, the vulnerability backlog will grow indefinitely. Some examples:
● Two high-severity, real vulnerabilities are found – along with 98 other vulnerabilities. A 98% false positive rate is common in typical 3rd party dependency scanning. After reviewing the first 5 false positives, the developer's eyes glaze over and they conclude the scanner is useless.
● A critical, high-severity issue enabling RCE is discovered – in a codebase that's never going to be deployed beyond a data analyst's laptop. The scanner does not understand the threat model for the codebase, and falsely alerts about a critical issue that actually has no impact.
● A vulnerability is discovered in a transitive dependency – but there's no upgrade available. Unless we're expecting the developer to fix the root cause, what's the point of notifying them?
A gloomy security engineer at a large bank once explained to me that if development stopped today, he had calculated it would take over 100 years for them to get through the vulnerability backlog. That's the AppSec doom loop.
Making shift left easy
But when you make the developer's path of least resistance the secure path, you break the app sec doom loop. Here's a scorecard for making shift left work:
A+ | A | B | F | |
---|---|---|---|---|
Speed | On keystroke in editor | Fastest tool in CI pipeline | Not the slowest tool in the CI pipeline | Slowest tool in the CI pipeline |
False positives (as perceived by developers) | 0% | < 2% | < 10% |
|
Where results are seen | In editor | PR/MR comments on the line of code | Somewhere in CI/CD | Some internal tool URL that only the security team looks at |
Actionable remediation | Every result has a 1-click fix (patch, upgrade command, or suggested code snippet) shown in editor | Fix is available | Advice is available | No remediation advice |
Customizable to add contextual understanding of business-specific security issues | Customizable by any developer | Customizable by skilled developers | Customizable, if you have a PhD | Pure black box, with no customization |
Semgrep AppSec Platform is purpose-built with Semgrep Pro engine to make it easy for developers to do the right thing. We don't get an A+ on everything in this scorecard yet (although do score an A+ in speed, results, and customizability), but we intend to as we believe focusing on the developer experience is the only effective way to make shift left work and deliver more secure software faster.
If you’re looking for more info on how to make shift left work, check out our new resources page on this!