← All articles

You don't need twelve scanners, just the four that apply

August 7, 2026 · Wilson Santos
devsecopsappsecprioritizationsastscaiac
On this page

There are two common ways teams adopt security tooling, and they fail the same way.

Nothing

Until an incident or a customer questionnaire forces it, at which point the decision gets made under time pressure by whoever is available.

Everything

Twelve scanners wired in over a fortnight, four hundred findings, an eleven-minute pipeline, and a gate disabled within the month.

Both skip the same step. Nobody worked out which controls the thing they build requires.

Controls come from what you have, not from a list

The useful question is not "which security tools should we run" but "what is this software made of". The answer determines the controls, and it is usually shorter than expected.

If you haveYou need
Source code you wroteSAST
Third-party dependenciesSCA
A git historySecret detection
Container imagesImage scanning
Terraform, Kubernetes manifests, a DockerfileIaC / misconfiguration
A public HTTP endpointHeaders, TLS, and maybe DAST
A Kubernetes cluster you operateInfrastructure / CIS
Customers who ask what you shipSBOM, licenses

Every team has the first three. That is the floor, and it is three controls, not twelve.

The rest depend on facts about your software that you already know, and on facts a scanner cannot discover for itself. A tool pointed at a repository cannot tell whether the resulting service faces the internet or runs nightly on an internal schedule.

Why "everything at once" fails specifically

Not because the tools are bad. Because the findings arrive without an order.

Twelve scanners produce output in twelve formats with twelve severity scales, none comparable.

Five scales, one list, no order A dependency scanner reports a CVSS score, a static analysis tool reports its own ERROR and WARNING levels, a secret scanner reports every finding at one level, a misconfiguration scanner invents a severity because there is no CVE to carry one, and a license check reports a policy decision rather than a severity at all. Merged into a single list, the sort order is arbitrary. WHAT EACH SCANNER CALLS SERIOUS sca sast secrets iac licenses a CVSS score, 7.5 its own word, ERROR no scale at all a severity it invented a policy decision ONE LIST, 400 ROWS Sorted by a number that means something different on every row. A thirteenth scanner adds rows to this. It does not add an order. The problem was never coverage, so the fix is never another scanner.
A high from one tool is not a high from another, and a misconfiguration has no CVSS at all. Merged without a common scale, the ordering is arbitrary, and an arbitrary list of four hundred things does not get worked.

An arbitrary list of four hundred things is not actionable, so it does not get actioned, and the tools get blamed for the absence of a decision that was never made.

Adding a thirteenth scanner does not help. The problem is not coverage.

What orders the list

Two things, and only one is in the code.

Severity

How bad this class of problem is in the abstract. Every scanner computes it, it is the input everyone starts with, and it knows nothing about you.

Exposure and criticality

Whether the service is reachable from the internet, holds customer data, or would be missed in an outage. Not in the source, the image or the manifest. It is the difference between the same CVE being urgent and being a backlog item.

That is why declaring what your software is turns out to matter more than adding tools. The declaration is what makes ordering possible, and ordering is what makes a long list survivable.

A reasonable order to start in

If you are starting from nothing, roughly this:

ControlWhy here
1Secret detectionfastest, most precise, and the only finding that gets categorically worse with time
2SCAthe highest ratio of real findings to effort. The dependency tree is where most known vulnerabilities live
3SAST, scoped to changed filesso it is fast enough to read
4IaC, if you have infrastructure filescheap, and the findings are usually directly exploitable rather than theoretical
5Everything elseonce the first four produce a list somebody reads

The last step is the one that gets skipped, and it is the only one that matters. A control nobody reads is not a control.

The short version

The number of scanners is not the metric. What matters is whether the output is ordered, whether somebody reads it, and whether the ordering reflects your situation rather than a scale that knows nothing about you.

Draugr's premise is that you declare what your software is made of, repositories, images, endpoints, infrastructure, and it works out which controls apply, runs them, and merges the result into one ranked answer. Not because orchestration is interesting, but because the declaration is what makes the ranking possible.

It also means the gap between the two is visible. A component that lists images while nothing is set to look at them produces a clean pass over something nobody opened, the failure this whole argument is about, arrived at from the other direction. draugr doctor names it before the scan runs, and --fail-on-uncovered makes it a failing step for a description that is meant to be complete:

NOT CHECKED
  Component  Surface  Controls off
  api        images   images

Deciding a control does not apply to you is a decision. Never noticing it was available is not.

The security controls landscape covers each control in plain language, and when everything is critical, nothing is covers the ranking argument.