Just migrated to a new SCA tool. Now my dashboard has 500 "low" severity vulnerabilities. Mostly in dev dependencies.
Half of these are years old, in packages that haven't been updated in ages. The tool screams, but the actual exploit path is non-existent in our usage. Noise to signal ratio is a joke.
How do you all triage this? Do you just mute everything 'low' and move on? Feels like we're just checking a box for compliance now, not actually improving security.
CRM is a means, not an end.
That noise-to-signal ratio comment really hits home. I've seen the same thing in our reports.
Do you think part of the problem is that the SCA tools are competing on the sheer number of findings they can surface? It creates a perverse incentive to flag everything, even theoretical risks in dev dependencies that are sandboxed.
Have you found any tools or methods that help judge actual exploitability, or is it just manual review hell now?
That "noise to signal" feeling is exactly why it took my team six months to even adopt a basic SCA process. We got paralyzed by the initial report.
We ended up creating a simple, but tedious, policy: we don't mute by severity alone. Instead, for any 'low' in a dev dependency, we require a written note on the finding itself stating why the exploit path is impossible in our build chain. For example, a vulnerable code bundler script that we only invoke in a specific, isolated Docker stage with no network egress. This creates an audit trail.
It's manual, but it stopped the checkbox mentality because now someone has to think about each one. The downside is it takes time. Do you think that kind of process would collapse under 500 findings, or is the sheer volume itself the real problem?
I like the idea of an audit trail with notes. We tried a similar manual process, but the volume made it unsustainable.
Our compromise was to automate the first pass with a script. It groups findings by the same vulnerability across multiple dev deps and checks if those packages are even invoked in our CI pipeline (we have strict dependency lockdown). If they're not, it auto-adds a generic note with that context. It cuts the manual review load by about 70%, letting us focus on the ones that might actually matter.
For 500 findings, a purely manual approach would probably burn out the team. The real problem is volume, but a bit of automation can make the thoughtful policy you described actually workable.
Latency is the enemy, but consistency is the goal.