ATALAIAAdding SAST, dependency, secrets and infrastructure scanners to a pipeline takes an afternoon. The trouble starts the following week, when every pull request shows two hundred findings, most of them years old, and the build fails on something the author did not touch. Developers learn to scroll past the comments, then to re-run until green, then to ask for the check to be made optional.
Our position is simple: a scanner that is ignored provides less security than a smaller scanner that is read. The goal is not maximum findings. It is the right findings, in front of the right person, at the moment they can fix them.
Why scanning programmes drown
Three patterns show up again and again:
- History on every PR. Old findings are reported against new work, so the author pays for debt they did not create.
- Everything blocks. Medium and low findings fail the build, so the gate means nothing and gets bypassed.
- Duplicates and unreachable code. The same vulnerable library is reported per manifest, per image and per service, often in paths that never run.
None of these is a tooling problem. They are policy decisions that were never made.
Put findings where the fix happens
Before tuning any scanner, decide where its output lands. A finding in changed code belongs as an inline comment on the pull request, next to the line, written so the author can act on it without opening another tool. A finding in old code belongs in the owning team's backlog, grouped by service. A finding nobody owns belongs nowhere until someone does, which is a prompt to fix ownership rather than to file more tickets.
Deduplicate before anything reaches a person. One vulnerable library used by ten services is one decision about one upgrade, not ten tickets. Prefer reachability and fix availability over raw severity when ordering the backlog, and say so in the comment, so developers can see why an item is ranked where it is.
Baseline the backlog, then own it
Take a snapshot of what exists today and stop reporting it on pull requests. That backlog does not disappear: it becomes a list with an owner and a schedule, worked like any other technical debt. New code, meanwhile, is judged only on what it introduces.
# Gitleaks: record today's findings, then report only new ones
gitleaks git --report-path gitleaks-baseline.json
gitleaks git --baseline-path gitleaks-baseline.jsonThe baseline is a starting line, not an amnesty. Review it, triage the worst of it in the first month, and shrink it every quarter.
Scan the diff, sweep the rest
On pull requests, report findings in changed code only. Most open-source scanners support this directly:
# Semgrep: only findings not present on main
semgrep scan --config auto --baseline-commit origin/main --error
# Gitleaks: only commits in this branch
gitleaks git --log-opts="origin/main..HEAD"Full-repository scans still run, nightly or weekly, and feed the backlog rather than a pull request. That split matters. The pull request is a conversation with one developer about their change. The scheduled scan is a conversation with a team about their service.
Gate on a narrow set
Agree, in writing, what blocks a merge. Keep the list short enough that every block is worth stopping for:
| Scanner | Blocks the merge | Reports only |
|---|---|---|
| Secrets | Any verified or high-confidence new secret | Test fixtures, low-entropy matches |
| SAST | High-confidence injection, auth or crypto rules | Style and low-confidence rules |
| SCA | Critical or high, with a fix available | Unfixed, low, dev-only |
| IaC | Public storage, open admin ports, wildcard IAM | Tagging and hygiene checks |
trivy fs --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 .
trivy config --severity HIGH,CRITICAL --exit-code 1 ./infraEvery suppression needs a reason and an expiry date in the code, so it is reviewable. A suppression with no reason is just a quieter bypass.
What we would do
- Turn every scanner to report-only for two weeks and measure the volume per pull request.
- Write the gate table above for your organisation and agree it with engineering leads, not just security.
- Baseline existing findings, assign each repository's backlog to its owning team, and set a quarterly target.
- Switch pull request scans to diff-only, then switch on blocking for the agreed rules.
- Review the false-positive rate monthly and remove rules that nobody acts on.
The measure of success is not the number of findings. It is whether developers read the comment, fix the issue and merge, without asking security to make it go away.