Tier your software vendors and monitor them continuously

To manage software vendor risk without waiting for a yearly questionnaire, put every vendor in one register, give each a tier by how critical it is to you, request SBOMs on a cadence that matches the tier, and let monitoring re-check those SBOMs against new vulnerability data. Safeguard's Third Party Risk Manager (TPRM) does each of those steps and scores every vendor from 0 to 100, where higher is better.

This post is for the procurement or third party risk lead who owns the vendor list, and for the CISO and GRC lead who sign off on it. It treats TPRM as an operating model: tiers, cadence, score, alerts and a renewal decision. If you want the mechanics of SBOM intake and rescans, read vendor SBOM intake and rescans in Safeguard TPRM. For chasing requests at volume, see chasing SBOM requests across hundreds of suppliers.

Key takeaways

• A questionnaire tells you what a vendor said once. A software bill of materials (SBOM), rescanned against new vulnerability data, tells you what is in the software you run today.
• The documented tiers are Critical, High, Medium and Low. Safeguard's suggested SBOM requirement is quarterly updates for Critical, annual for High, recommended for Medium and optional for Low. TPRM can suggest a tier, and overrides need a written justification.
• SBOM requests move through six statuses: Sent, Viewed, In Progress, Submitted, Validated and Rejected. Reminders go out 7 days before the deadline and at the deadline, with an escalation 7 days after.
• Every 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. Assessment reports break it down and compare vendors side by side.
• Monitoring watches for new vulnerabilities in vendor SBOMs, severity changes, exploit availability, CISA KEV additions and component health changes. Rescans can run daily, weekly, monthly or quarterly, and contract renewals can trigger a reassessment.
• An SBOM covers software composition. It does not show a vendor's internal controls, staffing or hosting practices, so keep contract rights, attestation reports and targeted questions for those.

Why is a yearly vendor questionnaire not enough?

A questionnaire captures what a vendor told you on one day. Each release pulls in new open source components, and each week new vulnerabilities are published against components that were already there. A vendor that answered every question well in March can be shipping a component with a known exploited vulnerability in June, and the questionnaire on file will not say so.

The regimes that govern third party risk have moved in the same direction: away from a point in time check and toward monitoring for the life of the relationship.

What the frameworks and regulations ask for

NIST's Cybersecurity Framework 2.0, published 26 February 2024, has a whole category for supply chain risk management under the Govern function. Its outcomes read like a TPRM job description. GV.SC-04 says "Suppliers are known and prioritized by criticality." GV.SC-06 covers planning and due diligence before entering a supplier relationship. GV.SC-07 says supplier risks are "understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship." GV.SC-10 covers what happens after the relationship ends. NIST SP 800-161 Revision 1, the federal supply chain risk guide, likewise recommends supplier risk assessment "on a prioritized basis."

In the EU, the Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA) has applied to financial entities since 17 January 2025. Article 28(3) requires a register of information covering all contractual arrangements for ICT services, distinguishing between those that support critical or important functions and those that do not, with a report to the competent authority at least yearly. Article 28(4) requires entities to assess risks and "undertake all due diligence" before entering an arrangement. Article 28(7) lists termination grounds that include circumstances "identified throughout the monitoring of ICT third-party risk." Article 30(3) gives entities, for critical or important functions, "the right to monitor, on an ongoing basis" the provider's performance.

The NIS2 Directive (Directive (EU) 2022/2555) lists supply chain security among the cybersecurity risk management measures in Article 21(2)(d). Article 21(3) asks entities to take into account "the vulnerabilities specific to each direct supplier" and the quality of suppliers' products and cybersecurity practices, including their secure development procedures.

In the US, the Federal Reserve Board, FDIC and OCC issued joint Interagency Guidance on Third-Party Relationships on 9 June 2023 (88 FR 37920). It organizes the work as a life cycle of five stages: planning, due diligence and third party selection, contract negotiation, ongoing monitoring and termination. In the preamble, the agencies say they are "not encouraging any specific approach to ongoing monitoring"; monitoring should be appropriate for the risks of each relationship and commensurate with the bank's size and complexity.

CISA's Secure by Demand guide gives software buyers a set of questions and says product security can be built into procurement at three points: before procurement, during procurement through contract language, and after procurement "by continually assessing software manufacturers' product security." The first artifact on its list of things to collect from a manufacturer is an SBOM that lists the product's third party components.

On the supplier side, the EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to draw up an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies." The regulation applies from 11 December 2027, with the reporting obligations in Article 14 applying from 11 September 2026. The CRA does not require manufacturers to publish it (Annex II only covers the case where the manufacturer chooses to share it with users), so for many products you will still have to ask.

None of these documents names a tool or says an SBOM alone meets the requirement. They describe an outcome; the rest of this post shows one way to evidence it.

The operating model in one table

Each row is a stage you can describe to an auditor in one sentence, mapped to a documented part of Safeguard TPRM.

Step 1: build one vendor register

A vendor missing from the register is never tiered, asked for an SBOM or monitored.

What a vendor record holds

Safeguard's vendor management documentation lists the fields each record tracks:

You can add vendors one at a time (Vendors, then Add Vendor, then company name, primary contact, contact email, website, products used and risk tier) or import them in bulk. The bulk path in the docs is four steps: download the template CSV, fill it in, upload it, then review and confirm the import.

Procurement records miss software that arrived another way, so reconcile them with accounts payable (including card spend), the applications connected to single sign-on, the contract repository, agents and appliances on your infrastructure, and commercial SDKs bundled in software you build. A short worksheet keeps the reconciliation honest. The columns below are your preparation, not the Safeguard template; the template you download from TPRM defines the real columns, so map these onto it.

vendor_name, product_used, business_owner, source_found_in,
data_access (none | internal | confidential | regulated),
system_criticality (supporting | important | critical),
user_count_band (under 50 | 50 to 500 | over 500),
compliance_scope (none | SOC 2 | PCI DSS | HIPAA | DORA critical function),
contract_status, renewal_date, sbom_on_file (yes | no)

The four middle columns are not arbitrary. They are the inputs Safeguard's documentation says TPRM uses to suggest a tier: data access level, system criticality, user count and compliance requirements. Collecting them now means the suggestion has something to work with.

Relationships and contracts

Vendor relationships track parent companies, subsidiaries, resellers and implementation partners. If you buy through a reseller, record that link so you know who to ask (our suggestion: address the request to whoever builds the software).

Contract management links documents, start and end dates, SLA terms, security requirements and SBOM obligations to the vendor. The end date tells you when to plan a renewal review; the SBOM obligation makes a request a contractual expectation instead of a favor.

Step 2: tier every vendor by criticality

Tiering decides how much effort each vendor gets, so a font library does not get the scrutiny of a payments system.

The documented tiers

Safeguard's TPRM overview defines four tiers and a suggested SBOM requirement for each:

TPRM can suggest a tier based on data access level, system criticality, user count and compliance requirements. To change one, select the vendor, choose Edit Risk Tier, pick the new tier, document the justification and save. The justification step is the part auditors care about: a tier changed without a reason looks like a vendor being moved out of scrutiny.

A rubric you can defend

Suggestions help, but you will want your own written rule for the edge cases. A rubric that maps to the same four inputs works well:

1. Would an outage stop a core business process within a day? If yes, the vendor is Critical, whatever its data access. Under DORA, this is close to the question of whether the service supports a critical or important function.
2. Does the software read or store regulated or confidential data? If yes and the first answer was no, start at High.
3. Does it run inside your network, on your hosts or inside software you ship? Software that runs in your environment carries its components into your attack surface. Raise it one tier above what data access alone would suggest, capped at Critical.
4. Is it in scope for a compliance regime you report on? Then at least Medium. Everything else is Low, reviewed at renewal.

Write the rubric into the justification field when you override, for example "Raised to Critical: settles customer payments; outage stops trading (rubric Q1)." That sentence is your evidence for GV.SC-04.

Two worked examples

These vendors are hypothetical.

A payroll platform delivered as software as a service. It holds employee bank details and tax identifiers, about 900 staff log in, and payroll is a monthly core process. Data access is regulated, the user count is high and an outage on pay day stops a core process. Tier: Critical. Quarterly SBOM updates are the suggested requirement, though a hosted service raises a question about what its SBOM covers, which Step 3 addresses.

An on premises reporting server bought from a mid-size vendor. It runs on your hosts, reads the data warehouse and 60 analysts use it. An outage is painful but does not stop a core process. Data access is confidential, and it runs in your environment. Start at High for data access, then raise one tier because it runs on your infrastructure: Critical. That is a case where your rubric overrides the suggestion, and the justification should say so.

Step 3: request SBOMs on a cadence that matches the tier

With tiers in place, SBOM requests follow from them. Critical and High vendors get required requests on their cadence. Medium vendors get a recommended request. Low vendors get one only when something changes.

Sending a request

A single request in TPRM follows these documented steps: open the vendor, choose Request SBOM, select the product or products, choose a request template, optionally customize the message, set a deadline and send. For a tier at a time, use the bulk path: go to Vendors, select the vendors, choose Bulk Request, configure the request settings, then review and send.

The standard template asks for SBOM format requirements (SPDX or CycloneDX), the required fields for EO 14028 compliance, submission instructions and the deadline. You can also create custom templates under Settings, then Request Templates.

Write one template per tier

One template for every vendor is the most common reason SBOM programs stall. A Critical vendor and a Low vendor should not get the same letter. Here is a template body for the Critical tier that you can adapt. It is your text, sent through TPRM's custom template feature.

Subject: SBOM request for [product] under our supplier security schedule

We list [product] as a critical service. Under clause [x] of our agreement,
please provide a software bill of materials for the version we run, by
[deadline].

Format: SPDX or CycloneDX, machine readable (JSON preferred).
Coverage: all components, including transitive dependencies. Where depth
is limited or information is withheld, please state that explicitly.
Fields: component name, version, producer, unique identifiers (for example
package URL), component hash and algorithm, license, dependency
relationships, SBOM author, tool name and version, timestamp, and the
generation context (source, build or deployed artifact).
Cadence: a new SBOM with each release, and at least quarterly.
Submission: upload through the secure portal link below.

If an SBOM does not exist yet for this product, please reply with the
date you expect to have one, so we can record it.

The field list is not invented. CISA and its partner agencies published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, which updates and replaces the NTIA minimum elements from 2021. It adds new data fields: SBOM Author Signature, SBOM Tool Name, SBOM Tool Version, SBOM Data Format Name, SBOM Data Format Version, SBOM Version, SBOM Generation Context, Component Hash Value, Component Hash Algorithm and Component License. It updates SBOM Author, Component Producer, Component Identifiers and Component Version. On coverage, the document says an SBOM "should include information for all components that make up the target software, including transitive dependencies," and that "there is no minimum depth." On frequency, it says each software version or update should have an associated SBOM.

Asking for those fields in your template is a buyer choice. Safeguard's documentation describes its built in completeness check against EO 14028 required fields; treat the 2026 fields as your own contractual ask on top of that.

Hosted services need a different question

CISA's 2026 document notes that some software types, including software as a service in cloud environments, may need additional elements. A hosted vendor's SBOM may describe the client, an installed agent or the service's server side components. Ask which one you are getting and record it; an agent SBOM is useful, since that code runs inside your perimeter, but it is not the whole service.

What the status trail tells you

Each request moves through documented statuses:

TPRM sends reminders on a fixed schedule: the first 7 days before the deadline, the second at the deadline, and an escalation 7 days after. Set deadlines with that schedule in mind. A deadline only 10 days out leaves little room between the first reminder and the escalation.

Vendors can submit by email attachment, the secure upload portal, API submission or direct integration. Vendors invited to the vendor portal can also update their own information, respond to questionnaires and view their risk status, which is a quiet way to start a remediation conversation.

What validation checks

When an SBOM arrives, Safeguard's documentation lists five things that happen: format validation (valid SPDX or CycloneDX), a completeness check for required fields, compliance verification against EO 14028, an automatic vulnerability scan, and a notification to the requestor. If the SBOM fails, you review the failures, choose Request Revision, specify the corrections needed and the vendor receives the update request.

Before you even upload a file a vendor emailed you, you can do a quick sanity check yourself with a JSON tool. For a CycloneDX JSON file:

# Format and spec version
jq -r '.bomFormat, .specVersion' vendor-sbom.cdx.json

# How many components are listed, and how many lack a version or a package URL
jq '[.components[]] | length' vendor-sbom.cdx.json
jq '[.components[] | select(.version == null or .purl == null)] | length' vendor-sbom.cdx.json

# Is a dependency graph present at all?
jq '(.dependencies // []) | length' vendor-sbom.cdx.json

For an SPDX 2.x JSON file:

jq -r '.spdxVersion, .creationInfo.created' vendor-sbom.spdx.json
jq '[.packages[]] | length' vendor-sbom.spdx.json
jq '[.packages[] | select(.versionInfo == null)] | length' vendor-sbom.spdx.json
jq '[.relationships[]? | select(.relationshipType == "DEPENDS_ON")] | length' vendor-sbom.spdx.json

For a large product, a few dozen components with no versions and no relationships is a list of names, not a bill of materials. Send it back through the rejection workflow with a specific correction.

The standards behind the formats

SPDX is an international standard, ISO/IEC 5962:2021, currently at specification version 3.0. CycloneDX is developed by the OWASP Foundation and published by Ecma International as ECMA-424. Accept both and ask for JSON where the vendor can produce it.

Step 4: read the vendor risk score

Each vendor receives a risk score from 0 to 100, built from SBOM analysis, vulnerability data and compliance status. The scale runs the opposite way from CVSS: a higher score means lower risk.

The four bands

Read the band with the tier: 40 on a Low tier vendor is a note; 40 on a Critical tier vendor is this week's agenda.

When you write reports, state the direction of the score, or someone will read a good vendor score as a bad one.

The four factor groups

Safeguard's risk assessment documentation lists four groups of factors behind the vendor score.

Vulnerability risk, from SBOM analysis: the number of critical and high vulnerabilities, EPSS scores and known exploited vulnerabilities. EPSS, the Exploit Prediction Scoring System run by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days and publishes a probability for every CVE every day. Known exploited vulnerabilities are the ones on CISA's KEV catalog, the list of vulnerabilities with evidence of exploitation in the wild.

Compliance risk, from SBOM quality: how complete the SBOM is against EO 14028 required fields, which fields are missing, how old the SBOM is and whether the format is valid. Age is one of the listed factors, and our advice is to treat a vendor with no vulnerabilities and a two year old SBOM as unknown risk, not low risk.

Component risk, from dependency health: abandoned packages, license compliance and transitive dependency depth. A product built on components nobody maintains anymore will struggle to ship fixes when the next vulnerability lands, even if it is clean today.

Operational risk, from vendor factors: response time to requests, update frequency, security incident history and contract compliance. A questionnaire rarely captures this, because it is behavior over time.

Reading a score: two worked cases

Hypothetical vendors again, with made up inputs.

Vendor A, Critical tier, score 34 (High band). The assessment report shows the score driven mostly by vulnerability risk: one component in the SBOM has a CVE on the KEV catalog, and two others have high EPSS probabilities. Compliance risk is low because the SBOM is fresh and complete. The action is a remediation request to the vendor asking for a fixed release date for the KEV listed component, recorded in remediation tracking, with the business owner informed. If the vendor has a workaround, record it.

Vendor B, High tier, score 58 (Medium band). No KEV listed vulnerabilities. The score is pulled down by compliance and component risk: the SBOM is 14 months old, a third of components lack versions and several are from projects with no release in years. The action is not an incident. It is a revision request for a current, complete SBOM, and a note on the renewal record that component health is a negotiating point.

Vendor A needs a fix. Vendor B needs better data first.

Step 5: monitor continuously, not yearly

The register, tiers, requests and scores are the setup. Monitoring is what replaces the yearly cycle.

What monitoring watches

Safeguard's monitoring documentation lists what is watched for every vendor SBOM on file:

• New vulnerabilities affecting vendor SBOMs
• Vulnerability severity changes
• Exploit availability updates
• CISA KEV additions
• Component health changes

This is the core argument for SBOMs over questionnaires: the SBOM a vendor sent in March is re-analyzed against June's vulnerability data, so you hear about a new CVE or KEV addition without asking the vendor anything.

Alerts worth configuring

Alerts are configured under Settings, then Monitoring. The documented alert types are:

The routing and thresholds are a starting point, not documented defaults; tune them after a month.

Alerts can go to email, Slack, Microsoft Teams, an on-call paging service or a custom webhook. Send Exploited alerts somewhere a person is watching.

Rescan cadence per tier

Scheduled re-analysis of vendor SBOMs can run daily, weekly, monthly or quarterly; the docs give daily as the option for critical vendors. A cadence that tracks the tiers:

Note the two different clocks. The vendor refreshes the SBOM when the software changes. Safeguard rescans the SBOM you hold when the vulnerability data changes. A Critical vendor that ships quarterly still gets a daily rescan because new CVEs do not wait for their release.

Reassessment triggers

Besides the schedule, a reassessment can be triggered by new vulnerability disclosures, major version updates, contract renewals and security incidents. The last two are the ones procurement owns. Our suggestion: use the contract end date on the vendor record to start a reassessment 60 to 90 days ahead of renewal, so the score is fresh when the negotiation starts.

The dashboard and trend views

The vendor dashboard shows aggregate risk metrics, the vendors that need attention, recent score changes and upcoming SBOM expirations. Trend analysis tracks risk score trends, vulnerability count trends, remediation velocity and compliance improvements over time.

Remediation velocity is the trend to watch for operational risk. A vendor whose scores recover within a few weeks of each alert is fixing things. A vendor whose score drops and stays down is not, and that pattern is exactly the "circumstances identified throughout the monitoring" that DORA Article 28(7) names as a termination ground.

Scheduled reports for each audience

Scheduled reports go out weekly, monthly, quarterly and annually, and ad hoc reports can be exported as PDF or Excel for a date range and vendor set. A workable split: the weekly summary for the TPRM analyst and security operations, the monthly vendor review for the TPRM lead and business owners, the quarterly risk assessment for the CISO and risk committee, and the annual vendor audit for internal audit and the board. For a DORA register of information, the vendor register, contract records and the annual audit report can supply inputs on the arrangements and your monitoring trail (the critical or important distinction is yours to record); map them to your authority's template.

Step 6: make renewal a decision, not a date

Monitoring produces information; someone still has to decide.

Risk acceptance with a review date

When a vendor risk is real but you choose to live with it, the documented flow is: review the risk finding, choose Accept Risk, provide a business justification, set a review date and obtain the required approvals. The review date is the part that keeps acceptance honest. An acceptance with no date becomes permanent by default.

A good acceptance record answers four questions in the justification: what the risk is, why the business accepts it now, what compensating control exists, and what would end the acceptance early.

Remediation tracking with the vendor

Remediation tracking records requested fixes, vendor commitments, progress updates and verification status. Verification is the step that is easy to skip. When the vendor says the fix shipped, ask for the new SBOM. Validation and the automatic vulnerability scan show whether the affected component version is gone, and the score can move with it. That closes the loop without relying on the vendor's word.

The renewal gate

Put the decision on the calendar. For Critical and High tier vendors, the reassessment triggered by contract renewal produces a short memo with four parts:

1. The current score and band, with the trend since the last renewal.
2. Open remediation items and how long each has been open.
3. Accepted risks and whether their review dates passed.
4. A recommendation: renew as is, renew with contract changes (SBOM obligation, notification terms, remediation SLAs), or plan an exit.

Contract changes are where TPRM evidence pays off. A vendor with a slow remediation trend can be asked for a remediation timeline clause. A vendor whose SBOMs keep failing validation can be asked for the 2026 minimum elements in the contract. DORA Article 30(3) already expects notice periods, reporting obligations and the right to monitor for critical or important functions, so for financial entities this is less negotiation than compliance.

On exit, GV.SC-10 and the interagency termination stage point to the same work: data return, access removal and a record that the relationship ended. Mark the contract expired so the history stays.

Where questionnaires still belong

An SBOM program does not make questionnaires obsolete. It makes them shorter and better aimed.

An SBOM tells you what components a product contains and, once analyzed, what known vulnerabilities and health issues those components carry. It does not tell you how the vendor runs its own company: who has production access, how it hires, whether it encrypts backups, how it handles an incident. For those, you still need targeted questions, independent attestation reports such as SOC 2, and contract rights to audit.

CISA's Secure by Demand guide is a good model for the questions that remain. It asks about single sign-on and multi-factor authentication at no extra cost, default passwords, systematic elimination of vulnerability classes such as SQL injection, security logs retained for at least six months for cloud services, accurate CWE and CPE fields in the vendor's CVE records, and a published vulnerability disclosure policy. None of those is answered by an SBOM. All of them are answered quickly by a vendor with a mature product security program.

TPRM's vendor portal takes questionnaire responses alongside SBOM submissions. A practical split: an annual questionnaire for Critical tier vendors, one at renewal for High, and one on change for the rest.

What this does not cover

• Software composition only. The score does not measure a vendor's internal controls, financial health or staffing.
• Only as good as the SBOM. Missing fields and age lower the score, but the analysis cannot see components that were never listed. For software as a service, the SBOM may cover only the client or installed agent.
• The vendor still ships the fix. You cannot patch a vendor's closed source product yourself; your options are compensating controls, risk acceptance with a date, or exit.
• Your regulator's format. Map the register and reports to the template your authority requires, such as the DORA register of information.

Common mistakes

Requesting SBOMs from every vendor at once. One deadline for hundreds of vendors produces a backlog nobody reviews. Request by tier, Critical first.

One template for everyone. A Low tier vendor that receives a contractual demand ignores it. A Critical vendor that receives a polite optional request treats it as optional. Write a template per tier.

Reading the vendor score like CVSS. In TPRM, 90 is good and 10 is bad. In CVSS, 9.0 is bad. Put the direction in every report header.

Tier overrides without a reason. An override with no justification is the first thing an auditor will ask about, and the hardest to explain a year later. The docs build justification into the flow; use it every time.

Risk acceptance with no review date. It becomes permanent. Set the date, and set an early end condition.

No owner for Exploited alerts. A KEV addition affecting a Critical tier vendor routed to a shared mailbox gets read on Monday. Route it to a person or a channel that someone watches.

Forgetting vendors inside your own software. Commercial SDKs and libraries bundled into products you ship are third party software too. They belong in the register, and they show up in your own SBOMs.

Letting tiers drift. A pilot that became core infrastructure is still marked Low. Treat every reassessment trigger as a prompt to recheck the tier, and look at vendors with recent score changes to see whether their use changed too.

FAQ

How do I tier software vendors by risk?

Start with criticality: would an outage stop a core process, and does the software touch regulated data? Safeguard TPRM uses four tiers and can suggest one from data access, system criticality, user count and compliance requirements. Override with a written reason when your rubric disagrees.

How often should I ask vendors for an SBOM?

Safeguard's suggested requirement is quarterly updates for Critical vendors, annual for High, recommended for Medium and optional for Low. CISA's 2026 minimum elements add that each software version or update should have its own SBOM, so for Critical vendors ask for one with each release as well.

What does the Safeguard TPRM risk score mean?

A vendor score from 0 to 100 where higher is better, unlike CVSS. 0 to 25 is Critical, 26 to 50 High, 51 to 75 Medium and 76 to 100 Low. It combines vulnerability, compliance, component and operational risk.

What happens when a vendor's SBOM is incomplete?

Validation flags it. You choose Request Revision and specify the corrections, and the vendor receives the update request. Missing fields and age also lower the compliance part of the score.

Does an SBOM replace a security questionnaire?

No. An SBOM shows what is in the software, not how the vendor runs its security program. Keep a short questionnaire for Critical and High tier vendors, plus attestation reports and contract rights.

What should I do if a vendor will not provide an SBOM?

Record the refusal in the request trail and on the vendor record. For Critical and High tier vendors, raise it at renewal and ask for an SBOM obligation in the contract. Under the EU Cyber Resilience Act, manufacturers of products with digital elements must draw up an SBOM, but they are not required to publish it, so a contract clause is the reliable route.

Does DORA require SBOMs from ICT providers?

DORA's text does not use the word SBOM. It requires a register of ICT arrangements, due diligence before contracting, appropriate information security standards from providers and, for critical or important functions, the right to monitor on an ongoing basis. SBOMs and continuous monitoring can form part of the evidence for those duties, but the text does not say they are sufficient. Check with your compliance team how your authority reads them.

How does Safeguard itself answer a vendor review?

Safeguard is SOC 2 Type I and Type II audited. That covers Safeguard as your vendor; the TPRM workflow in this post covers the vendors you buy from.

Why fast fixes still matter for third party risk

TPRM tells you when a vendor's product carries a vulnerable component, but much of your exposure sits in the open source components your own teams build into software you ship and buy alongside it. Shortening the time from a published fix to that fix running in your builds is the part of supply chain risk you control directly, and it is what your own customers' TPRM programs will measure you on.

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, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. 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. Auto-merge is a separate switch and stays off by default, so your team decides what merges 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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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 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 the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use, so you control what an assistant can do with your Safeguard data.

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

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. If your own customers run TPRM programs, it is a quick way to have SBOMs of your projects ready before they ask.

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

The third demo is a real Safeguard CLI session. A developer asks the assistant to fix a lodash CVE; it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. When the vulnerable component is in your code rather than a vendor's, this is how you move it yourself.

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

To try Safeguard yourself, download the apps or start with the CLI documentation. For the regulatory side of supplier risk, see supplier software risk under DORA, NIS2 and M-22-18 with Safeguard TPRM, and for a reviewer's checklist, vendor checks for procurement reviewers. The product overview is in Safeguard TPRM for third party risk.

Quick check

Sources

• Safeguard docs: Third Party Risk Manager
• Safeguard docs: Vendor Management
• Safeguard docs: SBOM Requests
• Safeguard docs: Risk Assessment
• Safeguard docs: Monitoring
• NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices
• Regulation (EU) 2022/2554, Digital Operational Resilience Act
• Directive (EU) 2022/2555, NIS2
• Regulation (EU) 2024/2847, Cyber Resilience Act
• Federal Register: Interagency Guidance on Third-Party Relationships: Risk Management (88 FR 37920)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA: Secure by Demand Guide
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• Federal Register: Executive Order 14028, Improving the Nation's Cybersecurity
• SPDX specifications
• CycloneDX specification overview

Last reviewed: 27 October 2026.