A misconfiguration has no CVSS, which is why nobody fixes it
On this page
A vulnerability arrives with paperwork. A misconfiguration arrives with none.
A vulnerability brings
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 brings
A privileged Kubernetes pod, a security group open to 0.0.0.0/0, a public storage bucket, a container running as root. No identifier, no NVD entry, and no score anyone else computed.
So every tool that reports one 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 puts the theoretical first and the container escape below the fold.
The pod is a container escape. The CVEs above it 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
Needs several things to be true at once: the vulnerable function reachable, the input attacker-controlled, the deployment exposing the path. Serious work has gone into reachability analysis precisely because most dependency findings fail one of those tests.
A misconfiguration
A public bucket is public. A security group open to the internet is open to the internet. No chain to establish and no reachability question to answer, because 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.
Naming it as such beats 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, so somebody declares it. Once declared it ranks both categories on one 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 rather than a possibility. That deserves weight against a CVE whose exploitability is conditional on a chain nobody has established.
Who can fix it
Not a severity input, and 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 on 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.