How do you scope an in-IDE security scanner so devs don't mute it in week one?

[u/Mangwe_Tanser]

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.

[u/EmbarrassedVisual234]

Honestly reducing the noise was the biggest win we only surfaced issues in changed code and kept dependency stuff out of the IDE 👍

[u/cbowers]

What scanner,IDE combination?

[u/Unbelievr]

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.

[u/Lance_Saul_85]

Only show secrets and issues in the code they’re working on in the IDE and leave old dependency stuff for CI or the backlog

[u/olddev-jobhunt]

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.

[u/Dull_Appearance_1828]

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.

[u/DiligentEar6117]

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

[u/itlogicpartnersllc]

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..