It’s Time Developers Say Goodbye to Code Vulnerability Backlogs

Without the widespread developer adoption of security tools, it's extremely difficult to build secure applications in the cloud. Developers aren’t security experts, which is why development teams will leverage application security tools – like SAST, SCA, IaC Scanning, secrets detection, and other technologies – to scan their code and surface vulnerabilities.

These tools are often resisted by developers. No matter how many times vendors claim their solutions are “loved by developers'', their tools are either begrudgingly adopted by developers or are neglected altogether.

Why? Application security tools directly contradict the primary motivator for developers: delivering innovative features quickly. It's not surprising that any tool forced upon developers to achieve a goal unrelated to delivering new features quickly would be met with resistance. Security is no exception.

In this post, I’ll make the case that this is largely due to the vulnerability backlog: a continuously growing list of vulnerabilities per repository. The backlog slows down developers, which often causes them to abandon security tools altogether. 

How the vulnerability backlog fits into the AppSec process

To surface and prioritize software vulnerabilities for developers, all application security tools follow roughly the same basic flow. 

First, some development action triggers a scan. Examples of these actions include manually triggering scans in the IDE, a software build, creating a PR, or automatically scanning a repo every x hours.

Next, the security tool begins its analysis. Commercial tools usually pull the code to the vendor’s cloud to scan their code, while open source tools will run the analysis locally or in the user’s cloud. These analyses can vary from analyzing the data flow of code (Static application security testing, or SAST), mapping software components to a database (Software Composition Analysis, or SCA), or looking for specific data within the code (like secrets detection).

Third, the security tool will list the vulnerabilities found in the analysis – we call this the backlog, and nobody likes it. The developer must search through the backlog to find the relevant vulnerabilities to make the fix. 

And finally, the developer can fix the security issue. Some tools will provide context around the vulnerability to help developers make the fix, which may include what causes the vulnerability, what are potential fixes, whether it's exploitable in production, and what code fix could solve the issue.

The first, second, and fourth steps seem unavoidable (disagree? Let me know in the comments!). In the rest of this post, let's focus on the problems with the third step, and how to get around them.

Why do backlogs prevent developer adoption for AppSec tools?

Backlogs slow developers down by taking them out of their coding rhythm – physically and mentally. Physically, they need to switch UIs to see the backlog. Mentally, they need to stop thinking about their code change and start thinking about any new vulnerabilities they may have introduced.

Lets say a new PR is created to fix a minor bug, and a SAST scan is automatically initiated. The scan surfaces a new vulnerability and points the developer toward the vulnerability backlog for more information. So the developer leaves their environment to enter the vulnerability backlog, where they are confronted with every security issue in their entire repository. 

To find the newly introduced vulnerability, they need to comb through hundreds or even thousands of security issues that have nothing to do with the minor bug fix they just made! No developer is going to take on every issue in their repo during a routine update.

Once they find the vulnerability in the backlog and learn more about it, they’d need to go back to their PR to finally make the fix.

A useful analogy to the vulnerability backlog is a dystopian Spell Check tool. In this scenario, the spell check tool finds misspelled words as you write, but rather than showing the problem within your document, it lists every problem in a separate list (a backlog). After writing a new paragraph, you want to make sure there are no misspelled words, so you click on the backlog and comb through every misspelled word in the entire doc to find the problems in your new paragraph. 

It's time for application security to follow the real spell check UX, where developers can:

1. Surface vulnerabilities as they create a PR.

2. View only the security issues related to the code change they just made, rather than combing through results that aren’t related to their current change.

3. See all the related remediation information within their PR, rather than a separate UI.

4. Make the fix with suggested remediation code within the PR.

Say goodbye to backlogs: Iterative code scanning within the PR using Jit

Jit offers a backlog-less security UX for developers.

As new PRs are created, Jit invokes whichever security tools the user needs – including SAST, SCA, secrets detection, IaC scanning, CI/CD security, and others – all at once. 

After scanning new code, Jit only surfaces the vulnerabilities caused by the code in that PR. Rather than navigating to a separate UI to investigate the backlog, developers only see the security findings that matter most to them entirely within their dev environment.



In the screenshot above, Jit’s security analysis indicates vulnerabilities within the PR. Other tools would point you to the backlog to learn how to fix the issues, but Jit provides all of the relevant information within the PR (see below).



As you can see above, in addition to showing the results within the PR, Jit also includes the relevant remediation information, including remediation guidance and a suggested code change.

Interested in trying it yourself? Start using Jit free for backlog-less developer security.