After a year of scanning our repos and containers with Snyk, the headline results are misleading. We had 2 criticals and over 3000 low-severity findings.
The criticals were legitimate and got fixed. The massive low-severity pile is the real problem. It's mostly noise:
* Outdated packages in devDependencies for tools not used in production.
* `lodash` version bumps with no linked security advisories.
* Transitive dependencies flagged, but 5 layers deep in a library we don't even call directly.
This creates alert fatigue. The signal is buried. We're now tuning aggressively:
```json
{
"severity": "critical|high",
"ignore-paths": ["**/node_modules/**", "**/test/**"],
"policy": "production"
}
```
The value is in the accurate critical/high findings in direct dependencies. The rest is a configuration management problem. If you don't set strict policies, the dashboard becomes useless.
Least privilege is not a suggestion.
Totally feel this. That dashboard noise is real.
We hit the same wall and started using custom policies per project type. For our internal tools, we basically ignore devDependencies now. For customer facing APIs, we lock it down to critical/high only in runtime deps.
Your config tweak is the right move. It turns Snyk from a panic button into a useful signal. Still, sifting through those 3000 lows must have been a chore 😅
Thanks for sharing your config, that looks really helpful. I'm just starting out with Snyk and the noise is exactly what's been worrying me.
When you say "configuration management problem," do you think teams should set these strict policies right from the beginning? I'm afraid we might miss something important if we ignore too much too soon.
Great question. That "miss something important" fear is exactly why I don't recommend starting super strict.
My approach is to run a broad first scan, just to see the raw output. Then, you triage *once* to establish a baseline. Look for patterns in those 3000 lows: are they all in test folders? Dev tools? Specific legacy projects? Your initial policy should be built from that evidence, not from a guess.
It's less about ignoring things "too soon" and more about ignoring things "forever, for a good reason." Document why a path or severity is excluded, and review those rules quarterly. It turns noise management into a deliberate, traceable process instead of a reactive scramble.
Keep it real
Totally agree with the initial broad scan approach. That first chaotic report is actually a goldmine for understanding your own dependency hygiene.
The quarterly review point is key, but I'd add that you should tie it to your release cadence or major dependency updates. If you bump a core framework, that's the time to re-run a full scan and see if any old ignores are now relevant. It keeps the policy living with the codebase.
One caveat: that "triage once" phase can be a monster if you have a huge monorepo. We ended up scripting a bit to group findings by library and path first, which made spotting those patterns (like "all lodash lows are in legacy-admin-panel") way faster.
ship it
Custom policies per project type sounds sensible in theory, but doesn't that just shift the problem? Now you're managing a zoo of policies instead of a mountain of alerts. How do you keep that from becoming its own configuration management nightmare?
And you're still relying on Snyk's own severity scoring for "critical/high only." I've seen their definitions drift after a CVE gets more analysis. What was critical on Tuesday can become medium by Thursday. So you're filtering noise with a moving target.
cg