Hundreds of Projects, One Question: Portfolio Sweeps and Blast Radius

To answer a question that spans dozens or hundreds of Safeguard projects, do not open each project and page through its findings. Sweep the project list for counts and scan health, read blast radius (how many projects, components and occurrences a CVE touches) straight off one vulnerability call, and drill into the three to five projects that matter. Safeguard's public safeguard-at-scale companion skill teaches Claude exactly this workflow over the Safeguard MCP server (GA), so "is this new CVE anywhere in our estate?" becomes one or two calls instead of a few hundred.

Key takeaways

• The connector is read only by default. A new Safeguard workspace exposes six read only MCP tools to Claude: list products, list projects, get project, list vulnerabilities, get vulnerability and list findings. The MCP server itself is GA. An administrator turns on anything else per tool.
• Counts and rankings come from projects and vulnerabilities. Findings are for drilling, never for surveying. That one rule, from the safeguard-at-scale skill, is what keeps a fleet question inside a conversation's context and keeps the numbers honest.
• Blast radius is precomputed. Vulnerability rows carry affected_project_count, affected_component_count and occurrence_count, so "where is this CVE?" needs no loop.
• Vulnerability management (GA), SCA (GA), SBOM generation with continuous scanning (GA) and reachability analysis (GA) produce the data the sweep reads. Reachability support for some languages is marked Preview in Safeguard's docs.
• Acting on the answer happens elsewhere. Fix pull requests come from autonomous remediation (GA, ships switched off with every category set to Manual); blocking comes from policies and gates (GA); scans come from the CLI and local runner (both GA).
• Drill with project records and the app, not connector findings. Safeguard's offering notes that list_findings returns zero on the Claude connector today. Blast radius comes from list_vulnerabilities and get_vulnerability; drilling uses get_project and the project's tabs in the web app.
• In-app Griffin Search is early access. It answers "which projects use component X at version Y" for components with no CVE, which the six connector tools cannot.
• Coverage is the number dashboards hide. A sweep reports scanned projects as a fraction of your real repository inventory, flags stale scans and sets test projects aside.

The problem: estate questions do not survive per project loops

Every security team eventually gets the same message from a CISO or an incident channel: a critical advisory just dropped, are we affected, and where? In a small codebase you open the project and look. Across 150 repositories, four business units and a handful of scanned web targets, that habit breaks.

What the standards expect of you

The expectation is not new. NIST SP 800-218, the Secure Software Development Framework, asks producers under practice RV.1.1 to gather information on potential vulnerabilities "in the software and third-party components that the software uses" and to investigate credible reports. RV.2.1 asks you to analyse each vulnerability well enough to plan a response, and RV.2.2 asks you to plan and implement that response. None of those tasks is scoped to one repository. An advisory about a shared logging library is a question about every product that ships it.

For US federal agencies, CISA's Binding Operational Directive 22-01 turns that into a clock. Each entry in the Known Exploited Vulnerabilities catalog carries a due date: six months for CVEs assigned before 2021 and two weeks for everything else, unless CISA shortens it for grave risk. The directive's page also explains why speed matters. CISA reports that under 4% of all CVEs have been publicly exploited, but of those, 42% are exploited on day zero of disclosure, half within two days and three quarters within 28 days. Many private teams adopt KEV due dates as their own SLA for the same reason.

FIRST's Exploit Prediction Scoring System adds a second signal: the probability that a published CVE will be exploited in the wild in the next 30 days. KEV tells you what is being exploited now; EPSS estimates what is likely to be. Both only help if you can answer the prior question, which is where in your estate the vulnerable component actually runs.

The NTIA's minimum elements for an SBOM make a design point that matters here: it recommends tracking vulnerability data in separate data structures from the SBOM itself. That is how Safeguard models it. A component inventory lives on each project's SBOM, and a vulnerability index sits beside it and points back at every project and component it touches. A blast radius question should read the index, not reopen every inventory.

Why the naive approach fails

The obvious way to ask an assistant "is this CVE anywhere?" is to have it list every project and then pull findings for each one. The safeguard-at-scale skill is blunt about why that does not work: a mid sized estate is dozens of projects, findings carry roughly 150 fields each, and their descriptions run to thousands of words. Three findings can use more context than a whole portfolio sweep. Iterating findings across every project, in the skill's words, "is not slow, it is impossible."

Even if context were free, the numbers would be wrong. Safeguard's companion safeguard skill lists three properties of the raw data that produce confident errors:

1. Findings are duplicated by design. A finding is one row per vulnerability, per component occurrence, per policy gate. The same CVE on the same component version shows up once for each gate that evaluates it. The skill's own illustrative example: a project reporting 640 findings may hold around 39 distinct vulnerabilities.
2. Counts do not reconcile. A project's severity buckets and its total_vulnerabilities routinely disagree, and the total caps at 10,000.
3. Fields mean different things per scan type. A DAST target reports risk_level: "Unknown" and risk_score: 0 while carrying hundreds of high severity issues. Ranked naively, the noisiest assets look like the safest.

A per project loop multiplies all three errors by the number of projects. That is the problem the at scale workflow solves.

What the safeguard-at-scale skill is, and what it is not

Safeguard publishes four companion skills for its Claude connector in a public repository at github.com/Safeguard-sh/safeguard. They are instructions, not new product features. Each one tells Claude how to read Safeguard's data correctly:

Claude loads them on its own when the question matches. You do not type commands. The at scale skill triggers on phrasing like "across all our repos", "everywhere", "org wide", "which teams are behind" and "set up a weekly check", even when nobody says the word scale.

The skills ride on the Safeguard MCP server (GA), which Claude reaches through Safeguard's community listing in Claude's connector directory. That listing is a directory entry, not a partnership with Anthropic.

The data model the skill works over

The skill's routing follows Safeguard's object model:

Product          a top level offering that groups projects
  └─ Project     a repo, a scanned URL, an uploaded artifact
       └─ SBOM   one component inventory per scan
            └─ Finding   one vulnerability occurrence, evaluated against a policy gate

A Vulnerability sits outside this tree. It is the organisation wide view of one CVE, and a single vulnerability can produce many findings across many projects. Products are how Safeguard lets you see combined risk across a release train or business unit, which is useful when the question is "which teams are behind" rather than "which repos".

The six default tools

Safeguard's MCP tool gating docs say a new workspace starts with six read only tools, so a client can approve the whole set at once and nothing in it can create, change or delete anything:

Every other tool on the server, including the ones that start a scan or add an integration, ships switched off and is enabled per tenant by an administrator. The workflow in this post needs none of them.

The cost model behind every decision

The safeguard-at-scale skill gives each call a rough weight. This table is the reason the workflow looks the way it does:

The connector supports this. list_vulnerabilities returns trimmed summary rows (CVE, severity, CVSS, component name and version, fix version, the estate counts, project name and a shortened description), 25 per page by default and up to 200. list_projects returns 20 rows per page and pages with offset.

Everything below follows from one sentence in the skill: counts and rankings come from projects and vulnerabilities; findings are for drilling.

There is a second, practical reason to keep findings out of the plan. Safeguard's own offering notes record that list_findings currently returns zero on the Claude connector. So in Claude today, drilling means get_project (the full record for one project, including its components and vulnerabilities) and, for per occurrence detail such as reachability, the project's tabs in the Safeguard web app. The rest of this post is written that way.

Step by step: connect Claude and load the skills

You need a Safeguard account with scanned projects. If you have none yet, the Portal free entry tier (GA) gives you a free signup with one existing repo plus one open source repo from GitHub, GitLab or Bitbucket, one project per month, SCA only. That is enough to try the workflow, though not enough to need it.

1. Open Safeguard's entry in Claude's connector directory. Anthropic's help centre describes browsing the directory from a chat: click "+" (or type "/"), hover over Connectors, choose Manage connectors, then click "+" next to Connectors. The directory is inside Claude, so you need to be signed in to claude.ai.
2. Select Safeguard and connect. Claude sends you to Safeguard's sign in page.
3. Sign in and authorise. Safeguard's docs say to check the app name and the host the authorisation code will be sent to, then click Authorize access. There are no keys to copy; the connection uses OAuth.
4. Add the companion skills. The public repository's README says that if the connector is already connected from the directory, the skills attach to that connection and nothing else is needed. Add them the way your Claude surface adds plugins or skills.
5. Check which tools are on. Ask Claude which Safeguard tools it can see. If it lists the six read tools above, the sweep will work. If you expected more, ask your Safeguard administrator; the docs say a disabled tool does not appear in the tool list at all.

The full connection walkthrough, including Team and Enterprise plans and how OAuth works under the hood, is in Safeguard in your IDE and in Claude and ChatGPT connector directories. The rest of this post assumes the connector is live.

Step by step: the portfolio sweep

The portfolio sweep is the skill's default answer to any estate wide question, from "what is our posture" to "which repos are worst". It never opens a finding until the last step.

1. List projects, 20 at a time, until you have them all. Call safeguard_list_projects with limit: 20 and page with offset. The response header states the total, so Claude knows how many pages to expect and can say so if it stops early.

   { "tool": "safeguard_list_projects", "arguments": { "limit": 20, "offset": 0 } }
   { "tool": "safeguard_list_projects", "arguments": { "limit": 20, "offset": 20 } }
   

2. Split by provider. Repo and CLI scans, DAST targets and uploaded artifacts are not comparable and must not be summed into one table. A DAST target has no component inventory, so its component_count, sbom_count and finding_count read 0, which means "not applicable", not "clean". (DAST is early access; where you have it, it shows up as its own provider.)

3. Rank on severity buckets, not on risk score. Sort by critical, then high. The skill warns that risk_score and risk_level are unpopulated for DAST and will silently rank real risk as "Unknown". When the buckets and total_vulnerabilities disagree, show the buckets and note the difference. A total of exactly 10,000 means "at least 10,000".

4. Flag stale and incomplete scans. A project with assessment_status other than completed, assessment_progress under 100, or a last_scan_at more than about 14 days old gets called out. The skill's point is sharp: a project that has not been scanned is a bigger problem than a project with findings, and it is invisible if you only look at counts.

5. Set aside test and placeholder projects. Real tenants collect demo scans and test uploads. Names like testing or demo, or public intentionally vulnerable practice sites, distort every aggregate. Claude flags them, excludes them, and lists what it excluded. It does not drop them silently, and it asks if unsure.

6. Drill into the top three to five projects only. Only now does Claude call safeguard_get_project, one project at a time. For per occurrence detail (which gate, which path, whether the vulnerable code is reachable), open the project's Vulnerabilities and Findings tabs in the web app. Wherever findings are counted, they are deduped on cve_id + component_name + component_version first.

If someone asks Claude to "open every project", the skill tells it to explain the cost and propose the sweep plus targeted drilling instead.

What the sweep output looks like

The safeguard-reporting skill supplies the layout. This is an illustrative estate overview in that format, with made up project names:

47 projects scanned · 3 critical · 61 high open. Scans from 6 October to 24 October 2026. Two test projects excluded: demo-upload, testing-scan.

Code repositories:

Web targets (DAST, no component inventory):

Then a coverage line, because the overview is not finished without one:

Blast radius without a loop

"Is this CVE anywhere in our estate?" is the question the at scale skill was most clearly written for. The answer is already on the vulnerability record.

The three fields that answer it

Every vulnerability row from list_vulnerabilities carries the estate wide reach of that CVE:

So one safeguard_get_vulnerability call on a named CVE, or one safeguard_list_vulnerabilities call with a severity or CVSS filter, gives you estate wide reach without touching a single project.

Step by step: is CVE X anywhere?

1. Look up the named CVE directly.

   { "tool": "safeguard_get_vulnerability", "arguments": { "cve_id": "CVE-2026-XXXXX" } }
   

   The full record includes the affected component and version, the fix version where one is known, CVSS, references and the three counts above.

2. If you do not have a CVE ID yet, pull the worst of everything. Call safeguard_list_vulnerabilities with cvss_min (or severity: "critical") and read the counts.

   { "tool": "safeguard_list_vulnerabilities", "arguments": { "cvss_min": 9, "limit": 25 } }
   

3. Leave the ecosystem filter alone unless you mean it. The connector's own description warns that most vulnerability records do not carry an ecosystem, so filtering to npm returns far fewer results than really exist for npm. The skill says to keep it at all and to say so if you narrow it.

4. Name the projects, then stop. The vulnerability rows name a project. For the few projects that matter, get_project gives the full record, and the project's Vulnerabilities tab in the web app shows reachability and exploitable status per vulnerability. You do not need per occurrence detail from every affected project to answer "where".

5. Write the answer so it can be checked. The reporting skill's template for a yes is short:

**Yes. CVE-2026-XXXXX is in 6 projects.**

example-logger 2.3.1 · 14 total occurrences · fixed in 2.3.4

| Project       | Occurrences | Reachable |
|---------------|------------:|-----------|
| payments-api  |           4 | Yes       |
| web-frontend  |           3 | No        |

One upgrade to 2.3.4 clears all of them.

The numbers above are illustrative, and the Reachable column comes from each project's Vulnerabilities tab in the app, not from the connector. For a no, the template asks for one line plus what was checked, so the negative is trustworthy:

**No. CVE-2026-XXXXX does not appear in any of your 47 scanned projects.**
Checked against the full vulnerability index as of 24 October 2026.

That second line matters more than it looks. Safeguard's connector instructions say an empty result means the query matched nothing in the active scope; it is not proof that nothing exists elsewhere. "Not in your 47 scanned projects" is a true statement. "Not in our estate" may not be, if 30 repositories have never been scanned.

Which projects ship component X at version Y?

This is a related but different question, and it is worth being precise about what answers it.

If the component has a known vulnerability, the connector answers it: vulnerability rows carry component_name and component_version, so a CVE lookup or a filtered list_vulnerabilities call names the projects that carry that version. Claude matches on name and version client side, because the tool has no component filter.

If the component has no known vulnerability (you are asking "where do we still use version 1 of this library?" for an upgrade plan or a licence review), the six default tools cannot answer it. The vulnerability index only holds components that have vulnerabilities. Two places in the Safeguard web app can:

• Griffin Search (early access in the app). Safeguard's Search docs show plain lookups such as a package name, a CVE ID, or a package and version like react 18.2.0, and say component results list the projects where each component is used. You can scope a search to a project with an @ mention and star a search you run on a cadence.
• The project's Dependencies tab. Each project's SBOM explorer in ESSCM (GA) has a Dependencies view as a tree or table. That is per project, so it is for confirming, not surveying.

Say which route you used. A connector answer covers vulnerable components only; a Search answer covers what the SBOMs list.

The first hours after a new advisory

Here is how the pieces fit when a new critical advisory lands and someone asks "are we affected?" This is the playbook the skills support, in order.

1. Confirm Safeguard has re-evaluated. Safeguard's Vulnerabilities docs say the platform scans all projects continuously and re-evaluates them automatically when new CVEs are published, drawing on NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. If the advisory is minutes old and has no CVE record yet, say so and check again rather than reporting "not affected".
2. Run the blast radius lookup. One get_vulnerability call on the CVE. Read affected_project_count, affected_component_count and occurrence_count, the affected version and the fix version.
3. Check exploitation signals. Safeguard's Vulnerabilities view in the web app shows CVSS, EPSS, exploitable status from CISA KEV, fixed version and reachability for each vulnerability, and has an Exploitable category alongside the severities. If the CVE is in KEV, it goes to the top regardless of anything else. You can also check KEV status, EPSS and a recommended safe version on Gold Open Source (GA), which is free and needs no login.
4. Decide whether it is a platform fix. The skill's rule: anything that appears in more than about a quarter of projects is a platform level fix. Route it to whoever owns the base image, the shared library or the service template, rather than filing it against every team. One upgrade across 20 repos beats 20 unrelated fixes.
5. Drill into the top projects only. For the three to five projects most exposed, call get_project one at a time, and confirm reachability in each project's Vulnerabilities tab in the app.
6. Turn CVEs into upgrades. Apply the safeguard-triage skill's rule and batch by component: take the highest fix version across all CVEs on that component, verify it covers the others, and flag major version jumps for a compatibility check instead of presenting them as a clean bump. If there is no fix version, it says so and lists the honest options (compensating control, removing the dependency, or a patch) rather than inventing a task.
7. Act outside the connector. The read only connector cannot raise a pull request or change a finding's state. In the Safeguard web app, AI Remediate on the Vulnerabilities page generates fixes and opens pull requests, singly or in bulk with one pull request per repository. Autonomous remediation (GA) ships switched off, with every category set to Manual, so a person approves each change until your team decides otherwise. A policy gate (GA) with a Block action stops the vulnerable version merging back in.
8. Record what "not affected" means. Where a project carries the component but the vulnerable code is not reachable, record it as a mitigation in the app, and if your customers need a statement, publish a VEX document; Safeguard's CSAF and VEX upload is GA. The triage skill is explicit that unreachable is lower priority, not resolved.
9. Save the sweep. Keep the blast radius answer and the project list from this run. Tomorrow's question is "what changed?", and the connector cannot answer that without a baseline (more on this below).

Steps 2, 4 and the counting in 5 and 6 are conversation; the per project detail in steps 3 and 5 and everything in steps 7 and 8 are the web app, CLI or CI. The skill tells Claude to say so plainly instead of approximating actions it cannot take.

For more on how the ranking signals combine into Safeguard's priority score, see Prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard. For the remediation strategies, see Autonomous remediation in Safeguard.

Finding shared components: one fix, many projects

The at scale skill calls this the work that pays back most in a large estate, and it is easy to miss when every ticket is filed per repository.

The method is short. Take deduplicated vulnerability rows, sort by occurrence_count and affected_project_count descending, and read the top of the list. Anything in more than about a quarter of projects is not a team problem. It is almost always one of three things:

• A base container image that most services build from.
• A shared internal library or SDK that every service imports.
• A service template that new repositories were generated from, carrying a pinned version nobody revisited.

Each has an owner who can fix it once. Filing the same CVE against 30 teams produces 30 tickets and a long tail of repos that never upgrade.

An illustrative shared component view looks like this:

The first two rows are platform fixes by the quarter rule. The third is not, and goes to the teams. If your container images are tracked per environment in Safeguard, Track container images per environment covers how base image fixes flow through.

Sampling instead of iterating

"Sampling" in the at scale skill means something specific: you never read detail for the whole estate; you read it for a deliberate sample chosen from the sweep, with get_project in the conversation and the project's tabs in the app. In practice there are three samples worth taking, and each answers a different question.

The worst three to five. Ranked by critical then high severity buckets, these are the projects you open in detail. This answers "what should we fix first?"

The odd ones out. Projects whose buckets and total disagree badly, totals at exactly 10,000, and projects stuck below 100% assessment progress. One of each tells you whether the numbers you are about to report can be trusted.

One per provider or product. Open one repo scan, one uploaded artifact and one web target so you know what the columns mean, and one project per Safeguard product so you know whether a team's low count is real or a coverage gap.

What you do not do is extrapolate from a sample to a count. Counts come from the sweep, which already covers every project. The sample tells you how to read those counts and where the work is.

Recurring reviews: weekly and monthly

The at scale skill defines two cadences.

Weekly: the portfolio sweep, new criticals and highs since last week, any scan that has gone stale, and any policy gate now in block.

Monthly: severity trend by business unit or provider, the top shared components, projects never scanned or dormant, and coverage gaps against the repository inventory.

The connector cannot tell you what changed

This is the limit people trip over. The connector is read only and stateless. It returns the state of the tenant now; it does not remember what it returned last Tuesday. A "new this week" column therefore needs a previous snapshot.

You have two honest options. Save the sweep output each run (a table pasted into the team's notes, or a file kept with the review) so the next run has a baseline. Or say plainly that the numbers are point in time and no delta is available. The reporting skill's executive summary template says the same: if there is no prior snapshot, write "point in time" and do not imply a trend.

The Safeguard web app keeps history that the connector does not expose. The ESSCM dashboard (GA) shows vulnerability trends over time, fix rate, mean time to remediation and new vulnerabilities this week, and Safeguard's enterprise features (GA) include scheduled tasks, editable dashboards and bulk export in formats such as CSV, Excel, JSON and Parquet. If a trend line matters to the reader, take it from the dashboard and use the conversation for the questions the dashboard cannot answer.

An illustrative weekly digest in the reporting skill's format, assuming a saved baseline:

Needs a decision: example-logger upgrade across 31 projects, owner is the platform libraries team, compatibility check needed for one major version jump.

Fix queue: three lines from the ranked fix list, each a component upgrade, not a CVE.

Coverage, onboarding and the projects you cannot see

The skill has a line worth quoting in full in spirit: a tenant with 38 clean projects and 120 unscanned repositories is not in good shape. Dashboards hide that, because they show what was scanned.

When the question is posture, the skill tells Claude to check whether the project list matches the real repository inventory. If a source control connector is also available to the assistant, compare the two lists and report the gap. If not, ask for the expected count. Then report coverage as an explicit fraction: "39 of 140 known repositories scanned in the last 14 days (28%)". Never imply that the scanned set is the whole estate.

Closing the gap is not a connector job. New repositories come in through the web app's integrations for GitHub, GitLab, Bitbucket and generic Git, through the CLI (GA), or through the local runner (GA) when code cannot leave your machines. Repo connection: CLI or local runner compares the routes. Once connected, continuous scanning on push, on a schedule or on release keeps the sweep's last_scan_at fresh.

Decision table: which call answers which question

What Safeguard does not do

• The default connector does not act. With the six default tools, Claude cannot start a scan, mark a finding as a false positive, accept a risk, open a ticket or raise a pull request. Those happen in the web app, CLI or CI, and only tools an administrator enables can do more over MCP.
• It does not compute deltas. The connector is stateless. Week over week change needs a snapshot you saved, or the dashboard's own trend views.
• It does not see what was never scanned. Blast radius covers scanned projects in the active scope. A repository that is not connected, or a vendor appliance you do not build, is outside the answer. A "no" is "not in your scanned projects", nothing stronger.
• It does not find unvulnerable components through the vulnerability index. "Where do we use version 1 of this library" for a component with no CVE needs Griffin Search (early access) or the project's Dependencies tab, not the six default tools.
• It does not filter vulnerabilities by exploitation status in the list call today. Safeguard's MCP code removed an exploit filter on list_vulnerabilities because records did not carry the field it filtered on, so it could only ever return an empty set. Some docs still describe that filter. Read KEV status from the CVE record, finding rows or Gold Open Source instead.
• It does not return per project findings in Claude today. Safeguard's offering notes record that list_findings returns zero on the Claude connector. Use get_project and the web app's project tabs for occurrence level detail.
• It does not reveal file paths. Component paths are redacted at the API, so Claude cannot tell you which manifest or lock file a component came from. The project's SBOM explorer in the app shows the dependency tree.
• It does not fix vendor or operating system code you do not build. The blast radius tells you a hosted service or appliance is affected only if you scanned an artifact of it; the fix still comes from that vendor.

Common mistakes

Counting findings. "You have 640 findings" is almost never true in the way the reader hears it. Dedupe on CVE, component name and component version, then say "N distinct vulnerabilities across M components".

Ranking on risk score. risk_score and risk_level are empty for DAST targets. A table sorted by them puts the noisiest web target at the bottom with "Unknown". Sort by severity buckets.

Treating an empty result as clean. An empty list_vulnerabilities result means nothing matched in the active scope. Before reporting "not affected", check coverage, and check that the advisory has a CVE record yet.

Filtering by ecosystem by default. Most records carry no ecosystem. An npm filter returns a fraction of the real npm exposure.

Partial name lookups. The name filter on list_projects is exact match only. If a lookup comes back empty, list and match client side rather than concluding the project does not exist. Pass project IDs back exactly as returned, including any version suffix such as 435-1.0.0.

Filing a platform fix per team. If a component is in more than about a quarter of projects, route it to the base image, shared library or template owner.

Leaving test projects in the totals. Demo uploads and scans of public practice targets inflate everything. Exclude them, and list what you excluded.

Promising a trend from a single run. Without a saved baseline, the numbers are point in time. Say so.

FAQ

How do I find which projects are affected by a CVE in Safeguard?

Call safeguard_get_vulnerability with the CVE ID, or safeguard_list_vulnerabilities with a severity or cvss_min filter. Each record carries affected_project_count, affected_component_count and occurrence_count, so you get estate wide reach in one call without looping over projects.

Can Claude scan all my repositories through the Safeguard connector?

Not with the default tools. A new workspace exposes six read only tools that read existing results. Starting scans happens in the Safeguard web app, CLI or CI, or through additional MCP tools an administrator chooses to enable for the tenant.

What is the safeguard-at-scale skill?

It is one of four public companion skills Safeguard publishes for its Claude connector. It teaches Claude to work an estate of dozens or hundreds of projects with portfolio sweeps, blast radius lookups, shared component analysis and recurring reviews, instead of reading findings project by project.

Why not just list findings for every project?

Findings are the heaviest records Safeguard returns, with roughly 150 fields and long descriptions, and they are duplicated per policy gate. Looping over them exhausts an assistant's context long before it finishes and inflates the counts it reports. On the Claude connector today, list_findings also returns zero, so per project detail comes from get_project and the web app.

Does the Safeguard connector work in ChatGPT too?

The same MCP server works with ChatGPT and other assistants; the setup routes are covered in our connector post. The companion skills in this post are written for Claude, but the workflow (sweep, blast radius, drill a few) applies to any assistant reading the same tools.

How do I find every project using a library version that has no CVE?

Use Griffin Search in the Safeguard web app (early access), which accepts a package and version and lists the projects that use it, then confirm in a project's Dependencies tab. The connector's vulnerability index only holds components with known vulnerabilities.

Can Safeguard show me what changed since last week?

The web app's dashboard shows trends, fix rate and new vulnerabilities this week. The connector is stateless, so in a conversation you need last week's saved sweep to compare against, or you report the numbers as point in time.

Does an empty blast radius result mean we are not affected?

It means the CVE does not appear in your scanned projects in the active scope as of now. Pair it with a coverage fraction and the date checked, and confirm the advisory already has a CVE record in Safeguard's feeds.

From "where is it" to "it is fixed"

A blast radius answer is only useful if the fix follows. Once the sweep tells you a component sits in 31 projects and the triage skill turns that into one upgrade, the remaining risk is the time it takes the safe version to reach production, or the time before a safe version exists at all, which is what the block below covers.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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 shows the connection this whole workflow depends on: connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. For the at scale workflow, the six default read tools are all you need, and this is where you confirm that is what Claude sees.

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

The second demo picks up where the connector stops. It is a real CLI session: you install the CLI, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. After a blast radius answer, this is how one engineer clears one of the drilled projects locally.

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

The third demo addresses coverage. It shows setting up the local runner on your own machine, approving it with its device code, then scanning from the terminal. When the sweep says a quarter of your repositories have never been scanned, this is one way to bring them in without sending code off the machine.

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

To try the workflow on your own estate, get the apps and CLI at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• Safeguard companion skills for the Claude connector (public repository)
• Safeguard docs: Claude integration
• Safeguard docs: MCP tool gating
• Safeguard docs: ESSCM Vulnerabilities
• Safeguard docs: ESSCM Search
• Safeguard docs: ESSCM Dashboard
• Safeguard docs: Organization and user management
• Safeguard docs: MCP for Claude
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• CISA BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• NTIA: The Minimum Elements for a Software Bill of Materials
• CISA: Software Bill of Materials
• Claude Help Center: Use connectors to extend Claude's capabilities
• Model Context Protocol specification: Tools

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