Scanners, and the trick that makes them usable

The asymmetry that makes automation necessary

Code volume rose. Human attention did not. Scanners are one of the few things in this picture that scale the same way generation does, so the strategy is to automate every mechanical class in order to spend human attention on the classes that need judgment.

That is the whole argument. The rest is which tools, where they run, and the one configuration choice that decides whether anybody looks at the output.

The free toolchain, by what it catches

Every tool here is free and open source, runs locally, and needs no account.

Pattern-level static analysis. semgrep matches structural patterns in source: concatenated SQL, disabled certificate verification, weak hash calls, dangerous deserialisation. Fast, language-agnostic, and its community rule set covers most of the previous lesson’s list.

Dataflow analysis. CodeQL asks a harder question: does attacker-controlled input reach a dangerous sink, through however many function calls? Slower, deeper, free for open-source projects. This is what catches the injection that semgrep misses because the concatenation happens three functions away from the request.

Language-specific linters. bandit for Python, gosec for Go, brakeman for Rails. Narrow and well-tuned.

Dependency vulnerabilities. osv-scanner, trivy, pip-audit, cargo audit, npm audit. These check what you have against public advisory databases. Seconds to run.

Secrets. gitleaks or trufflehog, as a pre-commit hook.

Running applications. OWASP ZAP for dynamic testing against a deployed instance. Finds things no source analysis can, such as a misconfigured header or an endpoint nobody knew was exposed.

The trick: only fail on what is new

This is the configuration that determines whether the whole exercise works.

Turn a scanner on an existing codebase and you get hundreds of findings. Somebody triages forty, gets bored, and the pipeline gets a permanent exemption. Within a month the scanner is decoration, and, worse, people have learned that its output does not require action, which is a habit that outlasts the tool.

So compare against a baseline and block only on findings the change introduced.

semgrep --config=auto --baseline-commit=origin/main --error

That is a ratchet: the existing debt is recorded and does not block anybody, while nothing new gets added. It converts an unwinnable cleanup into a boundary you can actually hold, and the number goes down over time because people fix things while they are already in the file.

Where each one runs

• Pre-commit: secret scanning only. It must finish in under a second or people disable it, and they will.
• Pull request: semgrep with a baseline, dependency scanning, and the language linter. Minutes, blocking on new findings.
• Nightly or weekly: CodeQL, full dependency inventory, ZAP against staging. Slow things belong on a schedule, not in the path of a change.

What scanners cannot do, by mechanism

Authorisation. Covered earlier and worth repeating because it is the most common serious finding: a tool cannot know who should be allowed to read which record. There is no rule to write.

Business logic. A discount that can be applied twice, a refund that exceeds the payment, a state machine with a path from cancelled back to shipped. All valid code.

Design flaws. Storing something you should never have collected. A token with no expiry. These are correct implementations of a wrong decision.

Anything they have no rule for. Static analysis is a library of known patterns. A novel mistake is invisible by construction.

The failure mode to watch

A noisy scanner is worse than no scanner, and the mechanism is behavioural rather than technical. Each false positive teaches the team that alerts from this tool are usually wrong. After thirty of them, a true positive arrives and gets dismissed in four seconds by somebody who has learned, correctly, what the base rate is.

So tune aggressively. Delete rules that produce noise in your codebase, even good rules, even ones your policy document likes. A small set of rules people believe is worth far more than a comprehensive set people skip.

Do not oversell this

Running these tools does not make generated code safe. It makes a specific, enumerable set of mistakes unlikely, which is valuable and is not the same claim.

The honest framing for a management conversation: these tools handle the mechanical classes so that review time goes to authorisation, business logic and design, which are the classes that actually cause the incidents you will be explaining.