You don't need twelve scanners, you need to know which four apply

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

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

Everything, all at once: twelve scanners wired in over a fortnight, four hundred findings, a pipeline that takes eleven minutes, and a gate that gets 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 have	You need
Source code you wrote	SAST
Third-party dependencies	SCA
A git history	Secret detection
Container images	Image scanning
Terraform, Kubernetes manifests, a Dockerfile	IaC / misconfiguration
A public HTTP endpoint	Headers, TLS, and maybe DAST
A Kubernetes cluster you operate	Infrastructure / CIS
Customers who ask what you ship	SBOM, 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. A "high" from one is not a "high" from another; a misconfiguration has no CVSS at all. Merged into one list, the ordering is arbitrary, and 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 describes a flaw in the abstract: how bad is this class of problem. Scanners can compute it, and it is the input everyone starts with.

Exposure and criticality describe your situation: is this service reachable from the internet, does it hold customer data, would an outage be noticed. No scanner can determine any of that. It is not in the source, the image or the manifest. It exists in somebody's head, and 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:

1. Secret detection. Fastest, most precise, and the only finding that gets categorically worse with time.
2. SCA. Highest ratio of real findings to effort. The dependency tree is where most known vulnerabilities live.
3. SAST, scoped to changed files, so it is fast enough to read.
4. IaC, if you have infrastructure files. Cheap, and the findings are usually directly exploitable rather than theoretical.
5. Everything else, once the first four are producing 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:
      api declares images, and images is not enabled

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.