Products, Projects, SBOMs, Findings: How to Count Vulnerabilities

In Safeguard, a product groups projects, each project scan produces an SBOM, and each finding is one vulnerability on one component version evaluated against one policy gate. A vulnerability is the estate wide record for a CVE. So "how many vulnerabilities do we have" has three honest answers: distinct CVEs, findings, or affected projects. Pick one and say which.

This post explains how those objects fit together, why the numbers disagree, and the accuracy rules that keep a count true whether you read it in the Safeguard app or ask Claude or ChatGPT through the Safeguard connector. The rules come from the companion skills Safeguard publishes for its connector, and the screen names come from the app itself.

Key takeaways

• Findings are not vulnerabilities. A finding is one row per vulnerability, per component occurrence, per policy gate. Safeguard's own connector guidance gives an illustrative example of a project with 640 findings and 39 distinct vulnerabilities. Dedupe on CVE, component name and component version before you report anything.
• Severity buckets and the project total can disagree. Use the Critical, High, Medium and Low buckets for breakdowns, treat a total of exactly 10,000 as "10,000 or more", and say which number you used.
• Check the provider before you trust a score. A DAST project (early access) leaves component counts, risk level and risk score unpopulated. "Unknown" is not "safe".
• Stale scans lie politely. If the last scan is older than about 14 days or the assessment is not complete, say so before you quote numbers.
• Maturity labels for everything in this post: SBOM generation and analysis (GA), SCA and deep transitive dependency scanning (GA), vulnerability management with EPSS and KEV enrichment (GA), reachability analysis and prioritisation (GA), policies, gates and guardrails (GA), autonomous remediation (GA, ships switched off), the MCP server behind the Claude connector (GA), the CLI (GA), CSAF and VEX upload (GA), Portal (GA), DAST (early access), fork and patch (early access).

The problem: one estate, three different "vulnerability counts"

Ask three people on the same team how many vulnerabilities the company has and you will often get three numbers. None of them is lying. They are counting different things.

• The developer counts rows in the findings list, because that is the list in front of them.
• The AppSec lead counts distinct CVEs, because that is the unit of analysis in an advisory.
• The executive counts affected projects or products, because that is the unit a business owner can act on.

Each number answers a different question. The trouble starts when one of them is reported as if it were another. In an illustrative case, a board slide that says "640 vulnerabilities" when there are 39 distinct issues tells leadership the team is sixteen times further behind than it is. A slide that says "39 vulnerabilities" when those 39 sit in 120 projects hides the fact that the fix touches dozens of teams.

What the standards actually ask you to count

None of the main frameworks tells you to count raw rows. They ask you to understand each vulnerability and act on it.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, puts this in its Respond to Vulnerabilities group. Practice RV.1 is "Identify and Confirm Vulnerabilities on an Ongoing Basis", and task RV.1.1 asks you to gather information on potential vulnerabilities in your software and in the third party components it uses, and to investigate credible reports. Task RV.2.1 asks you to analyse each vulnerability to gather enough information about risk to plan its remediation or other response. Task RV.2.2 asks you to plan and implement those responses, including a risk based decision on whether each vulnerability is remediated or handled another way. Task RV.3.3 asks you to look for similar vulnerabilities and fix the class, not just the instance.

The unit in every one of those tasks is the vulnerability, analysed in context. A finding row is evidence that a vulnerability exists in a place. It is not a separate vulnerability.

Severity is not risk, and neither is a row count

FIRST's CVSS v4.0 specification describes CVSS as capturing the principal technical characteristics of a vulnerability, with numerical scores that indicate severity relative to other vulnerabilities. It splits metrics into Base, Threat, Environmental and Supplemental groups, and expects consumers to add their own context. A severity bucket is a starting point, not a measure of your exposure.

Two other signals change the picture:

• EPSS. FIRST describes the Exploit Prediction Scoring System as a data driven model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days.
• CISA KEV. CISA calls its Known Exploited Vulnerabilities catalog the authoritative source of vulnerabilities that have been exploited in the wild, and tells organisations to use it as an input to vulnerability management prioritisation. For US federal civilian agencies, Binding Operational Directive 22-01 sets default remediation timelines: within two weeks for most catalogued vulnerabilities, and within six months for those with a CVE ID assigned before 2021.

If you count raw rows, a KEV listed CVE that appears once looks smaller than a low severity CVE that appears four hundred times. That inversion is exactly backwards.

One vulnerability, several identifiers

Counting "unique CVEs" sounds simple until you meet advisory aliases. The OSV schema, published by the OpenSSF, includes an aliases field that lists the IDs of the same vulnerability in other databases. One flaw can have a CVE ID, a separate advisory database ID and an ecosystem advisory ID at the same time. A tool that counts every identifier as a separate vulnerability will overcount. A tool that only counts CVE IDs will miss advisories that have not been assigned one yet. When you report a "unique" count, the key you deduplicate on matters.

Exploitability statements change the count too

A vulnerability can be present in a component and still not affect the product that ships it. CycloneDX describes VEX (Vulnerability Exploitability eXchange) as a way to communicate the exploitability of vulnerabilities in a specific context, so teams can focus on what is actually exploitable. If you have published or received a "not affected" statement, the honest count of open, affecting vulnerabilities is smaller than the raw count of matches. Safeguard supports CSAF and VEX upload (GA); the details are in our post on using VEX and CSAF in Safeguard.

How Safeguard structures the data

Safeguard's connector skill, the guide it ships so that Claude reads Safeguard data correctly, draws the model as a short tree:

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

Vulnerability sits outside the tree. It is the estate wide view of a CVE, and one vulnerability can produce many findings across many projects. Here is each layer in plain terms.

Tenant and organisation: the scope everything sits in

Above the tree sits your tenant and its organisation hierarchy. Safeguard's product reference describes the hierarchy as tenant, then organisation, then project, then version, with built in roles of Tenant Admin, Manager, User and Viewer. Every count you see is scoped to what your session can see. If your role only covers one business unit, "all vulnerabilities" means all vulnerabilities in that business unit.

Product: a group of projects

A product groups projects so you can see combined risk across a release train or a business unit. In the app, the Products view lists each product, and opening one shows its projects in a table with Project, Version, Status, Organization, Findings and Vulnerabilities columns.

The word "product" has a second meaning in Safeguard, and it is worth knowing both. In Portal (GA), a product is also the external catalog item you publish and share with customers, with a lifecycle of Draft, Review, Published and Archived. Our post on publishing versus sharing SBOMs from Portal covers that side. For counting, the grouping meaning is the one that matters: a product total is the sum of its projects, and the same CVE in three of its projects is still one CVE.

Project: the unit that gets scanned

A project is the thing Safeguard scans. Depending on how it was created, it can be a source repository, a CLI scan, a scanned live URL, or an uploaded artifact such as an Android APK or a manifest file. Each project carries its scan status and its severity counts.

A project has versions. In the app, the project header has a version dropdown that lists previous scans, newest first, and loads more as you scroll. Each version is a point in time. When you compare numbers, compare the same version, or you will be comparing last month's inventory with today's.

The project page has tabs. Which tabs appear depends on the kind of project. For a repository or CLI scan you will see tabs such as Info, Attestation, Dependencies, Provenance, Vulnerabilities, Security Posture, Code Quality and Findings, and the product reference also lists Mitigations and Suppliers & Licenses. A DAST target shows a different set built around the live site, such as Pages, APIs, Forms, Parameters, Certificates and Technologies.

SBOM: the inventory for one scan

Each scan of a project produces a software bill of materials: the list of components and versions that scan found. SBOM generation and analysis is GA, in SPDX and CycloneDX, with continuous scanning on push, on a schedule or on release. CISA describes the SBOM as a key building block in software security and supply chain risk management, and that is the right way to think of it here. The SBOM is the inventory. Vulnerabilities are matched against it.

Two consequences for counting:

1. A project with no SBOM has no component level findings. That is not the same as being clean.
2. The SBOM is per scan. A vulnerability that disappears between versions disappeared because the component changed, the advisory data changed, or a statement such as VEX changed its status. Check which before you claim a fix.

Our post on SBOM generation and analysis in Safeguard walks through the formats and the minimum elements.

Finding: one occurrence, one gate

A finding is the most granular row in Safeguard. It records one vulnerability on one component version, evaluated against one policy gate. Policies, gates and guardrails are GA, and a project can be evaluated against several gates, for example one at the planning and fix stage and one at the monitoring stage.

That is why findings multiply. The connector skill states it directly: the same CVE on the same component version commonly appears once per gate it is evaluated against, with the rows identical except for the gate name, the gate stage and the time of evaluation. Two gates double the rows. A component that appears in two places in the dependency tree can double them again.

Findings are still the right surface for triage. Each one carries the context you need to decide what to do: whether the CVE is in KEV, whether the vulnerable code is reachable, whether a fix version exists, the EPSS score and percentile, how deep the dependency sits, and which gate and policy action (warn or block) applies. They are the wrong surface for counting.

Vulnerability: the estate wide view of one CVE

A vulnerability record is one row per CVE across everything in your scope. Vulnerability management, including CVE detection from public advisory sources and EPSS and KEV enrichment, is GA. The record tells you severity and CVSS, and it carries three fields that answer the "how far does this reach" question without opening a single project:

• source_data_affected_project_count: how many projects contain it
• source_data_affected_component_count: how many distinct components carry it
• source_data_occurrence_count: total occurrences across the estate

Those three numbers, side by side, are the cleanest explanation of why counts disagree. One CVE. Some number of components. More projects. Many more occurrences.

Three numbers, three questions

Here is the same estate described three ways. The numbers are illustrative, built from the example Safeguard's connector guidance gives.

The last row is the one that most often surprises people. Several CVEs usually land on the same component at the same version, so one upgrade clears more than one of them. Safeguard's triage guidance turns a list of CVEs into a list of upgrades, for example:

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

The accuracy rules

These rules come from the safeguard connector skill, the entry point of the companion skills Safeguard publishes for its connector. They are written for an assistant, but they apply just as well to a person reading the app or an export. Field names are included so you can check an answer against the raw data. Numbers in the examples are illustrative, not measurements from any customer.

Rule 1: dedupe findings before you report a count

The key is:

source_data_cve_id + component_name + component_version

Never report a raw row count or a raw finding_count as a number of vulnerabilities. Say "39 distinct vulnerabilities across 14 components", and mention gate coverage separately if it matters. This rule applies to the app's Findings tab and its exports; through the connector, take counts from vulnerability and project rows instead.

In the skill's illustrative example, when you see finding_count: 640 next to total_vulnerabilities: 39 on the same project, that is not a contradiction. It is 39 vulnerabilities multiplied out across gates and occurrences.

Rule 2: severity buckets and totals do not always reconcile

On a project record, total_vulnerabilities and the sum of critical_vulnerabilities, high_vulnerabilities, medium_vulnerabilities and low_vulnerabilities can disagree. The connector skill gives two illustrative patterns: a project reporting 39 total with buckets summing to 20, and a DAST project reporting 10,000 total with buckets summing to 17,038, because the total is capped at 10,000.

The rules:

• For a severity breakdown, use the individual buckets. They are the more trustworthy number.
• Treat a total of exactly 10,000 as capped. Write "10,000+", never "10,000".
• If the buckets and the total disagree materially and someone is making a decision on the number, show the breakdown and note that the platform total differs. Do not silently pick one.
• vulnerability_count and total_vulnerabilities are the same value under two names. Do not add them together.

You can see the app handle the same gap. On a project's Findings tab, the Total Findings card breaks the total into Critical, High, Medium, Low and Unknown, where Unknown is whatever part of the total the known severities do not account for. The Vulnerability Findings card splits by Fix Available and No Fix, and adds Not Reported when some records carry no fix information either way. Those extra buckets exist precisely so the parts add up to the whole without hiding the gap.

Rule 3: check the provider before you read a field

The same fields mean different things depending on how a project was created. The connector exposes this as provider.

The trap is obvious once you see it. A DAST project showing risk_level: "Unknown" and hundreds of high severity issues is not low risk. It is a project type that does not fill in that field. Sort a portfolio by risk score and the highest volume web targets float to the bottom as if they were the safest. Use the severity buckets instead, and never put repository projects and DAST targets in the same ranked table. Their columns do not mean the same thing. Our post on DAST scope and verified targets explains what a DAST project contains.

Rule 4: say how fresh the numbers are

A clean report from a scan three months old is worse than no report, because people will believe it. Before you quote a project's numbers as current, check:

• last_scan_at: more than about 14 days old means the numbers may be stale.
• assessment_status: anything other than completed means the scan is not finished.
• assessment_progress: under 100 means the same.

Lead with the staleness note. Do not bury it under the table.

Rule 5: an empty result is not a zero

There are three common ways to get "nothing" back when something exists:

• Exact name matching. The name filter on project and product lists is exact match only. A partial name returns nothing. List and match yourself before concluding a project does not exist.
• Status filters. The stored finding statuses are open, resolved, ignored and in_progress, and filter aliases do not always match. If a status filter returns nothing, widen it to all statuses before saying there are no findings.
• Scope. An empty result covers your scope only.

Say which kind of empty you have. "No findings matched that filter in this project" and "this project has no vulnerabilities" are different statements.

Rule 6: keep internal identifiers out of the answer

Project IDs can be composite, such as a number with a version or date suffix, and must be passed back exactly as returned. Do not strip the suffix. But do not show internal IDs (organisation, tenant, product, component, gate, policy or SBOM IDs, or finding UUIDs) to a reader unless they ask. They mean nothing to a human.

One field is deliberately hidden: the path where a component was found is redacted at the API. Neither you nor an assistant should claim to know which file a component came from based on connector data.

Rule 7: coverage is part of the count

A tenant with 38 clean projects and 120 repositories that were never scanned is not in good shape. Counts only describe what was scanned. When you report posture, report coverage as a fraction: projects scanned against repositories you expected. The at scale skill also flags test and demo projects (scans of deliberately vulnerable public test sites, for example) as things to exclude from aggregates, with the exclusion stated, never done silently.

Step by step: reading the numbers in the Safeguard app

These steps use the screen and card names in the current app. Your tenant may show more or fewer tabs depending on the project types you have.

1. Start on the dashboard for orientation, not for the final number. The dashboard shows headline cards such as Total Findings, Findings by Severity, Findings by Gate, Issue Count by Vulnerability Severity, Most Risky Projects and Risk Score. Note that the first three are finding counts. Use Findings by Gate to see how much of the total is the same issue evaluated by several gates.
2. Open Products to see how projects group. Pick a product. The projects table shows Findings and Vulnerabilities side by side for each project. If the findings column is many times the vulnerabilities column, that is gate and occurrence multiplication, not a backlog.
3. Open one project and confirm the version. Check the version dropdown in the project header. Make sure you are looking at the latest scan, or at the specific release you mean to report on.
4. Read the Vulnerabilities tab for the distinct view. The Total Vulnerabilities card gives the severity split. Total Components splits components into Open Source, Third Party, Internal and Unknown. Total Mitigations shows what has been addressed. The Reachable, Exploitable and Reachable & Exploitable filters narrow the list to what reachability analysis (GA) and exploit data say matter most. Our post on prioritising with reachability, EPSS and KEV covers how those signals combine.
5. Read the Findings tab for triage, and read its cards carefully. Total Findings splits by severity, including Unknown. Vulnerability Findings splits by Fix Available, No Fix and, where it applies, Not Reported. Total Components splits by Open Source, Private and Unknown. Use this tab to decide what to do. Do not lift its totals into a report as a vulnerability count.
6. Group by component before you plan work. Several CVEs on one component version are one upgrade. Take the highest fix version across that component's CVEs, then confirm it covers the others. Flag major version jumps as needing a compatibility check.
7. Act from the app, the CLI or CI. From a project, AI Remediate starts Griffin's remediation flow. Autonomous remediation is GA and ships switched off, with every category set to Manual, so your team chooses what runs on its own. Gates that block a release live in your policies; see plain English policies to release gates.

Step by step: asking Claude or ChatGPT through the Safeguard connector

The same data is available to an assistant through Safeguard's MCP server (GA). Safeguard is listed in Claude's connector directory as a community connector. That listing means you can find and add Safeguard from inside Claude without pasting anything. It does not mean a partnership with Anthropic.

Connect from the directory

1. Sign in to claude.ai.
2. Open the Safeguard entry in Claude's connector directory and choose to connect. Safeguard's docs note the directory lives inside Claude, so the link needs an active Claude session.
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. There are no keys to copy.
4. Start asking questions. The connector uses your session's scope; you never need to tell it your tenant or organisation.

For ChatGPT, follow Safeguard's ChatGPT guide together with OpenAI's own documentation for adding apps in ChatGPT. Our post on Safeguard in your IDE and in the Claude and ChatGPT directories covers both routes, plan rules and admin controls in detail. Everything below about reading the data applies the same way in either assistant.

The default tools and which question each answers

The connector is read only. The connector skill is written around six read tools:

The routing rule follows from the data model. Counts read through the connector come from safeguard_list_vulnerabilities and from the severity buckets on project rows (safeguard_list_projects and safeguard_get_project). Findings are the heaviest and least reliable surface for counting, because each row carries a long description, sometimes thousands of words of root cause analysis.

One plain note on findings: Safeguard's own open issues list records that the findings tool returns no rows on the Claude connector today. Do not rely on the connector for occurrence level detail. Read findings in the app, on a project's Findings tab, and treat an empty findings answer in Claude as a known gap, not as proof that a project is clean.

Install the companion skills, or give your assistant the rules

Safeguard publishes a companion plugin with four skills that teach Claude to apply these rules on its own:

• safeguard: the tool map, the data model and the accuracy rules in this post.
• safeguard-triage: ranks and batches fixes using KEV, reachability, fix availability and EPSS rather than raw CVSS, and outputs component upgrades rather than CVE lists.
• safeguard-reporting: layouts for engineers, AppSec leads, executives and auditors.
• safeguard-at-scale: portfolio sweeps across dozens or hundreds of projects without exhausting the conversation.

What a correct answer looks like

Ask: "How many vulnerabilities does the payments service have?" A naive reading of the raw data (illustrative numbers again) produces something like "The payments service has 640 vulnerabilities." A reading that follows the rules looks like this (the numbers are illustrative):

**payments-service: 39 distinct vulnerabilities across 14 components**
Last scanned 3 days ago · assessment completed

| Severity | Count |
|---|--:|
| Critical | 2 |
| High | 9 |
| Medium | 6 |
| Low | 3 |

The platform total for this project is 39; the severity buckets above sum to 20.
The buckets are used for the breakdown. The 640 finding rows are the same
39 issues evaluated across several gates and occurrences.

Notice what it does. It names the unit (distinct vulnerabilities), shows freshness first, uses the buckets for the breakdown, and states the disagreement rather than hiding it.

Ask: "Is that CVE anywhere in our estate?" The right answer comes from one vulnerability lookup, not a loop over projects (illustrative values):

**CVE-XXXX-XXXXX is in 6 projects, on 2 distinct components, 41 occurrences.**
High · CVSS 7.5 · EPSS 0.6% (46th percentile) · In KEV: no · Fix available

Ask: "What should we fix first in the payments repo?" Through the connector today, the honest answer is built from vulnerability rows: KEV status, EPSS, severity and fix version, grouped by component. The full triage method in the companion skill also uses finding level fields (Safeguard's precomputed priority score and reachability per occurrence), which you read in the app's Findings and Vulnerabilities tabs. Either way, the output should be a short list of upgrades, promoting anything in KEV and anything reachable with a fix available, keeping unreachable items at lower priority, and stopping at about ten (illustrative):

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

Where the connector stops

The connector is read only. It reads results that already exist in your tenant. It does not start scans, change a finding's status, open tickets or raise fix pull requests. Those happen in the Safeguard web app, the CLI (GA) or your CI integration. A good assistant answer says so plainly instead of pretending to do it in conversation.

The connector is also stateless. It cannot tell you what changed since last week unless you saved last week's answer. For a weekly review, keep the output of each portfolio sweep so the next one has a baseline, or label the numbers as point in time.

Decision table: which number to use

What Safeguard does not do

• It does not decide your counting convention for you. The platform shows findings, vulnerabilities and project counts. Which one goes on a board slide is your call, and you should state it every time.
• The connector does not take actions. It is read only and reads data that already exists. Scans, triage state changes, tickets and fix pull requests happen in the app, the CLI or CI.
• It does not populate component level data for DAST targets. DAST (early access) projects carry severity buckets only. There is no SBOM, no component count and no risk score for those projects, so there is nothing to dedupe on a component key.
• The connector does not return finding rows today. Safeguard's open issues list records that the findings tool returns zero on the Claude connector. Read occurrence detail in the app's Findings tab.
• It does not report exact totals above the cap. A project total of 10,000 means at least 10,000. Use the buckets.
• It does not reveal file paths through the connector. Component paths are redacted at the API, so an assistant cannot tell you which file a dependency was found in.
• It does not count what you never scanned. Unscanned repositories, images and artifacts appear in no count. Coverage is yours to check.
• It does not replace your risk decision. SSDF RV.2.2 expects a documented decision per vulnerability, whether to remediate, accept or transfer. Safeguard gives you the inputs and the priority score; the decision and its record stay with your team.

Common mistakes

1. Reporting raw finding rows as vulnerabilities. The most common error, and the most expensive. Dedupe first.
2. Ranking a portfolio by risk score with DAST projects in the list. Their "Unknown" risk level and zero score push real exposure to the bottom.
3. Mixing repository projects and DAST targets in one table. The columns mean different things. Split by provider.
4. Treating unreachable as resolved. Not reachable means lower priority, not closed. Keep it on the list.
5. Sorting by CVSS alone. A reachable, KEV listed high with a one line fix outranks an unreachable critical with no exploit and no fix.
6. Filing one ticket per CVE. Several CVEs on one component version are one upgrade. Batch by component.
7. Quoting numbers from a stale or incomplete scan. Check the last scan date and the assessment status first.
8. Concluding "not found" from an exact name filter. Partial names return nothing. List and match.
9. Counting every advisory ID as a separate vulnerability. One flaw can carry several aliases. Know which key you deduplicated on.

FAQ

What is the difference between a finding and a vulnerability in Safeguard?

A vulnerability is the record for one CVE across your whole scope. A finding is one occurrence of that vulnerability on a specific component version, evaluated against a specific policy gate. One vulnerability can produce many findings across many projects and gates.

Why does Safeguard show more findings than vulnerabilities?

Because findings multiply by gate and by occurrence. The same CVE on the same component version appears once for each gate it is evaluated against, and again for each place the component occurs. Safeguard's connector guidance gives an illustrative example of 640 findings that come down to 39 distinct vulnerabilities.

How do I count unique vulnerabilities in Safeguard?

Deduplicate findings on CVE ID plus component name plus component version (source_data_cve_id, component_name, component_version). For a project level count, use the severity buckets on the project record or the Total Vulnerabilities card on the Vulnerabilities tab.

Why don't the severity counts add up to the total?

The total and the severity buckets are calculated separately and can disagree, and the total is capped at 10,000. Use the buckets for a breakdown and note the difference when someone is deciding based on the number. The app's Unknown and Not Reported buckets show the gap rather than hiding it.

What is the difference between a product and a project in Safeguard?

A project is the unit Safeguard scans: a repository, a CLI scan, a live URL or an uploaded artifact. A product groups projects so you can see combined risk. In Portal, "product" also means the external catalog item you publish and share with customers.

Why does my DAST project say risk level Unknown?

DAST projects do not populate risk level, risk score or component counts. "Unknown" means the field is empty for that project type, not that the target is safe. Read its severity buckets instead. DAST is early access.

Can Claude or ChatGPT change findings in Safeguard?

No. The connector is read only. It does not start scans, change finding status, open tickets or raise pull requests. Those actions live in the Safeguard web app, the CLI and your CI integration.

Is the Safeguard Claude connector an official Anthropic partnership?

No. Safeguard is listed in Claude's connector directory as a community connector. That makes it easy to find and add from inside Claude. It is not a partnership.

Can I try this without a paid plan?

Portal's free entry tier offers free signup with one existing repository plus one open source repository from GitHub, GitLab or Bitbucket, one project per month, SCA only. That is enough to see projects, SBOMs, vulnerabilities and findings for real code.

From an accurate count to a shorter list

Counting correctly tells you how much work you have; the next step is shrinking it. Once your findings are deduplicated into a short list of component upgrades, the options below are how those upgrades actually get shipped, including the cases where no fixed version exists yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation 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 Claude connected to the Safeguard MCP server with OAuth, and how you choose which tools Claude can use. It is the same connection every question in this post runs through, so it is the place to check which tools your workspace has turned on before you ask a counting question.

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

The second demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It 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 your approval, prints a summary and pushes nothing. That is the action side this post points to: the connector reads and counts, and the CLI is where one deduplicated component upgrade becomes a change.

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

To try it on your own code, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh. For an overview of every capability with its maturity label, see what Safeguard does today.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework version 1.1 (CSRC page)
• NIST SP 800-218 full text (PDF)
• FIRST, CVSS v4.0 Specification Document
• FIRST, Exploit Prediction Scoring System (EPSS)
• CISA, Known Exploited Vulnerabilities Catalog
• CISA, BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA, Software Bill of Materials (SBOM)
• OpenSSF, OSV Schema
• CycloneDX, Vulnerability Exploitability eXchange (VEX)
• Safeguard docs, Claude integration
• Safeguard docs, Analytics and dashboards
• Safeguard documentation home
• Safeguard download page

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