Rank misconfigurations by the same questions as CVEs: is it exposed, what can an attacker reach, and is it being abused. A public storage bucket holding customer data can deserve a faster deadline than a high severity library bug. Use one risk scale for both, and different fixes for each.
What is different
A CVE is a flaw in a product, fixed by a vendor patch. A misconfiguration is a choice in how something is set up: an open port, a permissive role, a public bucket, a default password. No patch exists and no severity score arrives with it. (See CVE scan vs misconfiguration scan.)
So teams often keep two queues with two rulebooks, and the misconfiguration queue gets no deadlines at all.
One scale, two kinds of fix
Use the same tiers for both and map each finding to a tier by risk.
| Question | CVE example | Misconfiguration example |
|---|---|---|
| Is it exposed? | Library on an internet facing API | Management port open to the internet |
| What can an attacker reach? | Remote code execution in a service | Role that allows reading all storage |
| Is it known to be abused? | Listed as exploited | Open storage that anyone can find |
| Is a fix simple? | Version bump | One setting change |
If the answer pattern is the same, the deadline should be the same.
Why misconfigurations can be urgent
Many misconfigurations need no exploit at all. The access is simply allowed. An attacker who finds an open resource does not need to bypass anything. For this reason, exposure is the dominant signal.
On the other side, many misconfigurations are cheap to fix. A one line change that removes public access should happen fast, and delaying it for a monthly cycle is hard to justify.
Set deadlines in tiers
- Urgent: public exposure of sensitive data or administrative access. Same emergency path as an exploited CVE.
- High: broad internal permissions, missing encryption on important data, disabled logging on key systems.
- Standard: hardening gaps and defense in depth items.
- Low: cosmetic or documentation level issues.
Prevent recurrence
Unlike a CVE, a misconfiguration can be blocked at the source. Check infrastructure as code in review, enforce policies in the pipeline, and detect drift from the declared state. A rule that stops a public bucket from being created is better than a ticket after it appears.
Exceptions still apply
Some misconfigurations are deliberate, such as a public website bucket. Record them as exceptions with an owner, a reason, and an expiry date, so that a scanner flag has a documented answer.
Quick check
Do misconfigurations need CVSS scores?
No. Rank them by exposure, reach, and abuse likelihood using the same tier scale.
Who should own misconfiguration fixes?
The team that owns the resource, with the platform team providing guardrails that prevent common mistakes.
Safeguard's policies, gates and guardrails can be used to enforce rules like these before changes ship, and a free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
