Zero-Days Explained: A Hub for Defenders

A zero-day is a vulnerability that attackers exploit before the vendor has a fix out. Defenders cannot prevent the bug, so the work is response: know within minutes where the affected component lives, cut exposure the same day, ship the fix the moment it exists, and report on time. This hub links every guide in our zero-day series and adds a practical checklist that ties them together.

Use it two ways. If you have a live advisory on your desk, jump to the decision table and the readiness checklist below, then follow the links into the guide that matches your question. If you are preparing for the next one, read the guides in order: definitions, data, disclosure, the first 24 hours, inventory lookup, regulation, AI agents and measurement. Everything here stays on the response side. It does not cover finding zero-days, and it does not claim that any tool, Safeguard included, can tell you a bug exists before its vendor does.

Key takeaways

• A zero-day is defined by timing, not severity. NIST's glossary defines a zero-day attack as one that "exploits a previously unknown" hardware, firmware or software vulnerability. A 1-day is exploited just after the fix appears; an n-day long after.
• The volume is steady, the targets are shifting. Google Threat Intelligence Group (GTIG) tracked 90 exploited zero-days in 2025, 78 in 2024 and 100 in 2023. A record 48% of 2025's hit enterprise technology.
• Federal clocks are now risk based. CISA's BOD 26-04 (10 June 2026) revoked BOD 22-01 and BOD 19-02 and sets remediation timelines from four factors: asset exposure, KEV status, exploit automation and technical impact.
• EU manufacturers have a 24-hour clock. Since 11 September 2026 the Cyber Resilience Act requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability, through ENISA's Single Reporting Platform.
• Speed comes from inventory you already hold. The minutes-long answer to "are we affected?" only exists if SBOMs were built before the advisory.
• Safeguard helps on the response side only, with these capabilities, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV enrichment, Search, reachability analysis and prioritisation, mitigations, CSAF and VEX upload, policies and gates (Block, Warn, Notify, with exceptions), autonomous remediation and AI Remediate fix pull requests (ships switched off, every category set to Manual), the Safeguard CLI, and the Safeguard connector in Claude's connector directory.
• What Safeguard does not do here: it does not patch vendor appliances, file your regulatory reports, decide legal tests for you, or make a "not reachable" verdict a substitute for judgement.

What is a zero-day, in one page

The word gets used loosely, so it helps to pin it down before anything else. NIST's Computer Security Resource Center defines a zero-day attack as an attack that exploits a previously unknown hardware, firmware or software vulnerability, citing CNSSI 4009-2022. "Unknown" here means unknown to the people who could fix it. The vulnerability may be well known to the attacker.

Practitioners use three labels, and each one points at a different lever:

The same bug can wear all three labels. A flaw in a shared library can be a zero-day in the first product where it was caught, a 1-day for vendors who ship that library a week later, and an n-day for the team that never learned it was in their base image. That is why a zero-day program is really an inventory program with a clock attached. Guide 1 below has the full explainer.

The guides in this hub

Each guide below is live on the Safeguard blog. They were written to stand on their own, so read the one that matches the question you have today.

1. What is a zero-day? Zero-day vs 1-day vs n-day

Read the guide.

The vocabulary piece. It defines each term the way the public trackers use them, then walks five dated cases, from a managed file transfer zero-day to an Apache Struts flaw still exploited years after its patch, and ends with a decision table per label. Read it first if your team argues about whether something "counts" as a zero-day.

2. What public data says about exploited zero-days, 2024 to 2026

Read the guide.

This guide reads GTIG's annual zero-day reviews and Google Project Zero's "0days In the Wild" tracker line by line: yearly counts, product types, vendors, bug classes, who exploits them and what the data says about time to exploit, plus why the trackers disagree. Read it when you need to justify where readiness budget goes. The headline: edge appliances deserve their own inventory, and shared components are where you can act fastest.

3. Coordinated vulnerability disclosure explained

Read the guide.

Zero-days end when disclosure starts. This guide explains how a vulnerability moves from finder to vendor to public: CVE Numbering Authorities and CVE assignment, the CNA rule on publishing a record within 72 hours of an ID going public, embargoes, and where the 90 plus 30 day and 45 day norms come from. Read it if you receive reports as a vendor, or want to know why advisories arrive the way they do.

4. Zero-day response playbook: the first 24 hours

Read the guide.

The operational core of the series. It breaks the first day into five jobs (find, decide exposure and reachability, mitigate, patch, report) with hour ranges, maps them to KEV, BOD 26-04, NIST SP 800-61 Rev. 3 and SP 800-40 Rev. 4, EPSS, SSVC and the CRA, and replays three dated cases. Read it before your next tabletop exercise; "decide exposure" is the step most teams have never rehearsed.

5. Find every place a newly disclosed vulnerability lives in your estate

Read the guide.

The deep walkthrough of "where is it?": building SBOMs for repositories, images and supplier software in advance, keeping them current, searching by CVE ID and then by component, narrowing by fix availability, reachability and KEV, confirming each dependency path, and covering unconnected code with the CLI. Read it if your current answer to "are we affected?" involves a spreadsheet and a group chat.

6. Zero-days and the EU Cyber Resilience Act's 24-hour reporting

Read the guide.

For anyone placing products with digital elements on the EU market, a zero-day is now also a reporting event. This guide reads Article 14 of Regulation (EU) 2024/2847 and lays out an hour-by-hour manufacturer workflow from intake to final report, including ENISA's Single Reporting Platform. Read it if you ship software or connected products into the EU; the obligation covers products already on the market.

7. Zero-day risk in AI agents, MCP servers and skills

Read the guide.

A zero-day in an agent stack inherits everything the agent can reach. This guide covers the layers an agent session depends on, what KEV and public disclosures show about agent infrastructure, what the MCP specification, Anthropic and OpenAI say in their own docs, and a first-day plan built on narrow scopes and approvals for actions that change things. Read it if your agents touch production; the blast radius is set before the bug is disclosed.

8. Measuring zero-day readiness: time to know, time to mitigate, time to patch

Read the guide.

This guide defines three clocks per affected asset: time to know (disclosure until you can name every affected asset and owner), time to mitigate (disclosure until exposure is reduced) and time to patch (fix availability until the fix runs in production). It shows how to report medians and 90th percentiles split by exposure and KEV status, and includes a readiness drill. Read it when leadership asks "are we ready?".

Related guides outside the series

Two topics in this hub's plan are covered by guides already published elsewhere on the blog:

• When there is no patch yet. Recording "not affected" decisions and consuming vendor advisories is covered in Ingest and share VEX and CSAF in Safeguard to say a CVE does not affect you. The fork and patch route for open source dependencies is summarised in the "Fix it without waiting for upstream" section near the end of this page.
• Ranking what to fix first. Prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard goes deeper on the signals used in step 3 of the walkthrough below.
• Gates and exceptions. Policy gates in CI with Safeguard: Block, Warn, Notify, exceptions and break glass covers how to stop a vulnerable version from shipping again.
• Fixing at scale. Remediate a KEV vulnerability across hundreds of repos with Safeguard is the bulk pull request version of the same response.

Which guide answers which question

Why zero-days matter to defenders right now

The volume is steady, and the targets are moving into the enterprise

GTIG's 2025 zero-day review counts 90 zero-days exploited in the wild in 2025. That is below the 2023 record of 100 and above 2024's 78, and GTIG places all of them inside a 60 to 100 band it has seen over the previous four years. GTIG reads that as stabilisation.

The shift is in where they land. GTIG reports that both the number (43) and the share (48%) of 2025 zero-days affecting enterprise technologies hit all-time highs. Browser exploitation fell to historical lows, operating system exploitation rose, and state-sponsored espionage groups put just over half of their attributed zero-day exploitation into edge devices and security appliances.

For an AppSec or platform team, the zero-days most likely to hit you are in software you buy and run at the edge, not only in libraries you compile. Your response needs SBOM-driven lookup for what you build and a separate, current inventory of appliances and hosted services for what you operate. Guide 2 has the full data.

KEV keeps growing, and it is the input everyone now shares

CISA's Known Exploited Vulnerabilities catalog is the authoritative public list of vulnerabilities exploited in the wild. CISA's own page tells organisations to use it as an input to their vulnerability management prioritisation framework.

We pulled the catalog's JSON feed on 25 October 2026 (catalog version 2026.10.23, released 23 October). It held 1,756 entries. Counting the dateAdded field ourselves, 272 entries were added in 2026 to that date, compared with 245 in all of 2025. 361 entries carry "Known" in the ransomware campaign use field. Each entry also has a required action and a due date, which is why the feed works well as a machine-readable trigger for your own response process.

Two cautions. KEV only lists vulnerabilities with a CVE ID and evidence of exploitation, so it lags the first hours of a true zero-day. And a KEV due date binds federal agencies under CISA's directives, not your company, although many customers and auditors now ask about it.

The rules that set your clock

This section is a short reference. Each item links to the primary source; the guides above go deeper.

CISA BOD 26-04: risk-based federal timelines

BOD 26-04, "Prioritizing Security Updates Based on Risk", was issued on 10 June 2026. It states that it supersedes and revokes BOD 19-02 (April 2019) and BOD 22-01 (November 2021). CISA's page for BOD 22-01 is now marked "Revoked" and archived.

The directive sets remediation urgency from four variables:

1. Asset exposure. Is the vulnerable asset publicly exposed?
2. KEV status. Is the CVE on CISA's Known Exploited Vulnerabilities catalog?
3. Exploit automation. Can an adversary automate every step needed to exploit it?
4. Technical impact. Does exploitation give partial or total control of the asset?

CISA says it publishes answers to the last three for every CVE ID through services such as its Vulnrichment program; exposure is the agency's own question. Within 180 days of issuance, agencies must remediate no later than the timelines in the directive's Table 1 (read the day counts on CISA's page) and tag externally reachable assets with organisation, environment, exposure and asset type.

For a private company, the model is what matters. A policy that still cites BOD 22-01's fixed deadlines cites a revoked directive. The current approach needs exposure per asset, which is an inventory problem first.

EU Cyber Resilience Act, Article 14

The European Commission's CRA reporting page says that as of 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents affecting products with digital elements. The sequence is an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability. Open source software stewards have reporting obligations under Article 24(3) from 11 December 2027.

Reports go through ENISA's Single Reporting Platform, which ENISA describes as the online tool it developed, operates and maintains so that manufacturers, and later open source stewards, can meet those obligations. Guide 6 has the full workflow.

NIST: incident response plus patch management

Two NIST publications frame the work. SP 800-61 Rev. 3 (April 2025) presents incident response recommendations as a Community Profile of the NIST Cybersecurity Framework 2.0, so response is treated as part of risk management rather than a separate binder. SP 800-40 Rev. 4 (April 2022) defines enterprise patch management as identifying, prioritising, acquiring, installing and verifying patches, and its title calls patching "preventive maintenance". For software producers, NIST's Secure Software Development Framework (SP 800-218, February 2022) is the usual reference for building a vulnerability response process into development.

EPSS and SSVC: the two common decision aids

FIRST's Exploit Prediction Scoring System (EPSS) is a data-driven model that estimates the probability a published CVE will be exploited in the wild in the next 30 days. FIRST publishes a score between 0 and 1, with percentiles, every day for every CVE, free to use.

CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) is a decision tree that weighs exploitation status, safety impact and the prevalence of the affected product. CISA built its own version with Carnegie Mellon's Software Engineering Institute in 2020. Where EPSS gives a probability, SSVC gives a decision.

Neither helps much in the first hours of a true zero-day, because both depend on a CVE and on data that takes time to accumulate.

The zero-day timeline, from the defender's side

Every zero-day goes through roughly the same stages. What you control is different at each one.

Stage 3 is the hardest, because you act on incomplete data. Stage 6 is the most expensive, because the copy you did not know about is the one exploited a year later.

A defender's readiness checklist

This is the hub's own guidance: the short version of what the eight guides teach, arranged by when you do it.

Before the next zero-day

1. Build an SBOM for every repository, container image and release you ship. Do it on a schedule and on every release, not on the day. Include build and test dependencies if your response policy covers them.
2. Collect supplier SBOMs and advisories in the same place. If a vendor gives you an SBOM, CSAF advisory or VEX document, store it where the lookup will find it.
3. Keep a separate inventory of appliances and hosted services. Edge devices are where GTIG sees the most targeted exploitation, and they rarely appear in your SBOMs.
4. Tag every asset with environment, exposure and owner. BOD 26-04 asks agencies for exactly these tags. Without them, nobody can rank by exposure on the day.
5. Decide who can make the "not affected" call, and how it is recorded. A decision without a record will be relitigated in every audit.
6. Pre-write your communications. Customer notice, internal status update and, for EU manufacturers, the CRA early warning skeleton.
7. Rehearse. Pick a past KEV entry, run the lookup, time it and write the number down. Guide 8 has a drill.

In the first 24 hours

1. Read the primary advisory. Write down the CVE ID if one exists, the package or product, the affected version ranges and any fixed versions per branch.
2. Find every place it lives. Search your SBOMs by CVE ID and then by component and version, because a new CVE may not have reached every feed yet.
3. Rank by exposure. Internet-facing and production first. Use reachability where your language support is mature, and treat "unknown" as reachable.
4. Mitigate what you cannot patch. Apply vendor mitigations, restrict access, disable the affected feature. Record each one with an owner and an expiry.
5. Patch as soon as a fix exists. Open the upgrade pull requests across every affected repository rather than filing tickets.
6. Stop new copies. Add a policy that fails builds carrying the vulnerable version.
7. Report. Internal status, customers if you are a vendor, regulators if a clock applies.

After the event

1. Close the long tail. Re-run the search a week later.
2. Publish machine-readable "not affected" statements for products that carry the component but are not exploitable.
3. Measure the three clocks and fix the gaps the event exposed: an unconnected repository, a missing supplier SBOM, an untagged asset.

How Safeguard helps on the response side, step by step

Safeguard does not tell you about a zero-day before its vendor does, and this section makes no such claim. What it does is shorten the response once an advisory exists. Every screen name, field and command below comes from Safeguard's public docs at docs.safeguard.sh as fetched on 25 October 2026. The command snippets were not run for this post. Check safeguard --help in your installed build if anything differs.

Step 1: Build the inventory before the advisory (SBOM generation and analysis, GA)

Connect your repositories and container registries from Integrations in the Safeguard web app. Safeguard builds an SBOM for each project and supports SPDX and CycloneDX. On the Generate SBOM page you can turn on Include Dev Dependencies and enable extra scan triggers: On Push for commits to monitored branches, Scheduled for a daily, weekly or custom cadence, and On Release when a new tag is created.

Supplier SBOMs and advisories go in through the same Integrations page, filtered by Upload. That puts software you buy into the same lookup as software you build.

The outcome: when an advisory lands, you query data that already exists instead of scanning the estate under pressure.

Step 2: Ask "where is it?" in Search (SCA and vulnerability management, GA)

Open Search. Safeguard's Search docs show three plain lookups that need no special syntax:

lodash                    # find a component by name
CVE-2021-23337            # find a specific CVE
react 18.2.0              # find a specific version

Those are the docs' own examples. For a new advisory, start with the CVE ID, then search by component name and version, because a CVE published this morning may not yet be in every vulnerability feed with structured version ranges.

Search also takes plain English, such as the docs' example "Which projects have exploitable vulnerabilities?". Typing @ scopes a query to one project, follow-up questions narrow the previous answer, and a starred search gives the incident team one shared live query.

One limit the docs state plainly: Search runs against indexed SBOM and scan data, so results only include projects and scans you can access that have already been processed. A scan still in progress may not show up yet.

Step 3: Rank the list (reachability analysis and prioritisation, GA)

A common library returns a long list. Safeguard's reachability docs describe a prioritisation engine that combines four signals:

• Reachability: whether your code actually calls the vulnerable function, using static call graphs, runtime observation and configuration analysis.
• Exploitability: the daily EPSS feed and CISA KEV listing, plus public proof-of-concept availability.
• Runtime context: environment (production, staging, dev, sandbox), exposure (internet facing, internal, air gapped) and data class.
• Business context: which assets you have declared regulated, customer facing or critical.

Each finding gets a Priority Score from 0 to 100. Findings are classed as Reachable, Conditionally reachable, Unreachable or Unknown, and the docs say Unknown is treated conservatively as potentially reachable. The weights are configurable per tenant under Settings, then Prioritization.

These signals line up closely with BOD 26-04's four factors. KEV status comes from public data; exposure comes from what you have told Safeguard about each asset, so untagged services cannot be ranked by it. Reachability depth varies by language: check the per-language table in the reachability docs before you close a ticket on an "Unreachable" verdict.

In Search, the docs give this example for the same filter in plain English:

reachable and exploitable vulnerabilities only

Step 4: Record mitigations while you wait for a fix (vulnerability management, GA)

Before a fix exists, the record of what you did matters as much as the action. Open a project from Projects and go to the Mitigations tab. To add one, go to the Vulnerabilities tab, find the vulnerability, open the row menu and choose Add Mitigation.

The docs list four mitigation types:

• Risk Acceptance, with an optional expiration date for review.
• False Positive, for a misidentified component or version.
• Workaround Applied, for a configuration change, network control or compensating control. This is the type for most zero-day mitigations.
• Not Applicable, for example when the vulnerable code path is not used or the feature is disabled.

Each record carries a justification, an approver, optional evidence and a scope (this version only, or all versions). Statuses are Active, Expired, Revoked and Superseded, so a mitigation replaced by a real fix shows as superseded rather than disappearing. Bulk mitigations are available from the Vulnerabilities tab. Set a review date on every workaround; a zero-day mitigation that never expires becomes a permanent exception nobody remembers approving.

Step 5: Bring in the vendor's advisory and say what does not affect you (CSAF and VEX upload, GA)

When a supplier publishes a CSAF advisory or a VEX document, go to Integrations, filter by Upload and click Connect on the Upload CSAF/VEX card. Enter a name, add the file, set the project name and version, then click Upload. The docs list CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile, all as JSON.

The same feature lets you record your own exploitability decisions: the docs say VEX documents can mark vulnerabilities as "not affected" for your products, document mitigation status and reduce false positives in vulnerability reports. For a vendor, that is the machine-readable half of a customer notice. Our VEX and CSAF guide covers writing and sharing these.

Step 6: Stop the vulnerable version from shipping again (policies and gates, GA)

Go to Settings, then Policies, and click Create Policy. Conditions in the docs include vulnerability severity, CVSS score, EPSS score, license and component age, and there is a "No Critical Vulnerabilities" template.

Each policy's action decides what a failure does to the gate. The docs list three:

Gates are evaluated by the platform on the scans it runs for connected repositories. With policy outcomes on for your workspace, the docs show this command failing a CI job when the gate fails:

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

When a team has a legitimate reason to ship anyway, they click Request Exception, pick the policy and finding, give a business justification and set an expiration date. Approvers are notified, decide, and the decision lands in an audit trail. During a zero-day that is how you keep a Block policy honest without stopping every release.

Step 7: Ship the fix as a pull request (autonomous remediation and AI Remediate, GA, ships off)

When a fixed version exists, Safeguard's AI Remediate uses Griffin to work out the upgrade path, check for breaking changes and open a pull request. From the docs:

• Single vulnerability: open the vulnerability, click AI Remediate, review the proposed changes, click Create Pull Request.
• Bulk: select several vulnerabilities and click AI Remediate Selected. Compatible fixes are batched into one pull request per repository.
• 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 the pull requests.

Under Settings, then AI Remediate, you choose whether safe fixes open pull requests automatically, whether manual approval is required, whether tests run first and how breaking changes are handled. Generated pull requests include the CVE reference, a change summary, any breaking change warnings and advisory links.

Autonomous remediation ships switched off, with every category set to Manual. For a zero-day, keep a human review on every upgrade pull request and use bulk mode to save typing, not judgement.

Step 8: Cover what is not connected (Safeguard CLI, GA)

There is always a repository nobody onboarded or an image built outside CI. The CLI docs show safeguard scan building an SBOM for exactly one target and matching it against vulnerability databases. Refresh the local databases first so a CVE published this morning can match:

# Refresh the vulnerability databases
safeguard update

# Scan a local directory, an image, a repository or an existing SBOM
safeguard scan --dir .
safeguard scan --image nginx:latest
safeguard scan --repo https://github.com/org/repo
safeguard scan --sbom sbom.json

Results are written as JSON (including vuln.json, license.json and collection.json) in a folder per scan under the output directory, ./output by default. To see the result in the platform next to everything else, the docs say to scan from the interactive terminal while signed in, where the runner uploads the SBOM and findings and never your source.

Read the exit code carefully in scripts. Per the docs, safeguard scan exits 0 when the scan ran whatever it found, 1 when the command itself failed, and 2 when results were written but the vulnerability scan did not run. A script that treats 2 as a pass will report "not affected" for a check that never happened. There is no severity threshold flag; gating is done by policy gates in the platform.

Step 9: Ask the same questions from Claude (Safeguard connector, GA)

Safeguard is listed in Claude's connector directory. The docs call this the shortest route, with no URL to paste: open the directory entry, select Safeguard and connect, sign in to Safeguard, check the app name and the host the authorisation code goes to, then click Authorize access. The directory needs you signed in to claude.ai.

Once connected, the docs say Claude can query your vulnerabilities, SBOMs, packages, findings and compliance data, generate remediation plans and run policy gate checks. A new workspace starts with a small read-only set of tools, and an administrator turns on the rest per tool. Our guide to Safeguard in your IDE and in the Claude and ChatGPT connector directories covers setup on each surface.

What a first-hour session looks like

Here is an illustrative sequence for a new advisory in a widely used open source library, using only flows described above. The project names are placeholders and no output is shown, because the docs do not publish a sample result for this exact flow.

1. Minute 0. The advisory names the package, affected ranges and a fixed version on one branch. The lead writes them in the ticket.
2. Minute 5. In Search, the CVE ID returns nothing yet. The component name and version return the projects where it is used. The lead stars the search.
3. Minute 15. A follow-up narrows to reachable and exploitable findings. Two internet-facing services rank highest; a third is "Unknown" and treated as reachable.
4. Minute 30. The vendor's configuration mitigation goes on all three, each recorded as Workaround Applied with a seven-day expiry.
5. Minute 45. A Block policy goes on the vulnerable range. One team requests a two-day exception for a release in flight.
6. Hour 6. The fix ships upstream. Bulk AI Remediate opens one pull request per repository; owners review and merge.
7. Day 2. Mitigations move to Superseded. A VEX "not affected" statement covers the product without the vulnerable code path.

The point is the order, not the minutes. Your times depend on how complete your inventory was before minute 0.

Decision table: situation, first move, Safeguard, what you own

What Safeguard does not do

• It does not warn you before the vendor does. Nothing in this hub claims Safeguard detects a specific zero-day ahead of a public advisory. The workflow starts when an advisory, a vendor notice or your own detection exists.
• It does not patch software you do not build. Vendor appliances, hosted services, operating systems and firmware are fixed by their vendors. Safeguard can only see them if you hold an SBOM or advisory for them, and it cannot apply the vendor's patch.
• It does not apply runtime mitigations for you. Firewall rules, feature flags, WAF changes and access restrictions happen in your own systems. Safeguard records them as mitigations with an owner, justification and expiry.
• It does not file regulatory reports. It helps you scope affected products for a CRA early warning, but it does not decide whether a vulnerability meets the legal test of "actively exploited", and it does not submit anything to ENISA or any authority.
• It does not make reachability a guarantee. Reachability depth varies by language and build. An "Unreachable" verdict is a strong signal for ordering work, not proof that a vulnerability can never be triggered. Unknown results are treated as reachable for a reason.
• It does not know what you have not connected. Search only covers processed projects you can access. An unconnected repository, an image built on a laptop or a supplier without an SBOM is invisible until you scan or upload it.
• It does not merge or deploy on its own by default. Autonomous remediation ships switched off, every category on Manual. Your team reviews, merges and deploys.

Common mistakes

• Waiting for the CVE before searching. A brand new advisory may not have a CVE ID, or the ID may not have reached every feed. Search by package name and version first, then by CVE ID once it propagates.
• Searching only the libraries you compile. GTIG's data puts nearly half of 2025's zero-days in enterprise technology and a large share of espionage activity on edge devices. If your inventory stops at your own repositories, it misses where the most targeted exploitation happens.
• Citing BOD 22-01 in internal policy. It was revoked by BOD 26-04 on 10 June 2026. Update policy text to the four-factor model, and tag assets with exposure so you can actually apply it.
• Treating "Unknown" reachability as "Unreachable". The docs treat Unknown conservatively as potentially reachable. Do the same.
• Mitigating without recording. A 2 a.m. firewall change that nobody writes down gets removed later. Record it with an owner and an expiry.
• Blocking everything at once. Start with Warn or Notify across the estate, Block on internet-facing services, and time-boxed exceptions for releases in flight.
• Reading a scan exit code as a verdict. safeguard scan exits 0 when the scan ran, whatever it found, and 2 when the vulnerability scan did not run. Neither means "not affected".
• Skipping the long tail. Re-run the search a week later. The copy in a forgotten service is the one that becomes next year's n-day.

FAQ

What is a zero-day vulnerability in simple terms?

A software, firmware or hardware flaw that attackers exploit before the people who can fix it have a fix out. NIST's glossary defines a zero-day attack as one that exploits a previously unknown vulnerability. The name refers to the vendor having had zero days to respond.

What is the difference between a zero-day, a 1-day and an n-day?

A zero-day is exploited before a fix is public. A 1-day is exploited in the short window just after the fix and advisory appear, often by people reversing the patch. An n-day is exploited long after a patch has been available. Guide 1 in this hub has dated examples of each.

How many zero-days are exploited each year?

GTIG tracked 90 zero-days exploited in the wild in 2025, 78 in 2024 and a record 100 in 2023, and describes a 60 to 100 band over the previous four years. Other trackers, including Google Project Zero's, count differently. Guide 2 explains why the counts disagree.

Is BOD 22-01 still in force?

No. CISA's BOD 26-04, issued on 10 June 2026, states that it supersedes and revokes BOD 22-01 and BOD 19-02. Federal remediation timelines now depend on asset exposure, KEV status, exploit automation and technical impact. The KEV catalog itself continues.

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

Read the primary advisory and write down the product or package, affected versions and any fixed versions. Then find every place it lives, starting with internet-facing and production assets, and apply vendor mitigations where no fix exists. Guide 4 has the full 24-hour playbook.

How do I find out if a zero-day affects us?

Search an SBOM inventory you built before the advisory, by package name and version first and by CVE ID once one is assigned. In Safeguard that is the Search page, which returns the projects where a component is used. For appliances and hosted services, check your asset inventory and the vendor's advisory directly.

Does the EU Cyber Resilience Act require reporting a zero-day within 24 hours?

Since 11 September 2026, manufacturers of products with digital elements must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours and a final report no later than 14 days after a corrective measure is available, through ENISA's Single Reporting Platform. Guide 6 covers the workflow.

Can Safeguard detect or patch a zero-day automatically?

Safeguard works on the response side. Once an advisory exists, it helps you find affected projects, rank them, record mitigations, gate the vulnerable version and open fix pull requests when a fixed version exists. Autonomous remediation ships switched off with every category on Manual, so fixes are opened and merged under your control. It does not patch vendor appliances or hosted services.

When a fix exists, and when it does not

Every guide in this hub ends at the same point: a fixed version exists, or it does not yet. The section below is our standard description of how Safeguard closes both gaps for the open source dependencies and images you build and ship, and it applies to the zero-day response flow exactly as written.

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, Griffin, Safeguard's security model, opens 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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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 three demos below are recorded product sessions. None of them shows a zero-day; each shows a flow from the walkthrough above that you would use on the response side.

The first 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. The assistant 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 approval, prints a summary and pushes nothing. That is the same shape as step 7 for a single repository when a fixed version has just shipped.

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

The second shows Claude connected to Safeguard with OAuth, choosing which tools Claude can use. During an incident, that is how people on the bridge call ask "where does this package live?" from Claude, as in step 9.

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

The third sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is the route for repositories and images that are not connected to the platform, as in step 8.

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

To try it on your own estate, download the desktop app and CLI from safeguard.sh/download, and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• NIST CSRC glossary: zero-day attack
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 22-01 (Revoked)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: KEV catalog JSON feed
• CISA: Stakeholder-Specific Vulnerability Categorization
• Google Threat Intelligence Group: 2025 zero-day review
• Google Project Zero: 0-days In-the-Wild
• FIRST: Exploit Prediction Scoring System
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• NIST SP 800-218: Secure Software Development Framework
• European Commission: Cyber Resilience Act reporting obligations
• ENISA: Single Reporting Platform
• Safeguard docs: Search
• Safeguard docs: Generate SBOM
• Safeguard docs: Vulnerabilities
• Safeguard docs: Reachability analysis
• Safeguard docs: Mitigations
• Safeguard docs: CSAF/VEX upload
• Safeguard docs: Policies and gates
• Safeguard docs: AI Remediate
• Safeguard docs: CLI usage
• Safeguard docs: Claude

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