Unburdening Developers From Vulnerability Fatigue with Snyk Delta Findings
Developers are trapped in a loop: constantly chasing dependency upgrades to mitigate security risks or chasing down security reports of vulnerable code or findings in the CI pipeline. Developers often refer to this as “vulnerability fatigue,” a term commonly referenced in npm package install logs that list the newly introduced security vulnerabilities for third-party dependencies. There is a way to eliminate or reduce vulnerability fatigue, and it involves early, seamless remediation, and customization. In other words, dealing with security issues as early as possible, and showing developers only issues that impact them and that they can act upon. Meeting Developers in the IDE What if you could easily find security issues, such as command injection in your JavaScript codebase, while you code? Or, what if you could pre-emptively find and neutralize security issues instead of waiting until you finish building the feature, pushing the code to a feature branch and only then finding after the CI pipeline runs that you’ve introduced a vulnerable version of Jinja2 that creates a Cross-site Scripting vulnerability in your Python application? The Snyk VS Code extension provides you with precisely this proactive workflow experience, empowering you to act on vulnerabilities early in the development cycle, directly where you work – in the IDE. Once installed, the extension automatically runs and analyzes your project manifest files and application logic code whenever you save code changes and performs static code analysis to find vulnerable and insecure code. The Snyk DevSecOps platform’s quick yet complete scans, typically finishing in seconds, end with vulnerabilities being conveniently displayed in the Snyk extension pane, along with the popular squiggly line and in-editor file view annotations, all of which provide in-depth information about insecure code patterns and helpful details on how to address them. The above screenshot from my Node.js project shows 150 security vulnerabilities to address. With so many issues, where do we begin? We’ve already minimized disruption to the developer workflow and given you a way to tackle vulnerabilities proactively. Can we now improve the developer experience around security findings even further by showing developers only security issues that are relevant to them? Read on! Reducing Cognitive Load with Snyk’s Delta Findings Fixing vulnerabilities early in the development process significantly reduces the struggle and effort compared to analyzing security findings later in CI or later in the software delivery process. But even when developers receive insights right in the IDE when writing code, they still need to assess insights from not only Snyk’s IDE extension, but they also have to filter out overwhelming noise for their project from other extensions as well. In addition to this mental load, developers also have another potential source of friction: security teams gating code changes and deployments to address newly introduced security issues. Security teams do this for the following reasons: Prevention: Gating new code changes as a preventative measure. Action: Catching existing security issues that are likely already in production. Still, gating during the CI pipeline via PR checks or other facilities depends mainly on how you manage your code repository and DevOps workflows. There’s a lot of overhead and cognitive load for developers to handle security issues when they are gated at the continuous integration phase. This means that, from the developer's point of view, these "security gate" workflows happen much later in the development process. How can we highlight newly introduced security issues earlier in the process, i.e., during development, so that developers can rapidly take action and remediate problems before pushing a feature or fix that might include security vulnerabilities? The Snyk platform (including Snyk Code for SAST, Snyk Open Source, and Snyk IaC)’s updated IDE plugins now have a “delta findings” feature to help us do just this. Keeping Developers Focused This newly introduced “delta findings” capability in the IDE shows developers a clear view of only the security issues introduced by their code. This provides developers with focus and aligns their focus with what most security teams value most in their processes. The updated extension features a toggle to switch between the state of your base branch (e.g., main) and your current working branch. By choosing the new toggle option, you can reduce the noise generated from the repository's current state and instead focus on the code, dependency, and any IaC changes that you alone might have introduced during your development. The above screenshot shows that 150 total security issues need to be addressed across vulnerable open source dependencies and insecure code in my Express Node.js application. However, I can click the new toggle (or set it as my def

Developers are trapped in a loop: constantly chasing dependency upgrades to mitigate security risks or chasing down security reports of vulnerable code or findings in the CI pipeline.
Developers often refer to this as “vulnerability fatigue,” a term commonly referenced in npm package install logs that list the newly introduced security vulnerabilities for third-party dependencies.
There is a way to eliminate or reduce vulnerability fatigue, and it involves early, seamless remediation, and customization. In other words, dealing with security issues as early as possible, and showing developers only issues that impact them and that they can act upon.
Meeting Developers in the IDE
What if you could easily find security issues, such as command injection in your JavaScript codebase, while you code? Or, what if you could pre-emptively find and neutralize security issues instead of waiting until you finish building the feature, pushing the code to a feature branch and only then finding after the CI pipeline runs that you’ve introduced a vulnerable version of Jinja2 that creates a Cross-site Scripting vulnerability in your Python application?
The Snyk VS Code extension provides you with precisely this proactive workflow experience, empowering you to act on vulnerabilities early in the development cycle, directly where you work – in the IDE.
Once installed, the extension automatically runs and analyzes your project manifest files and application logic code whenever you save code changes and performs static code analysis to find vulnerable and insecure code.
The Snyk DevSecOps platform’s quick yet complete scans, typically finishing in seconds, end with vulnerabilities being conveniently displayed in the Snyk extension pane, along with the popular squiggly line and in-editor file view annotations, all of which provide in-depth information about insecure code patterns and helpful details on how to address them.
The above screenshot from my Node.js project shows 150 security vulnerabilities to address. With so many issues, where do we begin? We’ve already minimized disruption to the developer workflow and given you a way to tackle vulnerabilities proactively. Can we now improve the developer experience around security findings even further by showing developers only security issues that are relevant to them? Read on!
Reducing Cognitive Load with Snyk’s Delta Findings
Fixing vulnerabilities early in the development process significantly reduces the struggle and effort compared to analyzing security findings later in CI or later in the software delivery process. But even when developers receive insights right in the IDE when writing code, they still need to assess insights from not only Snyk’s IDE extension, but they also have to filter out overwhelming noise for their project from other extensions as well.
In addition to this mental load, developers also have another potential source of friction: security teams gating code changes and deployments to address newly introduced security issues. Security teams do this for the following reasons:
- Prevention: Gating new code changes as a preventative measure.
- Action: Catching existing security issues that are likely already in production.
Still, gating during the CI pipeline via PR checks or other facilities depends mainly on how you manage your code repository and DevOps workflows. There’s a lot of overhead and cognitive load for developers to handle security issues when they are gated at the continuous integration phase.
This means that, from the developer's point of view, these "security gate" workflows happen much later in the development process. How can we highlight newly introduced security issues earlier in the process, i.e., during development, so that developers can rapidly take action and remediate problems before pushing a feature or fix that might include security vulnerabilities? The Snyk platform (including Snyk Code for SAST, Snyk Open Source, and Snyk IaC)’s updated IDE plugins now have a “delta findings” feature to help us do just this.
Keeping Developers Focused
This newly introduced “delta findings” capability in the IDE shows developers a clear view of only the security issues introduced by their code. This provides developers with focus and aligns their focus with what most security teams value most in their processes.
The updated extension features a toggle to switch between the state of your base branch (e.g., main) and your current working branch. By choosing the new toggle option, you can reduce the noise generated from the repository's current state and instead focus on the code, dependency, and any IaC changes that you alone might have introduced during your development.
The above screenshot shows that 150 total security issues need to be addressed across vulnerable open source dependencies and insecure code in my Express Node.js application.
However, I can click the new
toggle (or set it as my default). Then, Snyk Code will only list security findings for new code changes, such as those that aren’t yet committed (like in the above screenshots) or that are committed but are part of a different branch than the git branch that is set as the primary (main
or master
) for this project.
This is great, because now I can focus only on the security issues resulting from my code, and fix them immediately!
And guess what? Fixing vulnerabilities in your code is very easy, too, thanks to Snyk Code’s AI-powered auto-fixing agent, DeepCode AI Fix.
See the lightning icon next to the Path Traversal finding? It shows in the left-sidebar detection list but also in the editor, where the red squiggly line denotes the insecure line of code:
All the above benefits of the “delta findings” feature can now be experienced in Snyk Code’s newly updated IDE extension. Broadly, what you can expect is as follows:
- Snyk will default to show all security findings to avoid breaking any of your workflows
- You can easily and quickly switch between your current working branch and what you define as a base branch to compare to.
Granular Security Filters
You can even further fine-tune the security findings filters by opening the Snyk IDE extension settings. The following VS Code settings page shows how you can select only a subset of Snyk’s findings to show up.
For example, you can filter by:
- The source of the findings, such as open-source dependency vulnerabilities, insecure code vulnerabilities (in your code), infrastructure as code such as Terraform, Kubernetes’s configuration files, and others, and even code quality findings.
- The severity of vulnerabilities - if you want to focus only on high and critical vulnerabilities, you can toggle medium and low off in the list.
I encourage you to explore more capabilities and enjoy the streamlined, customized security workflows in the Snyk VS Code extension.
Benefits of Snyk’s IDE Delta Findings Workflow
In our mission to further improve developer-first security workflows, we are helping both developers and security teams in the following ways:
- Remove the noise of overwhelming security findings from the sheer volume of scans and project files, through customization and prioritization, such as through the Snyk IDE plugin’s “delta findings” feature. Noisy scan results can cause frustration and make it challenging to prioritize and filter the noise properly.
- Help developers focus on finding and mitigating newly introduced vulnerabilities, and help developers to address these issues quickly and seamlessly through their coding flow as they are introduced so that developers can avoid spending countless hours investigating and fixing security issues at the code review and pull request review stages when the CI tests run. While security teams often rush to put security gates in CI pipelines, these usually result in delays and software delivery delays. The Snyk DevSecOps platform helps developers and security teams get ahead of this problem by allowing teams to tackle security right from the first line of code.
- Introduce early visibility into new issues introduced during development to reduce risk, potential CI pipeline disruptions, and process overheads needed to resolve security problems.
- If you are working outside of a source-code version control workflow, the Snyk IDE extension now allows you to choose a reference directory to benchmark against a base state.
Get started with the Snyk VS Code extension today; it’s free!