A misconfiguration has no CVSS, which is why nobody fixes it

A vulnerability arrives with paperwork. It has a CVE identifier, an NVD entry, a CVSS vector somebody argued about, and a published date. Whatever you think of CVSS, and there is plenty to think, it means two organizations scoring the same flaw land in roughly the same place.

A misconfiguration has none of that.

A privileged Kubernetes pod, a security group open to 0.0.0.0/0, a storage bucket that is public, a container running as root: no identifier, no NVD entry, no score anyone else computed. Every tool that reports these invents its own severity, and the inventions do not agree.

That single fact explains most of why misconfiguration findings get ignored.

What happens in a mixed list#

Put both kinds in one report sorted by severity, which is what almost every tool does, and the CVEs win. They arrive pre-labeled CRITICAL by an authority, and the misconfigurations arrive labeled HIGH by the scanner that found them.

So the list you work down looks like this:

1. A critical CVE in a transitive dependency, in a code path your application never calls.
2. Another one, same package, different year.
3. …

and somewhere below the fold:

Pod runs privileged with hostPath mounted at /

The second one is a container escape. The first two are theoretical unless something reaches them. The sort order says otherwise, because the sort order is a number's opinion of itself.

Nobody decided this. It is what happens when you rank two categories by a scale only one of them was designed for.

Misconfigurations are worse in one specific way#

They are almost always directly exploitable, without a chain.

A dependency CVE usually needs several things to be true: the vulnerable function must be reachable, the input must be attacker-controlled, the deployment must expose the path. Serious work has gone into reachability analysis precisely because most dependency findings fail one of those tests.

A public bucket is public. A security group open to the internet is open to the internet. There is no chain to establish and no reachability question to answer, the condition and the exposure are the same fact.

That does not make every misconfiguration urgent. It does mean the ones that matter are more often immediately true than a CVE at the same nominal severity.

The other reason they get skipped#

They are in somebody else's file.

A dependency CVE is fixed by bumping a version, and the person who reads the finding usually owns the manifest. A misconfiguration is in Terraform, a Helm chart, a Kubernetes manifest. Files that frequently belong to a platform team, in a different repository, on a different schedule.

The finding surfaces in an application pipeline and the fix lives elsewhere. So it gets noted, not actioned, and next month it is noted again.

This is an organizational problem wearing a technical costume, and it is worth naming as such rather than hoping better tooling dissolves it. What tooling can do is stop pretending the finding belongs to whoever happened to run the scan.

What to rank them by instead#

Since severity is not comparable across the two categories, use something that is.

Exposure. A privileged pod in an internet-facing namespace and the same pod in an isolated batch cluster are not the same finding. Nothing in the manifest says which you have. Somebody has to declare it, and once declared, it ranks both categories on the same axis, because "how much does it matter that this is wrong here" applies equally to a CVE and a misconfiguration.

Whether it is presently true. A misconfiguration is a state, not a possibility. That deserves weight against a CVE whose exploitability is conditional.

Who can fix it. Not a severity input, but the thing that determines whether anything happens. A finding routed to the team that owns the file gets fixed; the same finding in a report nobody in that team reads does not, whatever its score.

What this means for a gate#

If you gate a build on severity alone, you will either block on unreachable dependency CVEs or you will set the threshold high enough that the privileged pod sails through. Both are common and both are the same mistake.

The alternative is to gate on a band that already folds in context. Draugr ranks every finding into P1–P4 from the severity and the component's declared exposure and criticality, so a misconfiguration on an internet-facing service outranks a medium CVE on an internal tool, which is the order somebody would have chosen by hand, applied consistently.

Draugr's iac control runs Trivy over Terraform, Kubernetes manifests, Dockerfiles and Helm, and reports per-check severity as the scanner gives it. What changes the ordering is not a different scanner; it is the context the descriptor adds, which no scanner has access to.

The IaC guide covers what these tools check for and where they are weak, and vulnerability prioritization covers the ranking argument in full.