New CVE, same SBOM: continuous re-scoring in Safeguard

When a new CVE, advisory or CISA KEV entry lands, Safeguard re-scores the components it already holds in your SBOMs against the new data, so you do not rebuild or rescan to learn whether you are affected. A rescan is needed only when the asset itself changes: a new commit, image tag or vendor SBOM. Every scan lands in a per-asset timeline with a diff.

This post is for the head of AppSec or vulnerability management lead who hears the same question in every evaluation: "A new CVE dropped this morning. Are we exposed, and do we have to rescan everything to find out?" It covers the mechanism as Safeguard's documentation describes it: which signals re-score and which rescan, how history and diffs work, how events and gates react, the air-gapped case (a custom engagement), and a step by step setup.

Key takeaways

• Two things are called "continuous scanning". Re-scoring compares components you already hold against advisories that just changed. Rescanning extracts a fresh component list from an asset that just changed.
• Feed changes re-score; asset changes rescan. A new CVE, GitHub Security Advisory or OSV entry, a CISA KEV addition or an EPSS change triggers re-scoring. A new commit, image tag or vendor SBOM triggers a rescan.
• Matching is inverted. New advisories are matched to stored components by package URL (purl), version range and CPE, and only affected assets are re-scored.
• Every asset has a Timeline. Each scan records when it ran, what triggered it, and a diff of findings added, resolved and changed in severity.
• Changes become signed events, and gates follow the data: policies are evaluated again after new assessment data arrives for a product, so a gate result can change with no code change.
• Air-gapped custom engagements get the same loop at the cadence of the offline bundles you import.
• Your SBOM is the ceiling. Re-scoring only matches what the inventory contains.

Why does a clean build-time scan go stale?

Safeguard's continuous scanning page puts it in one line: a dependency you shipped on Monday can become vulnerable on Thursday when a new CVE is published. Nothing about the artifact changed; the world's knowledge about it did. Vulnerability data comes from several bodies on different schedules:

• The CVE Program assigns identifiers and publishes the base record.
• The National Vulnerability Database (NVD), run by NIST, enriches CVE records with severity scores and product lists. Since NIST's 15 April 2026 change, enrichment is prioritized for CVEs in CISA's KEV catalog, for software used within the federal government, and for critical software as defined by Executive Order 14028; the rest are labelled "Lowest Priority, not scheduled for immediate enrichment", and NIST no longer routinely adds its own severity score when the CVE Numbering Authority supplied one.
• The GitHub Advisory Database publishes advisories mapped to package ecosystems such as npm, PyPI, Maven, NuGet, Go and RubyGems, with affected and patched version ranges. GitHub separates reviewed advisories, which its team has curated and mapped to packages, from unreviewed ones that come straight from the NVD feed.
• OSV publishes a machine-readable schema and a database that aggregates advisories from many ecosystems, each expressing affected versions as precise ranges per package.
• CISA's Known Exploited Vulnerabilities (KEV) catalog adds CVEs when there is reliable evidence of exploitation in the wild, a clear remediation action, and an assigned CVE ID.
• FIRST's Exploit Prediction Scoring System (EPSS) publishes a fresh probability for each CVE every day, estimating the likelihood of exploitation activity in the next 30 days.

Each can change the answer to "are we exposed, and how urgently" for an untouched artifact. A KEV addition changes how urgent an existing finding is. A corrected affected range can make a finding disappear. A new advisory against a package you have carried for two years creates one.

If you only compare components to advisories at build time, each of those changes waits for the next build. For a service that ships daily, that is a small gap. For the internal tool nobody has touched since spring, or the image pinned in production, it is the whole risk.

What triggers a rescan in Safeguard?

Safeguard's continuous scanning documentation names the signals that drive rescans. The two that matter for this post are:

1. Vulnerability feed updates. A new CVE, GHSA or OSV entry, a CISA KEV addition, or an EPSS score change that affects a component you use.
2. Asset change. A repository gets a new commit, a registry gets a new image tag, or a vendor uploads a new SBOM.

The ESSCM documentation adds the project-level triggers you switch on for each connected source: On Push (scan on every commit to monitored branches), Scheduled (daily, weekly or a custom schedule) and On Release (scan when a new tag is created). It also states that Safeguard performs daily continuous scanning of all your projects, so that when new CVEs are published your projects are re-evaluated to see whether they are affected.

Put together, the triggers fall into two families, and the distinction is the most useful thing to understand about the whole feature.

Re-scoring: the world changed, the asset did not

When an advisory changes, the components in your inventory are the same as yesterday. Safeguard does not need to clone the repository, pull the image or re-run a package manager resolution. It needs to ask: which stored components does this advisory apply to? That question is answered against the inventory Safeguard already holds, which is why the docs call it feed-driven re-scoring.

Rescanning: the asset changed

When a developer merges a pull request that adds a dependency, the component list itself is different. No amount of re-scoring against yesterday's SBOM will find the new package. That needs extraction: a fresh SBOM from the new commit, the new image tag, or the new vendor upload. On Push, On Release and registry triggers exist for this case, and the scheduled scan is the safety net for anything a webhook missed.

The decision table

Here is the core question from the top of this post answered for each kind of event. "Automatic" means Safeguard handles it from the trigger without anyone starting a scan.

If the inventory is current, a new advisory needs matching, not scanning. Keeping the inventory current is your half of the job.

How does feed-driven re-scoring work?

Safeguard's documentation describes the expensive part of scanning not as extraction but as comparison: every component against every known advisory. Done naively, a new advisory means walking every SBOM you hold. Safeguard inverts the direction:

1. Components are stored as searchable nodes in the Safeguard knowledge graph. The documentation does not go further into the storage, so treat the rest of this section as the behaviour it describes, not the internals.
2. New advisories are matched to components through package URL, version range and CPE resolution.
3. Only affected assets are re-scored. Assets that contain no matching component are never re-traversed.

The practical consequence is that the cost of a new advisory scales with how many of your assets contain the affected package, not with how many assets you have in total. That is what makes it reasonable to re-score on every feed change rather than once a night.

Package URL: naming the thing precisely

A package URL (purl) is the identifier that makes this matching reliable. The purl specification defines a single string that names a package across ecosystems, in the shape pkg:type/namespace/name@version?qualifiers#subpath. For example, pkg:npm/lodash@4.17.20 or pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1. The type says which ecosystem's naming and versioning rules apply; the namespace and name identify the package within it.

CycloneDX and SPDX SBOMs can both carry purls, and OSV advisories name affected packages with an ecosystem and package name that map onto them. When both sides speak purl, a match is an exact comparison of type, namespace and name, followed by a version range check.

Version ranges: is my version inside the affected span?

Knowing that an advisory concerns lodash is not enough. The OSV schema expresses affected versions as a list of ranges, each made of events: introduced (the first affected version), fixed (the first version that is no longer affected), and optionally last_affected or limit. The range type tells the consumer how to compare versions: SEMVER for semantic versions, ECOSYSTEM for the ecosystem's own ordering rules, and GIT for commit hashes. An affected entry can also carry an explicit list of versions.

That precision matters during re-scoring. If an advisory says introduced: 4.0.0 and fixed: 4.17.21, a component at 4.17.20 is in range and one at 4.17.21 is not. If a later revision of the advisory corrects the range, the OSV record's modified timestamp changes, and a consumer that re-matches on change picks up the correction. The same logic explains why re-scoring sometimes resolves findings: the advisory, not your code, moved.

CPE: the fallback for things without a package identity

Not every component is a package from a registry. Operating system packages in images, appliances and some commercial libraries are described in NVD with Common Platform Enumeration (CPE) names, which identify vendor, product and version. Safeguard's docs list CPE resolution alongside purl and version range for matching. CPE matching is coarser than purl matching because vendor and product strings are not always consistent across sources, which is one reason a component with a purl is easier to keep accurately scored than one without.

Worked example 1: a new advisory against a package you already carry

Take a hypothetical estate where some of your repositories include pkg:npm/example-parser at various versions. A GitHub reviewed advisory is published for example-parser with an affected range from 2.0.0 up to, but not including, 2.6.3.

• Re-scoring looks up the example-parser node and re-scores only the assets that contain it.
• For each one it checks the recorded version against the range. Assets on 2.0.0 through 2.6.2 get a new finding; assets on 2.6.3 or later, or on 1.x, are evaluated and stay clean.
• Repositories without example-parser are never touched.
• Each new finding fires an event, each affected asset's Timeline records the change with its trigger, and any gate whose policy the finding fails will now fail on that project.

Nothing was rebuilt or cloned.

Worked example 2: a KEV addition for something you already knew about

A medium-severity CVE with a low EPSS score has sat in the backlog for three months on an image you run in production. CISA adds it to KEV this morning.

• Nothing in the image changed and no new finding is created. The existing finding is re-scored.
• Its exploitation status changes. The ESSCM Vulnerabilities view has an "Exploitable" category for vulnerabilities with known active exploitation in the wild, and the finding now belongs there.
• Safeguard's event catalog has a dedicated event for this case: findings.vulnerability.severity_changed, fired when an EPSS, KEV or CVSS update changes the severity bucket.
• Notification routing in Safeguard can key on exploitation status, so a route for KEV-listed findings in production can page the owning team even though the CVSS score has not moved.
• If you run a policy that blocks actively exploited vulnerabilities (the policy conditions include "No actively exploited CVEs"), Safeguard evaluates policies again after new assessment data arrives for the product, so the gate can fail with no commit. The docs do not say how soon after a feed update that evaluation runs, so time it in the drill in Step 8.

Build-time scanning handles this case worst: the finding was already triaged and parked, and only a person reading the KEV feed would have resurfaced it.

Worked example 3: the advisory moved, not your code

An advisory said versions 3.0.0 through 3.4.9 of a library were affected, and your service on 3.4.2 has an open high finding. Today the maintainers correct the range: the flaw arrived in 3.4.5. Re-matching takes 3.4.2 out of scope and the finding resolves, with a feed update, not a commit, recorded as the trigger. Anyone asking later why it closed can see that the data changed, not that someone dismissed it.

What gets scanned continuously, and how often?

The continuous scanning documentation lists each asset type with its frequency and mechanism. The table below reproduces the rows relevant to this post, as the documentation states them.

Every row pairs an event-driven trigger with a scheduled one, so a dropped webhook does not become a permanent blind spot. The SBOM row matters most for third-party software: a vendor SBOM you uploaded once keeps being re-scored against new advisories without the vendor doing anything. The docs advise most teams to leave the default frequencies on; overrides live under Policies, then Scan Policies.

What do the rescan history and diffs show?

This is the part of continuous scanning that turns it from a background process into evidence. According to the documentation, every asset shows a Timeline of scans, and each entry records:

• When the scan ran and what triggered it. A push, a schedule, a release tag, a feed update or a new upload.
• The diff of findings from the previous scan. Findings added, findings resolved and findings whose severity changed.
• A Griffin-written summary of what changed since the last scan, including whether new findings sit in production-reachable code paths. Griffin is Safeguard's security model.

The docs describe the purpose plainly: you can see exactly when a finding entered or left the system, which makes postmortems straightforward.

Reading a diff

Each of the three diff categories answers a different question.

The trigger recorded with each entry is what lets you separate the two kinds of change. A finding added by a commit is a development process question: why did a known-vulnerable version get merged? A finding added by a feed update is a disclosure question: how fast did we route it once it was knowable? Mixing those two up is the most common reason a vulnerability management report gets challenged.

Using the Timeline in a postmortem

When someone asks how long a vulnerability sat in production, three timestamps matter. The Timeline holds two: the entry where the finding first appears (when the risk became knowable, with its trigger) and the entry where it resolves (when the fix landed). The third, deployment, comes from your own records. Our suggestion: start any review of a missed vulnerability from the entry where the finding was added and work forward.

Mitigations and history

The diff covers what the scanner saw; the project's Mitigations tab covers what people decided, with risk acceptances and their expiry dates, false positive markings and mitigation history. A reviewer needs both halves.

How do re-scored findings reach people and systems?

A re-score that nobody sees has not reduced any risk. Safeguard offers two routes out: notification routes for people, and events for systems.

Notification routes

According to the continuous scanning page, when a continuous scan produces a new or escalated finding, Safeguard routes the alert by:

• Owner, taken from CODEOWNERS, container labels or manual assignment.
• Severity band: critical, high, medium or low.
• Exploitation status: KEV-listed, a high EPSS score, or a public proof of concept.
• Environment: production alerts can flow differently from development sandboxes.

Routes are configured under Settings, then Notifications, to chat channels, ticket creation, daily or weekly email digests, on-call paging for critical KEV findings in production, and a generic webhook. "New or escalated" matters: a re-score that moves an existing finding into a higher band counts, so worked example 2 produces an alert with no new finding. Our suggestion is to start with one route, KEV-listed findings in production paging the owning team, and send everything else to tickets and digests.

Events and webhooks

For systems, Safeguard publishes state changes as events named domain.subject.verb. The ones that matter here:

You create an HTTP webhook subscription on the Webhooks page with an endpoint URL, the event types, a signing secret and an optional filter. Filters run on Safeguard's side and use a subset of the policy expression language, for example:

severity in ["critical","high"]
AND env == "production"
AND finding.kev == true

The reliability contract is the part to design around:

• Delivery is at least once. Every payload carries an X-Safeguard-Event-Id header, and consumers must deduplicate on it.
• Retries back off exponentially over 24 hours, and undelivered events land in a dead-letter queue you can replay.
• Ordering is per subject. Within one event type, created_at increases monotonically for a given finding or asset.
• Every payload is signed. The X-Safeguard-Signature header carries a timestamp and an HMAC SHA-256 signature over the timestamp and body.
• Test events are marked. Synthetic test payloads include "test": true so a consumer can ignore them in production.

Safeguard's docs give a verification function. A minimal consumer built on it, in Python, looks like this:

import hmac, hashlib, time

SEEN = set()  # use a durable store in production

def verify(secret: bytes, header: str, body: bytes) -> bool:
    parts = dict(p.split("=", 1) for p in header.split(",", 1)[1].split(","))
    ts, sig = parts["t"], parts["s"]
    if abs(time.time() - int(ts)) > 300:  # reject stale events (replay guard)
        return False
    expected = hmac.new(secret, f"{ts}.".encode() + body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, sig)

def handle(headers: dict, body: bytes, secret: bytes):
    if not verify(secret, headers["X-Safeguard-Signature"], body):
        return 401
    event_id = headers["X-Safeguard-Event-Id"]
    if event_id in SEEN:  # at-least-once delivery: drop duplicates
        return 200
    SEEN.add(event_id)
    # route by event type, for example open a change record on severity_changed
    return 200

The verification function is from Safeguard's documentation; the deduplication wrapper is our suggestion. The five-minute replay window comes from the documented example, and you can tighten it.

How do gates react when a finding is re-scored?

Policies evaluate your SBOMs and generate findings; gates enforce them. A policy can have a Block action (the gate fails), a Warn action (the gate passes with a warning naming the policy) or a Notify action (the gate passes and a notification is sent). Gates are evaluated by the platform on the scans it runs for your connected repositories, and with policy outcomes turned on for your workspace, this command fails a CI job when the gate fails:

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

Re-scoring has a consequence here that teams often discover the hard way. A gate's result depends on the policy, the components and the advisory data. Safeguard's policy documentation says a policy is evaluated when it is linked to a gate and again after new assessment data arrives for the product, so the same commit can produce a different gate result. A release branch that passed on Tuesday could fail on Wednesday because a component it carries became actively exploited overnight.

That is the gate doing its job, but it lands on a team that changed nothing. Our suggestions: roll new Block policies out as Warn first; tell feed-triggered failures apart from commit-triggered ones using the Timeline trigger, because a developer whose build broke over a KEV addition needs a fix path, not a lecture; and use time-boxed exceptions. Safeguard's exception workflow takes a justification and an expiration date and records an audit trail, and when an exception expires a policy.exception_expired event fires.

What changes in an air-gapped custom engagement?

Re-scoring depends on fresh feeds, which seems to rule out sites with no internet egress. Safeguard's documentation describes how it works there.

• Offline bundles. Vulnerability database updates arrive as offline bundles that you import by hand with the CLI update command, on a schedule you pick, and check against the published checksum.
• Delta application. A helper downloads the snapshots and applies the deltas to the on-premises instance. No component inside the perimeter calls outbound.
• Local rescans. Rescans run locally the moment the delta is applied.
• Bundle contents. Bundles carry vulnerability feed data including NVD, the GitHub Advisory Database, OSV and CISA KEV, plus daily EPSS data, which you carry in by removable media or another route your security team approves.

For individual machines, the Safeguard CLI has an offline path too: safeguard update --import loads a vulnerability database downloaded elsewhere.

The trade-off is plain: air-gapped re-scoring runs at your import cadence, not the feed cadence. With weekly snapshots, a KEV addition can take up to a week to reach your findings. Our suggestion: choose the cadence by asking how long you are willing to be unaware of a KEV addition.

Step by step: set up continuous re-scoring for a pilot

This walkthrough uses only steps and commands from Safeguard's documentation. Menu names are as the docs give them.

Step 1: connect the sources that ship

From Integrations in the sidebar, use Add Project/Product to connect your source code hosts (GitHub, GitLab, Bitbucket or a generic Git URL) and the container registries your deployments pull from (Amazon ECR, Docker Hub, an OCI registry, and others listed on the page). For third-party software you cannot connect, use the upload options: a manifest file, or CSAF and VEX files.

For each repository, set the branch or tag to track. Track the branch that deploys, not only the default branch, if they differ.

Step 2: switch on the scan triggers

For each connected project, enable:

• On Push for monitored branches.
• Scheduled, daily at minimum, as the catch-up path for missed webhooks.
• On Release so every tag produces a scan you can tie to a version.

The daily continuous scan of all projects runs regardless; these triggers make sure the component list itself is fresh.

Step 3: produce a first scan locally

Install the CLI and scan one repository to see the data shape before you rely on the platform path.

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# Open the interactive terminal, then type /login and /scan .
safeguard

# Or scan from the command line, writing results under ./output
safeguard scan --dir .

According to the docs, a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and your source never leaves the machine. The CLI can also scan a container image or an existing SBOM.

Step 4: check the SBOM has purls

Open the project's Dependencies tab and spot-check that components appear with names and versions. If an SBOM you upload from elsewhere lacks package URLs, fix the generator before relying on re-scoring for it.

Step 5: set notification routes

Under Settings, then Notifications, create the KEV-in-production route first, then routes by owner, severity band and environment.

Step 6: subscribe a system to events

On the Webhooks page, create a subscription to findings.vulnerability.created, findings.vulnerability.severity_changed and findings.vulnerability.resolved, with a filter for production and critical or high severity. Point it at a consumer that verifies the signature and deduplicates on event ID, as in the code above. Use the synthetic test event the docs describe (its payload carries "test": true) and confirm your consumer ignores "test": true payloads in production.

Step 7: gate in CI, starting with Warn

Create a policy from a template such as No Critical Vulnerabilities, set its action to Warn, and add the gate to CI with safeguard ci scan --wait --fail-on-gate <gate>. After two weeks of Warn results, switch the action to Block for the projects that are ready.

Step 8: rehearse the "new CVE tomorrow" drill

Pick a CVE that was added to KEV in the last month and that affects a component you carry (look it up in the CISA catalog). Open the affected project's Timeline and find the entry where the finding's severity changed. Check that the route fired, the event was delivered, and the gate result matches your policy. If any of those failed, you found the gap on a quiet day instead of an incident day.

A runbook for the morning a KEV entry lands

A suggested sequence, not a product feature, assuming Steps 1 to 7 are in place.

If a finding the team believes is fixed is still open, check whether the fix reached a monitored branch or registry. Re-scoring cannot see a fix that lives only on a laptop.

Why "dynamic as facts change" is now the federal standard

CISA's Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk", issued on 10 June 2026, builds the same idea into federal patching rules. It carries forward the KEV catalog criteria from BOD 22-01, the 2021 directive that created the catalog: an assigned CVE ID, reliable evidence of active exploitation in the wild, and a clear remediation action.

Under BOD 26-04, the remediation timeline for a vulnerability on an asset is decided from four factors: KEV status, exploit automation, technical impact and asset exposure. CISA publishes answers to the first three for every CVE ID through services such as its Vulnrichment program; the agency answers asset exposure for its own systems. The directive says the timelines for each asset are dynamic as facts change, and gives an example: removing a system from the internet changes "Publicly Exposed" from yes to no and pushes the required timeline back. Timelines begin when CISA adds the vulnerability to the KEV catalog, or when the agency identifies the vulnerability on an asset.

Three of the four factors change without any change to your code, and the fourth changes with your deployment, not your SBOM. A program that scores only at build time cannot keep up with a clock that starts when CISA updates a catalog. Only federal agencies are bound, but CISA's KEV page says every organization should use the catalog as an input to vulnerability prioritization.

What continuous re-scoring will not do

• It cannot find components that are not in the inventory. Vendored source, binaries dropped into an image by hand, and code loaded from paths no manifest mentions are invisible to SBOM-based matching.
• It cannot match what the advisory does not identify. An advisory with no package mapping, or a CPE whose vendor and product strings do not line up with how your SBOM names the component, will not match cleanly. Under NVD's April 2026 prioritization, a CVE outside the priority groups may carry no NVD product list for some time, so a component that is only identifiable by CPE can stay unmatched until another source, such as an ecosystem advisory with package ranges, covers it.
• It does not make vendor SBOMs current. If the vendor shipped three releases since the SBOM you hold, you are scoring the wrong product.
• It does not fix anything by itself. A re-scored finding is information; remediation is the next step.

How this fits with the rest of the program

Continuous re-scoring answers "which assets does this new advisory affect, and did that change since yesterday?" Several neighbouring questions have their own walkthroughs:

• Keeping the inventory current is the precondition for everything above. SBOMs per release in CI with Safeguard covers generating, attesting and diffing an SBOM for every release.
• When you need a list of every place one component lives right now, find every place a newly disclosed vulnerability lives in your estate covers the SBOM lookup.
• Once the re-score has flagged a KEV entry across many projects, remediate a KEV vulnerability across hundreds of repos covers reachability, bulk pull requests and gates.
• Choosing which scan runs where in the pipeline is covered in scan modes in the pipeline.

Common mistakes

1. Rescanning everything for every new CVE. If the inventory is current, a new advisory needs matching, not extraction.
2. Relying on webhooks alone. Keep the scheduled scan on as the catch-up path, even where On Push is enabled.
3. Connecting the build registry but not the deploy registry. Images get retagged and promoted; connect the registries your clusters pull from.
4. Uploading vendor SBOMs once. Last year's SBOM is re-scored correctly but describes a product you may no longer run.
5. Ignoring the trigger column. Reporting every added finding as "new vulnerabilities" mixes regressions with disclosures. Split them by trigger.
6. Switching new policies straight to Block. Re-scoring will fail gates on unchanged code. Warn first.
7. Webhook consumers without deduplication or signature checks. Delivery is at least once, and an unauthenticated endpoint that opens tickets invites noise.
8. Permanent exceptions. With no expiry, nothing prompts anyone to look at the finding again.

FAQ

Do I need to rescan my SBOMs when a new CVE is published?

No, if the SBOM is current. Feed-driven re-scoring matches new advisories against stored components by package URL, version range and CPE, and re-scores only affected assets. A rescan is needed when the asset changes: a new commit, image tag or vendor SBOM.

What happens when a CVE I already have is added to CISA KEV?

The existing finding is re-scored. Its exploitation status changes, it can move severity bucket, a findings.vulnerability.severity_changed event fires, and KEV-keyed routes alert the owner. A policy that blocks actively exploited vulnerabilities is evaluated again after new assessment data arrives for the product.

How often does Safeguard scan repositories and images?

Per the documentation, repositories on every push plus an hourly pull for missed webhooks, images on push plus a periodic pass for running images, and every project gets a daily continuous scan. Projects can also scan on a schedule and on each release tag.

Where can I see what changed between two scans?

On the asset's Timeline: when each scan ran, what triggered it, and the diff of findings added, resolved and changed in severity, with a summary by Griffin, Safeguard's security model.

Can a finding disappear without anyone fixing it?

Yes, if the advisory's affected range is corrected or withdrawn. The Timeline records a feed update as the trigger, which tells it apart from a fix or a dismissal.

Does continuous scanning work air-gapped?

Yes. In an air-gapped custom engagement, vulnerability database updates arrive as offline bundles on a cadence you choose, you import them by hand and check them against the published checksum, and rescans run locally. Findings are as current as the last snapshot.

Will my CI pipeline fail when a dependency is added to KEV?

It can. Policies are evaluated again after new assessment data arrives for the product, so a policy blocking actively exploited vulnerabilities can fail a gate with no code change. Time it in your own drill.

How is EPSS different from KEV in re-scoring?

KEV records exploitation that has happened. EPSS is a daily probability of exploitation activity in the next 30 days. Both trigger re-scoring; KEV changes exploitation status, EPSS shifts priority.

Why the fix still matters after the re-score

Re-scoring tells you within the feed cycle that a component you ship has become a problem; it does not change the component. The work that reduces risk is moving to a fixed version, or getting a fixed build when upstream has none, and doing it across every asset the re-score flagged.

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 policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. 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. Auto-merge is a separate switch and stays off by default, so your team decides what merges 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 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 sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is one way to keep the inventory current for code that never reaches a connected repository, which is the blind spot re-scoring cannot cover on its own.

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

The second demo is a real Safeguard CLI session. A developer asks the assistant to fix a lodash CVE; it 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. It is what happens next when a feed update adds a finding to a service someone owns.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. On the morning a KEV entry lands, this is how a security engineer asks which projects carry the affected component without opening each one.

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

To try Safeguard yourself, download the apps or start with the CLI documentation.

Quick check

Sources

• Safeguard docs: Continuous Scanning
• Safeguard docs: ESSCM Vulnerabilities
• Safeguard docs: Generate SBOM
• Safeguard docs: Explore SBOM
• Safeguard docs: Webhooks and Events
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Air-Gapped Deployment
• Safeguard docs: Safeguard CLI
• Safeguard docs: CLI usage guide
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: EPSS Frequently Asked Questions
• OpenSSF: OSV schema
• Package URL specification
• GitHub Docs: About the GitHub Advisory Database
• NIST NVD: News
• NIST NVD: Official CPE Dictionary
• CycloneDX: Vulnerability Exploitability Exchange (VEX)
• FIRST: CVSS v4.0 Specification
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk

Last reviewed: 27 October 2026.