How do you collect SBOMs from hundreds of software suppliers?

To collect SBOMs from hundreds of software suppliers, treat it as an operations queue, not a letter. Tier your suppliers by how critical the software is, send each tier one standard request that names the CISA 2026 minimum elements, a format and a deadline, then track every request through sent, viewed, in progress, submitted and validated or rejected. Chase on a fixed reminder ladder, and re-request whenever a supplier ships a new version or an SBOM passes its age limit.

Writing one good SBOM request is easy. Getting four hundred of them back, valid, matched to the version you actually run, and still current six months later is the hard part. Most programs stall at the same place: a spreadsheet with a "requested" column, a shared inbox full of PDFs, and no one sure which suppliers were chased last week.

This guide is for third-party risk and vendor management leads at US banks, health systems and federal contractors. The first part is a method you can run with any tooling. The second shows how Safeguard's Third-Party Risk Manager handles requests, tracking, validation and monitoring, step by step from its docs, and what it does not do. This is not legal advice.

Key takeaways

• The bar for what to ask for moved in 2026. CISA's "2026 Minimum Elements for a Software Bill of Materials," dated 29 July 2026 and co-authored with NSA, FBI and international partners, replaces the 2021 NTIA minimum elements. Its first key action is that organizations should request SBOMs that satisfy the updated elements.
• Banks have a lifecycle to follow. The Interagency Guidance on Third-Party Relationships (88 FR 37920, final as of 6 June 2023) asks for oversight scaled to risk, with more rigorous oversight for third parties that support critical activities. SBOM requests belong in its due diligence, contract and ongoing monitoring stages.
• Federal buyers lost a mandate, not a tool. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16, but it says agencies may adopt contract terms that require a producer to provide a current SBOM upon request.
• Tier first, then request. Ask your critical tier first and accept nothing less than a machine-readable SPDX or CycloneDX file per deployed version. Lower tiers can wait or get a lighter request.
• Validation checks the file, not the build. A file can parse, carry every field and still describe the wrong version. Match it to what you run, and track hashes and signatures where the supplier provides them.
• An SBOM expires. Re-request on every new version you deploy, on an age threshold per tier, and on contract renewal.
• Report coverage by product version, not by supplier. "Share of tier 1 products in use with a validated, current SBOM" is the number leadership can act on.
• Safeguard capabilities in this post and their labels: TPRM, the Third-Party Risk Manager (GA), covering vendor management with risk tiers and a self-service vendor portal, single and bulk SBOM requests with templates, status tracking and automated follow-ups, validation and rejection, the 0 to 100 vendor risk score (higher is better) using EPSS and KEV, and monitoring alerts including SBOM expiry; Portal for storing received SBOMs and SBOM analysis (GA); CSAF and VEX upload (GA); the Safeguard MCP server (GA); the desktop app (early access, beta); autonomous remediation (GA, ships switched off with every category set to Manual); Gold Open Source and Gold Registry (GA); fork and patch (early access).

Why collecting SBOMs at scale is an operations problem

An SBOM request program fails quietly. The tracker just goes stale: a supplier ships version 9.4 while you hold an SBOM for 9.1, a contact leaves and requests bounce, a PDF gets filed as "received," and the coverage figure in the board pack stops moving.

The cause is volume times change. Several hundred suppliers, many with more than one product, each shipping versions on its own schedule, means a constant stream of small tasks: ask, wait, chase, check, file, ask again. Done by hand, that work grows with every supplier and version, and it is the first thing to slip when the team is busy.

The standards that create this work all assume you can keep up.

What CISA's 2026 minimum elements expect from buyers

CISA's 2026 Minimum Elements for an SBOM is the current baseline. Its version history shows a 2021 initial version, an August 2025 draft and the final version 2.1 on 29 July 2026, with NSA, FBI and partner agencies from more than a dozen countries listed as co-authors. The document is written for three audiences: organizations that produce, procure or operate software. The procure part is you.

Several of its practices turn directly into request and tracking requirements:

• Frequency. Each software version or update should have an associated SBOM, and a new build or release should come with a new SBOM. That single sentence is the reason a request program never finishes.
• Coverage. An SBOM should include all components, including transitive dependencies, with "no minimum depth." CISA's test is practical: a recipient should be able to conclude a new vulnerability does not affect them if the component is not listed.
• Machine-processable data. SPDX and CycloneDX are named as the two widely used formats. Organizations should accept any widely used, interoperable, machine-processable format, but should avoid accepting SBOMs for new software in deprecated format versions.
• Explicitly identifying unknown information. Where a field is missing, the author should say whether it is unknown or withheld, and CISA says organizations may consider an SBOM incomplete if essential component data is withheld.
• Distribution and delivery. SBOMs should be available promptly to those who need them. Access controls may limit sharing with unauthorized parties, but should not prevent sharing between authorized parties.

The data fields also grew. Alongside the familiar component name, version, identifiers and dependency relationships, the 2026 table adds SBOM Author Signature, Component Hash Value and Hash Algorithm, Component License, SBOM Data Format Name and Version, SBOM Generation Context, SBOM Tool Name and Version, and SBOM Version. The old Supplier Name field became Component Producer. If your request template still quotes the 2021 list, it is asking for less than the current baseline.

What CISA's framing document adds about depth

CISA's "Framing Software Component Transparency," third edition, published 15 October 2024, describes each SBOM attribute at three maturity levels. For depth, its minimum expected level is that SBOMs identify all static, direct dependencies of the primary component, while the recommended practice is to identify as many levels of subcomponents as possible. That gap matters when you validate: a supplier that sends only direct dependencies has met a minimum the 2024 framing describes, but not the 2026 coverage practice. Decide in advance which one you accept from which tier.

It also notes that no single exchange mechanism suits every ecosystem, so your request should name the delivery routes you accept.

What bank regulators expect

The Interagency Guidance on Third-Party Relationships: Risk Management from the Federal Reserve, FDIC and OCC was published at 88 FR 37920 and is final as of 6 June 2023. It does not mention SBOMs. It does set the shape of the program you run them through.

The guidance describes a third-party relationship life cycle of planning, due diligence and third-party selection, contract negotiation, ongoing monitoring and termination. It says not every relationship carries the same risk or needs the same oversight, and it calls for more comprehensive and rigorous oversight of relationships that support higher-risk activities, including critical activities. It leaves it to each banking organization to decide which activities are critical. On ongoing monitoring, it says monitoring may be periodic or continuous, and that more frequent monitoring fits higher-risk relationships.

For an SBOM program, tiering decides where "more rigorous" applies, the contract holds the SBOM duty, and the request cadence is part of ongoing monitoring.

What federal guidance expects

NIST SP 800-161 Rev. 1, the cybersecurity supply chain risk management practices for systems and organizations (May 2022, updated 1 November 2024), lists among acquisition practices ensuring that products, including software, are supplied with an SBOM that complies with agency-approved protocols. Its supplemental guidance to control SR-4, Provenance, says SBOMs should be digitally signed using a verifiable and trusted key. It also warns that SBOMs complement, and do not replace, vulnerability management and vendor risk assessments, and that organizations unable to ingest, analyze and act on SBOM data will not improve their posture. That warning is the case for treating collection as an operations job rather than a filing job.

On the policy side, OMB M-26-05, signed 23 January 2026, rescinded M-22-18 and M-23-16. It keeps the expectation that agencies maintain a complete inventory of software and hardware, and it says agencies may adopt contract terms requiring a producer to provide a current SBOM upon request. A footnote adds that for a cloud platform the term should cover an SBOM of the runtime production environment. Federal contractors should expect SBOM duties to arrive through contracts, agency by agency, rather than through one government-wide form. Older material that cites CISA BOD 22-01 is history too; that directive was revoked and superseded by BOD 26-04.

Health systems follow the same method. Regulated device makers have their own FDA path, but the rest of the estate (EHR modules, imaging archives, billing, identity) looks like any enterprise portfolio, with clinical criticality as one more tiering input.

Which suppliers should get an SBOM request first?

Start with the software that would hurt most if a new exploited vulnerability landed in it tomorrow. That is not your biggest spend: a small vendor whose agent runs with administrator rights on every endpoint matters more than a large SaaS contract that touches no sensitive data.

Tiering inputs that work

Score each supplier product, not just each supplier, on a handful of questions:

1. Does it support a critical activity? Use the definition your third-party risk policy already uses. For banks, the interagency guidance describes critical activities as those that could cause significant risk if the third party fails, have significant customer impact, or significantly affect financial condition or operations.
2. Where does it run? Software installed in your environment, on servers, endpoints or network edges, is where an SBOM helps most, because you can isolate, reconfigure or patch it.
3. What can it reach? Privileged access, sensitive data, patient or customer records, payment flows, and identity systems all raise the tier.
4. How exposed is it? Internet facing services and anything that parses untrusted input deserve more attention.
5. Do you have any other visibility? If the software is open source or you build it yourself, you can generate your own SBOM. Closed, vendor-built software is where you depend on the supplier.

A starting tier model

Safeguard's TPRM docs publish a simple default that is a reasonable place to start, and the table below adapts it with the request each tier gets.

Two adjustments are worth making. First, tier by product, because one supplier can sell you a critical identity agent and a low risk reporting add-on. Second, treat SaaS separately. CISA's 2026 document says SaaS SBOMs raise unresolved questions about frequency and shared responsibility, and OMB's cloud footnote points at the runtime production environment. For critical SaaS, the realistic answer may be a vulnerability notification commitment rather than a file per release.

Sequencing the waves

Do not send four hundred requests on day one. Send the critical tier first, perhaps thirty to sixty products, and use that wave to fix your template, validation rules and chase cadence before the high tier goes out. Our 30, 60, 90 day plan for consuming supplier SBOMs lays out that ramp in more detail.

What should the SBOM request ask for?

A request should be short enough that an account manager forwards it to an engineer, and specific enough that "here is a PDF" is plainly not an answer. The guide to writing an SBOM request to a supplier has full wording; here is the checklist for a request that works at scale.

Ask for vulnerability status, not just components

A component list tells you what is inside. It does not tell you whether a vulnerability in one of those components is reachable in the supplier's product. That is what VEX is for. CISA's "Minimum Requirements for Vulnerability Exploitability eXchange" (April 2023) defines four status values: not affected, affected, fixed and under investigation, and it requires a justification or impact statement when the status is not affected. CSAF from OASIS is the most structured carrier for those statements.

Ask critical tier suppliers to publish VEX or CSAF alongside the SBOM and to update it when they assess a new vulnerability. When a new KEV entry lands, a current VEX statement is often a faster answer than a fresh SBOM.

Put the duty in the contract

A request is a favour. A contract clause is an obligation. The interagency guidance spends a full section on contract negotiation, including rights to monitor the third party's compliance and to require timely remediation. OMB M-26-05 explicitly contemplates contract terms requiring a current SBOM upon request. At each renewal for a critical or high tier product, add an SBOM clause that names the format, the minimum elements, delivery with each release, a response time for vulnerability status questions, and how long you may keep the files. Our post on how long to keep supplier SBOMs after the contract ends covers the retention side.

How do you track hundreds of SBOM requests?

Track each request as a record with a status, an owner, a deadline and a history, and make the status move only on evidence. If you cannot answer "what happened to the request we sent this supplier on 3 March" in one click, the program will drift.

Use one state model for every request

The model that works is the one Safeguard's TPRM docs use, and it is worth adopting even if you build your own tracker:

Two rules keep it honest: a request is done only at Validated, never at Submitted, and every rejection produces a revision request naming the exact failures.

Fields every request record needs

Beyond status, each record needs the supplier, product and version requested, tier, template, supplier contact, internal owner, dates sent and due, reminder history, validation result and the date the resulting SBOM expires. Without version and expiry you cannot answer "is this current?" or "when do we ask again?"

Chase without spamming

Aim for predictable reminders a supplier can plan around, not daily nudges that train them to ignore you. A simple ladder works:

1. Reminder before the deadline, so the supplier has time to act.
2. Reminder at the deadline.
3. Escalation after the deadline, to the account manager or a named executive contact, copying your procurement owner.
4. Business review item. If there is still nothing, the request becomes an agenda item at the next account review or renewal meeting, and the risk owner signs a time-limited acceptance.

Safeguard's docs describe exactly this pattern for automated follow-ups: a first reminder 7 days before the deadline, a second at the deadline, and an escalation 7 days after. A few habits make the ladder land better:

• One request per supplier per wave. Bundle every product you need from that supplier into one request, so their team does one piece of work.
• One named contact. Ask procurement for the security or product contact at onboarding, and update it when requests bounce.
• Reasonable deadlines. Thirty days is common for a first SBOM; suppliers that already publish SBOMs can meet much shorter windows.
• Stop chasing on acknowledgement. When a supplier moves a request to In Progress with a date, pause reminders until that date.

How do you validate supplier SBOMs, and what counts as a rejection?

Validation should be a repeatable set of checks, run the same way for every file, with written rules for what fails. The guide to checking a supplier SBOM against the minimum elements walks through field level checks; at scale, run them in layers.

The validation layers

1. Format. Does the file parse as SPDX or CycloneDX? Is the format version current and not deprecated?
2. Identity. Does the SBOM describe the product and version you actually run? Compare the component name and version against your inventory. This is the check most programs skip and the one that causes most bad data.
3. Completeness. Are the minimum element fields present, or explicitly marked unknown or withheld? Are dependency relationships declared?
4. Coverage. Does the component list look plausible for the product? A large application with a handful of components and no transitive relationships is a warning sign.
5. Integrity. Is there an SBOM Author Signature or a hash you can verify? Is the signature from the entity you expect?
6. Freshness. Is the SBOM timestamp recent, and does it match the release date of the version you run?
7. Analysis. Run the components through vulnerability matching, flag any KEV matches and any components with no identifiers you can match.

Reject, or accept with a note?

Not every gap deserves a rejection. Write the rules down so two analysts make the same call.

The last row matters. Finding a known exploited vulnerability in a supplier SBOM is not a reason to reject the file. It is the reason you asked for it. Accept the SBOM and send a separate, specific question about status, fix version and interim mitigations.

What do you do when a supplier refuses or sends a PDF?

Most refusals come from three places: no SBOM tooling yet, worry about exposing the component list, or a request that reached someone who cannot say yes. Work through them in order.

1. Ask why, once, in writing. A short question ("Is this a tooling gap, a confidentiality concern, or a contract question?") turns a stalled thread into a solvable problem.
2. For confidentiality concerns, offer an access-controlled route: your upload portal, an NDA, or a time-limited share. CISA's 2026 distribution practice says access controls may limit sharing but should not prevent sharing between authorized parties.
3. For tooling gaps, point to open formats and tools and accept a first SBOM with gaps marked as unknown, on a dated commitment to improve.
4. For a PDF, log it as Rejected with the reason "not machine-processable," keep it as interim evidence, and ask for the source file. A PDF often means a tool generated the SBOM and someone printed it.
5. For a flat refusal, record a risk acceptance with an owner and a review date, and move the SBOM duty into the next contract renewal. Where your license allows it, you can also generate your own after-build SBOM from the installed software with binary analysis, labelled clearly as your work, not the supplier's.
6. For silence, follow the escalation ladder to a business review, then treat it as a refusal.

Keep a refusal register. "The supplier refused on these dates and the risk owner accepted until this date" is a far better answer for leadership than a blank cell.

When does a supplier SBOM expire, and what triggers a fresh request?

A supplier SBOM is current only while it describes the version you run and is younger than the age limit for its tier. When either stops being true, it has expired, and a new request should go out without anyone having to remember.

Set triggers in four groups:

• Version change. You deploy a new version, or the supplier announces one. CISA's frequency practice says each version or update should have its own SBOM.
• Age. The SBOM passes the age limit for its tier. The Safeguard docs default of quarterly for critical and annual for high is a reasonable starting point; tighten it for fast-moving products.
• Correction or new information. The supplier issues a corrected SBOM, or you find components the SBOM missed. CISA's 2026 document expects authors to accommodate corrections.
• Events. A contract renewal, a security incident at the supplier, or a major new vulnerability in a widely used component. For the last one, ask first for a VEX or CSAF status statement; ask for a fresh SBOM only if the old one is stale.

Our post on continuous vendor monitoring versus an annual review explains why these event triggers catch problems an annual questionnaire never will.

How Safeguard handles SBOM requests at scale, step by step

Safeguard's Third-Party Risk Manager (TPRM) is GA. Its docs split it into four parts: Vendor Management, SBOM Requests, Risk Assessment and Monitoring. The walkthrough below follows the docs pages linked in the sources. Where the docs do not show a screen, it describes the outcome instead of inventing one.

1. Build the vendor directory. Go to Vendors and click Add Vendor, then enter the company name, primary contact, contact email, website and products used, set the risk tier and click Save. For hundreds of suppliers, use Bulk Import: download the template CSV, fill it from your procurement or contract system, upload it, then review and confirm the import. Each vendor record tracks products, primary contact, contract status (active, pending or expired), risk tier, SBOM status (received, requested or none) and last assessment.

2. Set the tiers. TPRM can suggest a tier from data access level, system criticality, user count and compliance requirements. To change one, select the vendor, click Edit Risk Tier, choose the new tier, document the justification and save. The justification field is your audit trail for why a supplier sits where it does.

3. Link contracts and relationships. Attach contract documents, start and end dates, SLA terms, security requirements and SBOM obligations to each vendor, and record parent companies, subsidiaries, resellers and implementation partners. Contract end dates are what drive renewal-time SBOM clauses.

4. Write your templates. The standard template covers SBOM format requirements (SPDX or CycloneDX), required fields, submission instructions and deadline information. The docs describe the required fields in terms of EO 14028. For a 2026 program, create a custom template under Settings › Request Templates with Create Template, add the CISA 2026 data fields, coverage, signature and VEX asks from the checklist above, and save it for reuse. Make one template per tier.

5. Send the first wave in bulk. Go to Vendors, select the critical tier suppliers, click Bulk Request, configure the request settings (template and deadline), then review and send. For a single supplier, open the vendor, click Request SBOM, select the products, choose the template, add a message if needed, set the deadline and click Send.

6. Give suppliers a place to submit. The docs list an email attachment and a secure upload portal among the submission routes, and the self-service vendor portal lets invited vendors update their own information, submit SBOMs directly, respond to questionnaires and view their risk status. The docs also list API and direct integration routes; confirm their current availability with Safeguard before you offer them to suppliers.

7. Track every request. Each request moves through Sent, Viewed, In Progress, Submitted, and then Validated or Rejected. That status, per supplier and product, is the queue your team works every week.

8. Let follow-ups run. Automated reminders go out 7 days before the deadline and at the deadline, with an escalation 7 days after. The ladder is the same for every supplier, which keeps the chasing fair and predictable.

9. Validate on arrival. When an SBOM is received, TPRM checks the format (valid SPDX or CycloneDX), checks completeness against required fields, runs a compliance verification described in the docs as EO 14028, runs an automatic vulnerability scan, and notifies the requestor. Received SBOMs can be stored in Portal, the SBOM publish and share product (GA), and analyzed with Safeguard's SBOM analysis (GA).

10. Reject with specifics. If a file fails, review the validation failures, click Request Revision, specify the corrections needed, and the vendor receives the update request. The status returns to the supplier's side of the queue without losing history.

11. Read the vendor risk score. Each vendor gets a risk score from 0 to 100 where higher is better: 0 to 25 is Critical, 26 to 50 High, 51 to 75 Medium and 76 to 100 Low risk. The docs group the inputs into vulnerability risk (critical and high counts, EPSS scores and known exploited vulnerabilities), compliance risk (missing required fields, SBOM age, format validity), component risk (abandoned packages, license compliance, transitive dependency depth) and operational risk (response time to requests, update frequency, security incident history, contract compliance). Note that response time to your SBOM requests feeds the score, so slow suppliers surface on their own.

12. Record accepted risks and supplier fixes. For a finding you accept, click Accept Risk, give a business justification, set a review date and obtain the required approvals. Remediation tracking records requested fixes, vendor commitments, progress updates and verification status.

13. Turn on monitoring. Under Settings › Monitoring, configure alerts for a new critical CVE (Critical Vuln), a CVE added to CISA KEV (Exploited), a score dropping below a threshold (Risk Change) and an SBOM older than a threshold (SBOM Expiry). Alerts can go to email, Slack, Microsoft Teams, PagerDuty or a custom webhook. Periodic re-analysis can run daily for critical vendors, or weekly, monthly or quarterly, and re-assessment can trigger on new vulnerability disclosures, major version updates, contract renewals and security incidents.

14. Ingest supplier vulnerability statements. CSAF and VEX upload is GA, so VEX or CSAF documents your suppliers publish can sit next to their SBOMs and narrow findings to what the supplier says is affected. Safeguard ingests these documents; it does not write or sign VEX on a supplier's behalf.

15. Report. The vendor dashboard shows aggregate risk metrics, vendors requiring attention, recent score changes and upcoming SBOM expirations. Scheduled reports cover a weekly summary, a monthly vendor review, a quarterly risk assessment and an annual vendor audit, and ad hoc reports export as PDF or Excel for a chosen date range and set of vendors.

Requirement, what Safeguard does, what you still own

How do you report SBOM coverage to leadership?

Report a small number of metrics that answer "how exposed are we to software we cannot see into?" and keep the definitions stable from quarter to quarter.

The headline metric

Tier 1 SBOM coverage is the share of critical tier products in use that have a validated SBOM for the deployed version, younger than the tier's age limit. Count products and versions, not suppliers. A supplier with five critical products and one current SBOM is 20 percent covered, not covered.

As an illustration only: if your critical tier holds 120 products in use, 78 have a validated SBOM for the deployed version, and 9 of those are past the quarterly age limit, coverage is 69 divided by 120, or 57.5 percent. The other 51 products are the work list, and they split into requested and pending, rejected and awaiting revision, refused with an accepted risk, and not yet requested.

The supporting metrics

Show the trend, not just the snapshot. In Safeguard, the vendor dashboard and the scheduled quarterly risk assessment report carry most of these inputs; the coverage calculation by deployed version still depends on your inventory being accurate.

What Safeguard does not do

• It cannot make a supplier respond. TPRM sends, tracks and escalates requests, but a supplier that ignores every reminder leaves a gap that only a contract clause, a renewal conversation or a procurement decision can close.
• Validation checks the file, not the truth of the supplier's build. A well-formed SBOM can still omit components the supplier did not detect or chose not to list. Hashes and signatures help you trust where a file came from; they do not prove it is complete.
• It does not know which version you run unless you tell it. Matching a supplier SBOM to your deployed version depends on your asset and product records.
• The vendor risk score is a prioritisation aid. It ranks where to look first. It is not an assurance opinion, a regulatory rating or a substitute for your own risk assessment.
• It does not write or sign VEX for your suppliers. Safeguard ingests the CSAF and VEX documents suppliers publish. If a supplier publishes none, there is no supplier status to ingest.
• The template's field list is described in EO 14028 terms. The docs do not say the standard template or validation checks the CISA 2026 additions such as hashes, licenses and author signatures. Add them to a custom template and confirm with Safeguard which checks run automatically.
• SaaS is still hard. For hosted software, CISA itself treats SBOM frequency and responsibility as open questions. TPRM can record what a SaaS provider shares, but it cannot produce an SBOM the provider does not.
• Some API routes are not live. Docs pages for related supplier and mitigation endpoints carry a notice that the /v1 endpoints are not available yet. Run this workflow in the app.

Common mistakes

• Sending the whole portfolio on day one. You get hundreds of inconsistent replies and no time to fix the template. Start with the critical tier.
• Counting suppliers instead of product versions. "We have SBOMs from 80 percent of suppliers" hides stale versions and uncovered products.
• Treating Submitted as done. A file in the inbox is not an SBOM program. Only Validated counts.
• Accepting PDFs as compliance. A PDF cannot be matched against a vulnerability feed. Keep it as interim evidence, but log it as Rejected.
• Skipping the version match. An SBOM for last year's release describes software you no longer run.
• Rejecting a file because it shows a KEV match. That is the SBOM working. Accept it and ask for vulnerability status.
• Quoting the 2021 NTIA list in new requests. The 2026 CISA minimum elements are the current baseline.
• No refusal register. A blank cell in the tracker is not a risk decision. A dated acceptance with an owner is.

FAQ

How do I collect SBOMs from all of our software vendors?

Tier your vendors by product criticality, send the critical tier a standard request that names the CISA 2026 minimum elements, a machine-readable format and a deadline, track each request to validation, chase on a fixed ladder, and then widen to the next tier. Put the duty into contracts at renewal so the next round is an obligation.

Which vendors should I ask for an SBOM first?

Ask first for software that supports critical activities, runs in your environment with privileged access, or is internet facing. Tier by product rather than by supplier, since one supplier can sell both critical and low-risk products.

What format should I ask suppliers to use?

Ask for SPDX or CycloneDX, machine-readable, in a current format version. CISA's 2026 minimum elements name both as the widely used formats and advise against accepting deprecated format versions for new software.

How often should a vendor send a new SBOM?

With every new version you receive and on corrections, with an age backstop per tier (Safeguard's docs default to quarterly for critical, annual for high).

Do vendors have to give us an SBOM?

Usually only if a contract says so. In the federal space, OMB M-26-05 says agencies may adopt contract terms requiring a current SBOM upon request. For banks, the interagency guidance puts these duties in contract negotiation. Without a clause, an SBOM request is a favour.

What is the difference between an SBOM and a VEX?

An SBOM lists components. A VEX statement says whether a specific vulnerability affects a specific product, using statuses such as not affected, affected, fixed or under investigation. Ask your critical suppliers for both.

How do I measure SBOM coverage?

Divide the number of critical tier products in use that have a validated SBOM for the deployed version, within the age limit, by the total number of critical tier products in use. Report it with the trend and the list of open refusals.

Does Safeguard check that a supplier SBOM is accurate?

It checks the file: format, required fields, a compliance check the docs describe in EO 14028 terms, and a vulnerability scan. It cannot prove the supplier listed every component in its build.

When the vulnerable component is in your own code

Supplier SBOMs tell you which open source components sit inside software you buy, and a KEV match in one of them is often the same component sitting in software you build yourself. When it is in your own code and images, you do not have to wait for anyone; the options below apply there.

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 connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. Safeguard is listed in Claude's connector directory as a community connector. For an SBOM request program, that gives an analyst a way to ask plain-language questions about components and vulnerabilities Safeguard holds while drafting a revision request or a vulnerability status question, with Claude limited to the tools you allow.

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

The second demo is a real session in the Safeguard desktop app (early access, beta). The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. That flow applies to the software you build, not to a supplier's product, but it is how you close the same KEV component in your own repositories while you wait on a supplier's answer.

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

To try it on your own estate, download the apps at safeguard.sh/download and read the Safeguard docs.

Quick check

Sources

• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), 29 July 2026
• CISA, 2026 Minimum Elements for a Software Bill of Materials (PDF)
• CISA, Framing Software Component Transparency, third edition (2024)
• CISA, Framing Software Component Transparency 2024 (PDF)
• CISA, Software Bill of Materials (SBOM) resources
• CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX), April 2023
• NTIA, The Minimum Elements For a Software Bill of Materials (SBOM), 12 July 2021 (history)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (CSRC)
• NIST SP 800-161 Rev. 1, update 1 (PDF)
• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (govinfo.gov)
• OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, 23 January 2026
• Safeguard docs, Third Party Risk Manager
• Safeguard docs, Vendor Management
• Safeguard docs, SBOM Requests
• Safeguard docs, Risk Assessment
• Safeguard docs, Monitoring
• Safeguard docs home
• Safeguard download page

Related reading: how to write an SBOM request to a supplier, a 30, 60, 90 day plan to start consuming supplier SBOMs, check a supplier SBOM against the minimum elements, how long to keep supplier SBOMs after the contract ends and continuous vendor monitoring versus annual review.

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