Which security addendum terms can a SaaS vendor sign at renewal?

You can safely sign the security addendum terms you already meet today, with evidence, and you should counter the rest before Sales signs. Go clause by clause: SBOM delivery, patch timelines, known exploited vulnerability windows, vulnerability notice, VEX, right to audit and attestation. Test each against the last 90 days of your own data, propose wording you can keep, and give every promise an owner and a metric.

The customer is a bank, an insurer or a health system, the addendum came from their procurement team, and Sales wants it signed this week. Your job as the person who runs product security is narrower: say which promises the product team can keep, every month, for the life of the contract.

The first part of this guide works with whatever tools you have. The second shows how Safeguard supports the same work, step by step from its docs, and what it does not do. This is general information, not legal advice; your counsel owns the contract language.

Key takeaways

• The addendum is usually your customer's regulator speaking through procurement. Banks follow the Interagency Guidance on Third-Party Relationships (June 2023), New York financial firms follow 23 NYCRR 500.11, and health systems need a HIPAA business associate contract under 45 CFR 164.314. Knowing the driver tells you what a workable counter looks like.
• Test before you sign. Measure each clause against the last 90 days, at the 90th percentile, not the median.
• SBOM terms should name format, scope and channel. CISA's 2026 Minimum Elements expect an SBOM per version or update; OMB M-26-05 says a cloud platform's SBOM term should cover the runtime production environment, on request.
• Patch timelines depend on definitions. Define "critical", start the clock when a fix is available, and write a no-fix path.
• Notice and VEX are two halves of one answer. The OASIS CSAF 2.0 VEX profile requires a justification for every "not affected" claim.
• Track every promise like a control, in an obligations register with a metric, an owner and evidence.
• Safeguard capabilities in this post and their labels: SBOM generation and analysis (GA); vulnerability management with EPSS and KEV enrichment (GA); reachability analysis and prioritisation (GA); Portal, meaning the SBOM publish, share and audit trail product, not the free entry tier (GA); CSAF and VEX upload (GA); policies, gates and guardrails, including plain English policy creation (GA); Trust Center (GA); the Compliance and GRC suite (GA); the Safeguard CLI and MCP server (GA); autonomous remediation (GA, ships switched off with every category set to Manual); Gold Open Source and fork and patch (GA).

The situation

The renewal paperwork looks routine until a new exhibit called something like "Vendor Security Requirements". It asks you to deliver an SBOM for each release, remediate critical and high vulnerabilities in fixed windows, remediate anything on CISA's Known Exploited Vulnerabilities (KEV) catalog on a shorter clock, notify the customer of vulnerabilities affecting the service, provide VEX statements, accept a right to audit, and attest to a secure development framework.

A bad week: you sign on Friday. Three weeks later a critical advisory lands in a library you ship everywhere. Upstream fixed only the next major version. The addendum's clock started at publication, you miss it, and the next renewal opens with a remediation plan instead of a price.

A good week: you redline four of eleven clauses, each with a reason and alternative wording, sign the seven you already meet with an evidence plan attached, and load all eleven into a register before the countersigned copy returns.

Why regulated customers send these addenda

Most addenda are the customer's way of meeting its own regulator's expectations about third parties. Name the rule behind a clause and you can usually find a version that satisfies the rule and that you can keep.

Banks: the Interagency Guidance on Third-Party Relationships

The OCC, the Federal Reserve and the FDIC issued the "Interagency Guidance on Third-Party Relationships: Risk Management" together. OCC Bulletin 2023-17 announced it on 6 June 2023, and it appeared in the Federal Register on 9 June 2023 (88 FR 37920). It describes a life cycle from planning and due diligence through contract negotiation, ongoing monitoring and termination.

Its contract negotiation section lists factors banks typically consider, and several map straight onto your addendum:

• Performance measures or benchmarks. A service level agreement can set expectations for both parties, and the guidance warns against measures that reward speed or volume without regard to accuracy or compliance. That warning helps you resist clauses that reward closing tickets over verified fixes.
• Responsibilities for providing, receiving and retaining information. Notification when compliance lapses or other events pose significant risk, and the type and frequency of reports, which may include security reports and control assessments.
• The right to audit and require remediation. Periodic, independent audits consistent with risk, naming the reports the bank receives (SOC reports are the guidance's example), and possibly the bank's own audits.
• Subcontracting, confidentiality and integrity, and default and termination appear later in the same list.

The guidance repeatedly says oversight should match the risk and criticality of the activity. That is your opening for tiered wording instead of one absolute promise.

New York financial services: 23 NYCRR 500.11

Section 500.11(a) requires covered entities to have written policies for third-party service providers covering risk assessment, minimum cybersecurity practices, due diligence and periodic assessment. Section 500.11(b) says those policies shall include guidelines for due diligence or contractual protections addressing, where applicable, the provider's access controls including multi-factor authentication, its encryption, notice of a cybersecurity event directly affecting the covered entity's systems or nonpublic information, and representations and warranties about the provider's cybersecurity policies.

So a New York insurer's notice clause is often 500.11(b)(3) in contract form. It concerns cybersecurity events affecting the customer, not every CVE in your dependency tree.

Health systems: HIPAA business associate contracts

If your product handles electronic protected health information for a covered entity, 45 CFR 164.314(a)(2)(i) requires the business associate contract to say you will comply with the Security Rule subpart, flow those duties to subcontractors, and report any security incident you become aware of, including breaches as required by 164.410. Section 164.410(b) sets breach notification at without unreasonable delay and no later than 60 calendar days after discovery.

Health system addenda often add shorter windows, remediation timelines and SBOM requests. Those extras are contract terms, not HIPAA requirements, so they are negotiable in a way the regulatory floor is not.

Federal signals that show up in private contracts

CISA's KEV catalog is described by CISA as the authoritative source of vulnerabilities exploited in the wild, and CISA recommends using it as an input to prioritisation. Customers turn that into "remediate KEV-listed vulnerabilities within N days". For federal agencies, BOD 26-04 ("Prioritizing Security Updates Based on Risk", 10 June 2026) revoked BOD 22-01 and BOD 19-02 and sets timelines from four factors: public exposure, KEV status, exploit automation and technical impact. A clause that cites BOD 22-01's flat KEV dates is citing a revoked directive.

OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. It says agencies may still use the Secure Software Development Attestation Form and may adopt contract terms requiring a current SBOM upon request. Its footnote adds that for a cloud platform, such a term should specify an SBOM of the runtime production environment on request. That footnote is the most useful sentence a SaaS vendor can bring to an SBOM negotiation.

NIST SP 800-161 Rev. 1 (May 2022, updated as of 1 November 2024) is the supply chain risk management reference many vendor risk teams build on. If a clause cites it, ask which control the clause is meant to satisfy; the answer usually narrows it.

Step by step: commit, counter or decline

This runs on a spreadsheet and a calendar.

1. Split the addendum into atomic promises. "Remediate Critical and High within 15 and 30 days and notify Customer within 72 hours" is three promises.
2. Tag each promise with its likely driver: interagency guidance, 500.11, HIPAA, internal policy, or unknown. Ask procurement when you cannot tell.
3. List the definitions each promise depends on: severity, "affecting the Services", "remediate", "discovery", business days. Most unkeepable promises become keepable once these are fixed.
4. Measure the last 90 days against the promise (next section). Record the number, its source and who pulled it.
5. Classify: commit, commit with definitions, counter, or decline.
6. Draft each counter in the customer's frame, explaining how it still meets their driver.
7. Attach an evidence plan to every committed promise: which report or artifact, how often.
8. Load the signed version into your obligations register with owners and review dates.

A decision table you can use today

How do you test each term against your current performance?

Ask of every clause: over the last 90 days, how often would we have met this, and how would we prove it?

Pull a baseline

From your scanner export, ticket system or spreadsheet, get for every vulnerability in the window: identifier and affected component, the severity you assigned plus CVSS, EPSS and KEV status at the time, the dates of advisory publication, fix availability, your detection and production deploy, and whether you judged it reachable or exploitable.

Then compute per severity the median and the 90th percentile of days from fix available to production, plus the count of findings with no fix at all. A clause is breached by your slowest case, so the 90th percentile is the number to negotiate with.

A test sheet per clause

If a row fails, change the clause or change the process before signature.

Watch the multiplier

Each customer sends its own addendum. Customer A wants CycloneDX on request; Customer B wants SPDX with every release; Customer C starts the critical clock at publication; Customer D at fix availability. Each is meetable alone. Together they make your slowest clock and most demanding format the operating standard for the whole product, so check every new clause against what you already promised others.

SBOM delivery wording that holds up

SBOM clauses fail when they name no format, no version and no channel.

What the 2026 minimum elements expect

CISA's "2026 Minimum Elements for a Software Bill of Materials (SBOM)" (29 July 2026, with NSA, FBI and international partners) replaces the 2021 NTIA minimum elements. New data fields include SBOM data format version, SBOM generation context, SBOM tool name, component hash value and algorithm, and component license, alongside author, timestamp, component name, version, producer, identifiers, dependency relationships and an SBOM author signature.

Its practices matter just as much in a contract:

• Frequency: each software version or update should have an SBOM, and a new build or release gets a new one.
• Coverage: all components including transitive dependencies, with no minimum depth.
• Distribution and Delivery: available promptly to those who need them, through channels such as a version-specific URL, an API or a repository, with access controls that do not block authorised parties.
• Explicitly identifying unknown information: say whether a missing field is unknown or withheld.

Its SaaS section says frequent change complicates SBOMs for cloud software, that very high delivery frequency may overwhelm producer and operator alike, and that SaaS delivery cadence may need further specification. That is solid ground to resist "an SBOM for every deployment".

Wording patterns

Illustrative patterns for discussion with counsel, not contract language.

Customer draft: "Vendor shall provide a complete SBOM for each release of the Software within two business days of release." For a SaaS product with no definition of "release", that can mean every deploy, in any format, through any channel.

A SaaS version you can keep: "Upon Customer's written request, no more than once per calendar quarter, Vendor will provide an SBOM in SPDX or CycloneDX format describing the runtime production environment of the Services as of the date of generation, meeting the data fields of CISA's 2026 Minimum Elements where known to Vendor and marking unknown or withheld fields as such, within ten business days, through a secure sharing channel limited to Customer's named recipients."

For installed software: "Vendor will make available an SBOM in SPDX or CycloneDX format for each generally available version of the Software delivered to Customer, no later than that version's general availability date, through a version-specific link."

Avoid "complete and accurate" without a definition; promise to follow the minimum elements and to correct errors promptly, which matches CISA's practice on accommodating updates. Do not promise signed SBOMs until you can sign them, and tie the duty to supported versions. For the day the request lands, see what to say when a customer asks for a fresh SBOM at renewal.

Patch timeline wording you can meet

Define "critical" before you agree to a number

An undefined "Critical" will be read as CVSS 9.0 or higher by the customer and as "what we rated critical" by you. Three options for a definitions schedule:

• CVSS base severity only. Simple and checkable, but blind to whether the vulnerable code runs in your product.
• CVSS plus exploit signals. Raise one level if the CVE is KEV-listed or its EPSS probability is above a named threshold. Closer to how BOD 26-04 thinks about urgency.
• Vendor-assessed severity in context. Your documented method, considering exposure and reachability. Most realistic, and needs transparency to be accepted.

A middle path that often lands: "Severity means the CVSS base severity in the CVE record, adjusted by Vendor using a documented methodology that considers KEV status, exploit availability and whether the affected code is reachable in the Services. Vendor will share the methodology on request and will not downgrade a vulnerability listed in CISA's KEV catalog." More on this in how to define a critical vulnerability in a patch SLA clause.

Say when the clock starts

Define "fix available" too: a fixed version published by the maintainer for the major version used in the Services, or a patch, configuration change or compensating control that eliminates the vulnerability. Without the major version qualifier, a fix released only for the next major version starts your clock on a quarter-long upgrade.

Write down what happens when there is no fix

For example: "Where no fix is available, Vendor will within the applicable period implement a compensating control or document why the vulnerability is not exploitable in the Services, notify Customer if Customer is affected, and remediate within the applicable period after a fix becomes available." This mirrors CSAF's remediation categories, which separate an official vendor fix from cases where no fix is available or none is planned.

Illustrative timeline table

Illustrative numbers only; replace them with your own 90th percentile plus margin.

Known exploited vulnerability windows

A KEV listing means exploitation has been seen in the wild, so customers accept fewer "not reachable" arguments. Propose that the KEV clock start at the later of the listing date and fix availability, and if the customer cites federal practice, point to BOD 26-04's risk-based table rather than one flat date. For running that promise daily, see keeping a contract promise of no known exploited vulnerabilities.

Finally, define "remediate" as the fix running in production, the component removed, or a documented compensating control in place, never "ticket closed".

Vulnerability notice and VEX: how they work together

Customers ask for notice so they can act, and for VEX so they can stop acting. Write the two clauses together.

The notice clause

500.11(b)(3) concerns cybersecurity events affecting the customer's systems or data, and 164.314(a)(2)(i)(C) concerns security incidents and breaches. Neither says "every CVE". A keepable notice clause separates:

1. Security incidents affecting the customer's data or systems, on the window your incident terms already set.
2. Vulnerabilities in the Services that you have confirmed affect the customer and are Critical or KEV-listed, within a set number of business days of confirmation, with a plan or the no-fix path.
3. Everything else, through a status page, Trust Center or advisory feed.

Name the channel: "written notice to Customer's designated security contact", not "notice to Customer".

The VEX clause

VEX, Vulnerability Exploitability eXchange, states whether a product is affected by a vulnerability. In OASIS CSAF 2.0 (18 November 2022), product status values include known affected, known not affected, fixed and under investigation. The VEX profile requires every "known not affected" product to carry an impact statement, as a flag or a written justification. The flags are component not present, vulnerable code not present, vulnerable code cannot be controlled by adversary, vulnerable code not in execute path, and inline mitigations already exist. A "known affected" product needs a remediation or action statement, and "no fix planned" or "none available" are allowed.

So a VEX promise can read: "Upon request, or with any vulnerability notice, Vendor will provide an exploitability statement in CSAF 2.0 VEX, CycloneDX VEX or OpenVEX format stating whether the Services are known affected, known not affected, fixed or under investigation, with a justification for any not affected status." You commit to a format and to honesty, not to a speed you cannot hold for every CVE. CISA's 2026 SBOM document makes the same link, noting that advisories such as VEX and CSAF help avoid wasted effort when a potential risk is not an actual one.

A "not affected" statement is a claim you will be held to. Have a named person approve each one and keep the reasoning; a scanner's reachability result helps prioritise, it does not sign statements.

Right to audit, attestation and the other clauses

Right to audit. Banks follow guidance that expects audit rights, so refusal rarely works. Offer current independent reports annually, one standard questionnaire a year, and an audit on reasonable notice, at the customer's cost, limited to the Services, once a year or after a material incident. Do not offer access to systems shared with other customers.

Attestation. "Vendor attests that it follows NIST SP 800-218" covers every practice in the framework. Check each against evidence, or narrow it to "maintains a secure development program aligned with NIST SP 800-218 and will provide a summary of its practices on request". A federal or federal-minded customer may send the Secure Software Development Attestation Form itself, which M-26-05 still allows.

Subcontractors. HIPAA requires flow-down to subcontractors that handle ePHI, and the interagency guidance lists subcontracting as a contract factor. Make sure your own vendors' terms let you pass the duty on.

Representations and warranties. Keep them factual and present tense ("Vendor maintains a written information security program"), not outcome guarantees.

Clauses to decline: "free of known vulnerabilities" at all times; unlimited SBOM requests on a 24 hour clock; notice of every vulnerability regardless of impact; liability for upstream release schedules. The bank-side list is in contract clauses banks expect from software vendors.

How do you track every promise across dozens of customer contracts?

Build an obligations register

One row per atomic promise per customer:

Run it like a control

• Normalise. Most rows collapse into a few operating standards: strictest SBOM format set, shortest critical window, shortest notice window. Run to the strictest where it is cheap; track exceptions where it is not.
• Measure monthly, and alert while a finding can still meet its window.
• Review before every renewal. Show the customer every promise met, and propose standard terms you keep for everyone.
• Name owners. Product security owns the register, engineering the fixes, counsel the text, customer success the notice channel.

How Safeguard does this

Safeguard does not read, negotiate or interpret contracts. It produces and keeps the evidence behind an addendum's technical promises. The flow below uses only what Safeguard's docs describe; commands are copied from docs.safeguard.sh and were not run for this post.

1. Generate an SBOM for each version you ship. In the Enterprise Software Supply Chain Manager, SBOM generation and analysis (GA) builds SPDX and CycloneDX SBOMs from connected repositories, container registries and uploaded manifests. You add a project from Integrations with a branch or tag and a version; continuous scanning runs daily, with optional triggers on push, on a schedule, or on release. From a terminal, the Safeguard CLI (GA):

   # Install the CLI
   curl -fsSL https://cli.safeguard.sh/install | bash
   # Scan a local directory, writing results under ./output
   safeguard scan --dir .
   # Scan a container image
   safeguard scan --image nginx:latest
   

   The docs say a scan from the interactive terminal while signed in uploads the SBOM and findings, and your source never leaves the machine. For a SaaS product, scan the images you run in production: that is the runtime production view M-26-05 describes.

2. Validate before you promise. safeguard validate checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications; --strict treats warnings as errors:

   safeguard validate sbom.json --strict -o report.json
   

   Portal's Compliance tab scores an SBOM and shows gaps. The docs describe that check against the NTIA minimum fields, not CISA's 2026 additions such as component license or generation context, so check those against the 2026 table yourself.

3. Read your real remediation numbers. Vulnerability management (GA) matches components against vulnerability sources and adds EPSS and KEV. Reachability analysis and prioritisation (GA) ranks findings by whether the vulnerable code paths are called. Export the data (CSV and Excel are among the formats) to compute the 90 day percentiles and to support a severity definition that considers KEV status and reachability.

4. Turn the promise into a gate. With policies, gates and guardrails (GA), conditions include vulnerability severity, CVSS score and EPSS score, and policies can be written from a plain English prompt. Each policy's Action decides what a failure does to the gate: Block fails it, Warn passes it with a warning naming the policy, Notify passes it and notifies your configured channels. Justified exceptions go through the exceptions workflow, with a justification, an expiry date and an approver's recorded decision. In CI the docs show:

   safeguard ci scan --wait --fail-on-gate <gate name or id | all>
   

   which exits non-zero when the gate fails. "No KEV-listed findings in a release" becomes a Block policy on the release gate. Policy outcomes are switched on per workspace by Safeguard, so ask if you see no Outcome column.

5. Record the no-fix path. The Mitigations tab records risk acceptance, false positive, workaround applied and not applicable, each with a justification, an approver and a scope. A risk acceptance can carry an expiration date with reminders 14 and 7 days before and on the day. Active mitigations exclude a finding from gate failures; expired ones do not. Every change is logged.

6. Bring in VEX and CSAF. CSAF and VEX upload (GA) accepts CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile from Integrations, filtered by Upload, so the platform matches the statements you send customers.

7. Publish and share each version through Portal. Portal (GA, the SBOM publish, share and audit product) organises SBOMs into Products and versions under My Products, with statuses of pre-release, current, deprecated or end of life, and optional approval before publishing. Publishing creates an immutable copy. Sharing offers direct shares with View, Download or Full permission, links with expiry, download limits and passwords, a branded customer portal, approved domains, per-SBOM NDA acceptance and immediate revocation: a direct match for "a secure channel limited to named recipients".

8. Keep the audit trail. Portal's audit trails log SBOM changes, views, downloads, sharing events, link use and permission changes, with timestamp, actor, IP address and result, exportable as CSV, JSON or PDF. When an auditor asks who downloaded the Q3 SBOM and when, this is the answer.

9. Publish standing answers on a Trust Center. Trust Center (GA), on Compliance › Trust Center, shows the frameworks you choose with statuses such as Compliant, In progress or Not assessed, controls read live from monitoring, policies, sub-processors and documents. Restricted documents are released only through access requests: the visitor accepts your NDA and verifies their email, and a compliance reviewer or an auto-approval rule decides. Where switched on for your workspace, it can carry security advisories and a Security contacts list for sending a published update to each customer's named contact. The Compliance and GRC suite (GA) holds the controls, evidence and questionnaires behind an attestation clause.

10. Ask in plain language, and fix faster. The Safeguard MCP server (GA) lets an assistant such as Claude query your data; the docs list read-only tools for gate and policy outcomes where policy outcomes are on and your access settings allow. Autonomous remediation (GA) opens tested fix pull requests, singly or in bulk, and ships switched off with every category set to Manual. Faster merges widen the margin between your 90th percentile and the clause.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not negotiate, interpret or draft contracts, or tell you whether a clause is enforceable. That is counsel's work.
• It does not guarantee a patch timeline. When upstream has no fix it can rank, gate, record a mitigation and, if you choose, help with fork and patch, but your contract still needs the no-fix path you wrote.
• It does not keep a register of promises you make to customers. Third-Party Risk Manager (GA) tracks your own vendors' contracts and SLAs, not your customer commitments. Keep that register yourself.
• It does not decide that a customer is affected or send contractual notice for you. Trust Center updates reach subscribers and named contacts where switched on; whether that meets a clause depends on its channel and timing.
• It does not sign "not affected" statements. A named person on your team approves and owns each one.
• The Trust Center shows only what you publish, and an In progress or Not assessed status means exactly that. It does not turn a self-assessment into an audit opinion.
• It does not fill every SBOM field. Producer or license can be unknown in source metadata, and the Portal check in the docs is based on NTIA fields, not the 2026 list.

Common mistakes

• Letting the clock start at public disclosure, and inheriting every day upstream needs.
• Signing an undefined "Critical". The dispute arrives during the first incident.
• Promising an SBOM per SaaS deploy. Offer the runtime production SBOM on request, as M-26-05 describes.
• Negotiating with the median. Breaches happen at the 90th percentile.
• Treating vulnerability notice like incident notice. Different events, different windows, different channels.
• Issuing "not affected" from a scanner result without review. The VEX profile and the customer's auditor both expect a justification.
• Copying BOD 22-01's KEV dates. It is revoked; BOD 26-04 uses a risk-based table.
• Letting Sales sign the security exhibit alone, or skipping the register afterwards.

FAQ

What security terms can a software vendor safely agree to in a customer addendum?

Terms you already meet with margin over the last 90 days and can evidence on request: usually SBOM delivery in a named format on request, remediation windows that start when a fix is available, notice of confirmed impact to a named contact, and annual independent reports.

How do I push back on a 15 day critical patch SLA?

Fix the definitions before the number: what counts as critical, when the clock starts, and what happens with no fix. Many vendors can meet 15 days from fix availability for a defined critical set but not 15 days from disclosure.

What should an SBOM clause in a SaaS contract say?

Format (SPDX or CycloneDX), scope (the runtime production environment), cadence (on request with a cap), delivery window, channel, and the minimum elements followed. OMB M-26-05's cloud footnote supports that scope.

Does HIPAA require a software vendor to patch within a set number of days?

45 CFR 164.314 requires Security Rule compliance, subcontractor flow-down and incident reporting in the business associate contract. Fixed patch windows are contract terms. Breach notification has a 60 calendar day outer limit under 164.410.

What is the difference between a vulnerability notice and a VEX statement?

A notice says you are affected and what is being done. A VEX statement says whether each product is affected, not affected, fixed or under investigation, with a reason for any not affected status.

Should we agree to a customer's right to audit?

Usually, with limits on frequency, notice, scope, confidentiality and cost. Bank customers follow interagency guidance that expects audit rights.

What does the CISA 2026 SBOM minimum elements change for vendors?

It replaces the 2021 NTIA list, adds fields such as component hash, license, generation context and tool name, expects an SBOM per version or update, and asks authors to mark unknown or withheld data.

How do I keep track of security commitments across many customer contracts?

An obligations register, one row per promise per customer, with definitions, metric, owner, evidence and review date, recomputed monthly.

Can a tool guarantee we meet a contractual patch SLA?

No. Tools measure, prioritise, gate and open fix pull requests; meeting the clause depends on upstream fixes, your deploy process and your people.

Every addendum in this guide eventually comes down to one question: how fast can you make a vulnerable component stop shipping once you know about it. The section below is how Safeguard shortens that time, including when upstream has no fix, which is the case your no-fix clause is written for.

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 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

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, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

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

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. For an addendum, that is how you would ask, in plain language, which critical or KEV-listed findings are open in production and how long each has been open, to test a clause before you sign it.

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

The second demo is a real Safeguard CLI session: install, open the interactive terminal, ask it to fix a lodash CVE in a repository, and watch it read the finding and advisory, ask before any command that changes something, edit package.json to lodash 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. It then shows /permissions, /model and /scan. That is the same path that shortens your time from fix available to fix merged, which is the number your patch clause measures.

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

Quick check

Sources

• OCC Bulletin 2023-17, Third-Party Relationships: Interagency Guidance on Risk Management, 6 June 2023
• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920, 9 June 2023 (govinfo PDF)
• 23 NYCRR 500.11, Third-party service provider security policy (Cornell LII text)
• 45 CFR 164.314, Organizational requirements (eCFR)
• 45 CFR 164.410, Notification by a business associate (eCFR)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), 29 July 2026
• CISA, 2026 Minimum Elements for a Software Bill of Materials (PDF)
• OMB Memorandum M-26-05, 23 January 2026
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 10 June 2026
• CISA, Known Exploited Vulnerabilities Catalog
• OASIS, Common Security Advisory Framework Version 2.0, OASIS Standard, 18 November 2022
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• Safeguard docs, Generate SBOM
• Safeguard docs, CLI usage
• Safeguard docs, Policies and Gates
• Safeguard docs, Policy outcomes and actions
• Safeguard docs, Mitigations
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, Portal: My Products
• Safeguard docs, Portal: Sharing
• Safeguard docs, Portal: Audit Trails
• Safeguard docs, Portal: Compliance
• Safeguard docs, Trust Center setup
• Safeguard docs, Trust Center access requests

Get started with the Safeguard download page or read the Safeguard docs.

Related reading: contract clauses banks expect from software vendors, how to define a critical vulnerability in a patch SLA clause, keeping a contract promise of no known exploited vulnerabilities and what to say when a customer asks for a fresh SBOM at renewal.

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