Our core software vendor was acquired: what to re-check, and how fast

When a core software vendor is acquired, treat it as a change in control and run a focused reassessment, not a full re-onboarding. In the first 30 days, confirm who now owns the vendor, where your data is hosted and supported, who builds the product, and whether the security controls you assessed still stand; ask for a fresh SBOM and compare it with the last one. Then raise monitoring for the transition year, because most of the real changes arrive after the press release, not on the day of it.

This post is written for the vendor risk or third-party risk manager at a US insurer whose policy administration, claims or billing vendor has just been bought. Same contract, new owner. The first two thirds work with whatever tools you already have. Safeguard appears only in the section called "How Safeguard does this".

Key takeaways

• An acquisition does not change your contract on day one, but it can change almost everything the contract assumed: ownership, hosting, the development team, the roadmap and the support model.
• The NAIC Insurance Data Security Model Law (section 4F) and 23 NYCRR 500.11 both expect oversight of third-party service providers that continues for the life of the relationship, not a one-time check at signing. Section 4G of the model law names mergers and acquisitions as a reason to adjust your own program.
• The 2023 interagency guidance for banks is not binding on insurers, but its lists of what to monitor and what to put in contracts (ownership structure, subcontracting, assignment, right to audit, termination) make a practical checklist for a change in control.
• Re-test the risks that move first: who can reach your nonpublic information, where it is hosted, who writes and ships the code, and how vulnerabilities are handled. Financial health and legal standing matter too, but they belong to other owners in your company.
• In the first 30 days, request a written change notice, an updated subprocessor list, current audit reports, the vendor's vulnerability handling process, an attestation that controls are unchanged (or a list of what changed) and a fresh SBOM in SPDX or CycloneDX.
• Compare the new SBOM with the last one you accepted: components added and removed, version changes, the Component Producer and SBOM Author fields, and new or resolved vulnerabilities, with CISA KEV entries first.
• Through the transition year, move the vendor to a higher monitoring tier: shorter SBOM refresh, alerts on new critical and known exploited vulnerabilities, and a scheduled re-assessment at each integration milestone.
• Safeguard capabilities covered here, all GA: TPRM (Third-Party Risk Manager) vendor management, SBOM requests with status tracking, risk assessment and continuous monitoring; Portal SBOM Repository version comparison; vulnerability management with EPSS and CISA KEV.
• Nothing here is legal advice. Read your own contract with counsel before you rely on any clause.

The situation

The announcement lands on a Tuesday. Your policy administration vendor, the system that holds policyholder records, rates and issues policies, and feeds billing and claims, has agreed to be acquired. The acquirer might be a larger software company consolidating the insurance market, a private equity firm building a platform, or a competitor of one of your other vendors. The vendor's account manager sends a short note: nothing changes for you, the contract stays in force, the team stays the same.

By Thursday your CISO wants to know if the vendor's risk rating should change, procurement wants to know whether the contract lets you do anything, and the business owner wants to know whether the promised roadmap is still real. Behind them is the next state examination, where an examiner may ask how you oversaw a critical third-party service provider through a change in ownership.

A bad week looks like this. You re-send last year's 300 question questionnaire, the vendor sends back last year's answers with a new date, and the file shows "reassessed". Six months later the product moves to the acquirer's hosting, the original engineering team has left, a subprocessor you never approved is handling support tickets with your policyholders' data, and nobody noticed because nothing in your monitoring was watching for any of it.

A good week looks different. You scope the reassessment to what an acquisition actually changes. You ask for a small set of documents that prove what is still true. You set a date for each answer. You change the vendor's monitoring tier for the next twelve months. And you write it all down, so the examiner sees a decision trail, not a calendar entry.

What the rules say about ongoing third-party oversight

Insurers in the US answer to state regulators, so the starting point is state law. Three documents shape what "ongoing oversight" means for a vendor risk team at an insurer, and two more give you a vocabulary that auditors recognise. This section summarises them; it is not legal advice, and the enacted text in your domiciliary state is what binds you.

NAIC Insurance Data Security Model Law (#668), sections 4F and 4G

The NAIC model law is a template that states adopt, sometimes with changes, so the section numbers in your state's statute may differ. In the NAIC text, section 4F is titled "Oversight of Third-Party Service Provider Arrangements" and has two parts. A licensee must exercise due diligence in selecting a third-party service provider, and must require that provider to put in place appropriate administrative, technical and physical measures to protect the information systems and nonpublic information the provider can reach or holds.

Section 4G, "Program Adjustments", is the one that speaks to acquisitions. It requires the licensee to monitor, evaluate and adjust its information security program in light of relevant changes, and the examples it gives include the licensee's own changing business arrangements, "such as mergers and acquisitions", alongside outsourcing arrangements and changes to information systems. Read narrowly, 4G is about your own company's deals. Read with 4F, it supports a simple position: when a critical provider's situation changes, your oversight should adjust too.

Section 6D matters as well. If a cybersecurity event happens in a system maintained by a third-party service provider, the licensee treats it as its own event for notification purposes, and the clock starts when the provider tells you or you otherwise learn of it, whichever is sooner. A change in ownership is exactly when incident notice routes break, because the people and mailboxes you had on file change.

23 NYCRR 500.11 (New York DFS)

If you are licensed by the New York Department of Financial Services, Part 500 applies, and section 500.11 is the third-party service provider security policy. Subsection (a) requires written policies and procedures, based on your risk assessment, that address four things: identification and risk assessment of providers, the minimum cybersecurity practices providers must meet, the due diligence used to evaluate those practices, and "periodic assessment" of providers based on the risk they present and the continued adequacy of their practices.

Subsection (b) lists what those policies should cover through due diligence or contract: the provider's access controls including multi-factor authentication, its use of encryption for nonpublic information in transit and at rest, notice to you of a cybersecurity event that directly affects your systems or your nonpublic information held by the provider, and representations and warranties about the provider's cybersecurity policies.

Two words in 500.11 do the work after an acquisition. "Periodic" means the assessment does not end at onboarding. "Continued adequacy" means the question is whether the controls still hold, which is exactly what a change in control puts in doubt.

The 2023 Interagency Guidance on Third-Party Relationships

On 9 June 2023 the Federal Reserve, the FDIC and the OCC published final interagency guidance on third-party risk management (88 FR 37920). It is written for banking organizations and does not bind insurers. It is still the most detailed public description of a third-party life cycle in US financial services, and many insurance vendor risk programs borrow its structure. Four parts are directly useful after an acquisition.

• Due diligence, strategies and goals (section C.2.a). It suggests understanding how a third party's current and proposed strategic arrangements, naming mergers and acquisitions, may affect the activity it performs for you.
• Due diligence, legal and regulatory compliance (section C.2.b). It suggests evaluating the third party's ownership structure, including beneficial ownership and whether ownership is foreign or domestic, and checking whether the third party or its owners are subject to OFAC sanctions.
• Contract negotiation (section C.3). The contract topics include the right to audit and require remediation (C.3.d), subcontracting (C.3.n), which raises whether the contract should prohibit assignment, transfer or subcontracting of the third party's obligations without your consent, and default and termination (C.3.p), which covers orderly transition, return or destruction of data and termination with reasonable notice.
• Ongoing monitoring (section C.4). The listed monitoring factors include changes to the third party's business strategy and its agreements with other entities, changes in financial condition, changes in key personnel, reliance on and location of subcontractors, and the third party's response to new vulnerabilities and incidents. The guidance also says monitoring can become more frequent or change type as risks change over the life of the relationship.

If you only take one thing from it, take that last sentence. An acquisition is a textbook reason to change how often and how closely you monitor.

NIST CSF 2.0, GV.SC

The NIST Cybersecurity Framework 2.0 has a Cybersecurity Supply Chain Risk Management category under Govern. Four outcomes map to this situation. GV.SC-04 asks that suppliers are known and prioritized by criticality. GV.SC-05 asks that supply chain security requirements are built into contracts. GV.SC-07 asks that supplier risks are "understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship". GV.SC-10 asks that plans cover what happens after a relationship ends, which matters if the acquisition leads to a product sunset.

NIST SP 800-161 Rev. 1 and the CISA 2026 SBOM Minimum Elements

NIST SP 800-161 Rev. 1 (with updates as of November 2024) is NIST's cybersecurity supply chain risk management guidance. It is written for federal agencies but widely used as a reference for supplier assessment practices across the life of a supplier relationship.

For software specifically, the current reference for what an SBOM should contain is CISA's 2026 Minimum Elements for a Software Bill of Materials, published 29 July 2026 with NSA, FBI and international partners. It replaces the NTIA 2021 minimum elements. Three of its elements matter after an acquisition. Component Producer names the one entity that created a component. SBOM Author names the entity that generated the SBOM, which may be different. And the Frequency element says each software version or update should have its own SBOM, with a new SBOM for each build or release and a revised one when errors are found. A product that changes hands should not be shipping last year's SBOM.

Which risks change most after an acquisition?

Not everything moves at once. The useful question is which assumptions in your last assessment are most likely to stop being true, and how soon. The table below is a starting point; adjust the timing to what the vendor and acquirer actually announce.

The riskiest changes are rarely announced: a hosting or support move often shows up only as an updated subprocessor list. And the software drifts slowly, so the product you run in month nine may differ a lot from the one you assessed. Comparing SBOMs is the easy way to see that.

Tier the vendor again before you do anything else

If the vendor was tiered lower because it was small or narrowly scoped, look again. A policy administration, claims or billing system that holds nonpublic information and supports core operations is critical for most insurers by any reasonable definition. Our post on tiering vendors by blast radius rather than spend covers how to make that call in a way you can defend.

Step by step: the change-in-control reassessment

These steps work with a spreadsheet, a ticketing system and email. Put dates on each one and record who decided what. Timings assume a critical vendor; stretch them for lower tiers.

1. Open a change-in-control record (day 0 to 2). Log the announcement date, expected close date, acquirer name, the products you use and the business owners. Link the contract, the last assessment and the last SBOM you accepted. This record is what you will show an examiner.
2. Read the contract for change-in-control language (day 1 to 5). With counsel, find the assignment clause, any change of control clause, notice obligations, audit rights, subcontracting consent, data location commitments, termination for convenience or cause, and data return. Note which ones give you a right to be told, a right to consent, or a right to leave.
3. Send a written request for a change notice (day 2 to 5). Ask the vendor to confirm in writing the transaction details, the closing date, and its plans for hosting, development, support and subprocessors for the next twelve months. A template follows below.
4. Run the ownership checks your company requires (day 2 to 10). Ownership structure, beneficial owners, sanctions screening and any foreign ownership review. These usually belong to compliance or legal, not vendor risk, but the result goes in your record.
5. Request the evidence pack (day 5 to 10). Current audit reports, the subprocessor list, the vulnerability handling process, the control attestation and a fresh SBOM. Set a deadline of 15 to 20 business days.
6. Validate what comes back (day 15 to 30). Check the SBOM format and fields, compare it with the last one, and compare the subprocessor list and audit report scope with what you had. List every difference.
7. Re-score and decide (day 25 to 35). Update the vendor's risk rating. Decide one of four outcomes: no change, accept with conditions, remediate with dates, or start exit planning. Record who approved it.
8. Raise monitoring for the transition year (day 30). Shorter SBOM refresh, alerts on new critical and known exploited vulnerabilities in the vendor's components, a check of the subprocessor list every quarter, and a re-assessment at each integration milestone the vendor names.
9. Tell the people who need to know (day 30 to 35). The business owner, the CISO, procurement and, where your incident response plan names the vendor, the incident response lead with any new contact details.
10. Close the 30 day review and schedule the next one (day 35). Set the 90 day, 6 month and 12 month checkpoints now, and tie the last one to the renewal date if it falls inside the year.

A change notice request you can send today

Adapt this to your contract and send it from the relationship owner, with vendor risk copied.

Subject: Change in control: information request for [product]

Following the announcement that [vendor] will be acquired by [acquirer], please confirm the following in writing by [date]:

1. The expected closing date and the legal entity that will hold our contract after closing.
2. Any planned change in the next 12 months to where our data is hosted, processed or backed up, including cloud provider and region.
3. Any planned change to the development team, build and release process, or code base for [product].
4. Any planned change to support, including the location of support staff and any new subcontractor.
5. Your current subprocessor list, and how you will notify us of changes.
6. The named security contact and the incident notification route after closing.
7. Your current vulnerability handling and disclosure process.
8. An updated SBOM for the version we run, in SPDX or CycloneDX, and your plan for SBOMs on future releases.
9. Confirmation that the controls described in your most recent audit report and our last assessment remain in place, or a list of what has changed.

Keep the list short. A focused request gets real answers; a 300 question questionnaire gets copy and paste.

What should you request in the first 30 days?

Here is the evidence pack with what each item proves, so you can explain to the vendor why you are asking.

If you already ask for most of this at renewal, reuse that list. Our post on what to re-request from a supplier at contract renewal covers the SBOM side in more depth.

How do you compare the new SBOM with the last one?

An SBOM comparison is the cheapest way to see whether the software you run is drifting under a new owner. It will not tell you about process changes, but it shows you what the process produced. Work through it in this order.

1. Check that you are comparing like with like. Both SBOMs should describe the same product and the version you actually run. Check the SBOM Generation Context too: an SBOM built from source ("before build") and one built from the shipped binary ("after build") can list different components without anything having changed.
2. Check the format and required fields. Is it valid SPDX or CycloneDX? Does it carry the CISA 2026 minimum elements, including SBOM Author, Component Producer, component versions and identifiers, dependency relationships and a timestamp? Does it explicitly say where information is unknown or withheld?
3. Read the SBOM Author and Component Producer fields. After an acquisition the author may now be the acquirer, and first-party components may be listed under a new producer name. That is expected, but it breaks matching in many tools. Our post on supplier names changing after a rename or acquisition covers how to keep those records joined.
4. List added and removed components. New components often point to merged shared libraries, a new authentication service or a new framework. Removed components can be good news (old code retired) or a sign the SBOM is less complete.
5. List version changes. Downgrades are worth a question. Large jumps in a framework can mean a re-platforming.
6. Look at new and resolved vulnerabilities. Match both SBOMs against current vulnerability data. Rank anything new by CISA KEV first, then by exploit likelihood, then by severity.
7. Write the questions back to the vendor. Not "explain every change", but "these five components are new; which products of the acquirer do they come from, and who maintains them now?"

A worked example (illustrative)

The numbers here are invented and round, to show the shape of the work. Your last accepted SBOM for the policy administration product listed 1,200 components. The new one lists 1,400. The comparison shows 250 added, 50 removed and 150 version changes. Of the 250 added, most share a namespace that matches the acquirer's other products, which suggests a shared platform layer has been merged in. Ten of the new components carry known vulnerabilities, two of them listed in CISA KEV.

What you do with that is a judgement, not a formula. You ask the vendor which release introduced the shared layer, whether the two KEV-listed vulnerabilities are reachable in your deployment, and when fixes will ship. You record the answers and the dates. You set the next SBOM request for the next release rather than for next year.

What monitoring should run through the transition year?

The transition year is the twelve months after closing, or until the vendor confirms integration is finished, whichever is later. Treat the vendor as one tier higher than it was for that period. A schedule that works for most critical vendors:

Put the vendor's integration milestones in your own calendar as soon as they are announced, and keep the 30 day record open as a living file so the examiner sees one thread rather than scattered emails.

Which contract terms matter now?

You cannot renegotiate on day one, but you can find out what you already have. With counsel, read for these terms. The point is to know your position before the vendor's new owner proposes new paper.

If the contract is thin on these, note it now and plan to fix it at renewal; the interagency guidance sections on right to audit, subcontracting and default and termination are a useful checklist for what to add.

A decision table for the 30 day review

How Safeguard does this

Everything above works with spreadsheets. If you want the vendor record, the SBOM requests, the comparison and the monitoring in one place, this is how the matching flow runs in Safeguard, using only what Safeguard's documentation describes. Every capability named here is generally available (GA).

The main product is TPRM, Safeguard's Third-Party Risk Manager (GA), which covers vendor management, SBOM requests with status tracking, risk assessment and continuous monitoring. Received SBOMs can be stored and compared in the Portal SBOM Repository (GA), and vulnerability matching draws on vulnerability management with EPSS and CISA KEV (GA).

1. Find or add the vendor record. In TPRM, go to Vendors, then Add Vendor if the vendor is new, and enter company name, primary contact, contact email, website, the products you use and the risk tier. For an existing vendor, open its record. The record holds contract status, risk tier, SBOM status and the date of the last assessment. If you hold many vendors in a spreadsheet, the docs describe a bulk import from a CSV template.
2. Re-tier and record why. Select the vendor, click Edit Risk Tier, choose the new tier, document the justification and save. The docs describe four tiers: Critical (core business operations, with SBOMs required and updated quarterly), High, Medium and Low. TPRM can also suggest a tier based on data access level, system criticality, user count and compliance requirements; the decision stays yours.
3. Record the new owner. The vendor record tracks relationships between vendors, including parent companies and subsidiaries, so you can link the acquired vendor to its new parent. Link the contract too: the docs list contract documents, start and end dates, SLA terms, security requirements and SBOM obligations.
4. Send the SBOM request. From the vendor record, click Request SBOM, select the product or products, choose a request template, customize the message if you want to add the change-in-control context, set a deadline and click Send. The standard template covers SPDX and CycloneDX format requirements, required fields, submission instructions and the deadline. You can build your own template under Settings → Request Templates with the change notice questions above.
5. Track the request. Requests move through Sent, Viewed, In Progress, Submitted, Validated and Rejected. Automated follow-ups go out 7 days before the deadline and at the deadline, with an escalation 7 days after. The vendor can respond through a secure upload portal or email attachment, and can use the self-service vendor portal to update its own details, submit SBOMs and respond to questionnaires.
6. Let validation run, and reject if needed. When an SBOM arrives, Safeguard checks the format (valid SPDX or CycloneDX), checks completeness against required fields, runs a compliance check, scans it for vulnerabilities and notifies you. If it falls short, review the failures, click Request Revision and specify what to fix; the vendor gets the update request.
7. Compare the new SBOM with the last one. In the Portal SBOM Repository, keep SBOMs grouped by product and version. Use Import SBOM to upload an older SBOM you hold elsewhere and assign it to the product and version. Then select two versions of the same product and click Compare. The comparison shows added components, removed components, version changes, new vulnerabilities and resolved vulnerabilities, which is the list in the comparison steps above.
8. Read the risk score and generate a report. 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. The score draws on vulnerability risk (critical and high counts, EPSS, known exploited vulnerabilities), compliance risk (SBOM completeness, age and format validity), component risk (abandoned packages, license compliance, transitive dependency depth) and operational risk (response time to requests, update frequency, incident history, contract compliance). Select the vendor and click Generate Report for an executive summary, score breakdown, vulnerability details, compliance gaps and recommendations. That report is a reasonable attachment to your 30 day record.
9. Document what you accept and what you expect fixed. For a finding you decide to accept, click Accept Risk, give the business justification, set a review date and obtain the required approvals. For findings the vendor must fix, remediation tracking holds requested fixes, vendor commitments, progress updates and verification status.
10. Set transition-year monitoring. Under Settings → Monitoring, turn on alerts for Critical Vuln (a new critical CVE), Exploited (a CVE added to CISA KEV), Risk Change (the score drops below a threshold you set) and SBOM Expiry (the SBOM is older than a threshold). Set automatic re-scans of the vendor's SBOMs daily for critical vendors, or weekly, monthly or quarterly. Alerts can go to email, Slack, Microsoft Teams, PagerDuty or a custom webhook. Re-assessment can be triggered by new vulnerability disclosures, major version updates, contract renewals and security incidents.
11. Report through the year. The vendor dashboard shows vendors that need attention, recent score changes and upcoming SBOM expirations. Trend analysis tracks risk score, vulnerability counts and remediation velocity over time. Scheduled reports can run weekly, monthly, quarterly or annually, and ad hoc reports export to PDF or Excel for the examiner file.

One gap to plan around: the monitoring triggers in the docs do not include "change of ownership". Safeguard will not notice the acquisition for you. You start the reassessment yourself, by re-tiering, sending the request and setting the alerts, and Safeguard keeps the record and the watch from there.

What Safeguard does not do

Be clear about these limits before you plan around the tool.

• It does not assess financial health, deal terms or the acquirer's other business. Debt load, credit ratings, sanctions screening, beneficial ownership and the acquirer's track record with past acquisitions are outside what TPRM scores. Finance, compliance and legal own them.
• It does not read or interpret your contract. TPRM stores contract documents and terms you enter. Whether your assignment clause gives you a consent right is a question for counsel, and nothing in this post is legal advice.
• It depends on the vendor responding. Request templates, deadlines, follow-ups and escalations make it easier to get an SBOM, but a vendor that will not provide one will not be made to by software. What you can do is record the refusal, raise the tier and decide.
• An SBOM comparison shows components, not process. The comparison tells you what changed in the software. It does not tell you whether the new owner kept code review, release approvals, access controls or incident response the same. Those need the control attestation, audit reports and direct questions.
• It does not watch hosting moves, subprocessor changes or staff turnover. Those signals live in notices, subprocessor lists and conversations with the vendor. Your quarterly checks stay manual.
• It does not detect the acquisition. As noted above, there is no change-in-ownership trigger in the documented monitoring settings. You open the reassessment.
• It does not decide for you. The risk score is an input. Accepting risk, setting conditions or starting an exit is your decision and your approver's.

Common mistakes

• Treating the press release as the event. Closing is often months after announcement, and integration months after that. Set checkpoints for each, not one review in week one.
• Re-sending the full annual questionnaire. It produces recycled answers. Ask the short change-in-control set instead.
• Accepting "nothing will change". Ask for it in writing, with dates, from someone who can commit, and add "or a list of what has changed".
• Comparing SBOMs for different versions or built at different stages. Check product, version and generation context first, or you will chase differences that are not real.
• Losing the vendor's history when the name changes. If the acquirer renames the vendor or product, link the records rather than creating a new vendor with no history.
• Forgetting incident notice routes. Under NAIC section 6D and 23 NYCRR 500.11(b)(3), notice from the provider starts or informs your own clock. Update the contact details the day they change.
• Leaving the decision undocumented. "Reviewed, no action" without an approver, a date and a next checkpoint is the record examiners question most.

FAQ

What should vendor risk reassess when a software vendor is acquired?

Reassess ownership and control, data hosting and location, the development team and secure development practices, the support model and subprocessors, vulnerability handling and incident notice, and the product roadmap. Ask for a fresh SBOM and compare it with the last one you accepted.

How quickly should we reassess a critical vendor after an acquisition announcement?

A focused review within 30 days of the announcement is a reasonable target for a critical vendor, with checkpoints at closing, at each integration milestone and at 6 and 12 months. Your own policy and your regulator's expectations set the actual timing.

Does an acquisition let us terminate the contract?

Only if your contract says so, usually through a change of control, assignment or termination for convenience clause. Read it with counsel. Many contracts give a notice right but not a termination right.

Is the vendor allowed to assign our contract to the acquirer?

It depends on the assignment clause. Some contracts allow assignment to an acquirer or affiliate without consent; others require it. The interagency guidance suggests considering whether contracts should prohibit assignment without your consent, which is worth adding at renewal if it is missing.

Does the NAIC Insurance Data Security Model Law apply to my company?

It applies where your state has enacted a version of it, and the enacted text and numbering may differ from the NAIC model. Check your domiciliary state's statute and any other states where you are licensed.

Why ask for an SBOM after an acquisition?

Because the software can change under a new owner without any announcement, through merged libraries, new frameworks or a re-platform. Comparing a fresh SBOM with the last one shows that drift and any new vulnerabilities it brings.

What is the difference between SBOM Author and Component Producer?

Under CISA's 2026 minimum elements, SBOM Author is the entity that generated the SBOM, and Component Producer is the entity that created the component. After an acquisition, either may change name, which is why matching across SBOMs needs care.

What if the vendor refuses to provide an SBOM?

Record the refusal, check whether the contract requires one, ask for compensating evidence such as audit reports and a vulnerability handling process, and consider whether the refusal itself changes the vendor's risk rating.

The next section is about a different gap from the one this post has covered: the open source components in software you build, not the software you buy. If the comparison work above shows your own integrations and extracts around the vendor's platform carry vulnerable components too, this is how Safeguard helps close that gap without waiting on anyone else's release.

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, and how you choose which Safeguard tools Claude can use. For a vendor risk team, the same connection is a way to ask questions of the data Safeguard holds in plain language, within the tools you have allowed, while you build the 30 day record.

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

The second demo shows the Safeguard desktop app, which is generally available. It is a way to work with Safeguard from your own machine; check the docs for which TPRM screens you use from the desktop.

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

For a wider view of supply chain risk at an insurer, see our guide to a software supply chain risk assessment for insurance carriers.

To try the flow yourself, download Safeguard or read the Safeguard docs.

Quick check

Sources

• NAIC Insurance Data Security Model Law (#668)
• 23 NYCRR 500.11, Third-party service provider security policy (Cornell LII)
• New York DFS cybersecurity resource center
• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (GovInfo)
• Interagency Guidance on Third-Party Relationships, Federal Register listing
• NIST Cybersecurity Framework 2.0 (CSWP 29)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• CISA, 2026 Minimum Elements for a Software Bill of Materials
• CISA, 2026 Minimum Elements for an SBOM (PDF)
• CISA Known Exploited Vulnerabilities Catalog
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Risk Assessment
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Portal SBOM Repository

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