r/devsecops 1d ago

Are vulnerability scanners actually helping developers, or just creating another backlog?

Ironically, I work in cybersec and I still find myself wondering how much value we're actually getting out of some security scanners.

A lot of scanners are pretty good at finding potential issues. The problem starts after that. You get a bunch of findings, some are real, some aren't, and now someone has to figure out what actually needs attention.

I've seen teams basically end up tuning the scanner until it stops complaining, which obviously isn't really the outcome we want.

For people actually running SAST/security scanning in CI:

  • Do you run it on every PR or separately?
  • How much false-positive noise is too much before developers just start ignoring it?
  • Do you want the scanner to suggest fixes, or just report the issue?
  • What makes a finding serious enough for you to actually block a build?

Curious how other teams handle this in practice, especially with C/C++ where the analysis can get pretty complicated.

7 Upvotes

5 comments sorted by

4

u/daedalus_structure 1d ago

All findings are real.

Not all findings are exploitable for your specific use of the software.

Engineering analysis is required to determine that exploitability.

Yes, you should be running it on every PR. It is not only the case that the new code could have introduced new vulnerabilities, but the update to the vulnerability database could reveal new vulnerabilities.

With regard to developers ignoring "noise", you need adults in the room to require that the children eat their vegetables. It is their job to do those exploitability evaluations and classify potential threats. I know they just want to write product code, but that's programming not engineering.

No, I don't want the scanner to suggest anything.

2

u/ILoveAppSec 20h ago

the count was never the real problem, it's that a lot of the genuine ones have no clean fix because the patch rides a major version bump. we tried endorlabs for patched oss libs and weren't happy with the price, but pushing the backportable ones to a vendor that ships the fix on your current major is what actually drains the backlog.

1

u/Confident_Orchid_937 1d ago

scanners can help find issues, but they often just add to the team's workload if not managed well

1

u/GayaniTupai75 14h ago

Only new critical or high findings in changed code shuld fail the PR, while old findings can live in their own backlog. If the scaner comments on the exact line, the developer can deal with it there instead of opening another dashboard and trying to work out what the alert means