Scan on every commit: what happens between the push and the finished fix

What really happens on every commit

The phrase sounds like a tool that X-rays the whole application on every push. No scanner works that way, nor should one, because a full scan per commit takes minutes and stalls developers. What actually happens is staged. The change itself is checked at once. Its effect on the rest of the code is assessed in context. And the codebase as a whole is searched on its own rhythm, so that what did not originate in this commit is found as well.

That staging is the difference between a scanner developers resent and one they stop noticing after a week. Our code security page names the three levels; what follows is what goes on inside each.

Depth one: the instant check

The push lands, and within seconds the changed lines are checked for three things: hardcoded passwords, keys and tokens; known unsafe functions and patterns; dangerous calls such as unchecked system commands. The result is there before the code moves on. Whoever checks in a secret hears about it while the editor is still open, not at the next audit date.

The instant check is deliberately narrow. It knows patterns, not intentions. What it reports is not yet a finding but a candidate.

Depth two: the check in context

Now the change is no longer looked at in isolation but in the context of the codebase. Does the new call really lead to a place where input arrives unchecked? Is the missing access check at a point reachable from outside, or in an internal helper module? This is where a candidate becomes a real risk or does not. The assessment follows the real risk, not the number of hits.

This is the stage where the thing scanners cannot do alone takes place: a person sees every candidate before it becomes a finding and drops what is not exploitable in the specific case. The outcome is a clear priority instead of an endless hit list. Anyone who has ever received 400 warnings of which 380 meant nothing knows why this step matters most.

Depth three: the full pass

The third level does not run per commit but across the whole codebase, because much of what is dangerous did not originate in the current commit. Every dependency is matched against known vulnerabilities. The repository history is searched for old secrets, because a key checked in two years ago and deleted since still sits in the history. And the configuration is checked for insecure defaults.

This level produces the findings that most often top the first report after 48 hours: not yesterday's mistake, but the library from eighteen months ago.

Why the fix is the measure, not the alert

A report full of findings that nobody works through is not protection. So the process does not end with a notification. For a critical finding, fixing means: the secret is rotated, not merely removed from the code, because a key once published stays valid until it is invalidated. The vulnerable library is updated. The dangerous pattern is defused. And each of these actions is documented with the finding and the date.

That a rotated secret is the only real fix is spelled out in our article on hardcoded secrets. The same holds for dependencies: as long as the old version runs, the finding is not closed, however often it has been reported.

How to get there

Getting started takes a contract and a list of repositories, not a project plan. The first pass over the existing code yields a prioritised set of findings within two days, anything critical is cleaned up during the first week, and after that the three depths simply run in the background. Start with the free code analysis: no obligation, and inside your environment if the code has to stay home.

Frequently Asked Questions