Onboard a New Software Vendor at an Insurer, Starting With the SBOM

When a new software vendor lands on your desk at an insurer, review its software bill of materials (SBOM) in five moves: tier the vendor by the data and systems it will touch, request an SBOM with a format, a scope and a deadline, check what comes back against CISA's 2026 minimum elements, triage the known vulnerabilities by exploitation evidence rather than raw severity, and record a dated decision that names who owns the remaining risk. Then keep the SBOM on a monitoring schedule, because the review you sign today goes stale the day a new exploited vulnerability is added to a catalog.

That sequence lines up with what insurance regulators already ask of you. New York's cybersecurity regulation (23 NYCRR Part 500) requires written third-party service provider policies covering identification, minimum practices, due diligence and periodic reassessment. The NAIC Insurance Data Security Model Law, which many states have adopted in some form, requires due diligence in selecting third-party service providers and requires you to make them protect the systems and data they can reach. An SBOM review is one of the few parts of that due diligence that produces evidence you can check, rather than answers you have to trust.

This use case is for the vendor risk manager at a US insurer who owns onboarding for third-party software. Most of it works with spreadsheets and email; near the end, a section shows how Safeguard runs the same flow. Nothing here is legal advice; counsel owns the reading of the rules that apply to you.

Key takeaways

• The job: get a new software vendor from "procurement wants to sign" to "approved, approved with conditions, or not approved", with an SBOM review as the evidence core and a monitoring plan attached.
• 23 NYCRR 500.11(a) requires written policies covering identification and risk assessment of third-party service providers, minimum cybersecurity practices, due diligence and periodic reassessment. 500.11(b) adds guidelines on access controls including multi factor authentication, encryption, incident notice and representations and warranties.
• The NAIC Insurance Data Security Model Law (Model 668) Section 4F requires due diligence in selecting a third-party service provider and requires the provider to implement appropriate safeguards. Section 13 gave licensees two years from the effective date to implement 4F. Section 6D starts your notice clock from when the provider tells you, or when you otherwise know, whichever is sooner.
• CISA's 2026 Minimum Elements for an SBOM (29 July 2026) replace the NTIA 2021 elements. Use them as your intake checklist.
• Triage vendor findings with CISA's Known Exploited Vulnerabilities (KEV) catalog and FIRST's EPSS probability, then ask the vendor for a VEX or CSAF statement on what matters.
• Safeguard's TPRM, Third-Party Risk Manager (GA), covers vendor records and risk tiers, SBOM requests with templates, deadlines and follow-ups, validation, a 0 to 100 vendor risk score (higher is better), risk acceptance and remediation tracking, and continuous monitoring with alerts. SBOM analysis (GA), vulnerability management with EPSS and KEV (GA), CSAF and VEX upload (GA), policies and gates (GA), mitigation records (GA), Portal's SBOM repository (GA) and the Compliance and GRC suite (GA) fill in the rest.
• Safeguard does not sign the contract, judge the vendor's answers for you, or decide whether the residual risk is acceptable. Those stay with you and the executive who owns the risk.

The situation

A business unit wants new software: a claims intake platform, a rating engine plug-in, a document generation service, an agent portal or a fraud analytics tool that reads claims history. Procurement has a signature date four to eight weeks out. The vendor has sent questionnaire answers, an attestation letter and, if you asked, an SBOM, which may be a spreadsheet, a PDF or, occasionally, a machine readable SPDX or CycloneDX file.

You are the vendor risk manager. Your job is to say whether this vendor can touch policyholder data and core systems, under which conditions, and how you will know if that answer changes. The business owner wants a yes by the signature date; internal audit and, eventually, a state examiner want a file that shows you followed your own written policy.

A bad week: the SBOM arrives three days before signature, a third of its components have no version, two match CISA's KEV catalog, and the vendor says the vulnerable code is unused but puts nothing in writing. You approve "pending remediation" in an email nobody can find six months later, and nobody looks at the SBOM again until a public incident.

The rest of this post is about avoiding that week.

What the rules ask of an insurer onboarding a software vendor

Insurers in the US answer to state insurance regulators, and the two texts that shape vendor onboarding most directly are New York's Part 500 and the NAIC model law that many other states have adopted with local changes. Neither one says the word SBOM. Both require due diligence and risk based oversight of third-party service providers, and an SBOM review is a practical way to do part of that work for software vendors. Check your own state statute and your domiciliary regulator's guidance; the summaries below are of the primary texts, not of any one state's version.

New York: 23 NYCRR 500.11, third-party service provider security policy

Section 500.11(a) requires each covered entity to implement written policies and procedures to secure information systems and nonpublic information that third-party service providers can access or hold. The policies must be based on the covered entity's risk assessment and address, to the extent applicable:

1. identification and risk assessment of third-party service providers;
2. minimum cybersecurity practices those providers must meet to do business with you;
3. due diligence processes to evaluate the adequacy of their cybersecurity practices; and
4. periodic assessment of providers based on the risk they present and the continued adequacy of their practices.

Section 500.11(b) requires those policies to include relevant guidelines for due diligence and contractual protections, as applicable, covering the provider's access controls (including multi factor authentication under 500.12), encryption of nonpublic information in transit and at rest (500.15), notice to you of a cybersecurity event that directly affects your information systems or your nonpublic information held by the provider, and representations and warranties about the provider's cybersecurity policies.

The section was adopted in 2017 and amended with the rest of Part 500 effective 1 November 2023.

Two neighbouring sections matter. Section 500.9 requires a documented risk assessment, updated at least annually and on material change, under policies that say how risks are mitigated or accepted; a vendor acceptance belongs there. Section 500.17(a) requires notice to the superintendent within 72 hours of determining that a cybersecurity incident occurred, including at a third-party service provider, and 500.17(b) requires an annual compliance submission by 15 April. A vendor file that cannot show the 500.11 steps makes that submission harder to sign.

NAIC Insurance Data Security Model Law (Model 668)

The model law defines a Third-Party Service Provider as a person, not otherwise a licensee, that contracts with a licensee to maintain, process or store nonpublic information, or is otherwise permitted access to it through its services.

• Section 4C requires a risk assessment that identifies reasonably foreseeable threats, "including the security of Information Systems and Nonpublic Information that are accessible to, or held by, Third-Party Service Providers", and assesses safeguards at least annually.
• Section 4E requires executive management to report in writing at least annually to the board or a committee, including on material matters such as third-party service provider arrangements.
• Section 4F has two duties: exercise due diligence in selecting a third-party service provider, and require the provider to implement appropriate administrative, technical and physical measures to protect the systems and nonpublic information it can reach.
• Section 6A requires notice to the commissioner as promptly as possible and no later than 72 hours after determining that a cybersecurity event has occurred, when the stated criteria are met. Section 6D says a cybersecurity event in a system maintained by a third-party service provider is treated the same way, with your deadline computed from the day after the provider notifies you or you otherwise have actual knowledge, whichever is sooner.
• Section 13 gave licensees one year from the effective date to implement Section 4 and two years to implement Section 4F.

State enactments differ in details, including notice deadlines, so read your state's version rather than the model. The NAIC keeps a state adoption map for Model 668.

NIST CSF 2.0: the supply chain category in plain terms

Many insurers map their program to the NIST Cybersecurity Framework. CSF 2.0's Govern function has a Cybersecurity Supply Chain Risk Management category (GV.SC) whose outcomes read like an onboarding checklist:

CISA's 2026 Minimum Elements for an SBOM

On 29 July 2026, CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials. It replaces the minimum elements NTIA published in 2021 and keeps the core principles. It tells you what a usable SBOM should contain.

The data fields are SBOM Author, Author Signature, Timestamp, Data Format Name and Version, Generation Context, Tool Name and Version, SBOM Version, and Component Name, Version, Identifiers, Hash Value and Algorithm, License, Producer and Dependency Relationship. Practices include Coverage, Distribution and Delivery, Frequency, Machine-Processable Data and Explicitly Identifying Unknown Information, which replaces "known unknowns".

Three of those matter most at intake. Coverage now says an SBOM should include all components that make up the target software, including transitive dependencies, with no minimum depth. Explicitly Identifying Unknown Information asks the author to separate what is unknown from what is known but withheld. SBOM Generation Context tells you whether the SBOM was produced from source, from a build or from a finished binary, which changes how far you can trust it. The guidance also notes that some software, such as AI systems and software as a service, may need additional elements.

Exploitation evidence and "not affected" statements

CISA calls its KEV catalog the authoritative source of vulnerabilities exploited in the wild and recommends it as a prioritisation input. FIRST's EPSS estimates the probability that a CVE will be exploited in the next 30 days, published daily. KEV shows what attackers already use; EPSS ranks the long tail. When a vendor says a vulnerability does not affect its product, ask for a VEX statement, in the OASIS CSAF 2.0 VEX profile or CycloneDX VEX. A written "not affected" with a justification is evidence; an email is a conversation.

How teams do it today and where it breaks

Most insurers already run a questionnaire, request an attestation report, tier by data access, sign off and reassess every year or two. The SBOM, when requested at all, is attached to the file. Where it breaks:

• Received, not reviewed. A PDF or spreadsheet SBOM cannot be matched against vulnerability data, so it proves only that you asked.
• No intake standard. A list of names with no versions gets accepted, and nothing can be matched without versions and package identifiers.
• Verbal "not affected". Assurances are never written down, so nobody can later tell explained findings from ignored ones.
• Conditions nobody tracks. "Approved pending fix" lives in an email with no due date, owner or review date.
• No monitoring after signature. A component added to KEV next quarter goes unnoticed until the news.
• Contract terms lag the review. Nothing says how often a fresh SBOM is due or how fast the vendor must report an affected component.

None of these needs a new tool. They need a sequence, a few templates and a record.

Step by step: onboard a software vendor with an SBOM review

These steps work with a spreadsheet, a shared mailbox and the free public data sources above. They also map directly onto the Safeguard flow later in the post.

1. Tier the vendor before you ask for anything

Tiering decides how much evidence you need. Base it on what the vendor's software will touch, not on contract value.

Write the reason for the tier into the file: what data, which systems, which obligations. That is 500.11(a)(1) on paper.

2. Send a precise SBOM request with a deadline

Vague requests get vague SBOMs. A request that names the product, the version you will deploy, the format and the minimum elements gets something you can use. A template you can adapt:

Subject: SBOM request for [Product] [Version], due [Date]

Hello [Vendor contact],

As part of our third-party service provider due diligence, please send a
software bill of materials for [Product], version [Version], the release we
plan to deploy.

Format: SPDX (2.2 or 2.3) or CycloneDX (1.4 or later), JSON preferred.
Scope: all components, including transitive dependencies. If the product
includes container images or separately installed agents, include those too.
Content: please follow CISA's 2026 Minimum Elements for an SBOM, including
component versions, package identifiers (PURL or CPE), hashes, licenses,
supplier or producer, dependency relationships, the tool used, and the
generation context (source, build or binary).
Unknowns: where information is unknown or withheld, please say so
explicitly rather than leaving fields blank.
Exploitability: for any component with a known vulnerability, please include
a VEX or CSAF statement of affected or not affected, with justification.

Please send by [Date]. We will confirm receipt and let you know within
[N] business days if anything needs to be revised.

Thank you,
[Name], Vendor Risk, [Company]

Log the date sent, the deadline and every follow up; response time is evidence too.

3. Check the SBOM at intake against the 2026 elements

Before you look for vulnerabilities, check that the SBOM is fit to be analysed. A same day intake checklist:

Record pass, pass with gaps, or rejected, with the date.

4. Match components to known vulnerabilities and rank by exploitation

Run the SBOM through whatever vulnerability matching you have. Then sort the results in this order:

1. Components with a CVE on CISA's KEV catalog.
2. Components with a high EPSS probability, using a cut off your program sets and documents.
3. Remaining critical and high severity findings.
4. Everything else, summarised rather than listed.

Send the vendor only the first two groups as questions, plus a count of the third. Ask for one of three answers per item, in writing: fixed in version X (with a date), not affected (with a VEX or CSAF statement), or affected with a remediation plan and date.

5. Pair the SBOM with the rest of your due diligence

The SBOM shows what is inside the software, not how the vendor controls access, encrypts your data or reports incidents (the 500.11(b) items). Keep the questionnaire and attestation work, and aim it using the SBOM: many unmaintained components means asking about their update process; a "binary" generation context means asking for one from the build.

6. Decide, and record the decision

Use a small set of outcomes so decisions are comparable across vendors:

Any acceptance of residual risk needs a named approver with the authority to own it and a review date. Under 500.9, your risk assessment policies must say how risks are mitigated or accepted; follow them.

7. Write the SBOM into the contract

GV.SC-05 and 500.11(b) both point at the contract. Ask counsel to consider clauses that cover:

• SBOM delivery in a named machine readable format for each major release and at a stated minimum frequency, following CISA's 2026 minimum elements.
• Written notice within a stated number of days when a component in the delivered product is added to the KEV catalog, with the vendor's status.
• VEX or CSAF statements for listed vulnerabilities on request.
• Incident notice terms that let you meet your own 72 hour clock under 500.17 or your state's version of Model 668 Section 6.
• Remediation commitments from the onboarding review, with dates.
• What happens to your data and the vendor's access at exit (GV.SC-10).

8. Set the monitoring schedule before go live

A vendor review is a snapshot. Decide now how you will know when it changes:

• Re-check the vendor's SBOM against new vulnerability data on a schedule set by tier: daily or weekly for critical vendors, monthly or quarterly for others.
• Alert on a KEV addition affecting any component in a critical or high tier vendor's SBOM.
• Alert when an SBOM is older than the refresh period in the contract.
• Re-review on renewal, a major version change, a vendor incident or an acquisition of the vendor.

Illustrative scenario: a claims intake platform at a regional carrier

This is a composite example, not a customer. The company and vendor are fictional, and every number below is an example input chosen to make the steps concrete, not a measured result.

The carrier and the request. Example Mutual is a fictional regional property and casualty insurer licensed in several states, including New York, with a two person vendor risk team. Its claims department wants an intake platform from a fictional vendor, Example Claims Co., that takes first notice of loss through a web form and a mobile app and feeds the claims system. Procurement wants signature in six weeks.

Tiering. The platform will hold policyholder names, policy numbers, loss descriptions and photos, and connect to the claims core, so the team rates it Critical.

Request. The team sends the template above on day 1 with a day 10 deadline, asking for CycloneDX JSON for the version to be deployed, plus the mobile app as a separate SBOM.

Intake. On day 9 the vendor sends a CycloneDX file for the web platform and nothing for the mobile app. As an example input, say the file lists about 600 components. The intake check passes on format, author, timestamp and tool. It flags gaps: about 40 components have no version, generation context is missing, there is no author signature, and unknowns are not labelled. The team logs "pass with gaps", requests a revision for the versionless components and the missing context, and chases the mobile SBOM.

Triage. The revised SBOM arrives on day 14 with versions filled and the context given as "build". Matching shows, as example inputs, two components with CVEs on the KEV catalog, five more with EPSS scores above Example Mutual's documented cut off, and a few dozen other critical or high findings. The team sends the vendor seven questions, one per item in the first two groups, and a count of the rest.

Vendor response. For one KEV item the vendor says the component is fixed in the next release, due in three weeks. For the other, it sends a CSAF VEX statement marking the product not affected, with a justification that the vulnerable function is not included in its build. For the five EPSS items, three are fixed in the next release, one is not affected with a VEX statement, and one has no plan yet.

Decision. On day 24 the CISO approves with conditions: the next release must ship before go live, the one item without a plan needs a dated plan within 30 days, and the mobile app SBOM must arrive before the app is enabled. Each condition has an owner, a due date and the evidence that closes it. The acceptance for the remaining open item is signed by the claims executive who owns the service, with a 90 day review date.

Contract and monitoring. Counsel adds quarterly SBOMs, KEV notice within a stated number of days, VEX on request and incident notice that fits inside Example Mutual's own 72 hours. Before go live the team schedules a weekly re-check, a KEV alert, an alert when the SBOM passes 90 days old and a re-review at renewal.

The point is the file at the end: a tier with a reason, a dated SBOM and its intake result, written answers to exploitation ranked questions, a decision with conditions and a named approver, contract terms and a monitoring schedule. That is what 500.11, Model 668 Section 4F and GV.SC-06 and GV.SC-07 ask you to be able to show.

How Safeguard does this

Everything above can be run by hand. If you use Safeguard, or want one place for the vendor record, the SBOM, the findings and the decision trail, here is how the same flow maps onto the product. Each capability below is generally available (GA). Screens and actions are named only where Safeguard's docs show them, and each step links to its docs page.

1. Add the vendor and set its tier in TPRM (GA). In Vendor Management, go to Vendors, click Add Vendor, enter the vendor's details and products used, set the risk tier and save. Each record tracks contract status, risk tier, SBOM status and last assessment. TPRM can suggest a tier from data access level, system criticality, user count and compliance requirements, and a manual override asks you to document the justification. Contracts can be linked with dates, SLA terms, security requirements and SBOM obligations. The TPRM overview describes the Critical tier as core business operations with an SBOM required and quarterly updates, and the High tier as significant data access with an SBOM required and annual updates.

2. Request the SBOM with a template and a deadline. From the vendor, the SBOM Requests page describes clicking Request SBOM, selecting the products, choosing a template, setting a deadline and sending. The standard template asks for SPDX or CycloneDX, the required fields for EO 14028, submission instructions and the deadline; under Settings, Request Templates you can create your own, for example one that names CISA's 2026 elements. Bulk Request sends the same request to several vendors at once.

3. Let the follow ups run. Request status moves through Sent, Viewed, In Progress, Submitted, Validated and Rejected. Automated reminders go out 7 days before the deadline and at the deadline, with an escalation 7 days after it. Vendors can submit by email attachment, the secure upload portal, API submission or direct integration.

4. Use validation as your first intake pass. When an SBOM arrives, TPRM checks the format (valid SPDX or CycloneDX), checks completeness against required fields, verifies the EO 14028 elements, runs an automatic vulnerability scan and notifies the requester. If it falls short, Request Revision sends the vendor the specific corrections. Keep the intake table above for 2026 elements validation does not name, such as generation context.

5. Analyse the SBOM as a project when you need detail. SBOM generation and analysis (GA) accepts vendor SBOMs through the Existing SBOM upload: go to Integrations, click Connect on the Upload SBOM card, enter a project name and version, and upload the file. After upload Safeguard validates the schema and required fields, then enriches each component with vulnerability matches, EPSS scores, KEV status, license information and supplier data, and shows quality metrics: completeness score, component coverage, PURL accuracy, version specificity and license coverage. The same page shows two CLI commands for checking an SBOM locally; we did not run them for this post:

   # Check the document against its specification
   safeguard validate sbom.json
   # Scan it for vulnerabilities, writing results under ./output
   safeguard scan --sbom sbom.json
   

   The docs say the CLI does not upload SBOMs to the platform; use the UI for that.

6. Rank findings by exploitation. Vulnerability management (GA) brings in CVE data with EPSS and KEV enrichment, so the KEV first, EPSS second ordering from step 4 of the manual flow is the natural sort. The Existing SBOM page says uploaded SBOMs are re-checked daily.

7. Load the vendor's VEX or CSAF statements. CSAF and VEX upload (GA) takes CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile through Integrations, Upload CSAF/VEX, as described on the CSAF/VEX Upload page. A vendor's "not affected" statement then sits next to the finding it explains, instead of in an email.

8. Read the vendor risk score and generate the report. The Risk Assessment page scores each vendor from 0 to 100, where higher is better: 76 to 100 is low risk, 51 to 75 medium, 26 to 50 high and 0 to 25 critical. Inputs include vulnerability risk (critical and high counts, EPSS, known exploited vulnerabilities), compliance risk from SBOM quality (EO 14028 coverage, missing 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). Generate Report produces an executive summary, score breakdown, vulnerability details, compliance gaps and recommendations, which fits as an attachment to your decision memo.

9. Record acceptance and track the vendor's commitments. The same page describes a Risk Acceptance flow: review the finding, click Accept Risk, give the business justification, set a review date and obtain the required approvals. Remediation tracking holds requested fixes, vendor commitments, progress updates and verification status, which is where each condition from your decision lands.

10. Keep finding level decisions with an expiry. For a vendor SBOM analysed as a project, mitigation records (GA) cover Risk Acceptance (with an expiration date), False Positive, Workaround Applied (including where compensating controls are in place) and Not Applicable. Each carries a justification, an Approved By field, optional evidence and a scope; Safeguard notifies you 14 and 7 days before an acceptance expires and on the day, and logs every change.

11. Set a policy and gate for vendor SBOMs. Policies and gates (GA) let you write your onboarding bar as rules, for example no critical vulnerabilities or approved licenses only. Each policy's action decides what a failure does to the gate: Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and a notification is sent). Approvals for exceptions run through Request Exception, with a justification and an expiration date, and every decision lands in an audit trail.

12. Store each SBOM version and compare releases. Portal's SBOM Repository (GA; here Portal means the SBOM management side, not the free tier) groups SBOMs by product and version and compares two versions to show added and removed components, version changes, and new and resolved vulnerabilities. That comparison is your quarterly delta review.

13. Turn on monitoring with your triggers. TPRM Monitoring watches vendor SBOMs for new vulnerabilities, severity changes, exploit availability updates, CISA KEV additions and component health changes. In Settings, Monitoring, alerts cover a new critical CVE, a CVE added to KEV, a risk score below your threshold and an SBOM older than your threshold, and go to email, Slack, Microsoft Teams, PagerDuty or a webhook. Re-scans can run daily for critical vendors, or weekly, monthly or quarterly, and re-assessment can trigger on new disclosures, major version updates, contract renewals and security incidents.

14. Report on a schedule and keep the program view together. TPRM scheduled reports run weekly to annually, with trend analysis of risk score, vulnerability counts and remediation velocity. The Compliance and GRC suite (GA) has Risks and Vendors tabs alongside controls and evidence, so the vendor decision sits in the same register as the rest of your risk program when you prepare the annual board report Model 668 Section 4E describes.

Safeguard holds the SBOMs, the findings, the scores and the decision trail. The judgment calls in the decision table above stay with your team.

What to measure

These are checks you can run on your own program, with or without Safeguard. They are not results anyone has promised you.

• Share of Critical and High tier software vendors with a machine readable SBOM on file for the version in production.
• Median days from SBOM request to a validated SBOM, by tier.
• Share of vendor SBOMs older than the refresh period in their contract.
• Open KEV listed findings in vendor SBOMs, and the age of the oldest one.
• Share of vendor "not affected" claims backed by a VEX or CSAF document.
• Conditions from approvals that passed their due date without evidence.
• Risk acceptances past their review date.
• Time from a KEV addition affecting a vendor component to the vendor's written status.

Track them quarterly. When one moves the wrong way, look first at the contract (step 7) and the monitoring schedule (step 8).

What Safeguard does not do

• It does not decide whether to approve the vendor. The score, the report and the findings inform the decision. Accepting residual risk is a business decision that a named person with authority must make and sign.
• It does not negotiate or enforce your contract. Safeguard can track SBOM obligations, vendor commitments and due dates. Getting those terms into the contract, and acting when a vendor misses them, is your job and counsel's.
• It cannot make a poor SBOM complete. If the vendor leaves out components, versions or identifiers, analysis can flag the gaps but cannot invent the missing data. Unknown packages that are not in public databases are tracked but cannot be enriched, as the Existing SBOM docs note.
• It does not see inside the vendor's code. An SBOM lists components; it does not show how the vendor's product calls them. Whether a listed vulnerability is exploitable in that product is a question for the vendor, answered in a VEX or CSAF statement you then load.
• It does not replace the rest of your due diligence. The 500.11(b) items (access control, multi factor authentication, encryption, incident notice) still need your questionnaire, attestation review and contract.
• It does not fix the vendor's software. Remediation works on code you build; a vendor's fix comes in the vendor's release.
• The /v1 REST endpoints are not available yet. Several docs pages show API examples with a banner saying the /v1 paths are not live. Use the UI and CLI flows above.

Common mistakes

• Accepting a PDF as an SBOM. If it cannot be parsed, it cannot be monitored. Ask for SPDX or CycloneDX from the first request.
• Sending the vendor every finding. Hundreds of CVEs get a defensive reply. Send KEV and high EPSS items as questions, and a count of the rest.
• Treating "not affected" as closed without a document. Ask for VEX or CSAF. Record the statement next to the finding.
• Approving with conditions that have no dates. Every condition needs an owner, a due date, the evidence that closes it and a consequence.
• Letting acceptance live forever. Give every acceptance a review date and someone who gets reminded.
• Skipping the contract step. If the contract does not require fresh SBOMs and KEV notice, monitoring runs on data that ages.

FAQ

What should an insurer ask a software vendor for during onboarding?

A machine readable SBOM (SPDX or CycloneDX) for the version you will deploy, following CISA's 2026 minimum elements, plus a VEX or CSAF statement for any listed vulnerability the vendor says does not affect its product. Pair that with your usual questionnaire and attestation review covering access control, multi factor authentication, encryption and incident notice, which 23 NYCRR 500.11(b) names.

Does NYDFS Part 500 require an SBOM from vendors?

No. Section 500.11 requires written policies for identifying and assessing third-party service providers, minimum practices, due diligence and periodic reassessment, with guidelines on access controls, encryption, notice and representations. It does not name SBOMs. An SBOM review is one way to perform and document the due diligence and periodic assessment the section requires.

What does the NAIC Insurance Data Security Model Law require for third-party service providers?

Section 4F requires due diligence in selecting a provider and requires the provider to implement appropriate administrative, technical and physical measures to protect the systems and nonpublic information it can reach. Your state's enacted version governs.

What are CISA's 2026 SBOM minimum elements?

Published on 29 July 2026, they replace the 2021 NTIA elements. Data fields include SBOM author, author signature, timestamp, data format and version, generation context, tool name and version, SBOM version, and component name, version, identifiers, hash, license, producer and dependency relationship. Practices include coverage of all components including transitive dependencies, distribution and delivery, frequency, updates, machine processable data and explicitly identifying unknown information.

How do I prioritise vulnerabilities in a vendor's SBOM?

Start with components whose CVEs are on CISA's KEV catalog, then those with a high EPSS probability under a cut off your program documents, then remaining critical and high findings. Ask the vendor about the first two groups in writing and summarise the rest.

What if the vendor says a vulnerability does not affect its product?

Ask for a VEX statement, in CSAF 2.0, CycloneDX VEX or OpenVEX, that marks the product not affected and gives a justification. Record it next to the finding. If the vendor cannot produce one, treat the finding as open and decide whether to accept it with a review date.

How often should a vendor send a new SBOM?

Set it by tier and write it into the contract: for example each major release and at least quarterly for critical vendors, and at least annually for high tier vendors.

Can Safeguard request and monitor vendor SBOMs?

Yes. TPRM (GA) sends SBOM requests with deadlines and follow ups, validates submissions, scores vendors from 0 to 100 (higher is better), records acceptance and remediation commitments, and alerts on new vulnerabilities and KEV additions in vendor SBOMs.

Fix what you build, not just what you buy

Most of this post is about software you buy, where the fix has to come from the vendor. The same vulnerabilities often sit in the integrations, connectors and internal services your own team builds around that vendor's product, and those you can fix yourself without waiting for anyone.

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 shows Claude connected to the Safeguard MCP server with OAuth, where you choose which tools Claude can use. For a vendor risk manager, the same connection is a way to ask plain language questions of the vendor data your team already holds in Safeguard, with access limited to the tools you allow.

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

The second demo is a real Safeguard CLI session: safeguard is asked to fix a lodash CVE in a repository, reads the finding and the 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. It does not touch a vendor's product; it is what fixing the integration code your own team writes around that product looks like.

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

For the product view of this job, see the vendor onboarding use case. Related reading: the NAIC Insurance Data Security Model Law for software vendors, a software supply chain risk assessment for insurance carriers, what to re-request from a supplier at contract renewal, when a critical software vendor fails your review at renewal and preparing for a state insurance examination IT review.

Quick check

Sources

• Cornell LII: 23 NYCRR 500.11, Third party service provider security policy
• Cornell LII: 23 NYCRR 500.9, Risk assessment
• Cornell LII: 23 NYCRR 500.17, Notices to superintendent
• NAIC: Insurance Data Security Model Law (Model 668)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: 2026 SBOM Minimum Elements (PDF)
• NIST CSWP 29: The NIST Cybersecurity Framework 2.0
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• OASIS: Common Security Advisory Framework 2.0
• CycloneDX: Vulnerability Exploitability eXchange
• SPDX
• 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: Existing SBOM
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Mitigations
• Safeguard docs: Policies and Gates
• Safeguard docs: SBOM Repository
• Safeguard docs: Compliance
• Safeguard: Vendor onboarding use case

To try the flows above, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh.

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