Define "critical" in a patch SLA with at least two inputs: a severity score and evidence of exploitation. A CVSS Base score alone measures severity, not risk. Add a clause that moves any flaw on a known exploited list into the fastest tier, whatever its score, and say who decides when the vendor and you disagree.
Why a score alone is a weak definition
Many contracts say "critical vulnerabilities will be patched within X days" and stop. That sentence hides a fight waiting to happen. The vendor will say a flaw is High, not Critical. You will say it is being exploited. Neither of you wrote down who is right.
The FIRST user guide for CVSS says Base scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk. It points to Threat and Environmental metrics as the way to get closer to risk. So a contract that keys everything to the Base score is keying it to the part of the score that ignores whether anyone is attacking the flaw.
Three inputs worth writing into the clause
| Input | What it tells you | Where it comes from |
|---|---|---|
| Severity score | How bad the flaw is in the abstract | The CVSS Base score on the advisory |
| Known exploitation | Whether attackers use it today | A catalog of exploited vulnerabilities, such as the CISA KEV catalog |
| Exposure | Whether the affected component is reachable from outside | Your own deployment, not the vendor's |
CISA describes its KEV catalog as the authoritative source of vulnerabilities exploited in the wild and tells organizations to use it as an input to their prioritization framework. Naming a public list in the contract gives both sides something neutral to point at.
CISA's directive BOD 26-04, issued in June 2026 for federal civilian agencies, uses four questions: is the asset publicly exposed, is the flaw known to be exploited, can exploitation be automated, and does it give partial or total control. Law firm summaries say a flaw meeting all four gets a three day deadline. The directive does not bind commercial buyers, but the four questions are a reasonable model for your own tiers.
A drafting pattern you can adapt
- State the tiers by name, for example Emergency, High and Routine.
- Put a flaw in Emergency if it is on a named known exploited list, or if the vendor itself has evidence of exploitation, regardless of score.
- Put a flaw in High if the Base score is in the top band and the component is network reachable in the standard deployment.
- Give each tier a deadline for a fix or a documented mitigation, and a separate deadline for telling you.
- Say that the buyer's reasonable evidence of exploitation moves a flaw up a tier, and the vendor may argue it back down only with written technical reasons.
- Say what happens when no fix exists: an interim mitigation, and the right to disable the affected feature.
Do not copy a number from another contract. Deadlines depend on what the product does and how exposed it is. Ask your own engineers what they could realistically deploy.
Common mistakes
- Defining severity by the vendor's own internal rating with no public reference.
- Treating the score as final after the day of disclosure, when exploitation news often arrives later.
- Forgetting that your exposure differs from the default. A flaw in an admin interface you never expose is lower for you, and one in a component you exposed to the internet is higher.
- Writing a deadline for the fix but not for the notice, so you hear about it last.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how the same finding changes priority once exploitability is considered.
Safeguard helps on your side of this clause: reachability analysis shows whether a flaw in software you run is reachable, and policies and gates let you set your own rules for what blocks a release. You can also run the free scan at gold.safeguard.sh/scan on a dependency file or SBOM.
Quick check
Is a CVSS score enough to define critical?
No. FIRST says Base scores measure severity and should not be used alone to assess risk. Add known exploitation and exposure.
Does BOD 26-04 apply to my company?
It applies to federal civilian agency systems and does not directly cover contractors or commercial buyers. You can borrow its questions as a model.
Sources
- FIRST CVSS v4.0 user guide
- CISA Known Exploited Vulnerabilities Catalog
- Wiley: CISA directive highlights risk based vulnerability management
Last reviewed: 19 October 2026.
