Find Every Place a Newly Disclosed CVE Lives in Your Estate, in Minutes

When a new vulnerability is disclosed, you find every place it lives by searching an inventory you built before the news broke: the SBOMs of your repositories, container images and supplier software. In Safeguard you type the CVE ID or the package and version into Search, get every project that carries it, then narrow by fix availability, reachability and exploitation status. The lookup takes minutes. Building the inventory is the part that has to happen first.

This post covers why that question sets the pace of a response, what public directives and standards expect, the Safeguard flow step by step, and what an SBOM lookup cannot see. It stays on the response side: what you do in the hours after a public disclosure lands.

Key takeaways

• The speed of a vulnerability response is set by the quality of your inventory on the day before disclosure, not by how fast anyone types on the day itself.
• Safeguard's SBOM generation and analysis (GA) builds that inventory from source repositories, container images, AI models and uploaded files, and its vulnerability management (GA) re-evaluates every project daily as new CVEs are published.
• Search (GA) takes a CVE ID, a package name or a package plus version in plain text and returns the components, vulnerabilities and projects that match, including the projects where each component is used.
• Reachability analysis and prioritisation (GA), EPSS and CISA KEV status narrow a long list of affected projects to the ones that need action first. Safeguard does not promise a fixed reduction figure, and neither should you.
• The Safeguard CLI (GA) covers what is not connected yet: a local directory, a container image, a Git repository or an SBOM file, with results written as JSON.
• Supplier SBOMs and CSAF and VEX documents (GA) extend the lookup to software you buy, and record "not affected" decisions in a standard format.
• Policies and gates (GA) turn the answer into enforcement with Block, Warn and Notify actions. Autonomous remediation (GA) can open fix pull requests, and it ships switched off, with every category set to Manual.
• An SBOM lookup cannot see what you never scanned: vendor appliances, hosted services, laptops, phones and host operating systems you do not build. Those still need the vendor's advisory and your asset inventory.

Why "where does it live" is the first question

Every response to a newly disclosed vulnerability follows the same shape. Someone reads an advisory. Someone asks whether you are affected. Then, for a surprisingly long time in many organisations, nobody can answer, because the answer depends on knowing which of hundreds of services, images and products include a particular library at a particular version.

That gap is the part of the response clock you control. You cannot speed up the vendor's patch, the maintainer's release or the attacker's tooling. You can decide that the "are we affected" answer takes minutes rather than days.

The pressure on that clock is real and measurable from public data.

Google Threat Intelligence Group's review of 2025 says GTIG tracked 90 zero-day vulnerabilities exploited in the wild during 2025, up from 78 in 2024, and that 48 percent of them (43) targeted enterprise technologies, a record share. The same review counts operating systems as the most exploited category, at 44 percent (39 vulnerabilities). GTIG also notes that every zero-day in its 2025 dataset had a patch available by the time of writing, which is the point at which inventory becomes the bottleneck: once a fix exists, the only question left is where you need to apply it.

Google Project Zero's public "0day In the Wild" tracker makes a related point about tempo. On the page that introduces the tracker, Project Zero reports that across the cases it had collected, a new in the wild exploit was discovered every 17 days on average, and that vendors took 15 days on average to patch a vulnerability being used in active attacks. Those figures describe the dataset at publication, not today.

CISA's Known Exploited Vulnerabilities (KEV) catalog is the other public anchor. CISA describes it as the authoritative source of vulnerabilities that have been exploited in the wild and urges every organisation to use it as an input to vulnerability prioritisation. The catalog version dated 23 October 2026 lists more than 1,700 entries. Each entry carries a CVE ID, vendor, product, the date CISA added it, a required action and a due date for federal agencies. FIRST's EPSS is the complementary signal: a daily estimate of the probability that a published CVE will be exploited in the next 30 days. KEV records exploitation already seen; EPSS forecasts it.

A dated example: Log4Shell

Log4Shell (CVE-2021-44228) is the textbook case of an inventory problem, and every date in it is public.

Read the Apache Logging Services security page and two details stand out, and both are inventory details rather than exploit details.

First, the component. Apache lists log4j-core as the affected component. For the follow-up issue CVE-2021-45046 it states plainly that applications using only the log4j-api JAR without log4j-core are not affected by that vulnerability. A lookup that matches on "log4j" alone will flag projects that are fine and waste a day of someone's time.

Second, the version range. Apache gives the affected versions for CVE-2021-44228 as three separate ranges, with specific security releases on older branches excluded. NVD's description says the same in words: versions 2.0-beta9 through 2.15.0, excluding the security releases 2.12.2, 2.12.3 and 2.3.1. A simple "less than 2.15.0" check gets this wrong in both directions.

That is the lesson for any new disclosure. The question is never "do we use library X". It is "which artifacts contain component X at a version inside the affected ranges, and where are those artifacts running".

Without a queryable inventory, teams fall back on grepping manifests (which misses transitive and vendored copies), messaging every owner (answers arrive over days, from memory) or scanning everything in a hurry (hours of work at the worst moment). An SBOM lookup replaces all three with a query against data you already hold.

What the standards and directives expect

None of the documents below says "you must answer within minutes". Together they say that you must know what is in your software, keep watching it against public vulnerability data and act on known exploited vulnerabilities on a risk based timeline. That is the same job.

BOD 26-04: risk based remediation for federal agencies

On 10 June 2026 CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk". It revokes and supersedes BOD 22-01 (the 2021 directive that created the KEV catalog) and BOD 19-02. BOD 22-01 deadlines are history now and should not be quoted as current requirements.

BOD 26-04 sets remediation urgency from four questions, answered per CVE and per asset:

1. Asset exposure. Is the vulnerable asset publicly exposed?
2. KEV status. Is the CVE on CISA's KEV 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?

The directive says CISA publishes answers to the last three for every CVE ID through services such as its Vulnrichment program, while agencies answer the first from their own asset data. Table 1 in Appendix A then maps those answers to remediation timelines, informed by the Stakeholder-Specific Vulnerability Categorization (SSVC) method.

The directive binds federal civilian agencies, not private companies, but CISA's KEV page encourages every organisation to prioritise KEV entries. The practical point for this post: three of the four BOD 26-04 inputs describe the CVE, and one describes your asset. You cannot answer the asset question for a vulnerability you cannot locate.

NIST SSDF: respond to vulnerabilities, keep provenance data

NIST SP 800-218, the Secure Software Development Framework version 1.1 (February 2022), includes a practice group for responding to vulnerabilities. Task RV.1.1 asks producers to gather information from acquirers, users and public sources on potential vulnerabilities in the software and the third-party components it uses, and to investigate all credible reports. One of its listed examples is to automatically review provenance and software composition data for all components to identify new vulnerabilities.

Task PS.3.2 asks producers to collect, safeguard, maintain and share provenance data for all components of each release, "e.g., in a software bill of materials [SBOM]" in NIST's words. One of its examples is making that provenance data available to the organisation's operations and response teams to help them mitigate vulnerabilities.

In plain terms: keep an SBOM for every release, and give your responders a way to search it.

SBOM minimum elements and the formats that make lookups work

NTIA published "The Minimum Elements For a Software Bill of Materials" on 12 July 2021, as directed by EO 14028. It defines an SBOM as a formal record of the components used to build software and their supply chain relationships. CISA continues that work and describes an SBOM as a nested inventory of software ingredients.

Three format details matter for lookups:

• Standard SBOM formats. SPDX is an international open standard, ISO/IEC 5962:2021. CycloneDX is an open SBOM format with VEX support built in. A lookup engine needs one of these, not a spreadsheet.
• Package URLs. The purl specification gives every package a URL style identifier of the form scheme:type/namespace/name@version?qualifiers#subpath. An SBOM with purls can be matched to advisories precisely. One without them forces fuzzy name matching, which is where false positives and misses come from.
• Affected ranges in advisories. The OSV schema describes affected packages with explicit version ranges and enumerated version lists. That structure is what lets a tool decide that 2.12.2 is safe while 2.12.1 is not.

VEX: the "not affected" half of the answer

CISA describes a VEX document as an attestation, a form of security advisory that indicates whether a product is affected by a known vulnerability. CycloneDX describes VEX as conveying the exploitability of vulnerable components in the context of the product where they are used.

VEX matters here because a good lookup produces two lists: where the component is present and the vulnerability applies, and where the component is present but the vulnerability does not apply (the vulnerable function is not present, the code is not reachable, a configuration blocks it). The second list is as valuable as the first, because it stops the same question being asked again next week.

A useful answer to "are we affected" covers four things in order: where the component is, whether each copy's version is inside the affected ranges, whether it matters here (reachability, KEV, EPSS, exposure), and what the fix is and who owns it. The steps below map each one to a Safeguard screen, command or document.

Step by step: find every place a vulnerability lives with Safeguard

The flow below uses the Safeguard web application, the Safeguard CLI and the Safeguard connector in Claude. Every screen name, field and command 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, which the CLI docs say is authoritative when it disagrees with the page.

Step 1: Build the inventory before you need it

The lookup is only as good as what is in it. Safeguard's SBOM generation and analysis (GA) builds an SBOM for each project you connect, and its docs list four integration families on the Integrations page, filterable as Source Code (SCM), Container Image, AI Model and Upload.

• Source code. Bitbucket, generic Git, GitHub and GitLab (self-hosted or cloud), public or private. You pick repositories, set the branch or tag, the project name and the version, then click Connect.
• Container images. Amazon ECR, Docker Hub, GCP Cloud Source and any OCI compatible registry.
• AI models. Hugging Face.
• Uploads. CSAF or VEX files, Android APK files and package manifests such as package.json or requirements.txt. Existing SBOMs from other tools are uploaded through the Upload SBOM card.

Turn on Include Dev Dependencies if build and test tooling is in scope for a response.

The docs give typical generation times: under a minute for projects with fewer than 100 dependencies, two to five minutes for 100 to 500, and five to fifteen minutes above 500. That is why "in minutes" only holds when the SBOMs already exist. Generating them for a large estate on the day of a disclosure is the slow path this post is trying to avoid.

For a deeper look at SBOM generation and the formats Safeguard exports, see SBOM generation and analysis in Safeguard, from NTIA minimum elements to the CRA.

Step 2: Keep it current without a rescan on the day

Safeguard's vulnerability management (GA) is documented as performing daily continuous scanning of all projects, so that when new CVEs are published, projects are re-evaluated automatically to decide whether they are affected. The Generate SBOM page lists three extra triggers you can enable:

• On Push, which scans on every commit to monitored branches.
• Scheduled, daily, weekly or custom.
• On Release, which scans when a new tag is created.

Uploaded SBOMs are covered too. The Existing SBOM docs say uploaded SBOMs are continuously monitored with daily scans for new vulnerabilities, alerts on newly exploited CVEs from KEV updates, and tracking of newer dependency versions.

This is what makes a minutes-long lookup possible: when an advisory lands, you query data that is already current instead of scanning everything.

The docs list NVD, GitHub Security Advisories, OSV, CISA KEV, vendor bulletins and researcher disclosures as data sources. A brand new disclosure can take time to reach those feeds with structured ranges; Step 4 covers that window.

Step 3: Pin down exactly what you are looking for

Before you open Search, read the advisory and write down four things:

• The CVE ID, if one has been assigned.
• The package name and ecosystem, ideally as a purl (for example a Maven group and artifact, an npm scope and name, or a PyPI project).
• The affected version ranges, including any excluded releases on older branches.
• The fixed versions, per branch if the project maintains several.

Use the vendor or maintainer advisory as the primary source, then NVD and OSV. Note the exact artifact (log4j-core, not every Log4j artifact).

Step 4: Search by CVE ID, then by component and version

Open Search in the Safeguard web app. Search (GA) runs against your indexed SBOM and scan data, and the docs describe three basic query shapes that need no special syntax:

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

Those three lines are the docs' own examples. For a new disclosure, start with the CVE ID. If the CVE has already reached the vulnerability feeds Safeguard aggregates, the Vulnerabilities results show the CVE identifier, severity and CVSS score, the affected components and whether a fix is available.

Then search by component, with and without a version. This is the step that still works in the window where a CVE is brand new, or where no CVE has been assigned yet. A component result shows the package name and version, the projects where it is used, its vulnerability count and its license. That "projects where it's used" field is the answer to the first of the four questions.

You can also ask in plain English. The Search docs list examples such as "What packages are affected by Log4j?" and "Which projects have exploitable vulnerabilities?". Griffin reads filter-like intent (severity, license, project, reachability, exploitability) straight out of the sentence, so there is no query language to memorise.

Two Search features help during an incident:

• Inline mentions. Typing @ opens a picker to scope the query to one project, and : references a specific entity such as a component or vulnerability. Use them to stop a broad query from returning the whole estate.
• Conversation. Search keeps context, so you can ask a follow-up such as "which of these are exploitable?" and get the narrowed list without starting again.

One honest caveat from the docs' own FAQ: results only include projects and scans you have access to and that have already been processed. A component from a scan still in progress may not show up yet. If a query returns nothing for a component you are sure exists, broaden the wording first, then check whether the project was ever connected.

Step 5: Narrow the list to what needs action first

A lookup on a common library will often return a long list. Narrowing it is the second half of the job. Safeguard's reachability analysis and prioritisation (GA) and vulnerability management (GA) give you the signals to do it in the same conversation.

The Vulnerabilities docs list these filters: severity, CVSS range, EPSS range, exploitable status, component name, fix availability, reachability status and date range. They also describe the prioritisation signals Griffin uses:

• Exploitability: EPSS score, known exploitation in the wild from CISA KEV, public exploit availability and exploitable status.
• Reachability: whether the vulnerable code is actually called (call path analysis), runtime context such as production versus development, and configuration impact such as feature flags.
• Business context: asset criticality, data sensitivity and exposure level (internet facing versus internal).

Notice how closely that list lines up with BOD 26-04's four inputs. KEV status and exploitability come from public data. Exposure and criticality come from what you have told Safeguard about each project. If you have not recorded which services are internet facing, the platform cannot rank by it, and neither can you.

In Search, the plain English versions are short:

reachable and exploitable vulnerabilities only
critical vulnerabilities in my-app

Both are examples from the Search docs. Reachability support differs by language; check the reachability analysis docs for your stack before you rely on a "not reachable" verdict to close a ticket. For a longer treatment of ranking with these signals, see Prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard.

Step 6: Open each project and confirm the path

For each project on the shortlist, open it from Projects to reach the Project Overview page. The tabs that matter for an incident:

• Dependencies. A tree view shows parent and child relationships, dependency depth, version information and vulnerability indicators. This tells you whether the vulnerable component is a direct dependency your team chose or a transitive one pulled in three levels down, which decides who can fix it and how. A table view lists component name and version, license, vulnerability count and last updated date.
• Vulnerabilities. Total count, severity breakdown, affected component details, fix recommendations and the AI Remediate button.
• Mitigations. Active mitigations, risk acceptances with expiration dates, false positive markings and mitigation history. Check this before raising a new ticket, because someone may already have decided this project is not affected.
• Info. Project name, version or branch, generation method (SCM, Container or Manual), source repository and the branch or tag scanned. Confirm here that the SBOM matches what is deployed: an SBOM of main is not the release running in production.

Step 7: Export and save the answer

Search results export as JSON, CSV or PDF, according to the docs. Project SBOMs export in more than 30 formats, including SPDX (JSON, XML, RDF) and CycloneDX (JSON, XML).

Star the conversation as well. The docs describe Starred searches in the Search sidebar, meant for queries you come back to, such as a recurring triage sweep. For an active incident, a starred search for the CVE and the component gives everyone the same live view instead of a spreadsheet that goes stale by lunchtime.

Step 8: Cover what is not connected with the CLI

There is always something outside the platform: a repository nobody onboarded, an image built on a laptop, a supplier SBOM that arrived by email. The Safeguard CLI (GA) covers those cases. According to the CLI usage docs, safeguard scan builds an SBOM for one target, matches it against vulnerability databases and writes results as JSON under --output (default ./output).

These are the documented target forms:

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

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

# A Git repository
safeguard scan --repo https://github.com/org/repo

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

Results include vuln.json, license.json and collection.json, among others, in a folder per scan. To get the result into the platform next to every other project, the docs say to scan from the interactive terminal while signed in (safeguard, then /login, then /scan .). The runner uploads the SBOM and findings, never your source.

Three details from the docs matter on incident day:

• Refresh the databases first. safeguard update refreshes the local vulnerability databases. A scan against yesterday's data cannot match a CVE published this morning.
• Read the exit code properly. 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 clean pass will report "not affected" for a scan that never checked. There is no severity threshold flag; gating is done by policy gates in the platform.
• Check an SBOM before you trust it. safeguard validate sbom.json checks CycloneDX, SPDX and VEX documents (CSAF and OpenVEX) against their specifications. --strict treats warnings as errors.

The CLI does not upload SBOM files to the platform. The Existing SBOM docs say to upload them through the web app, which is Step 9.

Step 9: Find it in running containers, not just in registries

An image in a registry is not the same as an image running in production. If you run Podman hosts, the CLI docs describe a safeguard podman command that reads the local Podman store through the Podman REST API, with no Docker and no inbound connection needed:

safeguard podman inventory [--json]   # running containers grouped by image digest
safeguard podman scan --running       # the images of running containers

inventory answers "where is this image actually running" on that host, and results stay on the machine. For registry based tracking across environments, see Track container images per environment in Safeguard.

Step 10: Extend the lookup to software you buy

Much of an estate is software you did not build. If suppliers give you SBOMs, upload them through Integrations, then Connect on the Upload SBOM card. The Existing SBOM docs list CycloneDX 1.3 to 1.6 (JSON and XML) and SPDX 2.2 and 2.3 (JSON, tag-value and RDF), plus Syft and Trivy JSON (converted to CycloneDX) and Grype JSON (vulnerability data imported), up to 100 MB per file. After upload, Safeguard validates the file, enriches it with vulnerability matches, EPSS scores, KEV status, license and supplier data, and analyses it.

Once uploaded, a supplier's SBOM is searchable exactly like your own projects, so the CVE lookup in Step 4 covers it. The docs warn that packages with malformed or missing purls are tracked but cannot be enriched.

Supplier SBOM collection and vendor tracking sit in TPRM (GA). The sibling post SCA from a supplier SBOM in Safeguard walks through that flow end to end.

Step 11: Record the "not affected" answers with VEX

For every project where the component is present but the vulnerability does not apply, record the decision. Safeguard's CSAF and VEX upload (GA) accepts CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. In the web app you go to Integrations, filter by Upload, click Connect on Upload CSAF/VEX, name the upload, drop the file in, set the project name and version, and click Upload.

The docs' OpenVEX example shows the shape of a "not affected" statement:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2024/001",
  "author": "Example Corp",
  "timestamp": "2024-01-15T00:00:00Z",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2024-12345" },
      "products": [ { "@id": "pkg:npm/example-package@1.0.0" } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present"
    }
  ]
}

That example is copied from the Safeguard docs with placeholder values. Note the purl: a VEX statement is only as precise as its identifiers.

Inside a project you can also click Mark False Positive (with a justification, submitted for approval if policy requires) or Accept Risk (with an expiration date and a business justification). Use VEX for decisions you share outward and the in-app actions for internal triage; see Ingest and share VEX and CSAF in Safeguard.

Step 12: Stop new copies from shipping

Finding every existing copy is half the job. The other half is making sure no new build reintroduces the vulnerable version while you are fixing the old ones. Safeguard's policies and gates (GA) do that.

Policies are created under Settings, then Policies, then Create Policy, with a visual builder or YAML. The docs list conditions such as vulnerability severity, CVSS score and EPSS score, and each policy has an action that decides what a failure does to the gate:

Approvals are handled through exceptions: a developer requests one with a justification and an expiry date, approvers decide, and the audit trail records it. Gates are evaluated by the platform on the scans it runs for connected repositories. With policy outcomes turned on for your workspace, the docs show this CI command failing a job when a gate fails:

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

Start with Warn to see how many builds would fail, then move to Block once fixes exist. Policies can also be written in plain English (GA); see Plain English security policies to release gates in Safeguard.

Step 13: Open the fixes

Where a fixed version exists, the AI Remediate button on the Vulnerabilities page has Griffin analyse the vulnerabilities, propose changes and create pull requests after you review them. View Fix on a single vulnerability shows upgrade options and breaking change warnings.

At estate scale, autonomous remediation (GA) can open fix pull requests in bulk across every project that carries the vulnerable version. It ships switched off, with every category set to Manual, so nothing opens on its own until your team chooses a strategy. See Autonomous remediation in Safeguard for the categories and strategies.

Step 14: Ask the same question from Claude or ChatGPT

If your responders live in an AI assistant, they can ask the lookup question there. Safeguard is listed in the Claude connector directory as a community connector. Add it from the connector directory in Claude or ChatGPT, sign in to Safeguard when prompted, check the app name and the host on the sign-in page, and click Authorize access. The docs say there is nothing to install and no key to copy, that the assistant acts as you and sees only what your Safeguard role allows, and that each workspace controls which Safeguard tools an assistant can call.

From there, a plain question works:

Is CVE-2021-44228 anywhere in our estate? List the affected projects,
the component version in each, and whether a fixed version exists.

That prompt is an illustration, not output. The vulnerability record the assistant reads already carries how many projects and components the CVE touches, so it does not need to open every project. For setup detail, see Safeguard in your IDE and in the Claude and ChatGPT connector directories.

What the answer looks like

Here is a worked shortlist built from the fields Safeguard's docs list for search results and vulnerability details. The names are invented and it is not real output:

The last three rows are why precision matters. A name-only lookup would have raised five tickets. A version and artifact aware lookup raises two, records two clear "not affected" decisions and sends one question to a supplier.

Which path fits which part of your estate

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It cannot see what you never connected. Search covers indexed SBOM and scan data you have access to. A repository nobody onboarded, an image built and shipped outside your registries, or a supplier product without an SBOM returns no result. A "no matches" answer means "not in the inventory", which is not the same as "not affected".
• It does not cover vendor appliances, hosted services or host operating systems you do not build. GTIG's 2025 review says nearly half of tracked zero-days hit enterprise technologies, with security and networking devices a large share, and operating systems the most exploited category. Those fixes come from the vendor or distribution, and the lookup for them comes from your IT asset inventory, not from an SBOM of your code.
• It does not invent affected ranges before advisories publish them. Matching depends on the vulnerability data the docs list (NVD, GitHub Security Advisories, OSV, KEV, vendor bulletins, researcher disclosures). In the first hours after a disclosure, the component and version search in Step 4 is your tool, and you apply the advisory's ranges yourself.
• It does not know your exposure unless you record it. BOD 26-04's exposure question, and Safeguard's business context signals, depend on you recording which assets are internet facing and how critical they are.
• It does not decide on your behalf. Reachability and EPSS help order the list. Marking something not affected, accepting risk or shipping a VEX statement is your team's decision, and the docs route those through approval where policy requires.
• It does not open fixes by default. Autonomous remediation ships switched off, every category set to Manual. AI Remediate proposes changes you review before pull requests are created.
• It does not offer a working public REST API for search today. The Search docs say the page is UI driven and point to the hosted MCP server for programmatic access; the Existing SBOM docs carry a banner that the /v1 REST endpoints are not yet available. Use the web app, the CLI or the connector.

Common mistakes

Searching only by package name. A name match flags every project that mentions the library, including those on safe versions and those that ship a sibling artifact. Search by name and version, then check the affected ranges and the exact artifact.

Treating "no results" as "not affected". An empty result means the component is not in the indexed inventory you can see. Confirm coverage before you send the all clear.

Scanning main while production runs a tag. If the SBOM was built from a branch that has moved on, the lookup answers a question about unreleased code. Scan the branch or tag that is actually deployed, and check the Info tab.

Forgetting transitive dependencies. The vulnerable component is often three levels down. Use the Dependencies tree to see the path before you assign the fix to a team, because the fix may need an upgrade of the parent package rather than the vulnerable one.

Reading exit code 0 as clean. safeguard scan exits 0 whenever the scan ran, whatever it found, and 2 when results were written but the vulnerability scan did not run. Gate on policy outcomes in the platform instead.

Answering "not affected" in chat and nowhere else. A decision that lives in a message thread will be asked for again by an auditor or a customer. Record it as a VEX statement or an in-app mitigation with a justification.

Confusing KEV with EPSS. KEV says exploitation has been observed; EPSS forecasts the probability of exploitation in the next 30 days. A low EPSS score on a KEV-listed CVE is not a reason to wait.

Quoting revoked deadlines. BOD 22-01 was revoked by BOD 26-04 on 10 June 2026. If you cite federal timelines in an internal runbook, cite the current directive.

FAQ

How do I find which projects use a vulnerable library?

Search for the component name and version in Safeguard's Search page. Component results list the projects where the component is used, the vulnerability count and the license. Then check each match against the advisory's affected ranges.

Can I search my SBOMs by CVE ID?

Yes. Type the CVE ID into Search. If the CVE is already in the vulnerability data Safeguard aggregates, the results show severity, CVSS, the affected components and whether a fix is available. If it is too new, search by component and version instead.

How fast can I tell if a new CVE affects us?

If your projects are already onboarded and scanned, a Search lookup returns in minutes. If they are not, SBOM generation takes from under a minute to around 15 minutes per project according to Safeguard's docs, depending on dependency count. Build the inventory before you need it.

Does Safeguard automatically recheck old SBOMs when a new CVE is published?

The docs say Safeguard runs daily continuous scanning of all projects and re-evaluates them when new CVEs are published. Uploaded SBOMs are monitored daily as well, including KEV updates.

Can I check supplier software for a new vulnerability?

Yes, if the supplier gave you an SBOM. Upload it through Integrations and it becomes searchable like your own projects. Without an SBOM, rely on the supplier's advisory or a CSAF or VEX document from them.

How do I record that we are not affected by a CVE?

Upload a VEX document (CSAF 2.0, CycloneDX VEX, OpenVEX or CSAF VEX profile) through Integrations, or use Mark False Positive or Accept Risk inside the project with a justification and, for risk acceptance, an expiry date.

Do I need a query language to search SBOMs in Safeguard?

No. Safeguard's Search docs say plain terms work as they are (a CVE ID, a package name, a package and version), and filters such as severity, project, reachability and exploitability can be written as an ordinary sentence. Inline mentions such as @ for a project are optional shortcuts.

Does BOD 26-04 apply to private companies?

No. BOD 26-04 binds federal civilian executive branch agencies, and the directive says it does not apply to contractors unless their contracts require it. CISA still encourages every organisation to prioritise KEV vulnerabilities.

Safeguard runs as SaaS, in a private VPC, on premises or fully air-gapped, so the same lookup can stay inside your own environment. To try it on your own repositories, install the apps and the CLI from safeguard.sh/download, and read the full docs at docs.safeguard.sh. The free entry tier covers one existing repository plus one open source repository from GitHub, GitLab or Bitbucket, one project per month, SCA only.

Finding every copy is only useful if the fix follows quickly. The section below covers how Safeguard closes the time to a fix once the lookup has told you where to apply it, including the cases where no fixed version exists yet.

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, asks it to fix the lodash CVE in a repository, and shows it reading the finding and the advisory, asking before any command that changes something, editing package.json to lodash 4.17.21, running npm install and npm test with approval, and printing a summary without pushing anything. It ends with /permissions, /model and /scan ., the same scan that puts a project into the inventory this post depends on.

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

The second demo connects Claude to Safeguard with OAuth and shows how you choose which Safeguard tools Claude can use. Once connected, the "is this CVE anywhere in our estate" question from Step 14 can be asked in plain language from the assistant your responders already use.

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 and then scans from the terminal. It is the quickest way to bring a repository that was never onboarded into the inventory on the day you discover it is missing.

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

Quick check

Sources

• Google Threat Intelligence Group: 2025 Zero-Days in Review
• Google Project Zero: 0day "In the Wild"
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: KEV catalog JSON feed
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 26-04 Implementation Guidance
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST SP 800-218 full text (PDF)
• NTIA: The Minimum Elements For a Software Bill of Materials
• CISA: Software Bill of Materials
• SPDX specifications
• CycloneDX: Vulnerability Exploitability eXchange
• Package URL (purl) specification
• OSV schema
• FIRST: Exploit Prediction Scoring System
• NVD API record for CVE-2021-44228
• NVD API record for CVE-2021-45046
• Apache Logging Services: Log4j security vulnerabilities
• Safeguard Docs: Search
• Safeguard Docs: Explore SBOM
• Safeguard Docs: Generate SBOM
• Safeguard Docs: Vulnerabilities
• Safeguard Docs: Policies and Gates
• Safeguard Docs: Existing SBOM
• Safeguard Docs: CSAF and VEX Upload
• Safeguard Docs: CISA KEV Correlation framework
• Safeguard Docs: CLI Usage
• Safeguard Docs: MCP

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