What Is Static Application Security Testing (SAST)?

Static analysis reads code without running it, tracing how data moves from where it enters to where it is used. That is its strength and the source of every complaint about it: it sees everything the code could do, including a great deal that it never does in practice.

The result is coverage no other technique matches and a false positive rate that determines whether anyone uses the tool after the first month.

What it sees that nothing else does

Coverage of unexercised paths is the genuine differentiator. Dynamic testing only examines what it manages to reach; static analysis examines the error path nobody triggers.

The false positive problem, honestly

A static analyser flags a path from user input to a database query without knowing that a framework escapes the value in between, or that the input can only ever be one of three enumerated values, or that the function is only reachable by an administrator.

The single most effective configuration decision is to gate on new findings in changed code only. It makes the tool an assistant to the person writing the code rather than an inherited punishment for the state of the repository.

Where it is blind

• Configuration and environment. The code may be correct while the deployment is not.
• Authorisation logic. It can see the check is absent only if it knows one was required, which it does not.
• Business logic. No tool knows what your application is supposed to permit.
• Runtime composition. How services actually interact in production is outside its view.
• Dependencies. That is composition analysis, a different tool.

Rolling it out without the team turning it off

The failure pattern is predictable enough to design around. A tool is enabled across the whole repository, produces several thousand findings against years of accumulated code, blocks a release in the first week, and is disabled or bypassed by the second.

A rollout that survives runs in reverse. Start in reporting mode with no gate at all, and spend the first weeks tuning to the frameworks in use rather than triaging findings. Scope to changed code so the backlog is invisible and the tool only ever comments on what someone is actively working on. Introduce a single blocking rule — secrets — which nobody will argue with. Add further gates only once the team trusts the signal.

Handle the legacy backlog separately and deliberately. It is a planned remediation project with its own budget and sequence, not something to be worked off incidentally by developers trying to ship unrelated features.

Where to start

Enable secret scanning and gate the build on it today — it is unambiguous and urgent. Then introduce vulnerability rules in reporting mode on new code only, and promote to blocking once the signal proves itself.

See building security into the lifecycle and DevSecOps in practice. GuardsArm delivers application penetration testing.