Open Source License and SBOM Clauses: A General Counsel's Guide

When a contract touches open source, three clauses do most of the work: the license representation (what the vendor promises about the third party code inside the product), the SBOM clause (what inventory is delivered, in what format, how often and to whom), and the vulnerability clause (what counts as a known vulnerability, how fast it is fixed and how the customer hears about it). Review each one against what the engineering team can actually evidence on the day of signature, and draft every promise so it can be checked with a document rather than argued about later.

This guide is for general, product and commercial counsel who see these clauses on both the sell side and the buy side. It is not legal advice. It explains how the clauses usually work, what the primary sources say, and how to tie each promise to evidence; your facts, jurisdiction and outside counsel decide the rest.

Key takeaways

• Open source licenses are conditional permissions, not passive disclaimers. MIT asks for a notice, Apache 2.0 asks for notices and a NOTICE file, GPL family licenses can ask for source code, and the AGPL extends that to users who reach the software over a network. A contract that ignores those conditions creates exposure no warranty disclaimer fixes.
• CISA's 2026 Minimum Elements for an SBOM (29 July 2026) added a Component License field and told organisations to deal with SBOM practices in any policy, contract or arrangement to ask for or provide SBOMs. It creates no new legal requirement by itself; your contract does.
• OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16 for federal agencies and lets each agency choose whether to require a current SBOM upon request. For federal sellers, the SBOM obligation now lives in each agency's contract terms rather than one government wide form.
• The safest clauses are the ones that name a format (SPDX or CycloneDX), a trigger (each release and on request), a coverage standard (all components, including transitive ones), a way to mark unknowns, and a confidentiality and access model.
• Vulnerability clauses should define "known vulnerability", separate "affected" from "present", allow a VEX statement as the answer, and tie remediation windows to severity and exploitation status rather than a single number of days.
• Safeguard maps to this work through SBOM generation and analysis (GA), license compliance with attribution notice export (GA), policies and gates (GA), the Compliance suite's License Obligations framework (GA), Portal SBOM sharing (GA), TPRM SBOM requests (GA), CSAF and VEX upload (GA) and the Trust Center (GA). Autonomous remediation (GA) ships switched off, with every category set to Manual.
• What stays with you: deciding what to promise, negotiating caps and indemnities, interpreting a license against your distribution model, and signing.

The situation

The trigger looks ordinary. A large customer returns your subscription agreement with a new "Software Supply Chain Security Requirements" exhibit. Your security team asks legal to add "SBOM on request" to every vendor renewal. Or a prospect wants a "no copyleft software" representation and an uncapped open source indemnity, and sales wants the redline back by Friday.

The question lands on counsel because the words are legal even though the facts are technical: promises about thousands of components no one in legal has seen, maintained by people who are not party to the contract.

A bad week looks like this:

• The company signs a representation that "all open source components are used in compliance with their licenses" without a current inventory. Six months later a customer's scan finds an AGPL licensed library in the hosted product and asks for the corresponding source or a cure plan.
• The company agrees to deliver an SBOM "within 10 days of request" without saying for which version, in which format, with what coverage, or under what confidentiality terms. The first request arrives for a version that shipped two years ago.
• The company accepts "remediate all known vulnerabilities within 30 days" and later finds the product's dependency tree carries many published CVEs at any given time, a large share of them in code the product never calls. The clause is breached on the day it is signed.
• On the buy side, the company receives a PDF listing only top level packages, with no contractual right to anything better.

None of these is exotic. Each comes from drafting about software nobody measured. The fix is to draft from evidence and make the evidence part of the contract.

The rules and standards behind these clauses

There is no single US statute that tells private companies what to promise about open source in a commercial contract. The obligations come from three places: the licenses themselves, government purchasing policy for those who sell to government, and voluntary standards that buyers increasingly write into contracts. Here is what each primary source actually says.

The licenses are the first set of obligations

Every open source license on the SPDX License List grants permission subject to conditions. The Open Source Definition maintained by the Open Source Initiative sets out what a license must allow to be called open source, including free redistribution, access to source code and no discrimination against fields of endeavour. It does not mean "no conditions". The conditions are where contracts go wrong.

The texts below come from the SPDX license pages. Read the full text before relying on any summary, including this one.

• MIT. The permission notice and copyright notice "shall be included in all copies or substantial portions of the Software", per the MIT text on SPDX. The obligation is attribution. It travels with every copy you distribute, including inside a mobile app or an appliance.
• Apache 2.0. Section 4 sets redistribution conditions: give recipients a copy of the license, mark modified files, keep copyright and attribution notices, and, where the work includes a NOTICE file, include "a readable copy of the attribution notices" from it, per the Apache 2.0 text on SPDX. Section 3 grants a patent license that terminates for anyone who starts patent litigation claiming the work infringes.
• GPL 2.0. Section 3 conditions distribution of object code on providing the corresponding source, either alongside the binary or by a written offer "valid for at least three years", per the GPL 2.0 text on SPDX. The same license says mere aggregation of a separate work on the same medium does not bring that work under the GPL.
• GPL 3.0. Section 6 adds Installation Information for User Products, which matters for devices. Section 8 makes termination automatic on violation but restores rights if you cure "prior to 30 days after your receipt of the notice" for a first notice from that copyright holder, per the GPL 3.0 text on SPDX. That cure mechanism is a useful anchor when you draft your own cure periods.
• AGPL 3.0. Section 13 requires that a modified version offer users interacting with it remotely over a network "an opportunity to receive the Corresponding Source of your version", per the AGPL 3.0 text on SPDX. This is the clause that turns a SaaS deployment into a source disclosure question.
• LGPL 2.1. Section 6 lets you combine a work with the library and distribute it under terms of your choice, provided those terms permit modification for the customer's own use and "reverse engineering for debugging such modifications", per the LGPL 2.1 text on SPDX. Read that next to your own end user license agreement's ban on reverse engineering. The two can collide.
• MPL 2.0. File level copyleft. Section 3.2 conditions distribution of the Executable Form on making the Source Code Form of covered files available, while Section 3.3 lets you distribute a Larger Work under your own terms, per the MPL 2.0 text on SPDX.

Each of these licenses also disclaims warranties and limits the author's liability. So whatever you promise your customer about open source, you promise on your own account.

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 updates and replaces the NTIA minimum elements from 2021, which are now history. Four points matter to counsel.

1. License is now a minimum element. The new Component License field captures the identifiers for the licenses under which a component is available, ideally as SPDX license identifiers, and says the field should flag proprietary license conditions and state when the license is unknown. A buyer citing the 2026 baseline can therefore ask for license data in the SBOM itself, not in a separate spreadsheet.
2. Practices belong in the contract. The document says organisations should explicitly address its practices "in any policy, contract, or arrangement to ask for or provide SBOMs". Those practices include Frequency (a new SBOM for each version or update, and a revised one when errors are found), Coverage (all components including transitive dependencies, with no minimum depth), Distribution and Delivery (prompt availability to those who need it, with access controls that should not block sharing between authorised parties), Explicitly Identifying Unknown Information (say whether data is unknown or withheld), Machine-Processable Data and Accommodation of Updates.
3. It creates no new requirement by itself. The guidance states that the minimum elements do not create new requirements, and its disclaimer says it is not advice for compliance, regulatory or legal purposes. The obligation exists only when a contract, a regulation or a purchasing policy adopts it.
4. New integrity fields. SBOM Author, SBOM Author Signature, Component Producer (which replaces the old Supplier Name), Component Hash Value and Algorithm, and SBOM Generation Context are now in the baseline. A contract can ask for them; a vendor can say which it cannot supply yet.

OMB M-26-05 for federal buyers and sellers

OMB M-26-05, dated 23 January 2026, rescinded M-22-18 and its companion M-23-16. Federal agencies are no longer directed to collect the Secure Software Development Attestation Form from every producer, though they may still use it. The memo keeps two things that matter for contracts:

• Agencies must continue to maintain a complete inventory of software and hardware.
• Agencies may adopt contractual terms that require a producer to "provide a current software bill of materials (SBOM) upon request". For a cloud platform, the memo's footnote says such a term should cover an SBOM of the runtime production environment.

For federal sellers, SBOM obligations will now vary by agency and contract rather than arrive through one standard form.

NIST SP 800-218, the Secure Software Development Framework

NIST SP 800-218 remains the reference most buyers cite for secure development. Three practices map directly to contract clauses:

• PS.3.2 asks producers to collect, safeguard, maintain and share provenance data for all components of each release, giving an SBOM as the example.
• PW.4.1 asks producers to acquire and maintain well secured third party components, including reviewing them in the context of their expected use.
• RV.1.3 asks for a policy on vulnerability disclosure and remediation, with the roles and processes to support it.

When a customer asks you to "comply with the SSDF", narrow the clause to the practices you can evidence.

ISO/IEC 5230 and 18974 (OpenChain)

The OpenChain Project maintains ISO/IEC 5230 (license compliance programmes) and ISO/IEC 18974 (open source security assurance), with free self certification checklists. Treat conformance as process evidence, not a promise about any specific component.

Machine readable formats and VEX

SBOM clauses usually name SPDX (published as ISO/IEC 5962) or CycloneDX. For vulnerability status, CycloneDX VEX and CSAF VEX let a producer state whether a vulnerability is exploitable in a specific product. A vulnerability clause that accepts a VEX statement as a valid response gives both parties a way to close an issue without a code change when the vulnerable code is not used.

The EU as context

CISA's guidance notes that the EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to include an SBOM in their technical documentation. Expect European customers to flow that down; handle it with EU counsel.

Which seat are you in?

Most legal teams sit on both sides of these clauses each quarter, and the drafting goal flips with the seat.

Step by step: reviewing the clauses, with or without Safeguard

This is the order that works for most legal teams. None of it needs any particular tool.

1. Find out what the product actually contains

Before you redline anything, ask engineering for a current SBOM of the exact product and version in scope, with license data. If none exists, that is your first finding. Ask three follow ups:

• Does it cover transitive dependencies, or only the packages the developers named directly?
• Does it cover what ships to the customer (the mobile app, the installer, the container image), or only the source repository?
• How many components have an unknown license, and why?

An illustrative example with round, invented numbers: a product with 50 direct dependencies might carry 800 components once transitive packages are counted. If 40 of those have no identified license, any representation that "all components are properly licensed" is a guess about those 40.

2. Map each license category to your distribution model

The same license can be harmless in one model and decisive in another. Build the map with your engineers.

"Usually" carries real weight in that table. Whether something is distributed, conveyed, a derivative work or mere aggregation turns on facts and on the license text. That is the analysis counsel owns.

3. Draft the license representation from the inventory

A representation that rests on a dated inventory is easier to give and easier to defend. The issues list below is what most negotiated versions end up covering. It is a checklist, not model language.

• Scope. Which product, which versions, and whether it covers hosted services, delivered software or both.
• Standard. "In compliance with the license terms applicable to the manner in which we distribute or make available the product", rather than an absolute statement about every component's license.
• Knowledge and materiality. Whether the representation is to the vendor's knowledge, and whether it covers material non compliance only.
• Prohibited licenses. A named list tied to the customer's use. "No open source" is unworkable; "no copyleft" is usually overbroad.
• Remedy. Replace, re-license or remove the component within a cure period, before damages or termination rights apply. GPL 3.0's own 30 day cure after first notice is a sensible reference point for the period.
• Evidence. The SBOM and attribution notices delivered on a stated schedule are the evidence that the representation was true when made.

4. Draft the SBOM clause around the 2026 practices

Use CISA's practices as the checklist, because both sides can point to the same public document.

5. Draft the vulnerability clause so it can be met

The common failure is a clause that defines success as "no known vulnerabilities", a state most products with a real dependency tree never reach. A clause that can be met tends to cover:

• Definitions. "Known vulnerability" means a vulnerability with a published identifier affecting a component in the version the customer runs. "Affected" means exploitable in that product as shipped or configured. Keep "present" and "affected" apart.
• Notice. Notice of affected vulnerabilities above a stated severity, or listed in CISA's Known Exploited Vulnerabilities catalog, within a stated window after the vendor confirms impact.
• Response. A VEX statement is an acceptable response when the vendor determines the product is not affected, with a short justification.
• Remediation windows. Tiers by severity and exploitation status. Start the clock at the later of confirmation and the availability of an upstream fix, and require interim mitigations where no fix exists.
• Disclosure policy. A published vulnerability disclosure policy and contact, which is what SSDF RV.1.3 asks for.
• Evidence. Monthly or quarterly status of open affected vulnerabilities for the customer's version.

6. Decide your position on indemnity

Open source indemnities are often the hardest point. The licenses give the vendor no upstream indemnity, so whatever is offered comes from the vendor's own balance sheet. Common positions fold open source into the general IP indemnity with the usual exclusions (customer modifications, combinations, use outside documentation), add a right to replace or modify the component, and cap exposure. Counsel decides the posture; the inventory tells you how much you are betting.

7. Build the evidence pack before you sign

For each deal, assemble what proves the promises at signature:

• The SBOM for the contracted version, with license data and a date.
• The attribution notice file shipped with the product.
• The license policy the engineering team enforces, with its allowed, blocked and review lists.
• The exception log: which license or vulnerability exceptions exist, who approved them, and when they expire.
• The vulnerability disclosure policy and the last quarter's remediation record.

Keep the pack with the contract, so a question a year later is answered from the file.

8. Run the buy side the same way

As the customer, ask vendors for the same pack and score what comes back: format, coverage, license data, unknowns marked, version match, signature. Reject documents no tool can read, and track due dates.

The questions counsel actually asks

What should an open source license representation actually say?

It should say what the vendor can prove. That usually means compliance with license terms as they apply to how the product is distributed or made available, tied to an SBOM for a named version, with a list of prohibited licenses relevant to the customer, and a cure and replace remedy before damages. Absolute statements ("all components are properly licensed", "the product contains no open source") are rarely true and rarely needed. A buyer who wants assurance is usually better served by the delivered SBOM and attribution notices than by a broader representation.

Is "no copyleft" a reasonable ask?

Usually not, as written. Copyleft covers everything from MPL's file level obligations to AGPL's network clause, and many products depend on LGPL or MPL libraries at a level that creates no meaningful obligation for the customer. A narrower ask works better: no AGPL in components the customer receives or in hosted services that are modified, no GPL in delivered SDKs the customer will embed, and disclosure of any LGPL or MPL component in delivered software with the relinking and source terms that apply.

How does the AGPL change a SaaS contract?

AGPL 3.0 Section 13 applies when a modified version is offered to users over a network. A SaaS vendor that runs an unmodified AGPL component as a separate service is in a different position from one that modified an AGPL component and exposes it to users. Ask engineering which applies. A SaaS contract may reasonably include a representation that no modified AGPL component is exposed to customer users, because that is checkable. For more on this one clause, see AGPL's network clause and what it means for SaaS.

What makes an SBOM clause enforceable in practice?

Specificity about version, format, coverage, unknowns and timing. "Vendor will provide an SBOM on request" is enforceable in theory and useless in practice, because a 40 line PDF satisfies it. Write the 2026 practices into the clause, and say what happens when a delivered SBOM fails validation: a revised SBOM within a stated period.

How should we handle SBOMs for SaaS?

Say what is covered. M-26-05's footnote asks federal agencies that adopt SBOM terms for cloud platforms to specify an SBOM of the runtime production environment. CISA notes that SaaS may need additional elements and that delivery frequency may need more specification because hosted software changes often. A reasonable clause covers the customer facing application and its runtime images, delivered on request rather than at every deployment.

Do we need to flow these terms down to our own suppliers?

If you promise your customers coverage of components you buy, you need matching rights from the suppliers who provide them. Flow down what you need to perform: SBOMs for components you redistribute, notice of exploitable vulnerabilities, and license information. Do not promise customers coverage of a subcontractor's software you have no right to inspect.

Does any of this matter in an acquisition?

Yes. License findings in diligence often become specific indemnities. See open source license risk in M&A due diligence and cybersecurity reps and warranties myths.

How Safeguard does this

Everything above works with a spreadsheet and patient engineers. Safeguard's job is to produce the evidence each clause rests on and keep it current. The steps below come from docs.safeguard.sh; where the docs show no screen or command, the step describes the outcome only.

1. Build the inventory for each release. SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs for repositories, container images and uploaded SBOM files, with software composition analysis and deep transitive dependency scanning (GA). Each project's SBOM view includes a Suppliers and Licenses tab with component level license and supplier data. The CLI (GA) command safeguard scan builds an SBOM and matches it against vulnerability databases, and the license compliance docs say it writes a license.json with the licenses it found.

2. Identify every license, and flag the ones that disagree. License compliance (GA) reads licenses from package metadata, SPDX identifiers, full text matching of LICENSE, COPYING and NOTICE files, source headers and, in container layers, the copyright files packaged with the operating system. When those signals disagree (for example a package manifest says MIT but the license file says AGPL), Safeguard raises a license discrepancy finding. For counsel, that finding is often the most valuable output: it is where the license data in an SBOM is most likely to be wrong.

3. Classify by obligation, not by name. Each license is classified as permissive, weak copyleft, strong copyleft, network copyleft, commercial, public domain or unknown, with explanations of obligations such as attribution, source disclosure and patent grants. SPDX expressions are parsed, including dual licensing (MIT OR Apache-2.0) and exceptions. Unknown licenses are flagged for review, which gives you the count your representation depends on.

4. Turn the prohibited license list into an enforced policy. License policies sort licenses into allowed, blocked and review lists, scoped to the organisation or a project, and can differ by context (for example a policy for a delivered SDK and another for a hosted service). Policies, gates and guardrails (GA) enforce them in CI, at pull request time and at deployment. Each policy's action on a gate is Block, Warn or Notify. When a team needs to ship with a listed license anyway, approval runs through the exceptions workflow, which records a named approver, a business justification and an expiry date, and keeps an audit trail. That exception log is the evidence a buyer's audit clause will ask for.

5. Produce the attribution notice. From a project's Suppliers and Licenses tab, Export, then Attribution Notice, produces a notice file in TXT, HTML or Markdown with component names, versions, license types, copyright notices, license text where required and supplier information. The docs note there is no CLI command for generating attribution files yet. Licenses dashboards export per asset license manifests as Excel, CSV, SPDX or CycloneDX.

6. Check your programme against a license obligations framework. The Compliance and GRC suite (GA) includes a License Obligations framework whose scan requirements check license identification, a complete open source inventory, attribution data completeness, copyright holder data, exact versions for source disclosure and a machine readable license manifest, citing ISO/IEC 5230 and ISO/IEC 5962. Its control catalogue covers attribution, source disclosure, copyleft boundaries, patent grants, license compatibility, commercial licenses and unknown or NOASSERTION licenses, with policy templates for license obligation compliance and distribution clearance. Use it as an internal readiness view, not as a legal opinion.

7. Share SBOMs under the contract's confidentiality terms. Portal (GA, here meaning the SBOM publish and share product, not the free entry tier) shares SBOMs with named recipients at View, Download or Full permission, or by links with expiry dates, download limits and password protection. Organisation settings can restrict sharing to approved domains and require authentication, and individual SBOMs can require NDA acceptance. Access can be revoked immediately, and the docs list access and download history for every share. That maps cleanly onto a clause that treats SBOMs as Confidential Information shared through access controlled delivery.

8. Collect SBOMs from your own vendors. Third Party Risk Manager, TPRM (GA), sends single or bulk SBOM requests with templates that state the formats you accept (SPDX, CycloneDX) and the required fields, sets deadlines, sends automatic reminders before and at the deadline with escalation after it, and tracks status from Sent through Submitted to Validated or Rejected. Each submission is validated for format and completeness and scanned for vulnerabilities, and a failed submission can be sent back with Request Revision. The license compliance docs add that the same license classification runs on a vendor's SBOM, flags components that trip your blocked list, and shows whether the license set changed between versions, which is a signal of unexpected relicensing.

9. Accept VEX as an answer. CSAF and VEX upload (GA) imports CSAF 2.0 advisories and VEX documents in CycloneDX, OpenVEX and CSAF VEX profiles, under Integrations, filtered by Upload. Vendors' "not affected" statements can then sit against your inventory. On your own products, vulnerability management (GA) with EPSS and CISA KEV enrichment and reachability analysis (GA) helps engineering separate present from affected before a notice obligation starts.

10. Publish the evidence once, release it under NDA. The Trust Center (GA), managed on Compliance › Trust Center, lets you list documents by category (including Questionnaire, Policy and Security) as Public or Restricted. Restricted documents are released only through approved access requests, which leave an audit trail. Where security contacts are switched on, the people your customers name can receive published updates and security advisories by email. For a buyer's evidence clause, that turns "send us your SBOM and policies each year" into a link and an approval.

11. Fix what the contract makes urgent. When a license finding forces a component swap or a vulnerability window is running, autonomous remediation (GA) can open fix pull requests for dependencies and licenses, among other categories. It ships switched off, with every category set to Manual, so engineering decides what runs automatically.

12. Ask questions in plain English. The Safeguard MCP server (GA) lets an AI assistant such as Claude query projects, vulnerabilities and findings in your account once you connect it and choose which tools it may use. Check every answer against the underlying record before it goes into a contract.

Clause to evidence map

What Safeguard does not do

• It does not give legal opinions. License classification and the License Obligations framework describe obligation categories. Whether your use is a distribution, a derivative work or mere aggregation, and whether a clause is enforceable in your jurisdiction, is legal analysis that stays with counsel.
• It does not see code it is not given. Coverage depends on the repositories, images and SBOMs connected or uploaded. Vendored code copied into a repository without a manifest, binaries from outside sources and hosted services you do not control can be missed or show as unknown. CISA's guidance itself says an SBOM recipient should be able to rely on Coverage; your SBOM is only as complete as what was scanned.
• It does not decide what an upstream author meant, or what you should promise. It can flag a license discrepancy, not resolve which license the copyright holder intended. Caps, indemnities, cure periods and what to promise belong to the parties.
• It does not generate attribution files from the CLI yet. The docs say there is no CLI command for attribution generation or license reports today; use the web export.
• It does not fix vendor software. For a commercial vendor's product, Safeguard can request and analyse the SBOM and record their VEX statements. The fix still comes from the vendor, under your contract.
• It does not replace your vulnerability disclosure process. Notices to customers, regulators or the public are your decisions and your words.

Common mistakes

• Signing a representation without an inventory. The most common error, and the hardest to unwind. If there is no SBOM for the version in scope, qualify the representation or get the SBOM first.
• Treating "open source" as one category. MIT and AGPL have almost nothing in common for a SaaS company. Clauses that lump them together are either too loose for the buyer or impossible for the vendor.
• Forgetting the delivered pieces of a hosted product. A mobile app, browser extension, on premises agent or CLI is distributed software, and notice duties apply.
• Accepting "remediate all known vulnerabilities" with a single window. Without definitions and tiers it is breached on signature.
• Asking for an SBOM without saying which version. Version mismatch is where SBOM disputes start.
• Ignoring the conflict between an EULA reverse engineering ban and LGPL 2.1 Section 6. If you ship LGPL libraries linked into a product, check your license terms permit what Section 6 requires.
• Letting SBOMs leak through ordinary email. Treat them as Confidential Information, share through access controlled delivery, and keep a record of who received which version.
• Citing retired documents. The 2021 NTIA minimum elements are replaced by CISA's 2026 Minimum Elements, and M-22-18 was rescinded by M-26-05. Update templates that still cite either as current.

FAQ

Do open source licenses require us to give customers an SBOM?

No common open source license requires an SBOM. They require notices, license copies and, for copyleft licenses, source code in some cases. SBOM duties come from contracts, purchasing policies and some sector or regional rules. An SBOM with license data is, however, the most practical way to show you met the license conditions.

Does CISA's 2026 SBOM guidance make SBOMs mandatory?

No. CISA states the minimum elements do not create new requirements. They become binding when a contract, a regulation or an agency's purchasing policy adopts them.

Can a federal agency still require an SBOM after M-26-05?

Yes. M-26-05 says agencies may adopt contractual terms requiring a producer to provide a current SBOM upon request, and for cloud platforms an SBOM of the runtime production environment.

What license data should an SBOM contain?

Under CISA's 2026 Component License element, the identifiers of the licenses under which each component is available, ideally SPDX license identifiers, an indication of any proprietary license conditions, and an explicit statement when the license is unknown.

How often should an SBOM be updated under a contract?

CISA's Frequency practice says each version or update should have an SBOM, with a revised one when errors are found. Contracts often narrow delivery to major releases plus on request to keep the volume workable, especially for SaaS.

Who should own SBOM requests, legal or security?

Both. Legal owns the contractual right, the deadline and the confidentiality terms; security owns validating what arrives and acting on it. Agree the handoff before the first request goes out.

What is a VEX statement and why put it in a contract?

VEX is a machine readable statement of whether a vulnerability affects a specific product. Accepting VEX as a valid response lets a vendor close a "known vulnerability" question without a code change when the vulnerable code is not used, and gives the buyer a record of the reasoning.

Is an OpenChain ISO/IEC 5230 conformance enough for a license representation?

It shows a license compliance programme exists. It does not prove that a specific product version's components are in compliance. Use it alongside a version specific SBOM, not instead of one.

The two practices that make a contract's open source promises survivable are evidence before signature and remediation after it. The second half matters because license findings and vulnerability windows usually end in a component change, and the faster engineering can make that change safely, the less any clause will ever be tested.

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

Counsel will mostly meet Safeguard through questions, not consoles. This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. The same connection lets someone on the legal team ask which products in a contract's scope carry a given license or vulnerability, then check the answer against the record.

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

When a vulnerability clause starts a clock, engineering has to make the change. This is a real CLI session: the developer asks the assistant to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That approval at each changing step is the kind of control a remediation clause assumes exists.

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

Some customers' contracts restrict where source code can be sent. This demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal, which is the route for teams that want scanning close to the code.

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

Quick check

Sources

• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), landing page
• CISA, 2026 Minimum Elements for a Software Bill of Materials (PDF)
• CISA bulletin announcing the 2026 Minimum Elements
• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• NIST SP 800-218, Secure Software Development Framework
• SPDX License List
• SPDX, MIT License
• SPDX, Apache License 2.0
• SPDX, GNU General Public License v2.0 only
• SPDX, GNU General Public License v3.0 only
• SPDX, GNU Affero General Public License v3.0 only
• SPDX, GNU Lesser General Public License v2.1 only
• SPDX, Mozilla Public License 2.0
• SPDX specifications
• Open Source Initiative, The Open Source Definition
• Open Source Initiative, Licenses
• OpenChain Project, ISO/IEC 5230 and ISO/IEC 18974
• CycloneDX, Vulnerability Exploitability eXchange
• Safeguard docs, License Compliance
• Safeguard docs, Suppliers and Licenses
• Safeguard docs, License Obligations framework
• Safeguard docs, Policies and Gates
• Safeguard docs, Portal Sharing
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, CSAF and VEX Upload
• Safeguard docs, Trust Center
• Safeguard docs, CLI

Related reading: a legal risk assessment template for the software supply chain, an SBOM driven vendor onboarding blueprint, what license contamination means and blocking AGPL at the pull request.

To see the evidence behind your own clauses, download Safeguard at https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs .

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