Remediate a KEV Vulnerability Across Hundreds of Repos with Safeguard

To remediate a CISA KEV vulnerability across hundreds of repositories in Safeguard, filter the Vulnerabilities view to the KEV-listed CVE, rank the affected projects by reachability, exposure and environment, and fix them in waves with bulk AI Remediate, which opens one pull request per repository. Then link a Block policy to a gate and run safeguard ci scan --wait --fail-on-gate in CI so the vulnerable version cannot come back. Autonomous remediation ships switched off, with every category set to Manual, so a person approves each wave until you decide otherwise.

Finding where a vulnerability lives is the first hour of the job. Our post on portfolio sweeps and blast radius covers that part in depth. This post covers everything after: deciding the order, getting hundreds of fixes merged without flooding teams, stopping regressions, handling the repositories you cannot fix yet, and keeping the evidence that shows you did it.

Key takeaways

• Vulnerability management (GA) enriches every CVE with CVSS, EPSS and CISA KEV status, and Safeguard re-evaluates projects when vulnerability feeds change, including KEV additions.
• Reachability analysis and prioritisation (GA) combines reachability, exploitability, runtime context and business context into one priority score from 0 to 100. Reachability depth varies by language, so check the docs for your ecosystem.
• Autonomous remediation with Griffin fix pull requests (GA, ships off) works on one finding, on a selection in bulk (one pull request per repository), or on a whole page. It starts with every category set to Manual.
• Policies and gates (GA) turn "this CVE must not ship" into a check. Each policy's action is Block, Warn or Notify, and approval for a justified deviation runs through exceptions with an expiry date.
• The Safeguard CLI and CI integration (GA) fail a pipeline on a gate with safeguard ci scan --wait --fail-on-gate. safeguard scan on its own never fails a build.
• The Safeguard MCP server (GA) lets Claude or ChatGPT read estate-wide blast radius once you add Safeguard from the connector directory. It is read only; fixes and gates happen in the web app, the CLI or CI.
• BOD 26-04 (10 June 2026) is the current federal directive. It revoked BOD 22-01, so 22-01's fixed deadlines are history.

The problem: one KEV entry, three hundred repositories

A new entry lands in CISA's Known Exploited Vulnerabilities catalog. The component is a widely used open source library. Within the hour someone asks the question every AppSec lead dreads: "Are we exposed, and when will it be fixed everywhere?"

In most organisations the honest answer is a spreadsheet and a few dozen copied tickets. Weeks later some are closed, some are "in progress", and some have bounced back with "we don't call that function" or "it breaks the build". Meanwhile new services pin the vulnerable version because their template still does. Each failure has a cause:

• The blast radius is not one number. A library can appear as a direct dependency in some repositories, a transitive dependency several levels down in others, and inside a base image in a few more. Each needs a different fix.
• Not every hit is equally urgent. A vulnerable function that a public API calls on every request is a different problem from the same library in a test fixture. Treating them the same either burns weeks of engineering time or, more often, means the urgent ones wait in the same queue as the harmless ones.
• Tickets are not fixes. Each ticket asks a team to research, upgrade, resolve conflicts and test. Across hundreds of repositories the research alone eats the deadline.
• Fixes regress. Without a pipeline check, an old template or a transitive pull brings the vulnerability straight back.
• Exceptions vanish, and evidence is rebuilt later. "We'll accept this one for now" is said in a meeting and never written down, and "how long did it take?" gets answered from chat logs.

What standards and regulators expect

Several primary sources turn "fix exploited vulnerabilities fast, and prove it" from good practice into an obligation or a buyer expectation.

CISA BOD 26-04, "Prioritizing Security Updates Based on Risk" (10 June 2026). This binding operational directive applies to US federal civilian executive branch agencies. It sets remediation urgency from four variables: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether an adversary can automate every step of exploitation, and whether exploitation gives partial or total control. The timelines themselves sit in the directive's Table 1, which you should read directly rather than from a summary. The directive also requires agencies to establish internal validation and enforcement procedures and tracking and reporting requirements, to monitor KEV catalog updates and mitigate aggressively, and, within 180 days of issuance, to remediate each vulnerability as quickly as possible and no later than Table 1's timelines. It supersedes and revokes BOD 19-02 and BOD 22-01.

BOD 22-01 is history. BOD 22-01 (November 2021) created the KEV catalog and attached a fixed due date to each entry. That model no longer applies to agencies. If an internal policy still cites 22-01 deadlines, it is out of date. KEV entries now carry BOD 26-04 language, including a due date and a "Forensic triage required per BOD 26-04" field, so read each entry rather than assuming one window fits all.

The CISA KEV catalog. CISA describes the catalog as the authoritative source of vulnerabilities exploited in the wild and tells organisations to use it as an input to their prioritisation framework. You do not need to be a federal agency for that advice to apply, and many security questionnaires now ask how quickly you act on KEV entries.

CISA Vulnrichment and SSVC. BOD 26-04 notes that CISA publishes KEV status, exploit automation and technical impact for every CVE ID through services such as Vulnrichment, which scores CVEs with CISA's SSVC decision points (Exploitation, Automatable, Technical Impact). Public exposure only you can answer.

FIRST EPSS. The Exploit Prediction Scoring System publishes, every day, a probability from 0 to 1 that a published CVE will be exploited in the wild in the next 30 days. It is a ranking signal, not a severity score, and it is most useful for CVEs that are not on KEV yet.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1. The Respond to Vulnerabilities group spells out the work. RV.1.1 asks producers to gather information on potential vulnerabilities in their software and its third-party components. RV.2.1 asks them to analyse each vulnerability to gather enough information about risk to plan the response. RV.2.2 asks them to plan and implement risk responses. RV.3.3 asks them to review the software for similar vulnerabilities and fix them before external reports arrive. A KEV entry in a shared library is exactly the case RV.3.3 describes: one finding is a signal to look everywhere the same component lives.

Put together, these sources ask for five things: know where the vulnerable component is, rank by real risk, fix fast, keep the fix in place, and keep records. The rest of this post maps each to a Safeguard step.

The remediation-at-scale loop

At estate scale the work is a loop, not a ticket. Here is the loop in one table before the detail.

The stages overlap: the first wave is in review before the last is ranked, and the gate goes in early, in Warn.

How Safeguard handles it, step by step

The steps below follow Safeguard's docs. Where the docs show a screen, a setting or a command, it is named exactly. Where they do not, the post describes the outcome instead of inventing a click path.

Step 0: before the CVE lands

The fastest remediation is the one where the groundwork already exists. Three things are worth doing on a quiet day.

1. Get coverage honest. Connect source control so repositories are imported as projects, compare the project list with your real repository inventory, and record the gap.
2. Label environments and exposure. Safeguard's prioritisation uses runtime context labels for environment (production, staging, dev, sandbox) and exposure (internet facing, internal, air-gapped). BOD 26-04's first variable is public exposure, so these labels are what lets Safeguard rank an internet facing service above an internal batch job. Without them, everything looks the same.
3. Review AI Remediate settings (Step 4) with engineering leads, so you know in advance what you will run in bulk and what waits for a reviewer.

Safeguard performs daily continuous scanning of all projects, and the docs say projects are automatically re-evaluated when new CVEs are published. Its continuous scanning page lists CISA KEV additions and EPSS score changes among the feed updates that trigger rescoring. That is what lets the "find" step start from current data rather than last month's scan.

Step 1: find the blast radius (briefly)

The full method is in the portfolio sweeps and blast radius post. The short version, in three routes:

1. In the web app. Open the Vulnerabilities tab. Its overview groups vulnerabilities into Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation in the wild. Filter by exploitable status and component name, or use the reachability filters from the prioritisation docs, such as kev:true. Each vulnerability record shows the CVE ID, CVSS, EPSS, exploitable status, affected component and version, fixed version and reachability.
2. With Griffin natural language search. The docs show queries such as "Show me critical vulnerabilities in production that are actively exploited".
3. From Claude or ChatGPT. Add Safeguard from the Claude or ChatGPT connector directory, sign in, and ask. Safeguard's public safeguard-at-scale skill teaches the assistant to read blast radius from a single vulnerability call: each record carries how many projects contain the CVE, how many distinct components, and how many occurrences in total. That avoids looping over hundreds of projects.

List stale or incomplete scans separately, since they cannot tell you they are affected, and exclude demo projects from counts. Step 1 ends with three lists: affected projects, the distinct components and versions involved, and projects you could not assess.

Step 2: rank by real risk, not by count

Three hundred affected repositories is not three hundred equal problems. Safeguard's prioritisation engine gives each finding a priority score from 0 to 100, combining four signals:

1. Reachability. Does your code actually call the vulnerable function? The docs describe static reachability (a call graph from source, lockfile and bytecode), dynamic reachability (a runtime collector recording what is loaded and invoked) and configuration reachability (framework configuration that decides whether code is wired in). Each finding is classified as reachable, conditionally reachable, unreachable or unknown.
2. Exploitability. EPSS (Safeguard ingests the daily feed), KEV status, and whether a public proof of concept exists.
3. Runtime context. Environment, exposure, data class and criticality labels.
4. Business context. Which assets are regulated, which handle customer data, which are on the critical path, declared through policy.

The weights are configurable per tenant under Settings › Prioritization. The defaults the docs publish map neatly onto a KEV response:

For a KEV-listed CVE, KEV status is already true for every affected project, so the ranking inside your blast radius comes from reachability, environment and exposure. The docs give the filter that isolates the P0 backlog in the Vulnerabilities table:

env:production reachable:true kev:true

The Vulnerabilities table has a Priority column and a Reachability column, and the default sort is Priority descending.

What "unknown" means at scale

Reachability analysis has limits, and the docs are direct about them. It is weakest when code runs through reflection, eval or dynamic dispatch, when the vulnerability is data driven (the danger is in what input reaches a function, not whether the function is called), and when the vulnerable path only runs under configurations the analyser cannot enumerate. Findings the analyser cannot decide are marked unknown and treated conservatively as potentially reachable, not suppressed.

At estate scale that matters. If you have three hundred affected repositories, expect a real share of them to come back unknown, particularly in dynamic languages. Put unknown findings in the same wave as reachable ones until someone has looked. Reachability depth varies by language, so in dynamic-language estates lean more on KEV, EPSS and runtime context.

Mapping BOD 26-04's four variables to what Safeguard holds

Use Safeguard's priority score as an input to your BOD 26-04 timeline, not a replacement for it. Table 1 is the authority for agencies, and your own policy is the authority for everyone else.

Turning the ranking into waves

A practical split for a KEV response:

• Wave 1: reachable or unknown, production, internet facing. These are the findings a P0 filter returns, plus the unknowns. Fix them first, with a human reviewing every pull request.
• Wave 2: reachable or unknown, production, internal. Same treatment, slightly more time.
• Wave 3: conditionally reachable, or non-production environments. Batch these more aggressively once Wave 1 has shown how the fixes behave.
• Wave 4: unreachable. Fix them anyway, on a schedule, because unreachable today is not a promise about tomorrow's code. They also keep the gate in Step 6 clean.

Write the waves down with owners and dates; that record is evidence for Step 8.

Step 3: decide where the fix belongs

Before you open hundreds of pull requests, look at the component list from Step 1. The safeguard-at-scale skill makes a useful rule of thumb: anything that appears in more than about a quarter of projects is probably a platform level fix. Sort by occurrence count and affected project count, and ask where the dependency enters.

• A shared internal library or service template that pins the vulnerable version. Fix it once at the source, release it, and then the per-repository fix is a bump of your own library. Opening three hundred pull requests against the transitive pin without fixing the template means the next new service brings it back.
• A base container image. If the vulnerable component arrives through the image rather than the application's lockfile, the fix is a new base image and a rebuild, not a lockfile change. See the container base image post if your blast radius includes images.
• A direct dependency in each repository. This is where bulk AI Remediate does the most work.
• A transitive dependency several levels deep. AI Remediate's docs say it handles transitive dependency conflicts and updates lock files. Some ecosystems still need a resolution override if the parent package has not released a version with the fix. Expect those pull requests to need a closer look.

Route platform fixes to the owner of the template or image; route the rest into the bulk flow.

Step 4: configure AI Remediate before you run it in bulk

Autonomous remediation ships switched off. Every category starts at Manual, and nothing is applied until an administrator enables it. Remediation categories include dependencies, license, security posture, findings, attestation, provenance, compliance and code quality, each set separately to Manual or Auto with its own strategy. For a KEV response you only need the dependencies category; leave the others alone. The autonomous remediation post covers the categories and strategies in full.

The AI Remediate docs list these settings under Settings › AI Remediate:

The docs' own best practices say the same thing in fewer words: enable tests, start with safe fixes, review major changes, do not auto-merge breaking changes, and track the fix success rate.

Check the supported ecosystem table before you plan. The docs list full AI Remediate support for npm, yarn and pnpm; pip, poetry and pipenv; Maven and Gradle; Go modules; Cargo; Bundler; NuGet; and Composer. If part of your blast radius is in something else, plan a manual route for it.

Step 5: open the fixes in bulk

The AI Remediate docs describe three ways to start, and a KEV response uses all of them at different moments.

1. Single vulnerability. Navigate to the vulnerability, click AI Remediate, review the proposed changes, click Create Pull Request. Use this on the first two or three repositories in Wave 1 to see what the fix looks like in your codebase before you scale.
2. Bulk AI Remediate. Select the vulnerabilities to fix, click AI Remediate Selected, and Griffin batches compatible fixes. Review all the changes, then create the pull requests, one per repository. This is the main tool for Waves 1 to 3.
3. Page-level AI Remediate. On the Vulnerabilities page, click AI Remediate at the top. Griffin analyses all fixable vulnerabilities and presents a remediation plan for you to review and approve before pull requests are created. Use this for Wave 4 or for a broader clean-up after the KEV fix is done.

Behind each of those, the docs describe five stages: analysis of the vulnerability and your codebase, solution generation (the safest upgrade path), impact assessment (breaking changes and compatibility), pull request creation, and validation with automated tests.

For a developer who wants to fix a single repository locally, the CLI has a fix command. The docs show it with its help flag, and say --help is authoritative for your build:

safeguard fix --help

The interactive CLI can also take "fix this CVE in this repository" and work through it locally, asking before any command that changes something; the first demo below shows it.

What each pull request contains

The docs say AI Remediate pull requests include a title with the CVE reference, a description of the vulnerability, a summary of the changes, breaking change warnings if any, test results if configured, and links to advisories. Each fix carries a breaking change rating:

At this volume the rating is how you split review effort between a central queue and owning teams.

When there is no fixed version yet

Sometimes no upstream fix exists yet, or it lands only on a major version you cannot adopt this week. The reachability docs say Griffin can propose a minimum-risk upgrade, or a safe downgrade when no patched version exists. Check that a downgrade does not reintroduce older CVEs or resolve back up to the vulnerable version. The section on fixing without waiting for upstream, near the end, covers the rest.

Step 6: put a gate in front of the vulnerable version

Fixing three hundred repositories is pointless if the three hundred and first, or a revert, ships the old version next week. Policies and gates are how Safeguard holds the line.

The docs draw the distinction clearly. Policies are rules that evaluate your SBOMs and generate findings. Gates are checkpoints that enforce policies: they block deployments when policies fail, integrate with CI/CD pipelines, and require approvals for exceptions.

Create the policy

1. Go to Settings › Policies and click Create Policy.
2. Define conditions with the visual builder or YAML. The documented condition types include vulnerability severity, CVSS score, EPSS score, license, component age and maintenance status.
3. Set the severity and the action.
4. Save and enable it, then link it to the gate that your CI checks.

If you prefer to describe the rule in words, Safeguard can create policies from plain English prompts (GA). The plain English policies post shows that flow.

The reachability docs also show how reachability feeds directly into guardrail policies, with this production admission example:

- id: no-reachable-kev-in-prod
  condition: |
    env == "production" AND any(vulnerabilities,
      reachability_class in ["reachable", "conditional"] AND kev == true
    )
  effect: BLOCK

Read it as a pattern rather than a paste: the docs point to their guardrails page for the full policy language, so confirm field names in your workspace before you rely on them.

Choose the action: Block, Warn or Notify

Each policy has one action, and it decides what a failed policy does to the gate:

The docs add a useful detail about Notify: it does not repeat the same failure on every evaluation. You are notified when a policy goes from passing (or never evaluated) to failing, and again when a failing policy finds new matching issues.

For a KEV rollout, a staged approach works:

1. Day one: Warn. Link the policy to your release gate in Warn. Every pipeline that would ship the vulnerable version now carries a warning naming the policy, and nobody is blocked while fixes are still in review.
2. When Wave 1 and Wave 2 are merged: Block for production. Switch the production gate to Block. New regressions now fail.
3. Keep Notify on a broader gate so the security team hears when the vulnerable version turns up in a project that was never in the original blast radius, such as a new repository.

The policy gates in CI post goes deeper on gate design.

Wire the gate into CI

The CLI does not evaluate policies itself; the docs say gates are evaluated by the platform on the scans it runs for your connected repositories. With policy outcomes switched on for your workspace, this command fails a CI job when the gate fails:

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

The policy outcomes docs spell out the exit behaviour. The command waits for the scan to finish and for the gate's policies to be evaluated on the new data, then:

• exits 0 when the gate is Passed or Warning, printing warnings and notified policies;
• exits non-zero when the gate is Failed, printing the Block policies that failed;
• exits non-zero when the gate is Error or Not evaluated, or its policies were not evaluated before --timeout, with a message that says why.

--fail-on <severity> can be combined with --fail-on-gate. The docs' generic CI example installs the CLI, sets SAFEGUARD_API_KEY and runs safeguard ci scan --wait with repository, branch and commit flags. They also recommend pinning a CLI version with SAFEGUARD_VERSION on the install line so a release does not change a build under you.

An Error is never counted as a pass, and a gate that has never been evaluated shows Not evaluated, never Passed. If the Outcome column is missing, ask your Safeguard contact to switch policy outcomes on.

Policy outcomes are visible under Policies › Gates and Policies › Policies, with an Outcome column showing Passed, Failed, Warning, Not evaluated or Error and when each was last evaluated. Expanding a gate shows each linked policy's outcome and the gate's evaluation history. That history is part of your evidence.

Step 7: handle what you cannot fix this week

Some repositories will not be fixable inside the window. The fix is a major version away, the service is frozen for a release, or the vulnerable function is provably unused and the team wants to schedule the upgrade with other work. The answer is not to leave the gate failing forever or to quietly switch it to Warn. It is a written, approved, time limited exception.

The Policies and Gates docs describe exceptions as part of the gate model: gates "require approvals for exceptions". A request names the policy and finding, gives a business justification and an expiration date, and goes to approvers. The workflow the docs describe runs from a developer's request, to a notification to approvers, to a decision, with an audit trail recorded either way. Exception history then appears in policy compliance reporting.

Rules that keep exceptions honest during a KEV response:

• Short expiry. An exception on a KEV-listed CVE should expire within the window you would have had to fix it.
• A named owner, a person rather than a team alias.
• A compensating control in the justification, such as the reachability verdict or the network control in front of the service.
• No exception for unknown reachability without a look. Unknown is a reason to inspect, not to accept.

Separately from exceptions, the Vulnerabilities docs describe marking a finding as a false positive (with justification, submitted for approval if policy requires) and accepting risk temporarily with an expiration date. The mitigations docs add that active mitigations exclude vulnerabilities from gate failures and expired ones do not, so an expired acceptance puts the finding back in front of the gate. The gate exceptions guidance in the policy gates post covers the design choices.

If your product genuinely is not affected, and you need to tell customers, publish a VEX statement. Safeguard supports CSAF and VEX upload (GA); see ingest and share VEX and CSAF in Safeguard.

Step 8: track to closure and keep the evidence

A KEV response is finished when the last affected repository is fixed or under a live, approved exception, and the gate is in Block for production. Safeguard gives you several places to watch that happen.

• The Vulnerabilities tab with the KEV and reachability filters from Step 2. The affected count should fall wave by wave. Rescan after merges so the counts reflect what is actually on the default branch.
• The Dashboard. The docs list a vulnerability trend chart with mean time to remediation, a fix rate view with vulnerabilities fixed per week, AI Remediate versus manual fixes and time to fix by severity, and a project table with last scan, critical and high counts, score and compliance status.
• The Prioritization dashboard, which the reachability docs say shows time to remediate by priority band and backlog aging.
• Gate outcome history. Every evaluation of the gate is recorded, which shows when the vulnerable version stopped passing.
• Issue tracking, where needed. The Jira integration docs describe bulk issue creation from findings and two-way status sync. Ticket only the repositories that need human work, such as Major and Critical ratings.
• From an assistant. Safeguard's MCP server has read only tools for gate and policy outcomes when outcomes are on and your MCP access settings allow it. It is stateless, so save each week's answer if you want a comparison.

BOD 26-04 has agencies report KEV status through the CDM dashboard or manually. Safeguard's docs describe no CDM integration, so its records feed your report rather than replace it.

A worked example (illustrative)

The numbers below are illustrative, not from a real tenant or a real CVE. They show the shape of a response, not a result anyone should expect.

A KEV entry is published for a remote code execution flaw in a JSON parsing library used across a mid sized estate. The team runs Steps 1 and 2 the same morning.

Step 3 shows 210 of the 300 projects get the library through a shared internal HTTP client, so the platform team fixes the client first and the bulk flow bumps it everywhere. Wave 1 runs with Require Approval and Test Integration on; most pull requests are rated Safe or Minor, a few Major ones go to their owners, and two Critical rated fixes in a frozen service get seven day exceptions with a compensating control recorded. The policy goes to Warn on day one and Block on production after Wave 2. Two days later a repository built from an old template fails the gate: a regression caught in CI, not in production.

The Dashboard fix rate, the gate history and the exception history together are the evidence an auditor or federal customer asks for.

Decision table: which Safeguard route for which situation

What Safeguard does not do

Be clear about the edges before you plan a KEV response around Safeguard.

• It does not fix anything until you turn remediation on. Autonomous remediation ships off, every category Manual. Even when enabled, your team reviews, merges, releases and deploys. A merged pull request is not a deployed fix.
• It does not decide reachability with certainty. Reflection, dynamic dispatch, native code and data driven vulnerabilities defeat static analysis. Unknown verdicts are not suppressed, but an unreachable verdict is still a model of your code, not a proof. Reachability depth varies by language, so check your ecosystem.
• It does not ingest every BOD 26-04 variable. KEV status is on every record, and exposure comes from your labels. Safeguard's docs do not describe ingesting CISA's exploit automation or technical impact values, so pull those from Vulnrichment yourself.
• It does not report to CISA for you. BOD 26-04 reporting goes through the CDM dashboard or CISA's reporting instructions. Safeguard holds the records; you file the report.
• It does not fail a build from safeguard scan. That command reports. Failing a build needs safeguard ci scan with --wait and --fail-on or --fail-on-gate, with policy outcomes switched on for gates.
• It does not see repositories you have not connected. Blast radius covers imported, scanned projects. Unimported repositories, stale scans and vendor appliances are outside it until you bring them in.
• It does not patch software you do not build. If the KEV entry is for a vendor appliance, a hosted service or an operating system you do not control, the fix comes from that vendor. Safeguard's remediation applies to the open source dependencies and images you build and ship.

Common mistakes

1. Ranking by count instead of by risk. "Three hundred repositories" is not a plan. Split by reachability, environment and exposure, and fix the internet facing reachable ones first.
2. Ticketing every repository. A ticket per repository creates research work for hundreds of teams. Open the fix as a pull request with bulk AI Remediate, and ticket only what needs a human decision.
3. Fixing the leaves and not the root. If a shared library or template pins the vulnerable version, fixing every consumer without fixing the source guarantees a regression.
4. Turning on Auto-Create PRs on day one. Start with Require Approval and Test Integration on. Watch how the first wave behaves before you let anything run on its own.
5. Suppressing unknown reachability. Unknown is "not proven safe". Keep those findings in the urgent waves until someone has looked.
6. Going straight to Block. A Block gate on day one stops releases across the estate while fixes are still in review. Start in Warn, then Block once the urgent waves are merged.
7. Leaving exceptions open-ended. Every exception on a KEV-listed CVE needs an owner, a justification and a short expiry.
8. Forgetting the projects you could not assess. Stale and failed scans are the ones most likely to hide an affected repository. Rescan them before you declare the response done.

FAQ

How do I find every repository affected by a KEV vulnerability in Safeguard?

Filter the Vulnerabilities tab by exploitable status or kev:true and the component, or ask Claude or ChatGPT through the Safeguard connector, which reads how many projects, components and occurrences a CVE touches from one record. The blast radius post walks through it. Check stale scans too.

Can Safeguard open fix pull requests across many repositories at once?

Yes. Bulk AI Remediate lets you select vulnerabilities, click AI Remediate Selected, and create one pull request per repository after Griffin batches compatible fixes. Autonomous remediation ships off with every category set to Manual, so an administrator enables it first.

Does Safeguard merge the fix pull requests automatically?

No merge behaviour is described in the docs. AI Remediate creates pull requests, optionally after running tests, and can create Safe rated pull requests automatically if you switch on Auto-Create PRs. Your team reviews and merges, and the docs advise against auto-merging breaking changes.

How does Safeguard decide which repositories to fix first?

Each finding gets a priority score from 0 to 100 from reachability, EPSS and KEV, runtime context (environment and exposure) and business context. By default, reachable, KEV-listed findings in production score 90 to 100. Weights are configurable under Settings › Prioritization.

What does BOD 26-04 require for KEV vulnerabilities?

For US federal civilian agencies, BOD 26-04 sets remediation timelines in its Table 1 from four variables: public exposure, KEV status, exploit automation and technical impact. Agencies must monitor KEV updates, remediate no later than Table 1's timelines, and report status. It revoked BOD 22-01.

How do I stop the vulnerable version from coming back after we fix it?

Create a policy that matches the vulnerable component, link it to a gate with the Block action, and run safeguard ci scan --wait --fail-on-gate <gate> in CI. Start in Warn while fixes roll out, then switch production to Block.

What happens if a team cannot upgrade in time?

They request an exception against the policy and finding, with a business justification and an expiration date. Approvers decide, and the audit trail is recorded. Keep expiries short for KEV-listed CVEs and record any compensating control.

Can I run this from Claude or ChatGPT?

You can read the estate: blast radius, priorities and gate outcomes, after adding Safeguard from the connector directory. The connector is read only, so opening pull requests, changing gates and approving exceptions happen in the Safeguard web app, CLI or CI.

To try any of this, download the CLI and apps at https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs .

Most KEV vulnerabilities in open source components have a fixed version, and the steps above are about getting that version into every repository and keeping it there. When the fix is late, or upstream will not ship one, these are the options that are left.

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 and asks it to fix a lodash CVE in a JavaScript repository; the assistant reads the finding and advisory, asks before any command that changes something, edits the manifest, runs the install and tests, prints a summary and pushes nothing, then shows /permissions, /model and /scan .. It is one repository, not three hundred. It shows what a single fix looks like up close, which is the right way to check the first few Wave 1 repositories before you run the same change in bulk from the web app.

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

The second demo connects Claude to Safeguard: you add Safeguard from Claude's connector directory, where it has a community listing, sign in with OAuth, and choose which tools Claude can use. Once connected, you can ask Claude how many projects a KEV-listed CVE touches, which affected projects are reachable in production, or how a gate is evaluating, within the tools your administrator has enabled. The connector reads; it does not open pull requests or change gates.

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. For a KEV response this is the route for repositories whose code cannot leave your own infrastructure: the scan runs where the code is, and only results go to the platform, so those repositories still show up in the blast radius and the gate.

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

Quick check

Sources

• Safeguard docs: AI Remediate
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Vulnerabilities
• Safeguard docs: Continuous Scanning
• Safeguard docs: Mitigations
• Safeguard docs: Findings
• Safeguard docs: Dashboard
• Safeguard docs: JIRA Integration
• Safeguard docs: Search
• Safeguard docs: CI/CD Integration
• Safeguard docs: CLI usage
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities (revoked)
• CISA Known Exploited Vulnerabilities Catalog
• CISA Stakeholder-Specific Vulnerability Categorization (SSVC)
• CISA Vulnrichment repository
• FIRST: Exploit Prediction Scoring System
• NIST SP 800-218, Secure Software Development Framework version 1.1
• NIST SP 800-218 full text (PDF)

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