The False Sense of Security
In the rush to adopt DevSecOps practices, many development teams have embraced software composition analysis (SCA) tools like Snyk, Dependabot, and others. The prevailing assumption is that using such tools automatically translates to strong security posture. After all, if you’re being alerted to vulnerabilities, aren’t you already ahead of the game?
Unfortunately, this mindset leads to a dangerous misconception: that security scanning equals vulnerability management. It doesn’t.
As many teams discover, the hard way, having visibility into vulnerabilities is only half the battle. “We use SCA, but the results are poor,” is a common thing we hear over and over again. Discovery happens fast - but fixes are delayed, inconsistent, sometimes never happen at all. This isn't a tooling failure. It's a process failure.
Visibility is Not Security
SCA tools are excellent at surfacing what’s wrong in your dependencies. They shine a bright light on vulnerabilities buried deep in your dependency tree, highlight licenses, and flag outdated packages. But here’s the catch: they stop short of fixing anything.
Knowing about a vulnerability doesn’t make your application any safer - unless you take concrete action. Visibility without remediation is simply risk awareness. And while awareness is a prerequisite for action, it's not a substitute for it.
Security isn’t about knowing something is broken. It's about fixing it before someone else exploits it.
You Don’t Have a Visibility Problem - You Have a Remediation Problem
In most teams, the problem isn’t discovering vulnerabilities. The problem is fixing them.
This is where the real work - the real security work - begins. Upgrades must be performed carefully to avoid regressions. Patches have to be tested. Configuration changes must be verified. For all the talk of automation, this is still a heavily manual, context-dependent process.
Consider the case of a vulnerable transitive dependency - a library you don’t directly use but one your project depends on indirectly. SCA tools will surface the issue, but they won’t help you rewrite your dependency tree, ensure compatibility, or upstream a fix. You’re left holding the bag.
Here’s a real life example:
Say your dependencies look like this:
"dependencies": {
"axios": "0.19.2",
"react-query": "3.13.0"
}
A vulnerability, CVE-2021-3749 was found in axios < 0.21.3. The remediation is to upgrade axios to at least 0.21.3. You upgrade axios just to find out that you need now to upgrade react-query as well:
react-query@3.13.0 has an unmet peer dependency: axios@"^0.19.2 || ^0.20.0"
It’s becoming a cascading dependency upgrade effort.
The Gap in SCA Tools
SCA tools stop at creating a pull request, to upgrade a dependency from version X to version Y - or worse, simply listing vulnerabilities. But the complexity of remediating remains with the developers.
You still have to figure out whether that upgrade will break your application. You still need to test, debug, and sometimes refactor surrounding code. That’s unpredictable and often daunting work.
While features like reachability analysis can help prioritize issues, they don’t eliminate them. Developers are still on the hook for resolving deeply nested problems in third-party packages they don’t maintain.
And what happens when those packages can’t be updated because their maintainers are unresponsive or inactive? Just look at issues like this one, where users are stuck waiting on maintainers to fix transitive vulnerabilities. You're not in control - your security is at the mercy of your supply chain.
The Cost of Fixing is Too High
Every fix has a cost. You may need to:
- Upgrade libraries (which might introduce breaking changes)
- Rewrite or refactor business logic that depends on outdated APIs
- Retest your entire application
This takes time, introduces risk, and often requires coordination across teams. It’s no wonder that many vulnerabilities remain unfixed - not because teams don’t care, but because they can’t afford to drop everything and hope nothing breaks.
The Cost of Revert is Too High
Even when a fix is attempted, the fear of failure looms large. Once you've made changes and moved on, rolling back is often messy and destabilizing. Teams hesitate to upgrade dependencies unless absolutely necessary, because breaking something in production doubles the work.
The result? A culture of inertia, where security issues pile up while everyone waits for a "safe" moment to act - one that rarely comes.
Conclusion: Scanning is Just Step One
SCA tools are an essential part of the modern security toolkit. But they’re not a silver bullet - and they were never meant to be.
To truly secure your software, you need a complete vulnerability management strategy. That means:
- Prioritizing vulnerabilities based on exploitability and business impact
- Automating remediation and backporting fixes where possible
- Building low-risk paths to apply fixes safely and quickly
Security isn’t just about identifying risk. It’s about reducing it - quickly, efficiently, and reliably.
Scanning gets you to the starting line. Remediation is what wins the race.
