Zero-Day Response Playbook: The First 24 Hours

The first 24 hours of a zero-day response come down to five jobs done in order: find every place the vulnerable component lives, decide which of those places are exposed and reachable, mitigate the dangerous ones, patch as soon as a fix exists, and report what you did. Speed comes from inventory you already have, not heroics on the day.

This post is a working playbook for an AppSec, product security or incident response lead. It is built on public guidance (CISA's KEV catalog and BOD 26-04, NIST SP 800-61 Rev. 3 and SP 800-40 Rev. 4, FIRST EPSS, CISA's SSVC, the EU Cyber Resilience Act reporting rules) and on real, dated cases. Where Safeguard helps, we show the actual product flow from its docs. Where it does not, we say so.

Key takeaways

• The clock starts at disclosure, not at the CVE. Many zero-days arrive as a vendor advisory or a researcher post before a CVE record is published. Search your inventory by component name and version, not only by CVE ID.
• SBOM generation and analysis (GA) and software composition analysis (GA) give you the inventory. Safeguard's Search (GA) answers "which projects use this component at this version?" in plain English across every SBOM you have indexed.
• Vulnerability management (GA) matches components to NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins, and shows EPSS and an Exploitable flag for actively exploited issues.
• Reachability analysis (GA) classifies each finding as reachable, conditionally reachable, unreachable or unknown. Unknown is treated as potentially reachable, so nothing is quietly dropped.
• Mitigations (GA) record workarounds, risk acceptances with expiry dates and "not applicable" decisions, each with a justification, an approver and an audit trail.
• Policies and gates (GA) stop new builds from shipping the vulnerable version. Each failed policy can Block, Warn or Notify, and exceptions go through an approval workflow.
• Autonomous remediation (GA) opens fix pull requests, one at a time or in bulk with one PR per repository. It ships switched off, with every category set to Manual.
• CSAF and VEX upload (GA) lets you load a supplier's "not affected" statements next to your own findings.
• The Safeguard CLI (GA) scans a directory, an image or an SBOM for anything not yet onboarded.

What a "zero-day" means to a response team

A zero-day is a vulnerability that attackers know about, and often exploit, before the people who maintain the software have shipped a fix. For a defender, the practical definition is simpler: it is a serious vulnerability where the usual patch cycle is too slow, and where the first information you get is incomplete.

At hour zero you might have only a vendor blog post, a mailing list message or a news story. A CVE ID may be reserved but not yet published. CISA's KEV criteria page explains that a CVE record moves through states, and that a published record must carry a CVE ID, a prose description and at least one public reference. Until that happens, many tools that match only on CVE IDs show nothing at all.

How common is this? Google Threat Intelligence Group tracked 75 zero-day vulnerabilities exploited in the wild in 2024, down from 98 in 2023 but up from 63 in 2022. GTIG reports that 44% of the 2024 zero-days (33 vulnerabilities) affected enterprise technologies, the highest share it has recorded, driven by security and networking software and appliances. Google Project Zero also keeps a public "0day In the Wild" spreadsheet of detected zero-day exploits. When it published the tracker, Project Zero noted that across vendors it took 15 days on average to patch a vulnerability being used in active attacks.

So zero-days are routine enough to need a written playbook, and fixes often lag exploitation, so mitigation is a first-class step.

Why the first 24 hours are now a compliance question too

The first day of a zero-day used to be an engineering problem. It is now a governance problem too.

CISA KEV and BOD 26-04 set risk-based timelines

CISA's Known Exploited Vulnerabilities catalog is, in CISA's words, "the authoritative source" of vulnerabilities exploited in the wild. A vulnerability enters KEV when three thresholds are met: it has a CVE ID, there is reliable evidence of active exploitation, and there is a clear remediation action such as a vendor update.

On 10 June 2026, CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk". It supersedes and revokes BOD 22-01 (the 2021 directive that created KEV) and BOD 19-02. The old fixed KEV deadlines from BOD 22-01 are history now. BOD 26-04 decides urgency from four factors:

1. Asset exposure. Is the vulnerable asset publicly exposed?
2. KEV status. Is the CVE in the KEV catalog?
3. Exploit automation. Can an adversary automate every step of exploitation?
4. Technical impact. Does exploitation give partial control or total control?

The directive maps those answers to remediation timelines in its Table 1, informed by CISA's Stakeholder-Specific Vulnerability Categorization (SSVC). Two details from the directive text matter for your first day. One tier is marked "& forensic triage": the agency must complete remediation or mitigation within that tier's three-day window and also run a forensic triage to check whether the asset was compromised. And the timelines are dynamic. The directive gives the example that taking a system off the internet changes "Publicly Exposed" from Yes to No and moves the required timeline back, while a new KEV listing shortens it.

BOD 26-04 binds US federal civilian executive branch agencies, not private companies, but it is a useful public model of risk-based urgency for anyone.

SSVC turns urgency into a decision

CISA's SSVC page describes four outcomes: Track, Track*, Attend and Act. Track and Track* are remediated within standard update timelines. Attend means supervisory people get involved and you may need to publish a notification internally or externally. Act means leadership gets involved as well.

EPSS gives you a daily probability

FIRST's Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and publishes a score between 0 and 1 for every CVE every day.

The EU Cyber Resilience Act adds a 24 hour reporting clock

The European Commission's CRA reporting page says that from 11 September 2026, manufacturers of products with digital elements must notify actively exploited vulnerabilities and severe incidents affecting their products. They must send an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability. Notifications go through the CRA Single Reporting Platform run by ENISA, addressed to the CSIRT of the manufacturer's main establishment. The CRA's main obligations apply from 11 December 2027, but the reporting duty is already live.

If you ship software into the EU, the first 24 hours is now a legal deadline for the early warning.

NIST frames it as incident response plus patch management

NIST SP 800-61 Rev. 3 (April 2025) recasts incident response as part of cybersecurity risk management under the NIST Cybersecurity Framework 2.0, rather than a separate checklist. NIST SP 800-40 Rev. 4 (April 2022) defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades. A zero-day response is both at once.

The playbook at a glance

Here is the whole first day on one page. Times are guides, not rules.

The windows overlap on purpose: start mitigating the first exposed system you find.

Step by step: the first 24 hours with Safeguard

The steps below follow the table. Each one says what to do in general, then how Safeguard handles it today, using only what Safeguard's documentation shows. Commands are copied from the docs and were not run for this post.

Step 1 (hour 0 to 1): Triage the advisory and open the incident

Before anyone touches a scanner, get four things written down.

1. What exactly is affected. Product or package name, affected version range, fixed version if one exists, and the vendor's own wording. Copy the advisory URL and the time you first saw it. Under the CRA, "becoming aware" starts a clock, so the timestamp matters.
2. Who owns the response. One incident lead, one person on inventory, one on communications. NIST SP 800-61 Rev. 3 puts preparation at the centre of good incident response.
3. Severity in plain words. Use SSVC style outcomes: Track, Attend or Act. If exploitation is confirmed and the component is internet facing anywhere in your estate, assume Act until proven otherwise.
4. Where you will talk and keep evidence. CISA's BOD 26-04 implementation guidance recommends a dedicated out of band communication channel that does not rely on potentially compromised infrastructure, and an evidence log recording each item collected, the system it came from, when and by whom.

What Safeguard does here: nothing yet. This step is about people.

Step 2 (hour 1 to 4): Find every place the vulnerable component lives

This is where most teams lose the first day. The question is simple: which repositories, services, container images and bought products contain the affected component at an affected version? The answer depends entirely on whether you already have SBOMs.

2a. Search across everything you have already indexed. Safeguard's Search page (GA) works across all your SBOMs, components and vulnerabilities, using Griffin natural language queries instead of hand built filters. The docs show plain terms working as is:

lodash
CVE-2021-23337
react 18.2.0

That first line is the one that matters for a zero-day. You can search by component name, and by name plus version, before any CVE record exists. The docs also list natural language examples such as "What packages are affected by Log4j?" and "Which projects have exploitable vulnerabilities?". Component results show the package name and version, the projects where it is used, the vulnerability count and license information.

Star the search so the whole team can re-run it from the sidebar as new scans land, and export the results (JSON, CSV or PDF) for your evidence log.

One honest caveat, also from the docs: Search runs against indexed SBOM and scan data you have access to. A scan still in progress may not show up yet. If a result looks too clean, broaden the query before you trust it.

2b. Confirm in the project view. Open each hit from the Projects list to reach the Project Overview. The Dependencies tab shows the full tree in a tree view (parent and child relationships, depth, versions, vulnerability indicators) and a sortable table view. This is how you answer "is it direct or transitive, and what pulls it in?", which decides whether the fix is a one line bump or a parent upgrade.

2c. Scan anything that is not onboarded yet. Every estate has gaps: a repository nobody connected, an image built on a laptop, a vendor tarball. The Safeguard CLI (GA) closes them quickly. From the CLI usage docs:

# A local directory (your own or proprietary code)
safeguard scan --dir .

# A container image
safeguard scan --image nginx:latest

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

safeguard scan builds an SBOM for the target, matches it against vulnerability databases and writes JSON results under ./output by default, including vuln.json, license.json and collection.json in a folder per scan. Run safeguard update first to refresh the local vulnerability databases, so a freshly published advisory is matched.

Know two behaviours before you script this. safeguard scan exits 0 whenever the scan ran, whatever it found, 1 when the command failed, and 2 when results were written but the vulnerability scan did not run, so never read exit 0 as clean. And results from a plain safeguard scan stay on your machine. To see them in the platform alongside other projects, scan from the interactive terminal (/scan .) while signed in. The docs say the runner then uploads the SBOM and findings, never your source.

2d. Do not forget software you bought. For a supplier product, ask the vendor for a current SBOM and upload it through Integrations. Once it is a project in Safeguard, it shows up in the same Search results as your own code. Our walkthrough on SCA from a supplier SBOM covers the upload in detail, and supplier software risk with TPRM covers requesting SBOMs from vendors at scale.

What you have at hour four: a list of affected projects, images and supplier products, with versions. Our older post on using SBOMs to find affected products fast goes deeper on inventory hygiene.

Step 3 (hour 2 to 6): Decide exposure and reachability

A list of 40 affected projects is not a plan. You need to know which five to fix first. Rank on three questions.

Is it exploited? Once a CVE is published, Safeguard's vulnerability management (GA) shows it in the Vulnerabilities tab with CVSS, an EPSS score and an Exploitable flag for known active exploitation in the wild (CISA KEV). The docs list the data sources: NVD, GitHub Security Advisories, OSV, CISA KEV, vendor security bulletins and security researcher disclosures. Safeguard runs daily continuous scanning of all projects, and when new CVEs are published, projects are re-evaluated automatically to check whether they are affected. For a true zero-day that is in KEV, treat exploitation as a fact, not a probability.

Is it reachable? Reachability analysis (GA) asks whether your code actually calls the vulnerable function or triggers the vulnerable path. The docs describe static reachability (a call graph from source, lockfile and bytecode), dynamic reachability (what is actually loaded and invoked in production workloads) and configuration reachability (whether framework configuration wires the code in at all). Each finding is classed as:

Reachability quality varies by language, and the docs keep a per language table; check it for your stack before you lean on an "unreachable" result. Where the analyzer is weak (reflection, data driven bugs, unenumerated configurations), fall back on KEV, EPSS and exposure.

Is it exposed? BOD 26-04's first factor is whether the asset is publicly exposed. Safeguard's prioritisation can weigh business and runtime context, but the honest answer to "is this service on the internet?" usually lives in your own asset records and network configuration. Write it next to each finding.

What you have at hour six: a ranked list. Exposed and reachable at the top, internal and unreachable at the bottom, unknown treated as reachable. Our post on prioritising with reachability, EPSS and KEV covers the scoring in more depth.

Step 4 (hour 4 to 12): Mitigate what you cannot patch yet

For a true zero-day, there may be no fixed version for days. Project Zero's 15 day average time to patch exploited bugs is a reminder that "wait for the vendor" is not a plan. Mitigation buys time. Typical moves:

• Reduce exposure. Take the affected service off the internet, restrict it to a VPN or an allow list, or put it behind an authenticating proxy. Under BOD 26-04's model, removing public exposure is itself a valid mitigation that changes the required timeline.
• Turn off the vulnerable feature. Many advisories name a module, endpoint or option. Disabling it is often safer than any code change on day one.
• Apply the vendor's interim guidance exactly before you improvise.
• Hunt while you wait. BOD 26-04 pairs its fastest tier with forensic triage for a reason. If the component was exposed and exploited in the wild, check whether you were hit, not only whether you are vulnerable.

Record every mitigation in Safeguard. The Mitigations tab (GA) tracks applied fixes, risk acceptances and false positives per project. From the Vulnerabilities tab, open the row menu and choose Add Mitigation. The form, per the docs, has:

Use Workaround for config changes, network controls and compensating controls. Use N/A when the vulnerable code path is not used or the feature is disabled. Bulk Actions apply one mitigation to many selected vulnerabilities at once. Every action is logged with who and when, and Safeguard notifies before an expiry. Active mitigations exclude a vulnerability from gate failures and expired ones do not, so set a short expiry on any day one risk acceptance.

Stop new builds from shipping the vulnerable version. Policies and gates (GA) enforce rules across projects. In Settings, Policies, create a policy with the visual builder or YAML. Each policy has one Action that decides what a failure does to the gate:

During an incident, a sensible pattern is Block on the release gate for the affected component and versions, and Notify on development gates so engineers hear about it without being stopped mid task.

In CI, the docs show a gate check with the CLI:

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

It waits for the scan and policy evaluation, then exits 0 when the gate is Passed or Warning, and non-zero when the gate is Failed, in Error, or Not evaluated before the timeout. Policy outcomes are switched on per workspace; if you do not see an Outcome column on your Gates and Policies tables, ask your Safeguard contact to turn it on. When a team has a real reason to ship anyway, the exception workflow records the request, the justification, an expiry date and the approver's decision. Our post on plain English policies to release gates walks through building one.

Step 5 (hour 6 to 24): Patch as soon as a fix exists

When the vendor or maintainer ships a fixed version, the race changes from "contain" to "deploy". Three things slow teams down here: finding the fixed version, changing dozens of manifests, and proving the change did not break anything.

Confirm the fixed version. The Vulnerabilities tab shows a Fixed Version field per finding. Choose View Fix on a vulnerability to see upgrade options and breaking change warnings. Gold Open Source (GA, gold.safeguard.sh), free and without login, also lists affected and fixed versions for packages, which is handy when the person checking is not a Safeguard user. Coverage of newly published advisories can lag, so always cross check the vendor advisory itself.

Open the fix pull requests. Autonomous remediation (GA), shown in the docs as AI Remediate, works in five stages: analysis, solution generation, impact assessment, PR creation and validation. You can use it three ways:

1. Single vulnerability. Open the vulnerability, click AI Remediate, review the proposed changes, click Create Pull Request.
2. Bulk. Select the vulnerabilities, click AI Remediate Selected, review, and create PRs, one per repository.
3. Page level. Click AI Remediate at the top of the Vulnerabilities page to get a remediation plan for all fixable vulnerabilities, then approve and create PRs.

Generated PRs carry a title with the CVE reference, a description of the vulnerability, a summary of changes, breaking change warnings if any, test results if configured, and links to advisories. Breaking change detection grades each upgrade as Safe, Minor, Major or Critical. The docs list full support for npm, yarn and pnpm, pip, poetry and pipenv, Maven and Gradle, Go modules, Cargo, Bundler, NuGet and Composer.

Autonomous remediation ships switched off, with every category set to Manual. Settings, AI Remediate, controls whether PRs are created automatically for safe fixes, whether manual approval is required, whether tests run first, and how breaking changes are handled. For a zero-day, keep a human on every merge. The point is to remove the typing, not the review. Our post on autonomous remediation's categories and strategies explains the settings.

Rebuild and redeploy. A merged PR fixes nothing until the new build is running. Our guides on scanning container images and tracking images per environment cover that loop.

Verify. NIST SP 800-40 Rev. 4 ends its definition of patch management with "verifying the installation". Rescan the affected projects. In Search, re-run your starred query and confirm the affected versions are gone. Close the mitigation records that the fix superseded; the docs give mitigations a Superseded status for exactly this.

When the fix is a downgrade. Not every response is an upgrade. In March 2024, CISA's alert on CVE-2024-3094 in XZ Utils recommended downgrading to an uncompromised version such as 5.4.6 Stable, hunting for malicious activity and reporting positive findings. Your patch step has to handle "go back a version" as cleanly as "go forward".

When there is no fix at all. Keep the mitigations and the gate in place, set short expiries, and look at the options in the remediation section below for getting a fixed build without waiting for upstream.

Step 6 (hour 12 to 24): Report

If steps 2 to 5 were recorded, the report mostly writes itself. There are four audiences.

Internal leadership. A short status: affected, exposed, mitigated, patched, still open, next update time. Mitigation reports in Safeguard (Reports, Mitigations) can be generated by date range as PDF, CSV or Excel, and include active mitigations, expired ones needing review, a breakdown by type, approvers and an expiry timeline.

Customers. Customers want to know whether your product is affected. A VEX statement answers that in a machine readable form. OpenVEX statements use the statuses not_affected, affected, fixed and under_investigation; a not_affected statement needs a justification such as vulnerable_code_not_present or vulnerable_code_not_in_execute_path, and an affected statement needs an action statement. CSAF 2.0 uses product status groups such as known_affected, known_not_affected, fixed and under_investigation. On day one, under_investigation is an honest and useful answer.

Your own records of supplier statements. When your vendors publish VEX or CSAF for their products, upload it. CSAF and VEX upload (GA) accepts CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. In Integrations, filter by Upload, choose Connect on the Upload CSAF/VEX card, name the upload, drop in the file (it is validated automatically), set the project name and version, and click Upload. You can also check a VEX or CSAF file locally first:

safeguard validate sbom.json --strict -o report.json

The docs say safeguard validate checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications. Our post on ingesting and sharing VEX and CSAF covers both directions.

Regulators and authorities. If you are a manufacturer under the CRA and the vulnerability is actively exploited in your product, the 24 hour early warning goes through ENISA's Single Reporting Platform. If you are a US federal agency, BOD 26-04 reporting runs through the CDM dashboard. Other sector rules may apply to you; check with counsel. Safeguard does not file regulatory notifications for you. What it gives you is the evidence: which products, which versions, when you knew, what you did and who approved it.

Example: what the first day looks like in practice

Here is a hypothetical timeline for a team with SBOMs already in Safeguard. It is an illustration, not a customer story.

Three dated cases, seen from the response side

These public cases show how the five jobs played out. They do not suggest any tool would have changed the outcome.

Log4Shell, December 2021

CISA's guidance page describes active, widespread exploitation of CVE-2021-44228, a critical remote code execution flaw in Apache Log4j 2 versions up to 2.14.1. By its 28 December 2021 update, CISA was urging upgrades to Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6). In its April 2022 update, CISA warned that early identification efforts "may have been scoped to a limited number" of assets, and asked organisations to include internally developed software and non-internet facing stacks. It also said that where an update exists it should be applied immediately, with temporary mitigations only where a product cannot be updated.

The response lesson: the find step was the bottleneck. Log4j was often a transitive dependency inside both in-house and bought software, and CISA's April 2022 update shows organisations were still widening their search months later. The recommended fixed version also changed within weeks, which is why verify is its own step.

MOVEit Transfer, May and June 2023

The joint FBI and CISA advisory AA23-158A says that, according to open source information, the CL0P ransomware gang began exploiting a previously unknown SQL injection flaw, CVE-2023-34362, in MOVEit Transfer from 27 May 2023. Internet facing instances were hit with a web shell.

The response lesson: exposure and forensic triage matter as much as patching. This was a product, not a library, so SBOM search helps you confirm whether bought software embeds it, but the decisive questions were whether the service was exposed to the internet and whether it had already been compromised. That is exactly the pattern BOD 26-04 now builds into its fastest tier.

XZ Utils, March 2024

CISA's alert on CVE-2024-3094 reported malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1, which may be present in Linux distributions. CISA recommended downgrading to an uncompromised version such as 5.4.6 Stable, hunting for malicious activity and reporting positive findings.

The response lesson: the patch step was a downgrade, and the find step had to cover operating system packages inside container images and hosts, not just application dependencies. An image scan that lists OS packages per layer answers part of that question. Hosts that are not built as images still need your own host inventory.

Decision table: who does what in the first 24 hours

Ask the same questions from Claude

If your incident channel lives next to an AI assistant, you can ask Safeguard the same questions there. Safeguard's MCP server (GA) is listed in Claude's connector directory as a community connector. Open the Safeguard entry in the directory, select it and connect, then sign in to Safeguard and click Authorize access. The docs say you can then query vulnerabilities, SBOMs, packages, findings and compliance data, generate remediation plans for npm, pip, Maven, Go and Cargo projects, and check policy gates for deployment readiness.

Treat assistant answers as a starting point and confirm the important ones in the project view. Our post on Safeguard in the Claude and ChatGPT connector directories covers setup.

What Safeguard does not do

A gap you know about is a gap you can cover.

1. It does not find vulnerabilities in software it has never seen. Search and matching work on SBOMs and scans you have loaded. A repository that was never connected, an image never scanned or a vendor product with no SBOM is invisible until you scan or upload it. The first day goes as well as your inventory did the day before.
2. It does not patch vendor appliances, hosted services or operating systems you do not build. For a zero-day in a firewall, a managed file transfer appliance or a SaaS product, the fix comes from the vendor. Safeguard can record your mitigation and track the vendor's statement; it cannot ship their patch.
3. It does not change your network or infrastructure. Taking a service off the internet, changing a load balancer rule or disabling a module in production is your team's change, through your change process. Safeguard records it as a mitigation; it does not make it.
4. It does not do forensics. Checking whether an exploited system was compromised, collecting memory or disk images and analysing logs needs incident response tooling and people. Safeguard's audit trails help with the timeline of your response, not with the attacker's.
5. It does not file regulatory notices. CRA early warnings, federal reporting and sector notifications are filed by you, through the official channels. Safeguard provides evidence, not filings.
6. Reachability is not proof of safety. Docs list reflection, dynamic dispatch, data driven bugs and unenumerated configurations as weak spots. "Unreachable" lowers priority; it does not close the incident. Unknown results are treated as potentially reachable.
7. Fix PRs need review. Autonomous remediation ships off, every category set to Manual, and you decide how much runs on its own. A generated PR with a Major or Critical breaking change grade needs a human who knows the service.

Common mistakes

Waiting for the CVE before searching. The advisory names the component and versions. Search on those immediately; the CVE match will catch up.

Searching only your own repositories. Bought software, base images and build tools carry the same libraries. CISA's Log4j guidance specifically asked organisations to check third-party software and SaaS they did not build.

Treating "unreachable" as "not affected". It is a priority signal, not a verdict. Record the reasoning, keep the finding, fix it on the normal cycle.

Leaving day one risk acceptances open forever. Active mitigations exclude a vulnerability from gate failures. A risk acceptance with no expiry quietly turns your release gate off for that issue. Set a short expiry.

Auto-merging generated fixes during an incident. Speed is the point, but an untested upgrade in the middle of an incident creates a second incident. Keep tests on and keep a reviewer on every merge.

Declaring victory at the merge. A fix is done when the rebuilt artifact is running and a rescan confirms the affected version is gone.

Quoting old federal deadlines. BOD 22-01 has been revoked. If a customer contract quotes its fixed KEV deadlines, map them to BOD 26-04's risk based approach in your answer.

FAQ

What should I do in the first hour of a zero-day?

Write down the advisory, the affected versions and the time you saw it. Name an incident lead. Assign a severity using SSVC style words (Track, Attend, Act). Open an out of band channel and an evidence log, as CISA's BOD 26-04 implementation guidance recommends. Then start the inventory search.

How do I find out if a zero-day affects us before there is a CVE?

Search by component name and version, not by CVE ID. In Safeguard's Search, a plain term like the package name, or name plus version, returns matching components and the projects that use them. Vulnerability matching, EPSS and the Exploitable flag appear once the public CVE record and KEV listing exist.

How long do we have to patch a zero-day under BOD 26-04?

It depends on four factors: public exposure, KEV status, exploit automation and technical impact. The directive's Table 1 maps them to timelines, and its fastest tier pairs remediation or mitigation within three days with a forensic triage. The directive binds US federal civilian agencies; private companies often borrow its logic.

Does the EU Cyber Resilience Act require reporting within 24 hours?

Yes, for manufacturers of products with digital elements, from 11 September 2026. An early warning on an actively exploited vulnerability is due within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a corrective measure being available, all through ENISA's Single Reporting Platform.

Can Safeguard automatically patch a zero-day?

When a fixed version exists, autonomous remediation can open fix pull requests for affected repositories, one at a time or in bulk. It ships switched off, with every category set to Manual, and you control approvals and tests. When no fix exists yet, there is nothing to upgrade to, so mitigation comes first.

How do I tell customers whether our product is affected?

Publish a VEX statement. OpenVEX uses not_affected, affected, fixed and under_investigation, with a justification required for not_affected. CSAF 2.0 uses product status groups like known_affected and known_not_affected. Start with under_investigation and update it.

Should we block all builds that contain the vulnerable component?

Block release gates, and use Warn or Notify on development gates so engineers can still ship the fix. Use the exception workflow, with an expiry and a named approver, for the rare case that must ship anyway.

Does reachability analysis mean we can ignore unreachable findings?

No. It means you can fix them after the reachable and exposed ones. Safeguard's docs list cases where reachability is weak, and treat unknown results as potentially reachable. Keep unreachable findings open and fix them on the normal cycle.

When a fix is the hard part, the remaining question is how fast it reaches your builds, and what to do when upstream has not shipped one. The block below covers Safeguard's options for both, written for every post in this series.

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 demos below are recorded product sessions, not zero-day responses. Each shows a piece of the flow you would use in step 2 or step 5 above.

This first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal, and asks it to fix a lodash CVE in a repository: it reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan, which is the same scan you would run on an unonboarded repository during step 2.

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 chooses which tools Claude can use. In an incident, that is how someone in the response thread asks which projects carry the affected versions without switching tools.

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

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It suits teams who want results in the platform during an incident without granting repository access to a hosted service.

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

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

Quick check

Sources

• CISA: Known Exploited Vulnerabilities Catalog
• 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: Stakeholder-Specific Vulnerability Categorization (SSVC)
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• FIRST: Exploit Prediction Scoring System (EPSS)
• European Commission: CRA reporting obligations
• European Commission: Cyber Resilience Act
• Google Threat Intelligence Group: 2024 zero-day exploitation review
• Google Project Zero: 0day "In the Wild"
• CISA: Apache Log4j Vulnerability Guidance
• CISA and FBI: AA23-158A, CL0P exploits CVE-2023-34362 MOVEit vulnerability
• CISA: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• OpenVEX specification
• OASIS: CSAF Version 2.0
• Safeguard docs: Search
• Safeguard docs: Explore SBOM
• Safeguard docs: Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Mitigations
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: AI Remediate
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: CLI Usage
• Safeguard docs: Claude MCP integration

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