What to Fix First: A Ranked, Batched Fix List From Safeguard in Claude

Ask Claude "what do I fix first?" with Safeguard connected, and you get back a short list of component upgrades, not a wall of CVEs. Claude reads your Safeguard vulnerability data, puts known exploited and reachable flaws with a fix at the top, groups every CVE on the same package into one upgrade, and stops at ten items you can finish this week.

That is the whole idea of this post. The rest explains how the conversation works, what Claude is reading behind each answer, how the batching cuts the work, and where the connector stops so a person takes over.

If you want the scoring model itself (how Safeguard weighs reachability, EPSS, KEV, runtime and business context into a Priority Score, and how to record a decision not to fix), read prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard first. This post assumes that score exists and focuses on what happens when you ask for a plan in plain language.

Key takeaways

• The question is conversational, the data is not. Claude answers from your real Safeguard tenant through the Safeguard MCP server (GA), which is listed in Claude's connector directory as a community connector.
• The ranking uses Safeguard's own priority data. Vulnerability management with EPSS and CISA KEV enrichment (GA) and reachability analysis and prioritisation (GA, with some languages in Preview) feed a precomputed 0 to 100 priority score. Claude sorts on that score first and only reweights when you ask.
• Known exploited and reachable-with-a-fix go to the top. Anything in CISA's KEV catalog, and anything reachable that already has a fixed version, is promoted regardless of score. Unreachable findings drop down the list but never disappear.
• The output is upgrades, not CVEs. Several CVEs on one package version usually close with one upgrade to the highest fix version. Claude groups them, checks the target covers all of them, and flags major version jumps for a compatibility check.
• The default connector is read only. A new workspace exposes six read-only tools. Claude can rank, explain and draft ticket text; it cannot change a finding, open a ticket or raise a pull request. Those actions live in the Safeguard web app, the Safeguard CLI (GA) and autonomous remediation (GA, ships switched off with every category set to Manual).
• Companion skills make Claude consistent. Safeguard's companion skills for Claude (safeguard, safeguard-triage, safeguard-reporting and safeguard-at-scale) encode the ranking and the accuracy rules. They are instructions that run in Claude on top of the GA MCP server, not a separate Safeguard product, and they are different from Safeguard's in-app Skills (early access).
• No fix version means a different answer. A compensating control, removing the dependency, or a patched build; Safeguard's fork and patch route is early access.
• Other labels in this post: software composition analysis and deep transitive dependency scanning (GA), policies and gates (GA), CSAF and VEX upload (GA), Gold Open Source (GA), the local runner (GA).

Why "what do I fix first" is the right question

Most teams do not have a finding problem. They have an ordering problem. A scan of a modest service can return dozens of distinct vulnerabilities spread across hundreds of components, and a portfolio of services multiplies that into a backlog nobody reads to the end. Sorting that backlog by severity feels responsible. It is also the main reason backlogs stall.

CVSS measures severity, not what to do next

The FIRST CVSS v4.0 user guide is direct about this: base scores measure the severity of a vulnerability and "should not be used alone to assess risk". A base score describes how bad a flaw could be in the abstract. It does not know whether your build calls the vulnerable function, whether anyone is exploiting it, or whether a fixed version exists.

So a CVSS 9.8 in a parser your application never invokes, with no public exploit and no fix, sorts above a CVSS 7.5 that sits on your request path, is being exploited now, and closes with a one line version bump. Safeguard's triage skill calls that inversion "the whole point of the product". Fixing it is what the rest of this post is about.

What CISA and FIRST say about exploitation

CISA's guidance on Binding Operational Directive 22-01 gives the numbers behind the shift. Based on historical data back to 2019, CISA says less than 4% of known CVEs have been publicly exploited. Of those, CISA reports 42% are used on the day of disclosure, 50% within two days and 75% within 28 days. Its FAQ answers the question this post is built around directly: known exploited vulnerabilities "should be the top priority for remediation".

The directive sets default federal timelines of six months for CVE IDs assigned before 2021 and two weeks for the rest, and says CISA may adjust them for grave risk. Those deadlines bind US federal civilian agencies, not you, but CISA's catalog page tells every organisation to use KEV "as an input to their vulnerability management prioritization framework".

EPSS answers a different question. FIRST describes it as a model estimating the probability that a published CVE will be exploited in the wild in the next 30 days, published daily with a probability and a percentile. FIRST's article on percentiles gives a worked example: a 10% probability sits around the 88th percentile, in the top 12% of scored CVEs. That is why Safeguard's reporting guidance tells Claude to show EPSS as a percentage with its percentile. A raw "0.1" means little to an engineering manager; "10%, 88th percentile" does.

CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) turns signals into one of four decisions (Track, Track*, Attend, Act). The lesson for this post is the shape of the output: a good triage result is a decision about what to do, not a sorted spreadsheet.

What NIST SSDF asks for

NIST SP 800-218, the Secure Software Development Framework, puts prioritisation in practice RV.2, "Assess, Prioritize, and Remediate Vulnerabilities". Two tasks matter here:

• RV.2.1 asks you to analyse each vulnerability to gather enough information about risk to plan its remediation or other response. One of NIST's examples is to calculate risk from exploitability, potential impact and other relevant characteristics.
• RV.2.2 asks you to plan and implement risk responses. NIST's examples include a risk-based decision on whether each vulnerability will be remediated or addressed another way, and, where no permanent fix exists yet, a temporary mitigation added to the plan.

The second example is the part teams skip. A list of CVEs with no fix version is not a plan unless each one says what you will do instead. The triage workflow below handles that case explicitly.

Why a ranked list is still not a plan

Even a perfectly ranked CVE list overstates the work. OWASP's Top 10 entry for vulnerable and outdated components warns that you are likely exposed if you do not know the versions of every component you use, "both client-side and server-side", including nested dependencies. Those nested dependencies are where CVEs pile up on the same package. Three CVEs on one library version are not three tasks. They are usually one upgrade.

That is the second half of the answer to "what do I fix first": rank by real risk, then batch by component so the list reads as a set of changes a developer can make.

What the Safeguard triage workflow in Claude actually is

Three pieces work together. Knowing which does what tells you where to look when an answer seems wrong.

The connector: read only by default

The Model Context Protocol project describes MCP as an open source standard for connecting AI applications to external systems. Safeguard's remote MCP server is how Claude reaches your projects and vulnerabilities.

Safeguard's tool gating docs say a new workspace starts with six read-only tools: list products, list projects, get a project, list vulnerabilities, get a vulnerability, and list findings. Nothing in that set can create, change or delete anything. An administrator can enable more per tenant; this workflow needs none of them.

Scope comes from your sign-in, and an empty answer means nothing matched in that scope, not that nothing exists anywhere.

The companion skills: what they are, and what they are not

Anthropic's documentation describes Agent Skills as reusable, filesystem-based packages of instructions that Claude loads on demand. Claude reads a short description of each skill up front and pulls in the full instructions only when a request matches, which Anthropic calls progressive disclosure.

Safeguard's companion plugin for Claude bundles four skills:

• safeguard is the entry point: the tool map, the data model (product, project, SBOM, finding) and three accuracy rules that stop Claude from inflating counts.
• safeguard-triage is the ranking model this post describes: which signals win, how to promote and demote, how to batch by component, and what to do when no fix exists.
• safeguard-reporting controls presentation: one layout per audience (engineer, AppSec lead, executive, auditor), the ranked fix list template, ticket blocks, and the fields never to show.
• safeguard-at-scale covers estate-wide questions without exhausting Claude's context.

If Safeguard is already connected from the directory, the plugin's README says the skills attach to that connection. Two clarifications: these are not Safeguard's in-app Skills, Workspaces and Connectors (early access), which run inside the Safeguard app; and they add no data or capability. They make Claude read the GA data the same careful way every time.

The signals Claude reads, in order of weight

The triage skill ranks signals by how much each should move a decision. This is the order Claude applies when it explains why something sits where it does.

Safeguard also precomputes, per finding, a priority score from 0 to 100, a priority level, and a written priority recommendation. The triage skill's example of that recommendation reads like an instruction a lead would give: "URGENT: Schedule upgrade of postcss to 8.5.18 within 7 days". The contributing weights are exposed alongside, so Claude can tell you which factor pushed a finding up.

Platform score first, your weighting second

The triage skill tells Claude to use the platform's priority score as the default sort, because it already blends these factors with your tenant's settings. Claude recomputes only when you ask for a different weighting ("rank by EPSS percentile only", "ignore reachability for this internet-facing service"), and it must say when it has departed from the platform score so the two are never confused.

The platform score is what your dashboard, gates and auditors see. A conversational re-rank is a labelled "what if".

Step by step: from "what do I fix first" to a batched fix list

The steps below follow Safeguard's Claude guide and its tool gating page for setup, and the companion skills for what Claude does with the data. Where a step is something Claude does on its own, it says so.

1. Add Safeguard from Claude's connector directory

1. Sign in to claude.ai. Safeguard's docs note that the directory lives inside Claude and needs a signed-in session.
2. Open the Safeguard entry in Claude's connector directory, select Safeguard, and connect.
3. Claude sends you to Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorisation code will be sent to, then click Authorize access.

That is the whole setup on the directory route. There is no URL to paste and no key to copy. If your plan or workspace does not show the directory, Safeguard's Claude guide covers the alternatives, and the Safeguard in your IDE and in Claude and ChatGPT post walks through each route, including team rollouts and ChatGPT.

Anthropic's help article on connectors advises connecting only to servers you trust and clicking "Allow always" only for tools you are happy to run unsupervised. With six read-only tools that is a low-risk choice, but read the list once.

2. Confirm which tools are on

Ask Claude: "Which Safeguard tools can you use?" On a new workspace you should see the six read-only tools. Safeguard's docs say a tool that is not enabled for the tenant does not appear at all, and older workspaces may still have a few extra tools switched on from before the default set was narrowed. If you see scan or integration tools you did not expect, check Feature Flags with your Safeguard administrator before you go further.

3. Add the companion skills, or paste the rules

If your Claude plan supports plugins or custom skills, add Safeguard's companion skills. You do not invoke them by name. Claude loads safeguard-triage when your request matches its description, which covers "what should I fix", "which of these matter", "we have 800 highs and no time", "is this one real" and "what do I tell the team to do this week".

If you cannot add skills, paste the "behind the scenes" procedure from step 6 into a Claude project's instructions, and check counts more carefully.

4. Pick the scope before you ask

Start with one project, not the estate. The base skill routes counting and ranking questions to the project and vulnerability lists and only drills into detail once it knows which project matters. A ranked fix list is a project-level deliverable.

If you do not know which project to start with, ask Claude first: "Which of my projects have the most critical and high vulnerabilities, and when was each last scanned?" That uses the light project list, splits results by scan type, and flags stale scans. Then pick one.

5. Ask the question

Any of these works. The more you say about the reader and the time box, the better the answer fits.

• "What should we fix first in the payments-api project this sprint?"
• "We have two engineers for three days. Give me the upgrades that remove the most real risk in payments-api."
• "Which of the reachable ones already have a fixed version?"
• "Is anything in payments-api known exploited? If so, what is the fix?"
• "Turn the top three into ticket text I can paste."

6. What Claude does behind the scenes

This is the procedure the triage and base skills give Claude, applied to the records the connector returns today. Knowing it lets you check the work.

1. Check freshness. Claude reads the project record (get project) for its last scan time and assessment status. If the last scan is more than about 14 days old or the assessment is not complete, it says so before showing numbers. A clean report from an old scan is worse than none, because people believe it.
2. Read the project's vulnerabilities. Safeguard's tool gating docs say the project record includes its components and vulnerabilities, and the vulnerability list can be filtered by severity, CVSS score or exploit status. Claude pages in small sets rather than pulling everything, and opens the full record (get vulnerability) only for a CVE you name.
3. Deduplicate. Claude keys each item on CVE ID plus component name plus component version, so one CVE on one component version counts once however many times it appears.
4. Sort by the platform priority score where the record carries it, highest first. Where it does not, Claude falls back to the signal order in the table above and says that it did.
5. Promote, regardless of score: anything in CISA's KEV catalog, and anything reachable that has a fix version.
6. Demote, but keep: anything not reachable. It stays on the list at a lower position, with a sentence saying why.
7. Batch by component. For each component, take the highest fix version across its CVEs, check that it actually covers the others, and flag conflicts or major version jumps.
8. Separate the no-fix items. Anything without a fix version is not presented as an upgrade task.
9. Cut at ten. If more sit below the line, Claude says how many.

One caveat on data depth. The triage skill was written against Safeguard's full per-project finding records, which carry every signal above plus policy gate details. Through the Claude connector today, build this workflow on project and vulnerability records; a per-project findings request can come back empty. The rule for Claude is simple: if a signal is not in the record it has, say so rather than infer it. The prioritised view in the Safeguard app stays the reference.

7. Read the answer

Here is what a ranked fix list looks like for an AppSec lead, following the template in the reporting skill. The component names, versions and counts below are illustrative, not from a real tenant.

5 upgrades clear 11 vulnerabilities in payments-api

Note: last scan 21 October 2026, 3 days ago. Two vulnerabilities have no fix version and are listed separately below.

When the reasoning matters more than density, ask for the list form. The same answer reads like this:

1. xml-reader 2.3.1 to 2.3.9 Clears 3 CVEs; one is in CISA's KEV catalog and reachable from the invoice import path. Direct dependency. Present in 4 other projects, so the same bump is worth doing there this week.

2. http-client 4.1.0 to 4.1.6 Clears 2 CVEs, both reachable, EPSS 12% (89th percentile) on the higher one. Direct dependency. Also in 6 projects.

5. yaml-lite 0.9.1 to 1.0.2 Clears 3 CVEs, none reachable. Major version jump from 0.9 to 1.0: needs a compatibility check, so schedule it for the next dependency sweep rather than this sprint.

For one vulnerability, Claude uses a facts strip instead of a table, because a one-row table reads worse than a sentence:

High · CVSS 7.5 · EPSS 0.6% (46th) · Reachable · Fix available

Three things to notice. The answer leads with the number of upgrades, not CVEs. Item 4 has the widest blast radius but sits fourth because it is not reachable. And the major version jump in item 5 is flagged instead of being presented as a clean bump.

8. Push back and re-rank

The conversation does not end with the first list. Useful follow-ups:

• "Why is date-utils fourth when it is in nine projects?" Claude explains the factors: not reachable, no KEV entry, low EPSS.
• "Rank by EPSS percentile only." Claude re-sorts and labels the result as a manual weighting, separate from the platform score.
• "Explain item 1 for an engineer who has never seen it." Claude summarises the vulnerability record in two sentences and offers the detail if you want it, instead of pasting a long root cause write-up.
• "What will block our build?" That depends on policy gate results, which the Safeguard app shows. Claude can explain the difference between a warn and a block, but check the gate itself before you promise a release date. See the policy gates section below.

9. Hand it off to the place that can act

The connector cannot open a ticket or raise a pull request, and Claude should say so plainly if you ask it to. What it can do is produce copy-ready text. Ask for ticket blocks and you get one per upgrade, in a fenced block so it pastes cleanly:

Title: Upgrade xml-reader 2.3.1 to 2.3.9

Clears 3 vulnerabilities:
  CVE-A  High      CVSS 8.1  reachable   in KEV
  CVE-B  High      CVSS 7.5  reachable
  CVE-C  Medium    CVSS 5.3  not reachable

Direct dependency. Also present in 4 other projects.

Then act where actions live:

• Safeguard web app. Change a finding's status or record a mitigation with a reason and an expiry.
• Autonomous remediation (GA, ships switched off). Griffin opens a tested, policy-gated fix pull request for one repository or in bulk. Every category starts as Manual, so a person decides what runs on its own. See autonomous remediation in Safeguard.
• Safeguard CLI (GA). Its terminal assistant can make the change in your repo with your approval for each command, which the CLI demo at the end of this post shows.

How batching by component works

Batching is the single largest effort reduction in the workflow, and the easiest to miss. The triage skill calls it out for a reason: Claude, left alone, tends to answer CVE by CVE.

One package, several CVEs, one upgrade

A pinned version of a common package often carries two or more CVEs whose fix versions differ. The skill's own example is a package with one CVE fixed in 8.5.12 and another in 8.5.18. These are not two pieces of work. One upgrade to 8.5.18 closes both. Its sample output looks like this:

postcss  8.4.31 to 8.5.18    clears 2 CVEs (1 reachable)
lodash   4.17.20 to 4.17.21  clears 1 CVE

So the unit of the list is the upgrade. Each row says which version to move to and how many vulnerabilities that move clears.

Verify, do not assume

Taking the highest fix version is the starting point, not the answer. The skill tells Claude to verify that the highest version covers the other CVEs on that component, rather than assuming it does. Advisories sometimes list fixes on separate release lines (a fix backported to 2.3.x and another only in 3.x), and the highest number on one line does not always include a fix shipped on another.

When fix versions conflict, or the target crosses a major version, Claude flags the row as needing a compatibility check. That flag is worth more than it looks. A "simple bump" that breaks the build costs a team more time than the vulnerability it closes, and it teaches developers to distrust the list.

Direct versus transitive

The triage skill weighs directness. A direct dependency is yours to bump in your manifest. A deep transitive dependency often needs an upgrade of the parent package that pulls it in, or an override in your package manager. Claude says which it is, so the engineer knows whether the fix is one line or a negotiation with a parent library.

Safeguard's software composition analysis and deep transitive dependency scanning (both GA) build the dependency tree that makes this distinction possible.

Blast radius turns one fix into many

Every finding and vulnerability record carries how many projects contain it and how many occurrences exist across the estate. The at-scale skill tells Claude to sort shared components by those counts, and to treat anything present in more than about a quarter of your projects as a platform-level fix. That one belongs with whoever owns the base image, shared library or service template, not filed against each team separately.

In the illustrative table above, date-utils is in nine projects. It is not reachable in payments-api, so it is not urgent there. It might be reachable somewhere else. A follow-up question settles it: "Is date-utils reachable in any project?"

When there is no fix version

An empty fix version means an upgrade will not resolve the vulnerability. The triage skill is firm that Claude must not present it as an upgrade task, because that produces a ticket nobody can complete. The honest options it lists:

• Find out why. Risk factors on the finding (for example, no patch from the distribution yet) often explain the gap.
• If not reachable, record it and monitor. That is a legitimate risk response under SSDF RV.2.2, provided it is written down.
• If reachable, the answer is a compensating control, removing the dependency, or a patched build. Claude says that plainly.

For the record-keeping half, Safeguard's mitigations and VEX support (CSAF and VEX upload, GA) let you document why a finding waits; see ingest and share VEX and CSAF in Safeguard. For the patched build route, see when upstream has no fix, which covers Safeguard's fork and patch flow (early access).

Policy gates, SLAs and "what will break the build"

In Safeguard, each finding is evaluated against policy gates. The finding record carries the gate's name and stage, the policy's name, severity and threshold, how long the finding has been open, and the policy's action, which is either warn or block. Safeguard's policies, gates and plain English policy creation (GA) are where those actions are set; see plain English security policies to release gates.

Those details live on per-project finding records, so for build and SLA questions the gate results in the Safeguard app are the answer to trust. What the triage skill adds is the right way to think about them.

"What will break our build?" is a question about the policy action, not severity. A high-severity finding under a warn policy will not stop a release. A medium under a block policy will. These are different conversations.

"Are we going to breach our SLA?" is a question about how long a finding has been open against your own policy thresholds. The triage skill tells Claude never to invent SLA windows. If your thresholds are not in the data Claude has, it says its timing advice is generic.

Deduplication matters here too. One CVE is evaluated once per gate, so a raw finding count can make one vulnerability look like several gate failures. Report distinct vulnerabilities and gate coverage separately.

Working across many projects

"What do I fix first?" sometimes means "across everything". The at-scale skill keeps Claude from looping over every project, which would exhaust its context and inflate every count. Instead it sweeps the project list 20 at a time, splits repository and CLI scans from dynamic scan targets and uploaded artifacts (they are never summed together), ranks on severity buckets, and flags stale, incomplete and test projects. For dynamic scan targets the overall risk level is not populated, so a target with hundreds of high-severity issues can read "Unknown"; Claude never treats that as safe. Then it drills into the top three to five projects and runs the per-project triage above.

For "is this CVE anywhere in our estate?", Claude does not loop at all: one vulnerability lookup returns the affected project and occurrence counts. And because the connector is stateless, "what changed since last week" needs a saved baseline; otherwise Claude says the numbers are point in time.

The accuracy rules that keep the numbers honest

The base skill exists because raw connector data, read naively, produces confidently wrong numbers. Its rules are worth knowing even if you never read the skill.

The reporting skill adds two more: component file paths are redacted at the API, so Claude never claims to know which file a component came from, and internal identifiers are never shown unless you ask.

Decision table: which question to ask, and what you get

Requirement, what Safeguard does, and what you still own

What Safeguard does not do

• The default connector does not act. On a new workspace, Claude can read and rank; it cannot change a finding's status, open a ticket, start a scan or raise a fix pull request. If you want any of that, a person does it in the Safeguard web app or CLI, or an administrator deliberately enables more tools.
• It does not scan anything new. The answer is only as current as your last scan. Claude flags stale scans, but it cannot refresh them over the default tools.
• It does not know your files or your history. Component file paths are redacted at the API, and the connector is stateless, so Claude cannot name the manifest line or say what changed since last week without a saved baseline.
• It does not give Claude everything the app shows. Per-project finding detail, including policy gate results and SLA timing, is fuller in the Safeguard app than over the Claude connector today. Use the app for gate and SLA questions.
• It does not make reachability perfect. Reachability analysis is GA, but Safeguard's docs mark static analysis for some languages (Ruby, PHP, Swift and Objective-C among them) as Preview. Expect more of those to stay high in the list.
• It does not guarantee a noise figure. Safeguard's docs say reachability filtering cuts 60 to 80% of CVE noise. Treat that as Safeguard's stated figure, and measure your own.
• It does not fix code it does not build. Vendor appliances, hosted services and operating system runtimes you do not ship still need a fix from their vendor.
• The companion skills are not a Safeguard product with its own maturity label. They are instructions in Claude. The data and the actions behind them carry the labels in this post.

Common mistakes

Asking for the whole estate in one go. Without the skills, "fix across all repos" can become a per-project loop that runs out of context and double counts. Start with one project, or ask for the sweep explicitly.

Reading raw finding counts as workload. A project with a few hundred finding rows may hold a few dozen distinct vulnerabilities, multiplied across gates. If an answer quotes a raw finding count, ask for the deduplicated number.

Treating unreachable as resolved. The skill demotes unreachable findings; it never drops them. Reachability can change when your code changes, and a KEV entry overrides it. Record why an unreachable finding waits, with a mitigation that expires.

Accepting a "clean bump" across a major version. If a row jumps a major version and Claude did not flag it, ask. Breaking changes cost more time than they save.

Filing the same upgrade against ten teams. A component in a quarter of your projects is a platform fix. Route it once to the owner of the base image or template.

Answering "what blocks the build?" with a severity list. The right filter is the policy action, warn or block. Check the gate results in the Safeguard app.

Trusting an old scan. If Claude opens with a staleness note, believe it. Re-scan before you plan a sprint around three-month-old numbers.

FAQ

How do I ask Claude what to fix first in Safeguard?

Add Safeguard from Claude's connector directory and sign in, then ask in plain language, for example "What should we fix first in payments-api this sprint?" Claude reads your Safeguard vulnerability data over the read-only connector, ranks them, groups CVEs by component and returns up to ten upgrades.

Does Claude use CVSS to decide what to fix first?

Only as a tiebreaker. Claude sorts on Safeguard's precomputed priority score, then promotes anything in CISA's KEV catalog and anything reachable with a fix available. CVSS separates items that are otherwise equal, which matches FIRST's guidance that base scores measure severity, not risk.

What is a batched fix list?

A list of component upgrades rather than CVEs. When several CVEs affect the same package version, one upgrade to the highest fix version usually clears them all, so Claude lists that upgrade once with the number of vulnerabilities it clears, after checking the target version covers each one.

Can Claude open Jira tickets or fix pull requests from Safeguard?

Not with the default connector. A new workspace exposes six read-only tools, so Claude drafts ticket text for you to paste. Pull requests come from Safeguard's autonomous remediation (GA), which ships switched off with every category set to Manual, or from the Safeguard CLI with your approval.

Does Claude ignore unreachable vulnerabilities?

No. Unreachable findings move down the list but stay on it, with a note explaining why. A finding in CISA's KEV catalog is promoted even if reachability says otherwise. Record a mitigation or VEX statement for anything you decide to defer.

What happens when a vulnerability has no fix version?

Claude does not turn it into an upgrade task. It lists it separately with the honest options: monitor if unreachable, or apply a compensating control, remove the dependency, or use a patched build if reachable. Safeguard's fork and patch route for patched builds is early access.

Do I need the Safeguard companion skills for Claude?

They are not required, but they make answers consistent. Without them Claude can still call the six tools, but may count duplicated finding rows, sort by severity, or answer CVE by CVE. You can approximate the skills by pasting the ranking procedure into a Claude project's instructions.

Can I change how Claude weights EPSS, KEV and reachability?

In the conversation, yes: ask for a different weighting and Claude re-ranks, labelling the result as departing from the platform score. To change the score your dashboards and gates use, change the prioritisation settings in Safeguard itself, as the prioritisation post describes.

Does this work in ChatGPT?

The same Safeguard MCP server serves ChatGPT, and the same questions work. The companion skills are written for Claude. Safeguard's ChatGPT guide covers how to connect, and the Claude and ChatGPT setup post walks through it.

From a fix list to merged changes

A ranked, batched fix list tells you which upgrades to make first; it does not make them. The section below covers how Safeguard turns that list into merged changes, including Gold Open Source (GA) for confirming the safe version, and what to do for the items the list marks as having no fix version.

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 setup half of this post: connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. It covers the connection and the permission step, not the ranking itself. Once that step is done, every question in this post is one message away.

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

The second demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix the lodash CVE in a repo: the assistant reads the finding and the 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, then shows the /permissions, /model and /scan commands. That is what happens to row one of your fix list after Claude ranks it: a reviewed change, made with your approval.

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 scans from the terminal. Use it when the fix list Claude gives you is stale and you need a fresh scan without granting Safeguard repository access.

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

To try it on your own code, download the apps and CLI at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs. For the full map of capabilities and labels, see what Safeguard does today. For asking Claude about a single finding's reachability, see ask Claude if a finding is reachable, and for the free lookup and CI gate, use Gold Open Source in your workflow.

Quick check

Sources

• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: Probability, percentiles and binning in EPSS
• FIRST: CVSS v4.0 user guide
• CISA: Known Exploited Vulnerabilities catalog
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• NIST SP 800-218, Secure Software Development Framework v1.1
• NIST SP 800-218 full text (PDF)
• OWASP Top 10 2021, A06 Vulnerable and Outdated Components
• Model Context Protocol: introduction
• Anthropic: Getting started with custom connectors using remote MCP
• Anthropic: Agent Skills overview
• Safeguard docs: Claude integration
• Safeguard docs: MCP server with Claude
• Safeguard docs: MCP tool gating
• Safeguard docs: Vulnerability prioritization (reachability analysis)
• Safeguard Gold Open Source
• Safeguard downloads

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