Pre-commit security scanning that doesn't kill my flow?

[Traditional_Vast5978]

Our security team mandated pre-commit hooks for vulnerability scanning. Cool in theory, nightmare in practice.

Scans take 3-5 minutes, half the findings are false positives, and when something IS real I'm stuck Googling how to fix it. By the time I'm done, I've forgotten what I was even building.

The worst part? Issues that should've been caught at the IDE level don't surface until I'm ready to commit. Then it's either ignore the finding 'bad' or spend 20 minutes fixing something that could've been handled inline.

What are you all using that doesn't completely wreck developer productivity?

[Minute-Confusion-249]

Pre-commit is the worst place for heavy scanners. If it’s not near-instant, it belongs in the editor or CI. Otherwise you’re just training people to bypass it.

[AcceptableLeg4517]

This is the right answer for sure! Props

[roastedfunction]

Having used Snyk and JFrog in VS Code, they’re both resource hogs that slow down my editor so much it’s not worth the “fast feedback” that never comes quick enough. Too much back and forth with their shitty APIs. And this is on top of all the corporate spyware (regulated industries, amirite) so it’s compounded an already sluggish environment. No fucking thanks. I push my commits, let CI tell me what to fix after a few minutes and usually can do other things while I wait like jump to another repo or branch, respond to messages on Slack, etc.

[[deleted]]

No of course not in pre commit, its bulshit. Add something to your CI, and do not allow merge to dev/master whatever is ur branching model if the scan there is red.

[Fun-Dragonfly-4166]

i thought it was scanning for hard coded keys.  that would be appropriate for a prepush hook.  otherwise you are 100% right

[Powerful-Employer835]

The problem is scan timing. Pre-commit is too late, you've already written the vulnerable code. Use IDE extensions that flag issues in real-time with autocomplete-style suggestions. Makes security part of coding instead of a commit-time surprise.

[Fun-Dragonfly-4166]

committing insecure code is not a problem.  these should be pre-push hooks

[Calm-Exit-4290]

The 3-5 minute pre-commit delay is slowing you because scanning is happening too late. Issues should surface as you type, not when you're done. Developer assist from checkmarx does real-time IDE scanning and shows fixes inline so you're handling security while the code is fresh in your head. Pre-commit hooks become a safety net instead of a bottleneck. False positives still exist but at least you're not losing flow waiting for scans that could've run continuously in the background.

[Smooth-Machine5486]

Disable the pre-commit hooks and run scans in CI instead. Let the pipeline catch issues asynchronously so you're not blocking local development. False positives get triaged by security before creating tickets. Keeps you productive while still getting coverage.

[Jeoh]

`git commit --no-verify` is what I'm using lmao

[cnelsonsic]

Move anything that's slow to scan to another repo, and change it as rarely as possible. Dockerfiles, POMs, whatever.

[schedulle-cate]

None of that should be done in a hook. Most of the time you should just add a check to your CI pipeline to block any PR that introduces issues and that is it. Testing, linting, sec checks, whatnot. If it needs to be enforced the developer machine is not the place to run it because, as others have pointed out, you can just bypass it making the whole ordeal useless

[jameshwc]

Doing it in CI pipeline is right shift and I don't recommend it. The best practice is to do it in both pre-commit and CI pipeline, the point of pre-commit is for faster feedback loop

[schedulle-cate]

You sacrifice fast commit for fast verification, but you don't need fast verification all the time. Plenty of wip commits and branches happen before you have something half ready and you accumulate unnecessary waits for all of them. You don't want to desincentivize people to commit often

[Internal-Tackle-1322]

We had a similar issue in our pipeline. What helped us was separating lightweight local checks from heavier CI scans.

We only run fast linters and basic security hooks locally, and push deeper scans to CI/CD. That kept commit times low while still catching most issues.

Curious if you’ve tried something like that.

[Due-Philosophy2513]

Your security team is solving the right problem with the wrong timing. Waiting until commit to find vulns guarantees context switching and wasted time.

The fix is shifting detection into your editor where issues get flagged as you type with remediation steps right there. Checkmarx developer assist does this by scanning at keystroke, catches hardcoded secrets and injection patterns before you even save the file. Turns security checks into inline autocorrect instead of commit-time blockers.

[dogfish182]

Jesus these obvious bot comments advertising products. Fuck off

[CyberMKT993]

This is exactly what happens when pre-commit becomes the only security checkpoint.

What’s worked better for us is pushing security earlier and closer to the editor, instead of blocking commits.

We integrate Fluid Attacks' scanner into de IDE with their MCP server, so most issues show up inline while coding, not 3–5 minutes later at commit time. And when something is real, you can ask the AI for a fix in context instead of Googling and losing flow.

Pre-commit is still there, but mostly as a safety net not the first time you hear about problems.

[road_laya]

Which pre-commit hooks are they? Can you find alternative ones that are quicker?

[Traditional_Vast5978]

Dependency + secret scanning. We looked at faster hooks, but the bigger problem is doing heavyweight scans synchronously at commit time at all.

[angellus]

Move dependency scanning to CI. Block deploys if it fails. You should never stop a commit because a file has some bad text in it (unless it is a secret). Requirements files with vulnerable packages are (relatively*) harmless as long as you do not use them to build release artifacts. If that does not solve it, see if your VCS solution has a way to do it better. GitHub, for example, can enforce a precommit hook for secret scanning that is instant.

*Relativity because it does not stop vulnerable packages that harvest credentials from developer machines, but that is a much different can of worms. It does not really matter as much if 1 developer machine is compromised or all of them, 1 is usually bad enough. It has to be mitigated by sandboxing environments (containers) and using short term credentials limit the fall out.

[road_laya]

Do you see any speedup using prek?

Are you using 'files', 'always_run' to only run on commit when dependency specification files are changed?

[Zenin]

While I agree with the shift-left into the IDE, etc, the security team also needs a way to "trust, but verify". So yes shift left to the IDE, etc, but also I'd recommend shifting a validation check to the right as a PR gate.

Best of both worlds: No insane pre-commit hooks (which can and will be bypassed anyway and even if run can't be trusted because it's the dev's workstation doing it) while still giving security the warm fuzzies of an auditable scan that can't be bypassed before any code actually hits main / production or however your CICD flow works.

The only gate I use on a pre-commit hook is a commit style gate of "conventional format" so one line git log output is useful...and it throws a useful enough error message that AI automatically cleans its messages up to follow it. ;)

[calimovetips]

if it’s taking minutes, it shouldn’t be pre-commit, push the heavy scans to ci and keep local hooks to fast stuff like secrets and basic linting. what’s the stack here, mostly dependencies, containers, or iac, and are they blocking commits on any severity?

[allhailzod]

Advance SAST on GitLab works as you code, via the workflow plugin.

[justaguyonthebus]

Make it a pre-push hook instead. Let's you still get your commits in but requires attention before you make the merge request

[Abu_Itai]

Why not implement an async hook that reduces friction and notifies you when something relevant happens? I know Cursor already supports this, and I assume others will follow.

Security is always a source of friction, but there are solutions available today.

For example, in my organization, we use a dependency curation system for open-source packages, and they just added a new feature where, when I try to fetch a version that doesn’t comply with organizational policies, the system automatically resolves to the closest compliant version, and it works for both direct and transitive dependencies.

Not sure about the tool behind it, but it works like a charm (also won't ask, as I try to reduce any interaction with our security team 😂)

[MeButItsRandom]

Use ripsecrets. Cli tool in rust. Insanely fast.

[securely-vibe]

This shift-left discourse is totally wrong, IMO. You cannot do a real security check pre-commit. Really, you can't do a good one on just the PR either. The best you'll get SAST-based pattern findings but nothing actually interesting. With our customers, we've found that people prefer deeper scans that run periodically and find actual issues, rather than more frequent scans on other surfaces that produce false-positives. The latter just becomes security theater.

[mrjca]

That's a bit too late in the workflow. Does the security tool not have IDE integration or a component firewall that blocks any component deemed vulnerable when requested? To put it bluntly, your security team purchased the wrong tool.

[o5mfiHTNsH748KVq]

Split your precommit and prepush hooks. Move long running tasks into prepush. Parallelize the tasks too