Code security analysis, without drowning in false positives.

Why one tool is not enough

• Each analyser covers a slice: different languages, different defect classes, different blind spots.
• SAST finds defects in your code; SCA finds vulnerabilities in the libraries you use: two different questions.
• Secrets written into the code, infrastructure misconfigurations (IaC), container images: the same tool does not see them.
• Relying on one tool means having one blind spot, as large as everything that tool does not look at.

The real problem: too many results, in too many formats

Day one with five scanners is not security, it is noise.

• Each tool has its own output format: comparing them by hand is work nobody does twice.
• The same defect found by three tools becomes three alerts: the list inflates and trust drops.
• False positives, unfiltered, train the team to ignore everything — the true positive included.
• Without priority, a thousand «medium» alerts bury the three «critical» ones that matter.

How to bring order

1. Normalise: bring every output into one format (the standard is SARIF 2.1.0) so they become comparable.
2. Deduplicate across tools: same line, same defect type (CWE), same rule = one finding, not three.
3. Enrich: for library vulnerabilities add the real CVSS, whether it is in KEV (actually exploited) and whether a fix exists.
4. Prioritise on risk, not volume: first what is critical AND exploitable AND fixable.

Where to wire it in

Analysis that runs once before release is theatre. The one that counts runs on every change.

• In CI (GitHub Actions, GitLab CI): on every push, not every release.
• With an agreed threshold: what blocks the pipeline and what is only a warning, decided beforehand.
• With real triage: assignment, status, SLA — otherwise findings just sit there.
• On executables and container images too, not only source: secrets and vulnerabilities hide there as well.

Costly beliefs