Measuring Zero-Day Readiness: Time to Know, Mitigate and Patch

Zero-day readiness is measured with 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 fixed version runs in production). Report medians and 90th percentiles, split by internet exposure and KEV status, and rehearse them before the next real event.

This post defines each clock precisely, shows what public data says about how fast attackers move, maps the clocks to CISA BOD 26-04 and NIST SP 800-40 Rev. 4, and walks through how to collect the timestamps in Safeguard. Safeguard's part here is the response side: inventory, search, prioritisation, mitigation records, fix pull requests, gates and reporting. It does not make the clocks start later, and it does not replace your incident response process.

Key takeaways

• Readiness is not a feeling or a tool list. It is three measurable intervals per affected asset: time to know (TTK), time to mitigate (TTM) and time to patch (TTP).
• Start TTK and TTM at public disclosure or KEV listing, whichever comes first. Start TTP when a fix is actually available, and track the vendor gap separately.
• Public data says the window is short. Google Cloud's threat intelligence team measured an average time to exploit of five days for vulnerabilities disclosed in 2023, and Google's threat intelligence group tracked 90 zero-days exploited in the wild in 2025, 48% of them in enterprise technology.
• BOD 26-04 (10 June 2026) replaced BOD 22-01 with risk-based remediation timelines driven by four factors: asset exposure, KEV status, exploit automation and technical impact. Your clocks should be segmented by the same factors.
• Safeguard capabilities used in this post, all generally available (GA): SBOM generation and analysis, SCA, Search across SBOMs, vulnerability management with EPSS and KEV enrichment, reachability analysis, mitigations and risk acceptance, CSAF and VEX upload, policies and gates with Block, Warn and Notify, autonomous remediation (ships off, every category set to Manual), dashboards and scheduled reports, the Safeguard CLI, and fork and patch for packages with no upstream fix.
• Run a timed drill every quarter. The first drill's numbers are your baseline; nobody else's numbers, including vendor benchmarks, are a substitute.

Why "are we ready?" needs numbers

Every security team gets the same question within an hour of a big disclosure: are we affected, and when will it be fixed? The honest answer usually starts with "we are checking", and the checking is where most of the exposure window goes.

The trouble is that "zero-day readiness" is often reported as a list of capabilities: we have a scanner, we have an SBOM tool, we subscribe to advisories. None of those tell a CISO how long the organisation stayed exposed the last time it mattered, or whether it is getting faster.

Three clocks fix that. They are simple enough to explain to a board, specific enough to improve, and they map directly onto how regulators and federal directives now frame vulnerability response. They also separate the parts of the window you control from the parts you do not, which keeps engineering teams from being scored on a vendor's release schedule.

What a zero-day actually is, for measurement purposes

A zero-day is a vulnerability exploited before a fix is available. Google Cloud's 2023 time-to-exploit analysis uses that definition, excluding end-of-life technology, and contrasts it with an n-day, which is first exploited after a patch exists. For measurement, the distinction matters because it changes which clock you can move:

• For a zero-day, there is nothing to patch at first. Time to mitigate is the only clock you control in the opening hours.
• For an n-day, a fix exists, so time to patch is the main lever and mitigation is a bridge.
• For a vulnerability in your own code or open source you build, you can sometimes patch before the vendor does, which is where fork and patch comes in.

Most readiness programmes lump all three together. The clocks below work for all three, provided you record which kind of event you are measuring.

What public data says about the window

You cannot set sensible targets without knowing how fast exploitation happens. The public record is good enough to anchor the discussion. These figures come from the primary sources listed at the end; none of them are Safeguard numbers.

Three things follow for measurement.

First, the gap between disclosure and exploitation has collapsed to days on average, and for zero-days it is negative by definition. A time to patch measured in weeks is no longer a readiness metric; it is a record of exposure.

Second, the enterprise share keeps rising. Google's 2025 review describes security and networking devices and enterprise software as prime targets. Many of those are appliances and hosted services you do not build, so time to mitigate (configuration change, isolation, disabling a feature) carries more of the load than it used to.

Third, the KEV catalog is growing every year, so "how many KEV findings are open in production" is a moving target. Counting them once a quarter misses most of the movement.

What the KEV feed shows about due dates since BOD 26-04

The KEV catalog's public JSON feed gives every entry a date added and a due date. We tallied the feed ourselves (catalog version 2026.10.23). Of the 139 entries added on or after 10 June 2026, the date BOD 26-04 was issued, 113 have a due date three days after they were added and 26 have a due date fourteen days after. Entries in the feed now also carry a field stating whether forensic triage is required under BOD 26-04.

Treat that as an observation about the catalog, not as the directive's Table 1. The directive's remediation timelines depend on the four factors below, and the table itself was not readable as text when we fetched it, so we do not quote its day counts here.

The three clocks, defined

Definitions are the part most teams skip, and it is why their numbers cannot be compared from one quarter to the next. Write these down in your vulnerability management standard and do not change them without restating history.

Time to know (TTK)

Starts: the earliest of the CVE record being published, the vendor advisory being published, or the CVE being added to the CISA KEV catalog. For a vulnerability you hear about through a private channel first, start at that moment and record that you did.

Stops: when you have a confirmed list of every affected asset (repository, image, deployed service or vendor product), the affected version on each, and a named owner for each. "We think it is only in the payments service" does not stop the clock. A list you would defend to an auditor does.

TTK has two parts worth tracking separately:

• Time to notice: disclosure until someone on your team or an automated system raises the event. This depends on your feeds and alerting.
• Time to scope: notice until the affected list is confirmed. This depends on your inventory. If you have current SBOMs for everything you ship, scoping is a search. If you do not, scoping is a week of messages.

Time to mitigate (TTM)

Starts: the same moment as TTK, because the exposure starts at disclosure whether or not you have noticed.

Stops: when the exposure on that asset is materially reduced, and you have a record of how. Acceptable mitigations include:

• a configuration change or feature flag that removes the vulnerable path;
• network isolation, removing internet exposure, or a filtering rule in front of the asset;
• a documented "not affected" determination with a justification (for example, the vulnerable code is not present or not reachable), ideally published as a VEX statement;
• a time-bound risk acceptance with an owner and an expiry, where the business decides the residual risk is tolerable.

A mitigation without a record does not stop the clock. A risk acceptance without an expiry is not a mitigation; it is a decision to stop counting.

Time to patch (TTP)

Starts: when a fixed version, vendor patch or vendor workaround is available. This is deliberately not disclosure. If you start TTP at disclosure, your team gets scored on the vendor's engineering speed.

Stops: when the fixed version is running in production on that asset and you have verified it. A merged pull request does not stop the clock. A built image does not stop the clock. The deployed version does.

Track the gap between disclosure and fix availability as a separate number, vendor lag. It is useful in supplier reviews and contract renewals, and it is the number that fork and patch, or a custom hardened build, exists to shorten.

The derived numbers

From those three clocks you get the metrics leaders actually ask for:

• Exposure window per asset: disclosure until the earlier of mitigation or patch. This is the closest single number to "how long were we open".
• Coverage: the share of assets where the clock could be measured at all. If 30% of your estate has no SBOM, your TTK for that 30% is unknown, and the report should say so.
• Open-clock age: for events still in progress, how old they are. Leaving open items out of a median makes the median look better than reality.

How to report the clocks

Bad aggregation hides more than bad tooling. Four rules keep the numbers honest.

1. Measure per affected asset, not per CVE. One CVE in forty services is forty clocks. The CVE is closed when the last one stops.
2. Use the median and the 90th percentile, not the mean. A handful of long tail items will dominate a mean. The 90th percentile tells you about the tail without letting one forgotten appliance swamp everything.
3. Segment by the BOD 26-04 factors. Internet-exposed versus internal, KEV-listed versus not, automatable exploitation versus not, total versus partial control. A median across everything is a number nobody can act on.
4. Count open items. Report how many clocks are still running and their age, alongside the medians of the closed ones.

A small worked example makes the arithmetic concrete. The data below is illustrative, made up for this post, and not drawn from any customer or from Safeguard.

asset,exposure,kev,disclosed,known,mitigated,fix_available,patched
api-gw,internet,yes,2026-09-01T08:00,2026-09-01T11:30,2026-09-01T16:00,2026-09-03T09:00,2026-09-05T14:00
billing,internal,yes,2026-09-01T08:00,2026-09-02T10:00,2026-09-04T09:00,2026-09-03T09:00,2026-09-09T12:00
search,internal,yes,2026-09-01T08:00,2026-09-03T15:00,,2026-09-03T09:00,2026-09-12T10:00
legacy-ftp,internet,yes,2026-09-01T08:00,2026-09-06T09:00,2026-09-06T17:00,,

Reading it:

• TTK is 3.5 hours for api-gw, 26 hours for billing, 55 hours for search and five days for legacy-ftp. The median is about 40 hours, and the internet-facing legacy system took longest because nobody had its inventory.
• TTM stops for api-gw in 8 hours and for billing in three days. Search was never mitigated; it went straight to patch. Legacy-ftp was mitigated (isolated) after five days and has no fix yet.
• TTP starts at fix availability on 3 September, not disclosure. Api-gw patched in about 2 days, billing in 6, search in 9. Legacy-ftp is an open clock with vendor lag still running.
• Exposure window is 8 hours for api-gw, three days for billing, eleven days for search (it was exposed from disclosure to patch), and about five and a half days for legacy-ftp, closed by isolation while its patch clock stays open.

The headline for this event is not "median TTP six days". It is "two internet-facing assets; one closed in eight hours, one was unknown for five days and is still waiting on the vendor". That is the sentence that drives investment.

How the clocks map to standards and directives

You do not need a regulator to justify measuring these clocks, but it helps to know which documents shape them.

CISA BOD 26-04: risk-based timelines from four factors

CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk", on 10 June 2026. It supersedes and revokes BOD 19-02 and BOD 22-01. BOD 22-01 is the 2021 directive that created the KEV catalog and its fixed remediation deadlines; treat those deadlines as history now.

Under BOD 26-04, the urgency of remediating a vulnerability on an asset depends on four variables, as the directive lists them:

The directive also tells agencies to remediate as quickly as possible and no later than the timelines in its Table 1, and to continuously identify and tag assets reachable from outside the agency network with organisation, environment, exposure and asset type.

BOD 26-04 binds federal civilian agencies, not private companies. It is still a clear public statement of how a mature programme should segment its clocks. If your report cannot split TTK and TTP by exposure and KEV status, you cannot answer the first two questions the directive asks.

NIST SP 800-40 Rev. 4: patching as preventive maintenance

NIST SP 800-40 Rev. 4, "Guide to Enterprise Patch Management Planning", was published in April 2022 and supersedes Rev. 3 from 2013. Its abstract defines enterprise patch management as identifying, prioritising, acquiring, installing and verifying the installation of patches, updates and upgrades. Those five verbs map neatly onto the clocks:

• Identifying is time to know.
• Prioritising sits inside time to know and decides which clock you work first.
• Acquiring and installing are most of time to patch.
• Verifying is the step that actually stops the time to patch clock, and the step most often skipped in reporting.

The same publication frames patching as a cost of doing business rather than an emergency activity. That framing supports measuring readiness continuously, not only during incidents.

EPSS and KEV as inputs, not outputs

The Exploit Prediction Scoring System from FIRST estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and publishes a score for every CVE daily. KEV records exploitation that has already been observed.

Both are inputs that decide which clocks you prioritise. Neither is a readiness metric on its own. A programme with a high average EPSS of open findings is not necessarily unready; a programme that takes a week to know whether a KEV entry affects it is.

The public trackers you can rehearse against

Google Project Zero's "0days In-the-Wild" project has tracked publicly known cases of detected zero-day exploits since 2019, with a public tracking sheet and root cause analyses. Google's annual zero-day reviews summarise each year's cases. Both are good sources of past events to rehearse against, because they give you a real disclosure date to start your drill clock from.

How Safeguard helps you measure and shorten the clocks

Safeguard does not change when the clock starts. Its job is to make the stop events faster and to record them, so the numbers come out of the system rather than out of a spreadsheet assembled after the fact. Every capability below is generally available (GA).

The flow assumes your repositories, images or SBOMs are already in Safeguard. If they are not, start with SBOM generation and analysis in Safeguard, because without inventory, time to know is just time to ask around.

Step 1: Make inventory current before the event (shrinks time to scope)

Time to scope is mostly decided before disclosure. Safeguard's SBOM generation and analysis (GA) supports SPDX and CycloneDX, and continuous scanning can run on push, on a schedule or on release, so the inventory you search during an event is not months old. SCA (GA) records the full transitive dependency tree for the ecosystems the docs list, plus packages in container image layers.

From a workstation or a CI job, the Safeguard CLI scans a directory, an image or an existing SBOM:

safeguard scan --dir .
safeguard scan --image <name>
safeguard scan --sbom <file>

Results are written as JSON under ./output. For supplier software you cannot scan, import the supplier's SBOM so it shows up in the same search.

What to measure here: coverage. Count the services and images you deploy, and count how many have an SBOM refreshed in the last scan cycle. That ratio is the ceiling on how fast time to know can ever be.

Step 2: Search the estate the moment a disclosure lands (stops time to know)

The Search page searches across all your SBOMs, components and vulnerabilities. Per the docs, plain terms work as they are: a CVE identifier, a component name, or a component name with a version. Results are grouped by type:

• Components: package name and version, the projects where it is used, vulnerability count and license.
• Vulnerabilities: CVE identifier, severity and CVSS score, affected components and fix availability.
• Projects: project name, last scan date and security score.

You can also ask in plain English, for example "which projects have exploitable vulnerabilities?", and use @ to scope a query to one project. Save a search you will reuse as a starred search, which matters later because policies run starred searches.

What to record: the timestamp when the affected list was confirmed, and who confirmed it. That is your time to know stop event. If Search returns nothing, record what it searched; an empty result means nothing matched in the inventory you have, not that nothing exists outside it.

For a deeper walk through the inventory side, see prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard.

Step 3: Prioritise which clocks to work first

Vulnerability management (GA) matches components against data from the NVD, GitHub Security Advisories, OSV, the CISA KEV catalog and vendor security bulletins. On the Vulnerabilities page, each finding shows the CVE ID, CVSS score, EPSS score, whether it is exploited in the wild, the affected component and version, the fixed version where one is known, and whether the vulnerable code path is reachable.

Reachability analysis (GA) checks whether the vulnerable code is actually called, and the docs describe runtime context (production versus development) and business context (asset criticality, data sensitivity and exposure level, internet-facing versus internal) as part of prioritisation. That is the same split BOD 26-04 asks for, so set exposure and criticality on your projects before you need them.

You can filter the Vulnerabilities page by severity, CVSS range, EPSS range, exploited status, component name, fix availability, reachability status and date range. During an event, the useful filter is narrow: this CVE, exploited, reachable, internet-facing. That list is your first set of clocks to close.

Step 4: Record mitigations so time to mitigate actually stops

Mitigation is where most programmes lose their data. Someone isolates a host, posts in a chat channel, and the evidence disappears. Safeguard gives you three places to record the stop event.

1. Mitigations and risk acceptance. The Mitigations area tracks vulnerability mitigations and risk acceptances. On a vulnerability, Accept Risk asks for an expiration date and a business justification and submits it for approval. The expiry is what keeps a risk acceptance honest: when it lapses, the clock is open again.
2. Mark as false positive. When a finding does not apply, Mark False Positive takes a justification and can require approval if your policy says so.
3. VEX and CSAF upload. Under Integrations, the CSAF/VEX Upload flow accepts CycloneDX VEX, OpenVEX and CSAF VEX documents, so a "not affected" determination with a justification such as "vulnerable code not present" is recorded against the product rather than in someone's inbox. See ingest and share VEX and CSAF in Safeguard for the full flow.

For appliances and hosted services you do not build, the mitigation is usually a configuration change or isolation made in another system. Record it as a mitigation with a reference to the change ticket, so the timestamp lives next to the finding.

Step 5: Open fix pull requests when a fixed version exists (shortens time to patch)

When a fixed version exists, the Vulnerabilities page offers two routes.

• View Fix shows upgrade options for a single vulnerability, with breaking change warnings.
• AI Remediate has Griffin analyse the vulnerabilities, generate remediation plans for you to review, and create pull requests.

Autonomous remediation (GA) can do this across repositories in bulk, one pull request per repository. It ships switched off, with every category set to Manual, so nothing is applied until an admin turns it on and chooses which categories run on their own. For the categories and strategies, see autonomous remediation in Safeguard.

What to record: the pull request merge time is an intermediate step, not the stop event. Time to patch stops when the fixed version is deployed and verified. Take the stop time from your deployment record, or rescan the deployed image or service and use the first scan that no longer shows the finding.

Step 6: Stop the vulnerable version coming back (protects the clocks you closed)

A clock that closes and quietly reopens is worse than one that stays open, because nobody is watching it. Policies and gates (GA) stop regressions.

1. Go to Settings → Policies and choose Create Policy.
2. Define conditions in the visual builder or YAML. The docs list conditions on vulnerability severity, CVSS score and EPSS score, among others.
3. Set the policy's Action: Block fails the gate, Warn lets the gate pass with a warning naming the policy, Notify lets the gate pass and sends a notification to your configured channels.
4. Link the policy to a gate. A policy runs its starred search each time it is evaluated on a gate.
5. In CI, with policy outcomes on for your workspace, fail the job when the gate fails:

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

Two behaviours from the docs matter for measurement. Notify does not repeat the same failure on every evaluation; it fires when a policy goes from passing to failing, and again when a failing policy finds new matches. And an Error is never counted as a pass, so a broken policy cannot quietly report green. Policy outcomes are turned on per workspace by Safeguard; if you do not see an Outcome column on the Gates and Policies tables, ask your Safeguard contact.

A sensible pattern for readiness: Notify on any new KEV-listed finding (this is a time to notice signal), Warn on high EPSS findings, and Block on KEV-listed, reachable findings in internet-facing services. For how to turn a plain English rule into a gate, see plain English security policies to release gates in Safeguard.

Exceptions work the same way as risk acceptance: a developer requests one with a justification and an expiration date, approvers decide, and the audit trail records it.

Step 7: Report the clocks every week, not every incident

The Dashboard shows a security score, vulnerability summary, top risks, vulnerability trends, fix rate and component health, and lets you configure alerts for new critical vulnerabilities, policy violations, SBOM generation failures and score degradation. Dashboards export to PDF and can be sent as weekly or monthly scheduled reports. The platform's editable dashboards support time filters, and bulk export covers formats including CSV, Excel, JSON and Parquet, so you can compute your own percentiles in whatever analytics tool you already use.

The Analytics & Dashboards docs also describe built-in views under Home → Dashboards, including a Program Overview with KEV-listed findings in production and time to remediate on a rolling 30 and 90 day basis, and a Vulnerability Backlog view with aging buckets (under 7 days, 7 to 30, 30 to 90, over 90) and a resolved versus new trend. Check which views your workspace shows; the same docs page notes that some programmatic access it describes is not available yet, so use exports for your own calculations.

A weekly readiness report needs only five lines:

1. Median and 90th percentile TTK for events closed this period, split by internet exposure.
2. Median and 90th percentile TTM and TTP, same split.
3. Number of KEV-listed findings open in production, and the oldest one's age.
4. Open clocks: how many, and how old.
5. Coverage: share of deployed assets with a current SBOM.

Step 8: Use an assistant for the first hour

During the first hour of an event, most of the work is questions: is this in our estate, which services, which owners, is there a fixed version. Safeguard's assistant surfaces can answer those against your own data.

In Claude or ChatGPT, add Safeguard from the assistant's connector directory, sign in, and choose which Safeguard tools the assistant may use. Its read tools cover your projects, vulnerabilities and findings within your authenticated scope, and the tools you enable decide what else it can do. For setup, see Safeguard in your IDE and in Claude and ChatGPT connector directories.

The Safeguard CLI also has an interactive assistant that can read a finding and its advisory, edit a dependency file and run your install and test commands. Since CLI v11.10.0 it asks before any command that changes something; the default Auto mode runs read-only commands without asking. That makes it useful for the patch step on a single repository when an engineer wants to see each change.

Decision table: which clock, which action

Run a readiness drill

You find out your real clocks in one of two ways: during a real event, or during a drill. The drill is cheaper.

1. Pick a past event. Choose a vulnerability that appeared in the CISA KEV catalog in the last few months and affects a component or product you plausibly use. Use its KEV date added as the drill's disclosure time. Do not tell the responders which one in advance.
2. Start the clock at a random time. Real disclosures do not wait for a planning meeting.
3. Time to know. Ask the on-call responder to produce the affected asset list with versions and owners. Stop the clock when they would sign it.
4. Time to mitigate. For each affected asset, have the owner state and record the mitigation they would apply, with the system and the change reference. Do not apply production changes for a drill unless that is part of the plan.
5. Time to patch. For one affected repository, open the upgrade pull request and run it through CI, including the gate. Record how long it takes to reach a deployable artifact.
6. Write down what slowed you. Missing SBOMs, unknown owners, a CI gate nobody understood, an approval that sat in someone's queue.
7. Fix one thing and rerun next quarter. The second drill's numbers against the first are the most honest readiness report you will ever give.

A drill against public data has one more benefit: it tests the parts that tooling cannot, such as whether the right people get paged and whether owners are current.

What Safeguard does not do

Being specific about limits keeps the metrics honest.

1. It does not move the start of the clock. Safeguard's vulnerability data comes from public and vendor sources listed in its docs, such as the NVD, GitHub Security Advisories, OSV, the KEV catalog and vendor bulletins. Disclosure time is set by the vendor and the CVE process, not by your tooling.
2. It does not see what it has not inventoried. Time to know for assets with no SBOM, no connected repository and no imported supplier SBOM is outside Safeguard. Google's reviews show enterprise appliances and edge devices are a large share of exploited zero-days, and for many of those you will depend on the vendor's own advisory and asset lists.
3. It does not deploy fixes to production. Safeguard can open and validate a pull request. Merging, building, deploying and verifying the fixed version in production are yours, and so is the time to patch stop event.
4. It does not patch vendor appliances, hosted services or operating system runtimes you do not build. Those fixes come from the vendor or the distribution. Safeguard can record the mitigation; it cannot apply the vendor's patch.
5. It does not do forensic triage or incident response. BOD 26-04 and some KEV entries call for forensic triage. Deciding whether a system was compromised before you patched it is an incident response task for your team or your incident response provider.
6. It does not decide your risk appetite. Exposure tags, asset criticality, which policies Block versus Warn, and how long a risk acceptance may last are decisions your organisation makes and Safeguard enforces.
7. It does not publish your readiness numbers for you, or give you someone else's. There are no Safeguard benchmark figures in this post because the only useful baseline is your own.
8. It does not file regulatory notifications. Where a regulation or contract requires reporting an exploited vulnerability, the filing is yours; Safeguard's records support it.

Common mistakes

• Starting time to patch at disclosure. It punishes teams for vendor lag and hides how long the fix sat unmerged once it was available. Start at fix availability and report vendor lag separately.
• Stopping time to patch at merge. A merged pull request is not a running fix. The clock stops when the fixed version is deployed and verified.
• Reporting the mean. One forgotten appliance turns a good quarter into a bad one. Use the median and the 90th percentile, and list the outliers by name.
• Leaving open clocks out. A median over closed items only looks better every time something stays open longer. Report open clocks and their age.
• One number for the whole estate. Without the split by internet exposure and KEV status, you cannot prioritise and you cannot answer the BOD 26-04 questions.
• Risk acceptance with no expiry. It stops the mitigation clock forever. Every acceptance needs an owner and a date.
• "Not affected" without a reason. A VEX statement or a false positive mark needs a justification someone can check later, or it becomes a way to hide findings.
• Gating on CVSS alone. Severity says how bad a vulnerability could be, not whether it is exploited or reachable. Combine KEV status, EPSS and reachability in policy conditions.
• Measuring only during incidents. Real events are rare and stressful, so the data is noisy. Weekly reporting and quarterly drills give you a trend.
• Treating inventory as a project rather than a clock. SBOM coverage decays as services are added. Track coverage weekly alongside the clocks.

FAQ

What is a good time to know for a zero-day?

There is no universal target, and anyone quoting one without context is guessing. Google Cloud's average time to exploit of five days for 2023 disclosures suggests time to know should be measured in hours for internet-facing assets. Set your target from your first drill's baseline and cut it each quarter.

Should time to patch start at disclosure or at fix availability?

At fix availability. Start time to know and time to mitigate at disclosure, and track the gap between disclosure and fix availability as vendor lag. That keeps team scorecards fair and gives you a supplier metric.

How do I measure time to mitigate if mitigation happens in another system?

Record the mitigation against the finding with a timestamp and a reference to the change ticket or configuration commit. In Safeguard, use the Mitigations area or Accept Risk with an expiry. The clock stops when the record exists, not when someone says it in a chat.

Is BOD 22-01 still in force?

No. BOD 26-04, issued on 10 June 2026, supersedes and revokes BOD 22-01 and BOD 19-02. BOD 26-04 sets risk-based remediation timelines from four factors: asset exposure, KEV status, exploit automation and technical impact. Mention 22-01 deadlines only as history.

Do private companies have to follow BOD 26-04?

No. It binds federal civilian agencies. It is still a useful model for segmenting your clocks, and suppliers to federal agencies often find their customers asking questions shaped by it.

How does Safeguard help with time to know?

By keeping SBOMs current through continuous scanning and letting you search all of them at once by CVE, component or component and version, with results that list the projects where a component is used. It cannot help with assets it has never inventoried.

Does a VEX "not affected" statement stop the time to mitigate clock?

Yes, if it has a justification someone can verify, such as the vulnerable code not being present or not being reachable. Safeguard accepts CycloneDX VEX, OpenVEX and CSAF VEX uploads, so the determination is recorded against the product.

What should a weekly zero-day readiness report include?

Median and 90th percentile time to know, mitigate and patch, split by internet exposure; KEV-listed findings open in production and the oldest one's age; the number and age of open clocks; and SBOM coverage. Five lines are enough if the definitions are written down.

Does Safeguard turn on automatic fixes by default?

No. Autonomous remediation ships switched off with every category set to Manual. An admin decides which categories run on their own and which still need a human approval.

What do I do when upstream has no fix at all?

Mitigate first and record it. For open source dependencies you build, you can request a hardened build or use fork and patch, described in when upstream has no fix. For vendor appliances and hosted services, the fix has to come from the vendor.

Measuring the clocks shows you where the window is widest. The section below covers the remediation side of the same problem: how to close the patch gap faster, and what to do while upstream has nothing to offer.

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. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix the lodash CVE in a repository. The assistant 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, then shows /permissions, /model and /scan .. That is the time to patch step for one repository, with each change visible to the engineer.

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

The second demo connects Claude to Safeguard with OAuth and chooses which Safeguard tools Claude can use. In your own workspace, add Safeguard from Claude's connector directory. During the first hour of an event, the same connection answers the time to know questions (which projects carry this component, what is the fixed version) against your own data, without anyone building a query.

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

The third demo is a real Android session: the phone sends work to a computer running the Safeguard CLI, and the responder approves the command on the phone with Allow once, Allow for turn or Deny. For an on-call engineer away from a desk, that keeps the patch step moving without giving up the approval.

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

To try the CLI and the apps, start at safeguard.sh/download. The full product documentation is at docs.safeguard.sh.

Quick check

Sources

• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA, Cybersecurity Directives
• CISA, Known Exploited Vulnerabilities Catalog
• CISA, KEV catalog JSON feed
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• FIRST, Exploit Prediction Scoring System
• Google Project Zero, 0days In-the-Wild root cause analyses
• Google Threat Intelligence Group, A 2024 Zero-Day Exploitation Analysis
• Google Threat Intelligence Group, 2025 Zero-Days in Review
• Mandiant, An Analysis of 2023 Time-to-Exploit Trends
• Safeguard Docs, Search
• Safeguard Docs, Vulnerabilities
• Safeguard Docs, Reachability analysis
• Safeguard Docs, Policies and Gates
• Safeguard Docs, Policy outcomes and actions
• Safeguard Docs, CSAF/VEX Upload
• Safeguard Docs, Dashboard
• Safeguard Docs, Analytics and Dashboards
• Safeguard Docs, CISA KEV framework

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