SCA From a Supplier SBOM in Safeguard: Import, Match and Track

To run software composition analysis on a product you did not build, upload the supplier's SBOM to Safeguard through Integrations, Upload SBOM. Safeguard validates the file, matches every component to known vulnerabilities with EPSS and CISA KEV context, and keeps rescanning it daily. Add the supplier's VEX or CSAF file to record what does not affect you, then track the vendor, each new SBOM version and every alert in Third Party Risk Manager (TPRM).

That is the whole flow in three sentences. The rest of this post walks through it step by step, using only what Safeguard's docs describe, and is honest about where the supplier's own data runs out.

Key takeaways

• SBOM generation and analysis (GA) accepts CycloneDX 1.3 to 1.6 (JSON and XML) and SPDX 2.2 and 2.3 (JSON, tag value and RDF). Syft and Trivy JSON are converted to CycloneDX, and Grype JSON has its vulnerability data imported.
• SCA and vulnerability management (GA) match each imported component to CVEs drawn from NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins, then add EPSS scores and KEV status.
• CSAF and VEX upload (GA) takes CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile, so a supplier's "not affected" statements sit next to the findings they explain.
• TPRM (GA) holds the vendor record, sends SBOM requests, tracks each one from Sent to Validated or Rejected, scores the vendor from 0 to 100 (higher is better) and alerts on new critical CVEs, KEV additions, score drops and stale SBOMs.
• Portal (GA), in its SBOM management sense, stores SBOM versions by product and compares two versions to show added and removed components and new and resolved vulnerabilities.
• The Safeguard CLI (GA) validates and scans a supplier SBOM locally, but it does not upload one to the platform. Upload goes through the web app.
• Reachability analysis (GA) needs your code. For a supplier product you usually have only the SBOM, so plan to prioritise on severity, EPSS, KEV and the supplier's VEX instead.
• Autonomous remediation (GA) ships switched off with every category set to Manual, and it fixes code you own. For a supplier product, the fix still has to come from the supplier.

Why supplier SBOMs need SCA, not just a filing cabinet

Most security teams already run SCA on their own repositories. The gap is the software they buy. A line of business application, an on premises agent, an appliance image or a desktop tool installs hundreds of open source components that never pass through your build. When a serious library CVE is announced, the first question from leadership is "are we exposed?", and for bought software the honest answer is often "we have asked the vendor".

An SBOM changes that, but only if someone does something with it. A supplier SBOM sitting in a shared drive answers nothing. It has to be parsed, matched against vulnerability data, checked again tomorrow when new CVEs land, and compared with next quarter's version when the supplier ships an update. That is SCA, run on a document instead of a codebase.

Three things go wrong when teams skip this step.

1. The SBOM is accepted without being checked. Files arrive with missing versions, blank producer fields or no package identifiers. Nobody notices until an incident, when the component you need to find turns out to be listed as "unknown".
2. The SBOM is scanned once and forgotten. A clean scan on the day of purchase says nothing about the CVE published three months later. Vulnerability data changes daily; the SBOM does not.
3. Supplier statements and your findings live in different places. The vendor sends a VEX or a security advisory saying a CVE does not affect their product, but it lands in an inbox. Your scanner keeps flagging the CVE, and someone re-asks the same question every quarter.

The rest of this post is about closing those three gaps inside one system.

What the standards expect from a supplier SBOM

You do not need to quote standards to your supplier, but knowing what they say tells you what a usable SBOM should contain and what you are entitled to ask for.

CISA's 2026 minimum elements

On 29 July 2026 CISA, together with the NSA, the FBI and international partners, published the 2026 Minimum Elements for a Software Bill of Materials (SBOM). CISA says it updates and replaces the minimum elements the NTIA published in 2021. Its key actions are aimed at both sides of the exchange: organisations should request SBOMs that satisfy the updated elements, and should use tools to generate, ingest and analyse SBOM data. Ingesting and analysing a supplier's SBOM is exactly the flow this post covers.

The 2026 document splits its data fields into SBOM metadata and component data. Table 1 in its Appendix A lists them:

It also sets practices and processes: Coverage, Machine-Processable Data, Explicitly Identifying Unknown Information, Accommodation of Updates to SBOM Data, Frequency, and Distribution and Delivery. The old Access Controls element is removed and folded into Distribution and Delivery.

Four changes matter most when you run SCA on a supplier file:

• Component Identifiers now asks for at least one machine-processable identifier per component, naming Common Platform Enumeration (CPE) and Package URL (PURL) as common examples, and asks authors to include all identifiers they have. This is the field vulnerability matching depends on.
• Component Version is what decides whether a component falls inside an affected range.
• Component Producer replaces the 2021 Supplier Name field, which the document says proved ambiguous in practice, particularly where software passes through distributors.
• Component Hash Value, Component License and SBOM Author Signature are new. They give you a way to check a component artifact, read its license and confirm who signed the SBOM.

The document also asks SBOM authors to say explicitly when information is unknown, rather than leaving a field blank. A supplier file that states "unknown" is more useful than one that stays silent, because you can see exactly where the gaps are.

History. The NTIA's 2021 report, The Minimum Elements For a Software Bill of Materials, set the original baseline of seven fields: Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data and Timestamp. CISA published a draft update on 22 August 2025 and took public comments until 3 October 2025. The 2026 document, version 2.1 in its own version history, is the final result of that comment period and supersedes the 2021 list. If an existing contract still cites the NTIA 2021 elements, plan to update it at renewal.

Package URLs make matching reliable

The Package URL specification (purl) defines a single identifier for a package across ecosystems, built from seven parts: scheme:type/namespace/name@version?qualifiers#subpath. The scheme is always pkg. A purl such as pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1 tells a matcher the ecosystem, the group, the artifact and the exact version in one string. The purl project notes that PURL was added to the CVE Record Format in version 5.2.0, which makes it easier for advisories and SBOMs to line up.

Safeguard's own docs make the same point from the other side: when package URLs are malformed or a package is not in public databases, Safeguard still tracks the component but cannot enrich it. No purl, weak matching.

How vulnerability databases describe affected versions

The OSV schema, one of the sources Safeguard lists, describes each affected package with an ecosystem, a name, an optional purl and version ranges marked by introduced, fixed and last_affected events. That structure is why the version field in a supplier SBOM matters so much. A component listed as log4j-core with no version cannot be placed inside or outside a range.

VEX and CSAF: the supplier's side of the story

An SBOM tells you what is inside a product. It does not tell you whether a vulnerable component is actually exploitable there. That is the job of VEX (Vulnerability Exploitability eXchange). CISA publishes Minimum Requirements for VEX, and the formats Safeguard accepts implement the idea in different ways:

• CSAF 2.0, an OASIS standard, defines a VEX profile (Profile 5) whose document category is csaf_vex. Its product_status object can list products as known_affected, known_not_affected, fixed, first_fixed, under_investigation and more.
• OpenVEX expresses statements with a status such as not_affected and a justification such as vulnerable_code_not_present.
• CycloneDX supports vulnerability disclosure and VEX use cases inside the same format family as its SBOMs.

A supplier that sends both an SBOM and VEX is giving you the inventory and its own exploitability assessment. Your job is to hold both in one place and decide how far to trust the second.

Supply chain risk management frameworks

NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (May 2022, with updates as of November 2024), treats supplier risk as a continuing activity across the organisation rather than a one time purchase check. NIST SP 800-218, the Secure Software Development Framework version 1.1, sets out practices for producers. Read together, they point to the same operating model: ask suppliers for evidence, analyse it, and keep analysing it for as long as the software runs in your environment. The flow below is that model in product terms.

The flow in one picture

Before the steps, here is how the pieces fit:

If you already collect SBOMs and only want the analysis, start at step 3 below. If you are starting a supplier programme from nothing, our longer post on collecting SBOMs from hundreds of software suppliers covers tiering and chasing in depth, and this post picks up once the file arrives.

Step by step: SCA on a supplier SBOM in Safeguard

Step 1: Add the supplier as a vendor in TPRM

TPRM, the Third Party Risk Manager (GA), is where the supplier relationship lives. Per the Vendor Management docs:

1. Go to Vendors and click Add Vendor.
2. Enter the company name, primary contact, contact email, website and the products you use.
3. Set a risk tier: Critical, High, Medium or Low.
4. Click Save.

If you have many suppliers, the docs describe a bulk import: download the CSV template, fill it in, upload it and confirm. Each vendor record tracks contract status, risk tier, SBOM status (received, requested or none) and the date of the last assessment.

The tier matters for what you ask. The TPRM overview suggests a starting policy: Critical vendors (core business operations) with an SBOM required and updated quarterly, High vendors (significant data access) with an SBOM required and updated annually, Medium recommended and Low optional. Treat that as a default to adjust, not a rule.

Step 2: Request the SBOM and track the request

From the vendor record, the SBOM Requests docs describe a single request:

1. Open the vendor and click Request SBOM.
2. Select the product or products.
3. Choose a request template, customise the message if you want, and set a deadline.
4. Click Send.

For several vendors at once, go to Vendors, select them, click Bulk Request, configure the settings and send. The standard template asks for SPDX or CycloneDX, lists required fields with EO 14028 in mind, and includes submission instructions and the deadline. You can build your own under Settings › Request Templates.

Each request moves through six statuses:

Automated follow ups remind the vendor seven days before the deadline and again at the deadline, then escalate seven days after it. The docs list four ways a vendor can submit: email attachment, a secure upload portal, API submission and direct integration. TPRM also offers a vendor portal where suppliers can update their own details, submit SBOMs and respond to questionnaires.

When an SBOM arrives through TPRM, the docs describe a validation pass: format validation, a completeness check against required fields, an EO 14028 compliance check, an automatic vulnerability scan and a notification to whoever made the request. If it fails, click Request Revision, say what needs correcting, and the vendor receives the update request.

If you already have the file in hand, from a contract pack, a download portal or an email, skip to step 3.

Step 3: Check the file before you import it

A two minute check saves a confusing first scan. The Safeguard CLI (GA) can validate an SBOM against its specification and scan it locally, without sending the file anywhere. The Existing SBOM docs show exactly these two commands:

# Check the document against its specification
safeguard validate sbom.json

# Scan it for vulnerabilities, writing results under ./output
safeguard scan --sbom sbom.json

The same docs are clear that the CLI does not upload SBOMs to the platform. Use it for a first look, especially when the file comes from a supplier you have not dealt with before or you want results before anyone else in the tenant sees the file. Then upload through the web app for tracking.

While you have the file open, sample twenty components and check four things by eye:

• Format and version. Is it CycloneDX 1.3 to 1.6 or SPDX 2.2 or 2.3? Safeguard's import docs list those versions. An SPDX 3.0 file, which the SPDX project now lists as its current version, is not in that list.
• Package URLs. Does each component carry a purl? Without one, Safeguard can track the component but cannot enrich it.
• Versions. Are versions exact (2.17.1) or vague (2.x, latest, blank)? Ranges cannot be matched to affected ranges.
• Depth. Do you see transitive dependencies with relationships, or only the handful of top level libraries?

If the file fails here, send it back with specifics. Our posts on what to check first in a vendor SBOM and what to test when an SCA tool imports supplier SBOMs go deeper on intake checks.

Step 4: Upload the SBOM through Integrations

This is the core of the flow. SBOM generation and analysis is GA, and the Existing SBOM docs describe four steps:

1. Navigate to Integrations. Open Integrations in the sidebar. You can filter the cards by All, Source Code (SCM), Container Image, AI Model or Upload. Click Connect on the Upload SBOM card.
2. Enter project details.

3. Upload the file. Drag and drop it, or click Browse. Accepted extensions are .json, .xml, .spdx and .rdf, up to 100MB.
4. Review and submit. Safeguard shows the detected format and component count. Check the count against what you expect, then click Upload SBOM.

If the supplier sent the output of a common open source SBOM tool rather than a standard document, the docs say Syft JSON and Trivy JSON are converted to CycloneDX, and Grype JSON has its vulnerability data imported.

A note on naming. The Version field is what makes later comparison possible. "Billing Agent 7.4.2" and "Billing Agent 7.5.0" are two versions of one product you can diff. "Billing Agent Oct" and "Billing Agent new" are not.

Step 5: Read what Safeguard did with the file

After upload, the docs describe three stages.

Validation. Format compliance (valid JSON or XML), schema validation against the CycloneDX or SPDX specification, required fields present, and component data quality.

Enrichment. Vulnerability data through CVE matching for all components, EPSS scores, CISA KEV status, license information and supplier data (package maintainer information).

Analysis. Griffin AI looks at attestation scoring, risk scoring, reachability and dependency health.

Then check the quality metrics the docs list for every uploaded SBOM:

These numbers are your evidence for a revision request. "PURL Accuracy is low and Version Specificity is poor for these 40 components" is a far more useful message to a supplier than "your SBOM is not great".

Step 6: Work the matched vulnerabilities

The upload creates a project. Open it from Projects and you get the same Project Overview tabs Safeguard uses for your own code, documented on the Explore SBOM page: Info, Attestation, Dependencies, Provenance, Vulnerabilities, Mitigations, Security Posture, Code Quality, Suppliers & Licenses and Findings. Several of those are built for code you own. For a supplier SBOM, four do most of the work.

Info. Shows the project name, version, created date, who created it and the generation method, plus charts for findings by severity, vulnerabilities by severity, supply chain risk by component and findings by gate.

Dependencies. A tree view (parent and child relationships, depth, version, vulnerability indicators) and a table view (name and version, license, vulnerability count, last updated). If the supplier's SBOM has no dependency relationships, the tree will be flat, which tells you something about the file.

Vulnerabilities. The Vulnerabilities docs describe five categories: Critical, High, Medium, Low and Exploitable, the last meaning known active exploitation in the wild. For each vulnerability you see:

You can filter by severity, CVSS range, EPSS range, exploitable status, component name, fix availability, reachability status and date range. Griffin AI natural language search accepts questions such as "Show me critical vulnerabilities in production that are actively exploited".

EPSS, maintained by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days and is published daily for every CVE. CISA's Known Exploited Vulnerabilities catalog records CVEs with evidence of exploitation. Together they are the most useful prioritisation signals you have for a product whose code you cannot see. Our post on prioritising with reachability, EPSS and KEV explains how Safeguard combines them for your own projects.

Suppliers & Licenses. License distribution, compatibility analysis, supplier information and attribution requirements. Useful when legal asks what open source licenses ride along inside a purchased product.

A worked example

Here is an illustrative case, not a real supplier. A Critical tier vendor sends a CycloneDX 1.5 JSON SBOM for version 7.4.2 of an on premises billing agent. You validate it with safeguard validate, upload it as "Example Billing Agent", version 7.4.2, and Safeguard reports the detected format and component count.

The quality metrics show high PURL Accuracy and Version Specificity, so matching should be reliable. The Vulnerabilities tab shows a handful of Critical and High findings. You filter to Exploitable and find one CVE that is in the KEV catalog, with a fixed version available upstream. Another High finding has a low EPSS score and no KEV entry.

Your next actions are clear without anyone guessing. The KEV finding goes to the supplier with a request for a fixed release date or a VEX statement. The low EPSS finding goes on the list for the next quarterly review. Everything else waits for the supplier's VEX in step 7.

Step 7: Upload the supplier's VEX or CSAF advisory

CSAF and VEX upload is GA. When the supplier sends exploitability statements, the CSAF/VEX Upload docs describe four steps:

1. Go to Integrations and filter by Upload.
2. Click Connect on the Upload CSAF/VEX card.
3. Enter a Name and, optionally, a Description. Drag and drop the file or click Browse. Safeguard validates it automatically.
4. Set the Project Name and Version, then click Upload.

Use the same project name and version you used for the SBOM, so the statements land against the right product.

Supported formats, from the docs:

The docs give this OpenVEX example of the kind of statement a supplier might send:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2024/001",
  "author": "Example Corp",
  "timestamp": "2024-01-15T00:00:00Z",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2024-12345" },
      "products": [ { "@id": "pkg:npm/example-package@1.0.0" } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present"
    }
  ]
}

And this CSAF fragment, where the product_status marks a product as known not affected:

{
  "document": {
    "category": "csaf_vex",
    "title": "Example Security Advisory",
    "publisher": { "category": "vendor", "name": "Example Corp" },
    "tracking": {
      "id": "EXAMPLE-2024-001",
      "status": "final",
      "version": "1.0.0",
      "current_release_date": "2024-01-15T00:00:00Z"
    }
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2024-12345",
      "product_status": { "known_not_affected": [ "PRODUCT-1.0" ] }
    }
  ]
}

Per the docs, VEX uploads let you mark vulnerabilities as not affected for your products, document mitigation status, track exploitability assessments and reduce false positives in vulnerability reports. CSAF uploads let you import vendor security bulletins and CVE advisories that affect software you run.

Notice the identifiers. The OpenVEX statement names its product by purl, and the CSAF example by a product ID. A VEX statement is only as useful as its match to the SBOM, so ask suppliers to use the same identifiers in both. Our post on ingesting and sharing VEX and CSAF in Safeguard covers the VEX side in more detail, including when you are the one publishing it.

Step 8: Record your own decisions

Supplier statements are one input. Your decisions are another, and they need an audit trail. The Vulnerabilities docs describe two actions.

Mark as False Positive. Click Mark False Positive, provide a justification, and submit for approval if your policy requires one.

Accept Risk. Click Accept Risk, set an expiration date, document the business justification and submit for approval.

The project's Mitigations tab then shows active mitigations, risk acceptances with their expiration dates, false positive markings and the mitigation history. TPRM's Risk Assessment page describes a matching flow at vendor level: review the risk finding, click Accept Risk, give a business justification, set a review date and obtain approvals.

Set expiration dates on every acceptance. A risk accepted on the strength of a supplier promise ("fix in the next release") should expire on the date of that release, so it comes back to you if the release slips.

Step 9: Keep tracking without lifting a finger

This is where SCA on a supplier SBOM pays off. The docs describe tracking at three levels.

Project level, in ESSCM. Safeguard performs daily continuous scanning of all projects and re-evaluates them when new CVEs are published. For uploaded SBOMs specifically, the Existing SBOM docs list daily scans for new vulnerabilities, KEV updates that alert on newly exploited CVEs, dependency updates when newer versions are available, and license changes.

Vendor level, in TPRM. The Monitoring docs list what is watched: new vulnerabilities affecting vendor SBOMs, severity changes, exploit availability updates, CISA KEV additions and component health changes. Configure alerts under Settings › Monitoring:

Alerts can go to email, Slack, Microsoft Teams, PagerDuty or a custom webhook. You can also set periodic re-analysis of vendor SBOMs daily (for critical vendors), weekly, monthly or quarterly, and trigger re-assessment on new disclosures, major version updates, contract renewals and security incidents.

Version level, in Portal. Portal (GA), in its SBOM management sense, has an SBOM Repository that groups SBOMs by product and version. Its Version Comparison takes two versions of the same product and shows added components, removed components, version changes, new vulnerabilities and resolved vulnerabilities. When the supplier sends 7.5.0, that diff is the fastest way to see whether last quarter's KEV finding actually went away. The docs also describe a manual import in Portal: click Import SBOM, select the format, upload the file or paste the content, assign it to a product and version, and click Import.

TPRM's own dashboard rolls this up across suppliers: aggregate risk metrics, vendors that need attention, recent score changes and upcoming SBOM expirations, with scheduled weekly, monthly, quarterly and annual reports and on demand reports in PDF or Excel.

Step 10: Read the vendor risk score correctly

TPRM gives each vendor a risk score from 0 to 100, and in TPRM a higher score is better:

The score draws on vulnerability risk (critical and high counts, EPSS, known exploited vulnerabilities), compliance risk (EO 14028 compliance percentage, missing required fields, SBOM age, format validity), component risk (abandoned packages, license compliance, transitive depth) and operational risk (response time to requests, update frequency, incident history, contract compliance).

Do not mix this score up with the component and project scores elsewhere in Safeguard, which run in the other direction. When you report upward, say "TPRM vendor score, higher is better" every time.

From the Risk Assessment page you can generate a report per vendor (executive summary, score breakdown, vulnerability details, compliance gaps, recommendations), compare vendors side by side, and track remediation the vendor has committed to: requested fixes, commitments, progress updates and verification status.

Step 11: Ask questions from Claude or your terminal

If your team works in an AI assistant, Safeguard's MCP server (GA) is available in the Claude connector directory as a community connector. Install it from the directory, sign in with OAuth, and choose which tools Claude can use. You can then ask, in plain language, which findings on the imported supplier project are in KEV, which have a fixed version, and what changed since the last version. Our post on Safeguard in the Claude and ChatGPT connector directories covers setup. Treat answers as a starting point and confirm important ones against the project view.

Which path fits the file you received

Requirement, what Safeguard does, what you still own

What Safeguard does not do

Supplier SBOM analysis is useful, and it has hard limits. These are the ones to plan around.

1. It cannot see what the supplier left out. Safeguard analyses the components in the file. If the SBOM omits a bundled runtime, a vendored library or a statically linked binary, nothing in Safeguard will find it from the SBOM alone. Ask for depth and check the dependency tree.
2. It cannot verify that the SBOM matches the installed product. Validation checks format, schema and fields, not truth. Safeguard's docs advise you to verify authenticity, check digital signatures if present and record where each SBOM came from. That part is yours.
3. It does not upload from the CLI. The CLI validates and scans a supplier SBOM locally. Upload for continuous tracking goes through the web app, or through TPRM when the supplier submits.
4. It does not fix the supplier's code. Autonomous remediation (GA) ships switched off with every category Manual, and it opens pull requests against repositories you connect. A supplier's product is not one of them. Safeguard tracks the finding and your request; the patch has to come from the vendor.
5. Reachability is limited without code. The docs list reachability in Griffin's analysis of uploaded SBOMs, but call path analysis depends on code you usually do not have for a purchased product. Do not expect it to cut supplier findings the way it does for your own repositories. Lean on EPSS, KEV and the supplier's VEX.
6. It does not enrich components it cannot identify. Without a valid purl, or for a private package not in public databases, Safeguard still tracks the component but cannot add vulnerability or license data. Weak SBOMs give weak results.
7. It does not import every format. The docs list CycloneDX 1.3 to 1.6 and SPDX 2.2 and 2.3, plus Syft, Trivy and Grype JSON. SPDX 3.0, PDFs and spreadsheets are not on that list.
8. It does not decide whether to trust a VEX. Safeguard records a supplier's "not affected" statement. Whether that claim is credible, and whether to ask for evidence, is a judgement your team makes. Our post on whether to trust vulnerabilities embedded in a supplier SBOM is a good companion here.
9. It does not replace your contract. Safeguard can track SBOM obligations and expiry, but only the contract can require a supplier to send SBOMs, refresh them or respond to findings by a date.

Common mistakes

Naming projects by date instead of product version. "Vendor SBOM October" cannot be compared with "Vendor SBOM January". Use supplier, product and the product's own version number, and Portal's version comparison works for you.

Uploading without looking at the quality metrics. A clean vulnerability tab on an SBOM with poor PURL Accuracy does not mean a clean product. It may mean nothing was matched. Read Completeness, PURL Accuracy and Version Specificity before you read the CVE count.

Treating a "not affected" VEX as the end of the conversation. VEX is a supplier's assessment. For KEV listed vulnerabilities in Critical tier vendors, ask for the justification and keep a review date on any acceptance that depends on it.

Accepting risk with no expiry. Every risk acceptance in Safeguard takes an expiration date. Set it to the supplier's promised fix date, not a year out.

Scanning once at procurement. The value of importing into Safeguard is daily rescanning. If you only look at the first result, a local scan would have done.

Uploading VEX against the wrong project. CSAF and VEX uploads ask for a project name and version. Use exactly the ones you used for the SBOM, or the statements will not sit next to the findings they explain.

Mixing up score directions. TPRM's vendor score is higher is better. Component and project risk scores elsewhere in Safeguard are not. Keep them in separate sentences and separate charts.

Sending vague revision requests. "Please improve your SBOM" gets ignored. "Version Specificity is low; 40 components have no exact version; please resend as CycloneDX 1.5 JSON with purls" gets fixed.

Trying to script uploads against the documented REST paths. Some docs pages describe intended REST shapes that carry a banner saying they are not yet available. Use the web app upload and TPRM submission routes, which are documented as working today.

FAQ

How do I upload a vendor SBOM to Safeguard?

Open Integrations, click Connect on the Upload SBOM card, enter a project name, version and optional description, choose SPDX or CycloneDX or let Safeguard detect it, drop in the file (up to 100MB, .json, .xml, .spdx or .rdf) and click Upload SBOM. Safeguard validates, enriches and analyses it, then rescans it daily.

Which SBOM formats does Safeguard import?

The docs list CycloneDX 1.3, 1.4, 1.5 and 1.6 in JSON and XML, and SPDX 2.2 and 2.3 in JSON, tag value and RDF. Syft and Trivy JSON are converted to CycloneDX, and Grype JSON has its vulnerability data imported.

Can the Safeguard CLI upload a supplier SBOM?

No. The CLI can check a file with safeguard validate sbom.json and scan it locally with safeguard scan --sbom sbom.json, writing results under ./output. Uploading for continuous tracking is done in the web app.

How does Safeguard match SBOM components to vulnerabilities?

It matches each component to CVEs from sources including NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins, then adds EPSS scores, KEV status, license data and supplier data. Matching works best when components carry a valid Package URL and an exact version.

What happens if the supplier SBOM has no package URLs?

Safeguard still tracks the components, but per its docs it cannot enrich packages it cannot identify. Check the PURL Accuracy metric after upload and send the supplier a revision request if it is low.

Can I upload a supplier's VEX to suppress findings?

You can upload CSAF 2.0, CycloneDX VEX, OpenVEX or CSAF VEX files through Integrations › Upload CSAF/VEX. The docs say this lets you mark vulnerabilities as not affected, document mitigation status and reduce false positives. Decide case by case how much to trust the supplier's statement.

How often does Safeguard rescan a supplier SBOM?

Safeguard performs daily continuous scanning of all projects, and the docs list daily scans and KEV updates for uploaded SBOMs. In TPRM you can also schedule vendor SBOM re-analysis daily, weekly, monthly or quarterly.

How do I see what changed between two versions of a supplier's SBOM?

Upload each version under the same product with its own version number. Portal's SBOM Repository version comparison shows added and removed components, version changes, new vulnerabilities and resolved vulnerabilities.

Does a higher TPRM vendor score mean more risk?

No. TPRM's 0 to 100 vendor score is higher is better: 76 to 100 is Low risk and 0 to 25 is Critical. Other risk scores in Safeguard run the other way, so label them clearly in reports.

Is the Portal here the same as the free tier?

The name covers two things. Portal is the free entry tier (free signup, one existing repo plus one open source repo from GitHub, GitLab or Bitbucket, one project per month, SCA only), and it is also the SBOM publishing, sharing and repository product. This post uses the second meaning. Our post on publish versus share in Portal explains that side.

Most of a supplier's exposure is fixed by the supplier, which is why this post spends so long on tracking. For the open source and container images your own teams build and ship, you can close the gap yourself, and the section below sets out how.

Fix it without waiting for upstream

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

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to Safeguard with OAuth and shows how you choose which tools Claude can use. Once a supplier SBOM is imported, the same connection lets you ask Claude which findings on that project are known exploited and which have a fixed version, without leaving the chat.

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

The second demo is a real Safeguard CLI session on a repository: it reads a finding and its advisory, asks before any command that changes something, upgrades the dependency, runs the tests and pushes nothing. For a supplier SBOM you would use the same CLI for the read only part, safeguard validate and safeguard scan --sbom, before uploading the file in the web app.

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

To try it on your own supplier files, download the apps at safeguard.sh/download and read the full guides at docs.safeguard.sh.

Quick check

Sources

• Safeguard Docs: Existing SBOM
• Safeguard Docs: Generate SBOM
• Safeguard Docs: Explore SBOM
• Safeguard Docs: Vulnerabilities
• Safeguard Docs: CSAF/VEX Upload
• Safeguard Docs: Third Party Risk Manager
• Safeguard Docs: TPRM Vendor Management
• Safeguard Docs: TPRM SBOM Requests
• Safeguard Docs: TPRM Risk Assessment
• Safeguard Docs: TPRM Monitoring
• Safeguard Docs: Portal SBOM Repository
• NTIA: The Minimum Elements For a Software Bill of Materials, 2021, superseded (PDF)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA: 2026 Minimum Elements for an SBOM (PDF)
• CISA: 2025 Minimum Elements for a Software Bill of Materials, draft for comment (history)
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• Package URL specification
• OSV schema
• OASIS: CSAF Version 2.0
• OpenVEX specification
• CycloneDX specification overview
• SPDX specifications
• NIST SP 800-161 Rev. 1
• NIST SP 800-218 SSDF version 1.1

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