CVE remediation: from advisory to a fixed, shipped build

The CVE remediation process

CVE remediation removes a publicly disclosed vulnerability from software you run or ship. For your own code that means a patch. For open-source dependencies, which is where most CVEs in a typical product come from, it means getting to a version where the vulnerability is fixed. Either way the steps are the same:

1. Find every product, build and release that contains the affected package and version.
2. Assess whether the vulnerability affects you, and how badly.
3. Prioritize against everything else that is open.
4. Fix by upgrading, patching, replacing or, if no fix exists, mitigating.
5. Verify that the fixed version is what the new build actually contains.
6. Record what was affected, what you decided and when the fix shipped.

Step 1: find every affected build

The first question after an advisory is where the package is. Answering it from source repositories is slow, and it is often wrong: the version in a lockfile, the version a build resolved and the version in a released container image can all differ. Transitive dependencies and packages that a build downloads outside the package manager do not show up in manifests at all.

The reliable answer comes from an SBOM of each release, matched against advisories continuously. If that SBOM is recorded during the build, it lists what the build actually used, so the match tells you which shipped builds contain the vulnerable version, not which repositories mention it.

Step 2: prioritize with severity and exploitation

Severity alone ranks too many vulnerabilities as urgent. Most teams combine three signals:

Signal	What it tells you	Published by
CVSS	How severe the vulnerability is if exploited, scored 0 to 10	FIRST (the standard); NVD and vendors publish scores
EPSS	The estimated probability of exploitation in the next 30 days	FIRST
KEV	Whether the vulnerability is known to be exploited in the wild	CISA's Known Exploited Vulnerabilities catalog

Then add your own context: whether the affected package ships to customers or only runs in a test job, and whether the vulnerable function is used at all. A known exploited vulnerability in a package that ships goes to the top of the list. Vulnerability prioritization turns these signals into a method.

Remediation timelines

• CISA BOD 26-04. Since June 10, 2026, US federal agencies set each deadline from four questions: is the asset publicly exposed, is the vulnerability in the KEV catalog, can exploitation be automated, and does it give partial or total control. The answers range from 3 days, with forensic triage for the worst cases, to fixing on the next system upgrade. It replaced BOD 22-01, which gave two weeks for most KEV entries.
• EU Cyber Resilience Act. Manufacturers must address and remediate vulnerabilities without delay, including through security updates (Annex I, Part II). Since September 11, 2026, an actively exploited vulnerability in a product also starts a reporting clock: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix being available.
• Your own policy. Most security programs set internal targets by severity. Whatever they are, you can only meet them if step 1 is fast.

Step 3: choose the fix

Option	When to use it
Upgrade	A fixed version exists. Prefer the smallest upgrade that includes the fix, to limit breaking changes.
Upgrade the parent	The vulnerable package is transitive. A newer release of the direct dependency often pulls in the fix.
Override	The parent has not released a fix. Force the transitive version with npm overrides, Yarn resolutions or pnpm.overrides, and test it.
Patch or backport	You cannot move to the fixed major version yet. Apply the upstream fix to the version you use.
Replace	The package is unmaintained or keeps producing CVEs. Move to an alternative.
Mitigate and document	No fix exists yet, or your product is not affected. Reduce the exposure, and record the assessment, for example as a VEX statement.

Most of this step can be automated, from picking the version to opening the pull request. Automated vulnerability remediation covers what to automate and what to keep for a person.

Step 4: a merged fix is not a shipped fix

The pull request merged, so the CVE is closed. Not necessarily. The fix is in the repository, but a build restores a stale cache, a base image still carries the old package, or a release branch never picked up the change. The ticket says fixed while the product still ships the vulnerable version.

Close the loop from the other end: check the SBOM of the next build and confirm the vulnerable version is gone. When that SBOM records what the build actually fetched, including packages restored from caches, the check answers the question the customer, the auditor and the regulator are really asking.

How CRACI supports CVE remediation

• Find. CRACI records the packages each GitHub Actions job fetched, including transitive dependencies and packages restored from caches, and re-evaluates monitored SBOMs continuously. Organization views aggregate findings across builds and repositories, so you see which builds a new CVE affects.
• Assign. Security teams triage each finding and send it to the team that owns the fix. CRACI supports VEX for recording how a vulnerability affects your product.
• Verify. Each new build gets its own SBOM with a completeness state, so you can confirm the fixed version is what the build used.
• Report. For actively exploited vulnerabilities under the CRA, CRACI submits the notifications to the authorities on the manufacturer's behalf.

See vulnerability tracking for the full capability.

CVE remediation: frequently asked questions

What is CVE remediation?

CVE remediation is removing a publicly disclosed vulnerability, identified by its CVE ID, from the software you run or ship. For a dependency that usually means upgrading to a version where the vulnerability is fixed. For your own code it means patching it.

How do I prioritize which CVEs to fix first?

Combine severity with evidence of exploitation. CVSS describes how bad a vulnerability is, EPSS estimates how likely it is to be exploited in the next 30 days, and CISA's Known Exploited Vulnerabilities catalog lists the ones that are exploited already. A known exploited vulnerability in a package you ship goes to the top.

How fast do CVEs need to be remediated?

It depends on who asks. CISA's Binding Operational Directive 26-04 gives US federal agencies between 3 days and the next system upgrade, depending on whether the vulnerability is in the KEV catalog, whether the asset is publicly exposed, whether exploitation can be automated and how much control it gives an attacker. The EU Cyber Resilience Act asks manufacturers to remediate vulnerabilities without delay, and since September 11, 2026 an actively exploited vulnerability in a product starts a 24-hour reporting clock.

What if there is no fixed version yet?

Mitigate and document. Disable the affected feature, block the attack path or swap the component if you can, and record your assessment, for example as a VEX statement. Then watch for the fixed release and remediate when it lands.

How do I fix a CVE in a transitive dependency?

First try upgrading the direct dependency that pulls it in, since a newer release often picks up the fix. If none exists yet, most package managers let you force the version of a transitive package: overrides in npm, resolutions in Yarn, pnpm.overrides in pnpm. Test the result, because the parent package was not built against that version.