How to Keep a Contract Promise of No Known Exploited Vulnerabilities

To meet a contract that says "no known exploited vulnerabilities", first pin the words down: a CVE listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, present in a component you actually ship, and affecting that shipped version, measured on delivery day and fixed within an agreed window afterwards. Then build a release gate that checks every artifact against the catalog, a documented exception and VEX path for components that are present but not affected, and a watch job that catches catalog additions between releases.

The clause is fair because it is measurable, and dangerous for the same reason: your customer can download the catalog, scan your SBOM, and find a match you missed. This post walks the problem end to end for a product security lead or CTO whose bank, health or federal customer has added the clause, then shows how Safeguard handles the job.

Key takeaways

• The KEV catalog is CISA's list of CVEs with reliable evidence of exploitation in the wild. On 23 October 2026 the JSON feed held 1,756 entries, catalog version 2026.10.23.
• BOD 26-04 (10 June 2026) revoked BOD 22-01 and BOD 19-02. It binds federal civilian agencies, not vendors, unless the procurement contract says otherwise. Your customer's clause is how it reaches you.
• Since BOD 26-04, new catalog entries carry due dates 3 or 14 days after listing. Those dates are written for agencies; do not copy them into a vendor contract.
• Define "present", "affecting" and "window" in the clause, and name VEX as the accepted not affected path.
• Gate every release artifact, keep a named, time limited override path, and treat KEV as a floor, with EPSS for what is not yet listed.
• Safeguard capabilities covered, with maturity labels: SCA and vulnerability management with CISA KEV and EPSS enrichment (GA); reachability analysis (GA); the CISA KEV Correlation framework in the compliance suite (GA); policies and gates with Block, Warn and Notify actions (GA); AI Remediate fix pull requests and autonomous remediation (GA, ships switched off with every category set to Manual); CSAF and VEX upload (GA); Portal SBOM sharing (GA); Trust Center (GA); the CLI and MCP server (GA); Gold Open Source (GA); fork and patch (GA).

Why a KEV clause is both fair and dangerous

Most security clauses are written in soft words like "industry standard" or "promptly" that nobody can test. A KEV clause points at a list a third party maintains and publishes as JSON. A customer's vendor risk team can test your compliance on any afternoon with free tools. That also helps you: you know exactly which identifiers matter, you can automate the check, and you can keep evidence that it ran.

The danger sits in three places.

The list moves. CISA adds entries as it confirms exploitation, including old CVEs. A release that was clean on Monday can contain a listed component on Thursday without a line of your code changing.

The words are loose. "Contains no known exploited vulnerabilities" can be read to cover a transitive dependency your code never calls, a test library that does not ship, a base image package, or a release you stopped supporting years ago. If the clause does not say, it will be read the widest way at the worst moment.

The window is borrowed. The catalog prints a due date on every entry, written for federal agencies patching their own systems. "Remediate within the timeframe specified by CISA" signs you up to a schedule written for a different job, and since BOD 26-04 that schedule is often three days.

What is the CISA KEV catalog, and how often does it change?

The catalog lives at cisa.gov and is published as a web table, a CSV file and a JSON feed. Each entry carries a CVE ID, the vendor and product, a short description, the date CISA added it, a required action, a due date, a flag for known ransomware campaign use, the related CWE identifiers, notes with links to advisories, and, since BOD 26-04, a field that says whether forensic triage is required.

What gets an entry listed

CISA's criteria page, updated to reference BOD 26-04, sets three thresholds for adding a vulnerability:

1. It has an assigned CVE ID.
2. There is reliable evidence it has been actively exploited in the wild.
3. There is a clear remediation action, such as a vendor update.

The BOD 26-04 implementation guidance repeats these and adds a fourth condition in its FAQ: the vulnerability carries significant risk to US government information systems. The two pages word this differently, so if your clause quotes CISA's criteria, quote the page you mean and the date you read it.

Three details matter for a vendor contract. "Exploitable" is not the test: a public proof of concept or security research alone does not list an entry, while reliable evidence of malicious code run without the owner's permission does, including attempts against a honeypot. Age does not matter: CISA says adding an older CVE does not mean it is seeing exploitation right now, and 21 of the entries added in 2026 carry a CVE year of 2020 or earlier. And entries are rarely removed, only for an error or a harmful vendor update, so treat the catalog as append only.

How often it changes

CISA's implementation guidance says it aims to update the catalog within 24 hours of identifying a new in-scope vulnerability, and lists reasons additions can be delayed. Counting the JSON feed by year of addition gives a sense of pace:

Monthly additions in 2026 ranged from 17 in January to 43 in September, and they arrive in bursts. Any day can bring an addition that matches something you have shipped. A related post looks at how big the KEV watch job really is.

What the due dates mean, and who they bind

BOD 22-01 created the catalog in November 2021 and required federal civilian agencies to remediate listed vulnerabilities by the due date. CISA revoked BOD 22-01 on 10 June 2026 when it issued BOD 26-04, "Prioritizing Security Updates Based on Risk", which also revoked BOD 19-02. Cite BOD 26-04 in anything you write today; mention BOD 22-01 only as history.

BOD 26-04 keeps the catalog and its criteria, but it no longer gives every listed vulnerability the same clock. The remediation timeline for each asset depends on four variables: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether an adversary can automate exploitation, and whether exploitation gives partial or total control. The directive's Table 1 maps those answers to timelines, and it adds forensic triage for the most urgent case. The directive's own text says the "& forensic triage" case means the agency must complete remediation or mitigation within three days and assess whether the system was compromised.

Two lines in the directive matter directly to a vendor. The first: "Unless directed by the governing procurement contract, this Directive does not apply to contractors". The second sits in the implementation guidance: CISA "strongly recommends" that agencies put appropriate remediation timelines into service level agreements or contracts with their service providers. In other words, the clause your federal customer just added is the mechanism BOD 26-04 expects agencies to use. Bank and health customers are copying the idea because the list is public and easy to test.

What do the printed due dates look like now? Of the 139 entries added between 10 June and 23 October 2026, 113 carry a due date 3 days after the date added and 26 carry a date 14 days after. All 91 entries in the feed flagged for forensic triage carry a 3 day due date. Before BOD 26-04, the most common gap was 21 days.

The required action text on new entries now tells stakeholders to evaluate each asset's internet exposure and follow BOD 26-04 timelines. The due date is one date per CVE; the directive's timeline is per asset. Neither was written for a vendor's release train, which is the main reason not to sign "within the timeframe specified by CISA".

How should the clause define "present", "affecting" and the remediation window?

Everything in this section is illustrative and is not legal advice. Contract language belongs to your counsel and your customer's. The point here is to give your engineers and lawyers a shared list of words that need a definition, so the clause describes something you can measure.

"Known exploited vulnerability"

Name the list, the identifier and the moment. A KEV entry is identified by its CVE ID. A clause that says "a vulnerability listed in the CISA Known Exploited Vulnerabilities catalog, identified by CVE ID, as published on the date of the relevant event" gives both sides one source to check and a timestamp to check it at. Without the date, a dispute about a release made in March can be argued against a catalog downloaded in September.

If the customer wants to include other exploitation lists, agree which ones by name. "Any publicly known exploited vulnerability" has no single source and cannot be tested consistently.

"Present"

Present should mean included in a deliverable you ship: an installer, a container image, a package, firmware, or the code running in a hosted service you operate. Write down what is out of scope, such as build tools, test dependencies and third party services the customer contracts for directly. Say whether base image operating system packages are in scope; they usually should be, because the customer runs them.

Tie "present" to your SBOM: a component is present if it appears in that release's SBOM. Both sides then scan the same inventory.

"Affecting"

A component can be present without the vulnerability affecting the product: the vulnerable function may be compiled out, never called, unreachable from attacker input, or blocked by a built in protection. The clause should say a present but not affected component is not a breach, as long as you document why in an agreed format. VEX is that format. Expect the customer to want limits: a standard justification, specific to the product version, issued by a named role, with supporting detail on request.

The remediation window

There are two promises hiding in one clause, and they need different words.

At delivery. The release you hand over contains no present and affecting KEV listed component, checked against the catalog as of a stated time before delivery, for example the start of the release day. This is the promise you can keep absolutely, because you control when you ship.

After delivery. When CISA adds an entry that affects a release the customer is running, you will notify them within a set time, provide a fix or mitigation within a set time, and in the meantime say what they can do. This is where the window lives. Base it on your own release process, not on the federal table. A team that can cut a patch release in two days can promise five business days for a fix where an upstream fix exists. A team with a quarterly release train cannot, and should not pretend to.

Also say what happens when no fix exists upstream. KEV's third criterion requires a clear remediation action, but that action can be a vendor mitigation rather than a fixed version, and the "vendor" may be an open source project with no release yet. The clause needs a path for "no fixed version available": a documented mitigation, a workaround, and a commitment to ship the fix within a set time after one becomes available.

Illustrative clause comparison

The table below contrasts wording that is hard to test with wording that names the moving parts. It is illustrative, not legal advice; your counsel decides what goes in a contract.

An illustrative clause, again not legal advice, might read:

ILLUSTRATIVE ONLY. NOT LEGAL ADVICE. Agree final wording with counsel.

1. Definitions. "KEV" means a vulnerability, identified by CVE ID,
   listed in the CISA Known Exploited Vulnerabilities catalog as
   published at the relevant time. A KEV is "Present" in a Release if
   the affected component appears in the SBOM delivered with that
   Release. A Present KEV is "Affecting" unless Supplier has issued a
   VEX statement with status not_affected and a standard justification
   for that Release.

2. At delivery. Supplier will not deliver a Release that contains a
   Present and Affecting KEV, assessed against the catalog no earlier
   than 24 hours before delivery, unless Customer has agreed a written
   exception.

3. After delivery. If a KEV listed after delivery is Present and
   Affecting in a supported Release, Supplier will (a) notify Customer
   within [N] business days of the listing, (b) provide a mitigation
   or a fixed Release within [M] business days of a fixed upstream
   version being available, and (c) where no fix exists, provide a
   documented mitigation within [P] business days.

4. Evidence. On request, Supplier will provide the SBOM, the release
   gate record and any VEX statements for a supported Release.

The bracketed numbers are deliberately blank: set them from what your release process can actually deliver.

How do you show a listed component does not affect your product?

VEX, short for Vulnerability Exploitability eXchange, is a machine readable statement that a product is or is not affected by a vulnerability. CISA's "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)", published in April 2023, sets out what a statement must contain. It is the right reference to name in a contract because it is format neutral: CycloneDX VEX, OpenVEX and the CSAF VEX profile can all carry the same fields.

What a not_affected statement must say

Under CISA's minimum requirements, each VEX statement carries one status for one vulnerability and one or more products. The status is one of four values: not_affected, affected, fixed or under_investigation.

For not_affected, the document says a statement should give a justification, and if it does not, it must give an impact statement explaining why. The justification must be one of five values:

For affected, the statement must include an action statement telling the reader what to do. That matters for the "after delivery" half of the clause: an affected statement with an action statement is how you tell a customer about a mitigation while the fix is in progress.

CISA's document also says VEX does not imply any default status. Silence is not "not affected". If your customer's scanner flags a KEV entry and you have no VEX statement for that release, the customer is entitled to treat it as affected.

Getting the customer to accept it

A VEX statement only helps if the customer agrees in advance that it counts. Put that in the clause, then make the statements easy to trust:

1. Tie each statement to a product version. "Our product" without a version fails the first time a new release ships.
2. Use the strongest justification you can prove. component_not_present and vulnerable_code_not_present are easy to verify against an SBOM and a build configuration. Execute path claims depend on call graph analysis, so keep the output. Inline mitigation claims are the hardest to defend.
3. Name who signs, and re-check every statement on every release, because an unused code path can become a used one.
4. Deliver it where the customer looks, alongside the SBOM with the same version identifier.

Expect customers to accept the first two justifications freely, ask for evidence on execute path claims, and push back on inline mitigation claims for KEV entries. Agree that in the clause, not during an incident.

How do you block a release that contains a KEV-listed component?

The release gate is where the "at delivery" promise is kept. It does not need any particular product to work, and it is worth understanding the method before choosing tools.

The method, with any tools

1. Produce an SBOM for each deliverable. Not for the repository: for the thing you ship. A container image built from a clean repository can still carry an operating system package with a listed CVE. Generate the SBOM from the built artifact, store it with the release, and give it the same version identifier.
2. Match components to CVEs. The catalog lists CVE IDs, not package versions. Your vulnerability scanner does the mapping from component and version to CVE. Its quality decides whether the gate works: missing ecosystems, wrong version ranges and unidentified components all leak through.
3. Intersect with the catalog. Download the catalog JSON fresh on every gate run, and intersect its CVE IDs with the CVEs your scanner reports.
4. Subtract accepted VEX statements. Remove CVEs for which a current not_affected statement exists for this release.
5. Fail on anything left. If the remainder is not empty, the release does not ship.
6. Record the result. Release ID, artifact digest, catalog version, scanner version, the remainder, the decision and the time. That record is your evidence.

The catalog part is plain enough to show. This pulls the current list of KEV CVE IDs and its version stamp from CISA's public feed:

curl -fsSL https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  -o kev.json
jq -r '.catalogVersion' kev.json
jq -r '.vulnerabilities[].cveID' kev.json | sort -u > kev-ids.txt

Intersecting it with your scanner's output depends on that scanner's JSON shape. If you have a sorted list of CVE IDs found in a release in found-ids.txt, the matches are comm -12 kev-ids.txt found-ids.txt. Record catalogVersion in the gate record so you can later show which version of the list you checked against.

What makes a gate fail open

Most gate failures are gates that pass when they should not: a scan times out and the job continues on error, a failed catalog download is read as "nothing matched", the repository is scanned but a later image ships, or an emergency skip flag is never removed. Make every error, timeout and missing catalog a failure. A gate that fails open is worse than none, because it produces evidence that says you checked.

The override path

One day the gate will block a release you must ship: an outage fix is ready, and an unrelated transitive dependency has just been listed with no fixed version. Decide the override path before that day.

A defensible override has a named approver, a written reason, the specific CVE and component, an expiry date, and a customer notification if the clause requires one. Keep the failed gate result on file next to it. If the clause needs the customer's written agreement for exceptions, separate "ship a fix that does not make things worse", usually acceptable with notice, from "ship new features past a listed CVE", which usually is not.

What happens when a KEV entry lands between releases?

The at-delivery promise is the easy half. The hard half is a catalog addition that matches a release your customer already runs.

Know what you have shipped, and watch the catalog

Rescanning main tells you about the next release, not the versions customers run. Keep an SBOM per release, per deliverable, for as long as the release is supported, and run the KEV intersection against all of them whenever the catalog changes, or at least daily. CISA offers email alerts for additions, and the JSON feed carries dateReleased and catalogVersion stamps you can poll.

A between-releases playbook

1. Confirm the match. Scanner false positives are common for similarly named packages and backported fixes.
2. Decide affected or not affected, using the five VEX justifications as the checklist. If not affected, send the VEX statement.
3. If affected, notify within the clause's window, using an affected VEX statement with an action statement.
4. Find the fix path: a fixed upstream version, a backport, a mitigation, or a vendored patch.
5. Ship a patch release through the same gate, then update the VEX statement to fixed and deliver the new SBOM.

Hosted services are different

If you operate the software for the customer, the clause can promise remediation of the running service rather than delivery of a release. That is often easier to meet, but your production inventory, not just your build pipeline, has to be scanned.

How do EPSS and severity fit around the KEV promise?

KEV is a short list of confirmed exploitation. It does not tell you about the much larger set of vulnerabilities that are likely to be exploited soon, and it is not meant to. CISA's implementation guidance says plainly that KEV is not the only list agencies need to worry about and that they should track and prioritise all vulnerabilities.

EPSS for "not yet listed"

FIRST's Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the wild in the next 30 days. FIRST publishes a score between 0 and 1, with a percentile, for every CVE every day, free through CSV, API and a public repository. EPSS fits in front of the KEV promise: a high EPSS score on a component you ship is a reason to fix it before it is listed, so the listing never becomes a breach. Our post on EPSS in the days before a KEV addition looks at that lead time in 2026 data.

Do not put EPSS thresholds in the contract: the score is a probability that moves daily. Use it internally to decide what to fix first.

SSVC for deciding urgency

CISA's Stakeholder-Specific Vulnerability Categorization, built with Carnegie Mellon's Software Engineering Institute, sorts vulnerabilities into four decisions: Track, Track*, Attend and Act. CISA's tree uses exploitation status, technical impact, automatability, mission prevalence and public well-being impact. BOD 26-04's Table 1 is informed by SSVC, and the implementation guidance notes that by revoking BOD 19-02, federal civilian agencies no longer need CVSS for vulnerability prioritisation.

For a vendor, that gives a sensible internal ladder: KEV and present and affecting means fix now, whatever CVSS says; high EPSS or high technical impact with automatable exploitation means fix in the next release; everything else follows your normal severity policy. CVSS severity still has a place, because many customer contracts and frameworks reference it. PCI DSS v4.0, for example, sets a one month window for critical security patches, which our PCI DSS 6.3.3 post covers.

Patch management as routine work

NIST SP 800-40 Rev. 4, "Guide to Enterprise Patch Management Planning", frames patching as preventive maintenance and a cost of doing business. The lesson carries to vendors: a team that ships routine dependency updates every week has fewer KEV emergencies, because many components are upgraded before they are listed. A related post asks whether an old KEV entry is as urgent as a new one.

What to promise and what never to promise

This table is illustrative and not legal advice. It reflects what an engineering team can actually deliver and evidence.

Look hard at any indemnity or termination rights attached to the clause; engineering supplies the facts, counsel decides the liability. Our post on contract clauses banks expect from software vendors covers the wider set.

How Safeguard does this job

Everything above can be done with open source tools and a disciplined team. Safeguard puts the inventory, the KEV matching, the gate, the fixes and the evidence in one place. The steps below follow Safeguard's own documentation; where a screen or a behaviour is not documented, the step says so.

Step by step

1. Scan every repository from CI (SCA, GA; CLI, GA). Create a secret key under Settings › Developer with the scopes scans:trigger and scans:read, store it in your CI as SAFEGUARD_API_KEY, and add the step from your CI's setup guide. The docs say one step runs safeguard ci scan and each push becomes a new version of the Safeguard project, named after the branch and commit. There is no plugin to install; the CLI runs in a plain shell step on a Linux or macOS runner. For self-hosted or firewalled Git servers, safeguard ci scan --local scans dependencies on the runner and sends only the results.

2. Scan the artifact you ship, not just the repository (GA). The CI docs point to a separate guide for scanning the container images your pipeline builds, per environment. Use it for every image you deliver. SCA covers the full transitive tree plus container layers, and SBOM generation in SPDX and CycloneDX is GA.

3. Read KEV status on the Vulnerabilities tab (vulnerability management with KEV and EPSS, GA). Safeguard's docs list CISA KEV among its data sources, alongside NVD, GitHub Security Advisories, OSV and vendor bulletins. The Vulnerabilities tab groups findings into Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation in the wild. Each finding shows CVE ID, CVSS, EPSS, exploited status, affected component and version, fixed version and reachability. Filter by exploitable status, EPSS range, fix availability and reachability status (reachability analysis is GA).

4. Turn on the CISA KEV Correlation framework (compliance suite, GA). Under the compliance suite's internal frameworks, CISA KEV Correlation checks components against the KEV catalog. The docs say it is on in your workspace unless you switch it off in Compliance › Manage. Its scan requirement, KEV-1 "No Actively Exploited Vulnerabilities", is decided by each scan: it passes when no component matched a KEV entry. The framework's Controls tab adds controls such as Remediation Due-Date Tracking, Patch SLA Compliance, KEV Exception Process, KEV Feed Freshness and Post-Patch Verification, and it ships policy templates written for KEV, including a CISA KEV Response SLA Policy and a KEV Exception and Risk Acceptance Policy. This is where the contract promise becomes a control you can show a customer's auditor.

5. Build a release gate (policies and gates, GA). Create a policy under Settings › Policies, then link it to a gate. Each policy has one Action: Block fails the gate, Warn lets it pass with a warning naming the policy, and Notify lets it pass and sends a notification to your configured channels. Two cautions from the docs. First, policy outcomes are turned on per workspace by Safeguard and are off until then; if you do not see an Outcome column on the Gates and Policies tables, ask your Safeguard contact to turn it on. Second, KEV and reachability appear in the docs as filters on the Vulnerabilities tab, not as documented policy conditions. The policy builder's documented conditions are severity, CVSS score, EPSS score, license, component age, maintenance and SLSA level. Confirm with Safeguard how to express "KEV listed" in a gate policy before you write a rule that a contract depends on.

6. Fail the CI job on the gate. With policy outcomes on, the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   It waits for the scan and for the gate's policies to be evaluated on the new data. It exits 0 when the gate is Passed or Warning, and non zero when the gate is Failed, Error or Not evaluated, or its policies were not evaluated before --timeout. That fail-closed behaviour on errors is what the clause needs. --fail-on <severity> still works and can be combined with it, for example --fail-on critical as a severity floor while the KEV gate policy is being confirmed.

7. Use the override path the docs describe. For a legitimate exception, a developer clicks Request Exception, selects the policy and finding, gives a business justification, sets an expiration date and submits it for approval. Approvers are notified, decide, and an audit trail is recorded. On the Vulnerabilities tab, Accept Risk also takes an expiry date and a justification, and Mark False Positive takes a justification and can require approval by policy. Map these to the clause: an exception that the contract requires the customer to agree should not be approved internally alone.

8. Fix with pull requests (AI Remediate and autonomous remediation, GA, ships switched off). From a finding, AI Remediate analyses the vulnerability, picks an upgrade path, checks for breaking changes, opens a pull request and runs tests if configured. Bulk AI Remediate opens one pull request per repository. Autonomous remediation ships switched off, with every category set to Manual, so nothing is applied until your team turns it on. Each pull request still goes through review and the KEV gate.

9. Upload VEX for components that are present but not affected (CSAF and VEX upload, GA). Go to Integrations, filter by Upload, and click Connect on the Upload CSAF/VEX card. Name the upload, drop in the file, which is validated automatically, then set the project name and version and click Upload. Supported formats are CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. The docs say uploads can mark vulnerabilities as not affected for your products and document mitigation status.

10. Share the evidence (Portal, GA; Trust Center, GA). Portal here means Safeguard's SBOM publish and share product, not the free entry tier of the same name. Its Sharing docs show direct shares with View, Download or Full permission, links with expiry, download limits and passwords, a branded customer portal, NDA acceptance per SBOM, access tracking and revocation. Those docs describe SBOMs; Trust Center, which is generally available, can publish SBOM and VEX on your own domain.

11. Catch listings between releases (GA). The Vulnerabilities docs say Safeguard scans all your projects daily and re-evaluates them when new CVEs are published; the continuous scanning docs list a CISA KEV addition as a trigger. A Notify policy sends a notification when a policy goes from passing to failing, and again on new matches, without repeating the same failure. Keep a project per supported release so a listing that matches last quarter's release is visible.

12. Ask from an assistant (MCP server, GA). The policy outcomes docs say the MCP server has read-only tools for gate and policy outcomes and evaluation history, when policy outcomes are on and your MCP access settings allow them.

Requirement, Safeguard, and what you still own

What Safeguard does not do

• It does not draft, review or interpret contracts. The clause comparison and illustrative language above are for discussion with counsel. Safeguard produces evidence; whether that evidence satisfies a contract is a legal question.
• It does not fix a component that has no fix. A gate can stop a release; it cannot produce a fixed version. If upstream has not shipped one, you need a mitigation or a patched build. Safeguard's fork and patch service is generally available, so ask which packages it covers before a contract window depends on it.
• It does not see what it does not scan. KEV coverage is only as complete as the set of artifacts you put through Safeguard. An image built in a separate pipeline, a vendored binary, or a hosted dependency you never inventoried will not be matched.
• It does not decide whether your customer accepts a VEX statement. Uploading VEX to Safeguard records your position. The customer, under the contract, decides whether it counts.
• It does not make KEV a documented gate condition today. KEV and reachability are filters on the Vulnerabilities tab. Confirm with Safeguard before writing a gate policy that depends on them, and turn on policy outcomes for your workspace first.
• It does not apply fixes by default. Autonomous remediation ships switched off with every category set to Manual. Nothing changes in your repositories until your team turns it on.
• It does not replace your release process. A hotfix or manual build that bypasses CI never meets the gate.
• The free Gold command line scan fails open. It passes the build if it cannot reach its API. Do not use it as the only check behind a contract promise; use the platform gate, which fails on errors.
• It does not cover vulnerabilities in software you do not build. An appliance, a hosted service or an operating system your customer runs needs a fix from that vendor or distribution.

Common mistakes

Signing "within the timeframe specified by CISA". Since BOD 26-04 the printed due dates are often three days, and the directive's real timelines depend on agency asset exposure. Write your own window based on your release process.

Scanning the repository and shipping an image. The base image carries its own packages. Scan the artifact you deliver.

Treating a failed catalog download as a pass. If the gate cannot fetch the catalog or the scan times out, the release should stop, not continue.

Promising coverage of every version ever shipped. Publish a support window and put it in the clause.

Writing VEX without a version. A not_affected claim for "the product" is useless once the next release ships.

Using inline mitigation as the default justification. It is the hardest one for a customer to verify. Prefer the justifications you can prove from an SBOM or a build configuration.

Gating on severity alone. A medium CVSS vulnerability can be in the catalog. A severity gate set to critical will let it through. Gate on KEV status explicitly.

Waiting for the weekly report. A short notification window cannot be met by a report that runs on Mondays.

FAQ

Does CISA's KEV catalog apply to private companies?

Not directly. BOD 26-04 binds federal civilian executive branch agencies, and its text says it does not apply to contractors unless the procurement contract directs it. CISA recommends that every organisation use the catalog to prioritise, and it recommends agencies put remediation timelines into contracts. Your obligation comes from your customer's clause.

Is BOD 22-01 still in force?

No. CISA revoked BOD 22-01 and BOD 19-02 on 10 June 2026 when it issued BOD 26-04. The catalog and its inclusion criteria carried over. Cite BOD 26-04 in new contracts and policies.

What due date should a vendor agree to for KEV fixes?

One based on your own release process, written in business days and starting when a fix is available upstream. The catalog's printed due dates are written for agencies patching their own systems; since BOD 26-04 they have been 3 or 14 days after the listing.

How often is the CISA KEV catalog updated?

As CISA confirms exploitation; it aims to update within 24 hours of identifying an in-scope vulnerability. In 2026 to 23 October it added 272 entries, including old CVEs, which CISA adds whenever they meet its criteria.

Does a VEX not_affected statement satisfy a no-KEV clause?

Only if the clause says so. Put it in writing: a not_affected statement with one of CISA's standard justifications, specific to the release version, is not a breach. The customer still decides whether to accept each statement.

What if there is no fixed version for a KEV-listed dependency?

The clause should cover this case: a documented mitigation within a set time, and a fix within a set time after upstream ships one. Meanwhile, look for a configuration change, a vendored patch, or a hardened build of the component.

Should we include EPSS thresholds in the contract?

No. EPSS is a daily probability and changes from day to day. Use it internally to fix likely targets before they are listed.

How do we prove to a customer that a release was KEV-free on delivery?

Keep, per release, the SBOM of the delivered artifact, the catalog version used, the gate decision with time and approver, and any VEX statements. Share them on request.

When the gate blocks and there is no clean version

A KEV gate is only as good as the fix you can ship after it blocks, and the clock in a contract keeps running whether or not upstream has released a fixed version. The block below describes how Safeguard helps close that gap, including its honest limits.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, run safeguard and ask it to "fix the lodash CVE in this repo". It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The same loop clears a KEV-listed dependency that just blocked a release.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows you choosing which tools Claude can use. For a KEV clause, that lets a product security lead ask an assistant about findings and gate outcomes without granting more access than it needs.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard from https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs .

Quick check

Sources

• CISA Known Exploited Vulnerabilities Catalog
• CISA KEV catalog JSON feed
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities (KEV criteria)
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance
• CISA BOD 22-01 (revoked)
• CISA Cybersecurity Directives
• CISA Stakeholder-Specific Vulnerability Categorization (SSVC)
• CISA Minimum Requirements for VEX (resource page)
• CISA Minimum Requirements for VEX (PDF, April 2023)
• FIRST Exploit Prediction Scoring System (EPSS)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• Safeguard docs: CISA KEV Correlation
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Vulnerabilities
• Safeguard docs: AI Remediate
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Portal Sharing
• Safeguard docs: CI/CD Integration
• Safeguard docs: Continuous Scanning

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.