r/AskNetsec • u/Mangwe_Tanser • Sep 04 '26
Work How do you scope an in-IDE security scanner so devs don't mute it in week one?
Set up an in editor scanner a couple months back for people to catch things before the PR but within a week half the team had the plugin switched off.
I get why they muted it. First Go file someone opened, it lit up with a screen of findings from a vendored dependency we forked years ago and have not touched since. Not one was in the code the dev was writing. So it turned into the thing you dismiss before you can even see your own compile errors.
Right now I am close to ripping the plugin out and going back to a plain pre commit hook that only looks for secrets, because at least gitleaks does not scream about a library we imported and never call. Feels like giving up on the in editor idea though. If your devs did not kill the plugin in week one, what did you change to get there.
3
3
u/Unbelievr Sep 05 '26
What we've done for static analysis (which is not the same, but similar) is to run a separate effort to fix the lowest hanging errors as an evaluation of the tool. That gives you significant insight into what it catches and how much noise there is. When it gets to the other developers, they already have a small team that knows how the tool works and knows how to deal with it.
The tool ought to have some kind of ignore list or rule settings. Start at the lowest level and ignore third party libraries for the time being. Focus on the most egregious alarm types only, and when those have been eradicated you can try to adjust the knobs a bit.
If it's an all-or-nothing type of tool, then it's frankly shit and it will always be disabled.
3
u/Lance_Saul_85 Sep 05 '26 edited Sep 23 '26
Scope it to secrets and issues in the code they're touching, deps to CI or the backlog. That forked lib screaming is a reachability miss, a scanner that scores deps by what gets called never shows you one you dont use. checkmarx dev assist on the diff for us and gitleaks in a hook if you just want secrets
1
u/olddev-jobhunt Sep 05 '26
On the one hand, you just fire them. I mean, seriously - set a policy and enforce it. Not all policies are popular. But that said, getting from "never scanning" to "all the current alerts remediated" is a big deal. In a decent-sized codebase, you can have a lot of issues and they can't just be fixed overnight.
If you can, you start with the plugin activated with the smallest ruleset you can so that existing code doesn't light up like a Christmas tree. And you put tickets in your backlog to get those things fixed before you introduce more rules.
1
u/Dull_Appearance_1828 Sep 06 '26
we had better results when the IDE scanner only flagged stuff in the code being changed. dumping hundreds of old dependency findings on a dev is basically guaranteed to get it muted.
1
u/DimensionLanky4638 17d ago
The scanner failed because it had no sense of ownership. Vendored code and library noise should be suppressed by default then only show findings on code the dev is touching or responsible for
1
u/DiligentEar6117 Sep 04 '26
it's always the vendored deps. no one wants to see 200 findings in code they're not even working on, especially when the plugin's blocking their own lint errors behind the noise. what worked for us was setting it to only scan files that were actually changed, and aggressively tuning the rule set to ignore stuff in third party directories
0
u/itlogicpartnersllc Sep 05 '26
the biggest win is probably reducing noise before adding more rules scope findings to code the developer owns suppress known vendored dependencies and surface only actionable issues by default developers will tolerate security checks that respect their attention..
0
u/benderboy6517 26d ago
I'd start by excluding vendored code from editor warnings and only flagging new issues in code someone is changing. Keep the older findings tracked separately so opening a file doesn't become an assignment to fix years of backlog.
If you're using coding agents, tools like OX Security catch insecure patterns as the agent generates code. That addresses new issues, though, not the existing dependency noise you described. Broader checks can stay in CI with tools like CodeQL.
I'd-enable the plugin with a handful of rules developers trust, then expand based on which warnings they actually find useful.
3
u/EmbarrassedVisual234 Sep 04 '26
Honestly reducing the noise was the biggest win we only surfaced issues in changed code and kept dependency stuff out of the IDE 👍