Answer an OEM Partner's Open Source Disclosure and License Warranty

Before an OEM partner embeds and redistributes your software, it will usually expect a list of every open source component you ship, the license of each (ideally as SPDX identifiers), the compliance artifacts those licenses require (notices, license texts, and source or a written offer where copyleft applies), the known vulnerability status of those components, and a commitment to keep it all current. The contract then asks you to warrant the disclosure and often to indemnify the partner. The safest answer is to produce the package from data for every release, and to promise only what that data supports.

This post is for product counsel, open source program office (OSPO) leads and product security leads at US software vendors who license a product to an OEM, reseller or platform that ships it inside its own offering. It covers what these agreements typically ask for, what OpenChain ISO/IEC 5230 and ISO/IEC 18974 expect a program to produce, which license terms travel downstream, how to format the disclosure, and how Safeguard handles the data side. This is general information, not legal advice. Your obligations come from the license texts and the contract you sign, and your counsel decides what you can promise.

Key takeaways

• When an OEM ships your binary, it becomes a distributor of every open source component inside it, so it needs your component list and compliance artifacts to meet its own obligations.
• OpenChain ISO/IEC 5230:2020 expects a bill of materials with identified licenses (clause 3.3.1), an obligations review (3.1.5), and compliance artifacts created and archived for supplied software (3.4.1). ISO/IEC 18974:2023 adds a per component record of known vulnerabilities and the action taken (4.3.2).
• Obligations that reach a redistributing partner include notices and license texts (MIT, Apache-2.0 section 4), source for weak copyleft files (MPL-2.0 section 3.2, LGPL-2.1 section 6), and full source or a written offer for strong copyleft (GPL-2.0 section 3, GPL-3.0 section 6).
• Express licenses as SPDX identifiers and expressions, mark unknowns explicitly, and include the Component License field that CISA's 2026 Minimum Elements for an SBOM added on 29 July 2026.
• Put vulnerability status next to licenses, with VEX for "not affected" decisions, and agree a per release update mechanism so the disclosure refreshes without renegotiation.
• Safeguard covers the data side: license compliance with copyleft categories and attribution generation (GA), the License Obligations policy and OpenChain ISO 5230 framework in the compliance and GRC suite (GA), SBOM generation and analysis in SPDX and CycloneDX (GA), software composition analysis and vulnerability management with EPSS and CISA KEV (GA), reachability analysis (GA), policies and gates (GA), CSAF and VEX upload (GA), Portal as the SBOM publish and share product (GA), the CLI (GA), the MCP server (GA) and autonomous remediation (GA, ships switched off). Trust Center and fork and patch are generally available.
• Safeguard does not give legal advice, draft warranties or indemnities, or generate written source offers.

Why an OEM deal turns your license compliance into the partner's risk

A SaaS subscription keeps most of your open source on your servers. An OEM license sends it out. The partner embeds your SDK, agent, library or on-premises server in its product and ships it to its customers. Shipping is distribution, and most open source licenses attach their conditions to distribution.

So the risk moves. If a GPL-2.0 component shipped without source or a written offer, the partner is the one that distributed object code to its users without meeting section 3. If your build dropped an Apache-2.0 NOTICE file, the partner's product now ships without the notices section 4(d) asks for. The partner did not pick those components and cannot see your build, so it asks you to say what is inside, supply the artifacts, and stand behind the answer in the contract.

There is a security layer too. A partner that ships your component inherits its known vulnerabilities, and the partner's own customers will ask it for an SBOM. CISA's 2026 Minimum Elements for an SBOM, released by CISA, NSA, FBI and international partners, replaced the 2021 NTIA minimum elements and now lists Component License as a baseline field. One disclosure increasingly serves both license compliance and vulnerability management.

What OEM and reseller agreements typically ask for on open source

Every agreement differs and nothing here is a template. The open source section usually asks for some mix of the following, and knowing the shape lets you prepare evidence instead of arguing wording.

A disclosure schedule

An exhibit listing the open source in the licensed product: name, version, supplier, license and whether it was modified. Some partners ask how each component is linked or used, because that affects copyleft analysis. Many now want it as a machine readable SBOM. A schedule typed by hand at signature goes stale with the next release; one generated from an SBOM can be regenerated and compared.

Compliance artifacts with each delivery

The notices file, license texts, NOTICE contents, and for copyleft components the source or a way to get it. OpenChain ISO/IEC 5230 calls these "compliance artifacts" and lists attribution notices, source code, build and install scripts, license copies, copyright notices, modification notices, written offers, the bill of materials and SPDX documents as typical members.

A license warranty

Buyers commonly ask for some version of four statements: the disclosure is complete and accurate at delivery; you complied with the licenses of what you included; no component would require the partner to release or license its own proprietary code when it distributes as planned; and you will say if any of this changes. These are different promises. The first is about your inventory, the second about your past conduct, the third a legal conclusion about a product you cannot see, and the fourth an ongoing duty. We separate the evidence for each below.

An indemnity

Often paired with the warranty: if a third party claims the partner's distribution breached an open source license because of your component, you defend and cover the partner. Scope, caps and carve-outs for the partner's own changes are for counsel. Engineering controls how likely a claim is and how fast you can show what shipped.

An update duty and inquiry rights

An updated disclosure with each release, notice of material changes such as a new copyleft component, notice of serious vulnerabilities within an agreed time, and sometimes a right to request evidence of your process. The update duty is the clause you will live with weekly, so shape it early.

What OpenChain ISO/IEC 5230 says a compliance program must be able to produce

OpenChain ISO/IEC 5230:2020 is the international standard for open source license compliance programs. The OpenChain Project says its version and the ISO version are functionally identical. The standard does not say which licenses are acceptable. It says which processes must exist and which records prove they ran, which is what an OEM partner wants to see.

Two details matter in negotiation. Clause 3.3.2 lists binary distribution and modified open source among the use cases a program must handle, and an OEM delivery is often both. Clause 3.4.1.2 ties the archive period to domain, jurisdiction or customer contracts, or the license requirement if longer, so your OEM agreement can and should set it.

Conformance comes through self-certification or independent assessment. Either way, what a partner can use is the records: the bill of materials per release, the obligations review, the artifacts and the archive.

How ISO/IEC 18974 adds security assurance

ISO/IEC 18974:2023 applies the same OpenChain program structure to security. The OpenChain Project describes it as helping organizations check open source for known vulnerabilities. Three clauses map to OEM asks:

• 4.1.5 Standard practice implementation. Documented methods to detect known vulnerabilities, follow up on them, communicate them to customers when warranted, analyze released software for newly published vulnerabilities, and export risk information to third parties as appropriate.
• 4.3.1 Software bill of materials. A procedure that continuously records all open source in the supplied software across its lifecycle, with an archive.
• 4.3.2 Security assurance. For each component, detect known vulnerabilities, assign a risk or impact score, document the remediation or mitigation, and keep a record of the action taken "including even if no action was required."

That record is the basis for a vulnerability status column and for documented "not affected" decisions. The clause also expects monitoring after release, which maps to the contract's update duty. Like 5230, conformance lasts 18 months (clause 4.4.2).

Which licenses create obligations for the partner when it redistributes

Obligations come only from the license texts. The summaries below describe what each text says about distribution, from the SPDX License List copies and the publishers' pages. Read the license and get advice on your facts. A partner asks three questions: what travels with the binary, must source be available, and how far does copyleft reach.

Permissive: notices and license text

The MIT License, as the Open Source Initiative publishes it, requires the copyright and permission notice in all copies or substantial portions of the software. Apache License 2.0 section 4 asks redistributors to give recipients a copy of the license, mark modified files, retain copyright, patent, trademark and attribution notices, and where a NOTICE file exists, include its attribution notices in one of the places section 4(d) lists. The practical OEM question is where your notices end up in the partner's product and who puts them there. See our Apache 2.0 NOTICE file redistribution checklist and what to ship for MIT license attribution.

Weak copyleft: source for covered parts

Mozilla Public License 2.0 section 3.2 says that if you distribute covered software in executable form, its source must also be available and you must tell recipients how to obtain it, at no more than the cost of distribution. Section 3.3 lets the larger work use terms of your choice. LGPL-2.1 section 6 lets you distribute a work that uses the library under your own terms, provided they permit modification for the customer's own use and reverse engineering to debug such modifications, with prominent notice, a license copy and one of several options, such as supplying the library source together with what the user needs to relink a modified library, or using a suitable shared library mechanism. That is why partners ask how each LGPL component is linked.

Strong copyleft: complete source or a written offer

GPL-2.0 section 3 permits object code distribution only if you also accompany it with complete machine readable source, or with a written offer valid for at least three years to give any third party the source at no more than the cost of physical distribution, or (noncommercial only) pass on the offer you received. Complete source includes all modules plus interface definition files and the scripts that control compilation and installation.

GPL-3.0 section 6 lists several ways to convey object code with its Corresponding Source, including a written offer valid for at least three years and for as long as you offer spare parts or support for that product model. For a "User Product", roughly a consumer device, section 6 also requires Installation Information needed to install modified versions. If your component lands in a partner's hardware, that is a real question for the partner.

The party conveying object code owes these obligations, and when the partner ships your binary, the partner is conveying it. That is why agreements usually require the vendor to supply complete corresponding source or to operate the written offer.

Network copyleft

AGPL-3.0 section 13 adds that a modified version used remotely over a network must offer those users its Corresponding Source. It matters when a partner hosts your component as a service. See how to reply when a customer asks about GPL and AGPL use.

Treat that as a sorting aid, not a conclusion. Exceptions, dual licensing and how a component is combined all change the answer.

Which SBOM format and fields the disclosure should use

SPDX or CycloneDX, agreed in the contract

CISA's 2026 Minimum Elements names SPDX and CycloneDX as the two formats widely used to generate and consume SBOMs. Both carry license data. Use the partner's preference if it has one; SPDX has the deepest license vocabulary and is standardized as ISO/IEC 5962. Agree the format, its version and the delivery path in the agreement so a change is a notice, not a renegotiation.

The fields a partner will check

From the 2026 Minimum Elements, these matter most for an OEM disclosure:

• SBOM Author, SBOM Timestamp and SBOM Version. Each version gets a new timestamp, and a revised SBOM should be issued when errors are corrected.
• Component Name, Version, Producer and Identifiers. Exact versions matter because copyleft source duties attach to what you distributed.
• Component License. New in 2026: the identifiers for the licenses under which the component is available, machine processable such as SPDX identifiers, with proprietary conditions noted and "unknown" stated when the author does not know.
• Component Hash Value and Algorithm. Lets the partner check the SBOM matches the binary it received.
• Component Dependency Relationship and SBOM Generation Context. Shows transitive components and whether the SBOM came from source, build or binary analysis.

The guidance also asks authors to state whether missing information is unknown or withheld. In a warranty conversation, "license unknown" is a disclosed gap; a blank field reads as an omission.

SPDX identifiers and expressions

The SPDX License List gives each license a short identifier such as Apache-2.0 or GPL-2.0-only. The SPDX specification's license expressions annex combines them: OR for a choice (MIT OR Apache-2.0), AND when several apply at once, WITH for an exception (GPL-2.0-only WITH Classpath-exception-2.0), parentheses for precedence, and LicenseRef- identifiers for licenses not on the list.

Record both the declared license (what the package says) and the concluded license (what your review decided), and for dual licensed components, say which option you elected. Our guides on running a license review from an SBOM and the SBOM distributor role go further.

How to disclose known vulnerabilities and "not affected" decisions alongside licenses

A partner wants the known vulnerabilities in what you ship, your decision on each, and a promise to report new ones. The clean pattern is a VEX document per release beside the SBOM. VEX states whether a product is affected, and why. Three formats are common:

• CSAF 2.0 VEX profile (OASIS). Its stated purpose is to say that and why a product is or is not affected. Every product marked known_not_affected needs an impact statement, as a machine readable flag or a human readable justification; every known_affected product needs an action statement in remediations.
• CycloneDX VEX, embedded in the BOM or as a separate document.
• OpenVEX, a minimal JSON format.

Per vulnerability, answer: which product version, which status (affected, not affected, fixed, under investigation), why, and what next. Two cautions. "Not affected" is now a claim a partner relies on, so keep the reasoning on file. And status changes daily, so the contract should describe a process (scan, triage, notify within an agreed time) rather than warrant a static fact. See keeping a contract promise of no known exploited vulnerabilities.

How to keep the disclosure current across releases without renegotiating

Put the mechanism, not the content, in the contract:

1. Per release delivery of an SBOM, notices bundle and VEX. CISA's 2026 guidance says each software version or update should have an associated SBOM.
2. A change summary: added, removed and changed components and licenses since the last release, ideally machine produced.
3. Material change notice before delivery for a defined list, for example a new strong or network copyleft component, an upstream license change, or an unknown license.
4. Vulnerability notice within an agreed window for serious issues in delivered versions.
5. One delivery channel with access control and an access log.
6. An archive period for each release's artifacts. OpenChain 5230 clause 3.4.1.2 lets the contract set it, and GPL-3.0 offers can run for years.
7. An inquiry route, which OpenChain 5230 clause 3.2.1 already asks you to publish.

Then a new release is a delivery under existing terms, not a reason to reopen them. The underlying method is tool neutral: scope the exact deliverables, generate the SBOM from the build, identify licenses from more than one signal, normalize to SPDX, review by distribution model, produce artifacts, record vulnerability decisions, gate the release, share through a tracked channel, and archive.

How Safeguard does this job, step by step

Safeguard handles the data and evidence side: inventory, license identification and classification, policy, attribution, vulnerability status and controlled sharing. It does not handle the legal side. This is the flow as Safeguard's docs describe it.

1. Connect the product, or scan locally

In the Enterprise Software Supply Chain Manager (ESSCM), open Integrations and connect the deliverable's source: a GitHub, GitLab, Bitbucket or generic Git repository, a container registry, or an uploaded manifest. Set the branch or tag, project name and version to the release you deliver, because copyleft duties attach to exact versions.

If you would rather not grant repository access, the Safeguard CLI (GA) scans on your machine. The docs show:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Open the terminal, then type /login and /scan .
safeguard

# Or scan from the command line, writing results under ./output
safeguard scan --dir .

Per the docs, a signed in scan from the interactive terminal uploads the SBOM and findings while the source stays on the machine, and safeguard scan writes a license.json with the licenses it found.

2. Generate the SBOM for each release

SBOM generation and analysis (GA) produces SPDX (JSON, XML or RDF) and CycloneDX (JSON or XML), with software composition analysis (GA) covering the transitive tree and container layers. Leave Include Dev Dependencies off for an OEM disclosure, since build tools are not supplied software. Continuous scanning runs daily, and the On Release trigger scans when new tags are created, which lines the SBOM up with what you ship.

3. Identify and classify every license

License compliance (GA) reconciles several signals: package metadata, SPDX identifiers, full text matching of LICENSE, COPYING and NOTICE files, source headers, and copyright files in container layers. When they disagree, for example a manifest saying MIT over an AGPL license file, Safeguard raises a license discrepancy finding, which is exactly what you want to catch before a partner does.

Licenses are classified as permissive, weak copyleft, strong copyleft, network copyleft, commercial, public domain, or unknown (review required). Safeguard parses full SPDX expression syntax. Note one behavior: for an OR expression the docs say the most permissive option matching your policy is chosen automatically. If the contract asks which option you elected, record the election yourself.

4. Review in the Suppliers & Licenses tab

Open the project's Suppliers & Licenses tab. It shows a license summary (distinct licenses, categories, compliance status, licenses needing attribution), per component detail (SPDX identifier, license text, obligations, attribution requirements, compatibility analysis), and supplier data with type: open source project, commercial vendor, internal or unknown. Status reads compliant, review needed, violation or unknown, and common issues such as GPL in a proprietary product or AGPL network use are flagged as review prompts for counsel. The page's /v1 REST examples carry a banner saying those endpoints are not yet available, so use the tab and its exports.

5. Set a license policy for the OEM distribution model

Go to Settings → License Policies, click + New Policy, configure allowed, blocked and review lists, and set the scope. The docs also show the policy as YAML with context overrides, so an SDK distribution can be stricter than a server:

apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
  name: default
spec:
  allow:
    - MIT
    - BSD-2-Clause
    - BSD-3-Clause
    - Apache-2.0
    - ISC
    - MPL-2.0
  deny:
    - GPL-3.0-or-later
    - AGPL-3.0-or-later
    - SSPL-1.0
  require_review:
    - GPL-2.0-only
    - LGPL-3.0-or-later
    - "Custom/*"
  context_overrides:
    - apply_to: { env: sdk }
      deny:
        - LGPL-3.0-or-later # LGPL tricky in SDK distribution
    - apply_to: { env: server }
      allow:
        - LGPL-3.0-or-later # fine for a service binary

That is the docs' illustration, not a recommendation; your lists come from counsel's review of the partner's model. The useful idea is scoping by asset label, so OEM products carry a stricter policy than your SaaS backend.

6. Enforce it before a release reaches the partner

Policies and gates (GA) make the policy a control. The docs describe failing CI builds when a denied license appears in the tree, a blocking check on pull requests that add a deny listed direct dependency, and admission blocking for images, with the transitive path shown. Exceptions need a named approver, an expiry date and a business justification, and re-evaluate at expiry. Those records are good evidence for the "we reviewed it" part of a warranty conversation.

7. Map the evidence to OpenChain and License Obligations

The compliance and GRC suite (GA) includes an OpenChain ISO 5230 framework and an internal License Obligations policy, both on unless you switch them off in Compliance › Manage. The OpenChain framework runs six scan checks against the product's SBOM, citing ISO/IEC 5230:2020: a bill of materials, license identification, readiness to prepare compliance artifacts, version tracking, documented evidence (an SBOM with document identifier and timestamp), and upstream origins. Catalog controls cover what a scan cannot decide, such as a written policy, roles, competence and fulfilling distribution obligations, which you evidence with uploads or attestations.

License Obligations checks six things per scan: license identification coverage, a complete inventory, attribution data (name and version populated), copyright holder or supplier, exact versions for source disclosure (no ranges), and a machine readable manifest with SPDX expressions. That is close to a pre-flight check for an OEM disclosure. A readiness view in Safeguard is not an OpenChain conformance certificate; conformance comes from OpenChain's self-certification or an independent assessment.

8. Generate the attribution package

From Suppliers & Licenses, click Export → Attribution Notice, pick TXT, HTML or Markdown, adjust the template and download. Contents include component name and version, license type, copyright notices, license text where required and supplier information, and the docs describe regenerating it with each SBOM update. Open Source Manager (OSM, GA) has a Generate Attribution action exporting a NOTICE file, HTML, PDF or Markdown, and the license compliance docs describe THIRD-PARTY-NOTICES.txt, a licenses/ directory and a per release SPDX document for redistributed artifacts. Export → License Report gives summary, detailed, attribution and compliance reports.

The docs say there is no CLI command for these yet, so export from the app. Attribution covers notices and license texts; a GPL written offer and the source package are yours to prepare.

9. Attach vulnerability status and VEX

Vulnerability management (GA) enriches findings with EPSS and CISA KEV, and reachability analysis (GA) ranks findings on code paths your product calls. The reachability docs list JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, C#, static reachability for Ruby and PHP, and both static and dynamic reachability for Swift and Objective-C.

For decisions already made, CSAF and VEX upload (GA) accepts CSAF 2.0, CycloneDX VEX, OpenVEX and CSAF VEX profile files. In Integrations, filter by Upload, click Connect on Upload CSAF/VEX, name the upload, drop the file (validated automatically), set project name and version, and click Upload. The docs list marking vulnerabilities not affected and documenting mitigation status among the uses, so your working view and the VEX you hand over describe the same decisions.

10. Publish to Portal and share with the partner

Portal here means the SBOM publish and share product (GA), not the free entry tier of the same name. Publish moves an artifact from ESSCM to Portal and creates an immutable copy; Share distributes it as is. For a warranty, that means you can show the exact SBOM a partner received for a release.

In Portal → My Products, click + New Product, enter name and SKU, optionally turn on Require Approval, then + Add Version per release and associate its SBOM. The Sharing docs describe direct sharing to named emails with View, Download or Full permission (Full allows re-sharing), shareable links with expiry, download limits, passwords and format restrictions, per SBOM Require NDA acceptance and download notifications, a branded Customer Portal, access tracking, bulk sharing and Revoke. Audit trails record views, downloads and sharing events in Settings → Audit Logs, exportable as CSV, JSON or PDF, which answers "what did we receive and when."

The SBOM Repository can compare two versions of a product and list added, removed and changed components plus new and resolved vulnerabilities, which is the core of the change summary. Trust Center (GA) is a separate public posture page; for one partner under NDA, Portal sharing usually fits better.

11. Fix what you can before delivery

Autonomous remediation (GA) can open fix pull requests when a fixed version exists. It ships switched off, every category set to Manual. License problems in an OEM product usually need a human decision about replacement, so treat any automated license change as a proposal.

What to warrant and what never to warrant

This is where legal and technical meet, and the wording is for your counsel. Here is how to think about the evidence behind each kind of promise.

Promises the data can support

• The disclosure reflects your scan of the delivered release, backed by the SBOM, its timestamp, the tool, the version scanned and the immutable copy the partner received.
• A documented license review process exists and ran, backed by policies, exception records with approvers and expiry dates, and OpenChain mapped evidence.
• Updated packages per release and notice of material changes, backed by per release SBOMs, version comparisons and the sharing log.
• Notice of serious vulnerabilities in delivered versions within an agreed window, backed by continuous scanning, KEV and EPSS enrichment and VEX.

Promises to scope with care

• "Complete" without a definition. Tie completeness to the delivered artifacts and the scanning method.
• License conclusions that depend on the partner's product. Whether copyleft reaches the partner's code depends on how the partner combines and distributes your component, which you usually cannot see. Describe your component and its intended integration instead.
• Declared metadata as fact. Upstream packages sometimes mislabel themselves; concluded licenses need a human decision.

Promises to avoid

• "No vulnerabilities" for the life of the contract. New vulnerabilities are published daily against components that were clean yesterday. No scan supports that.
• "No copyleft" when the product contains copyleft code. Disclose the components, how they are used and what you provide.
• Anything about components you do not ship, including what the partner adds around yours.

Make sure engineering knows what was promised. A warranty the build pipeline cannot see is one nobody is checking.

What Safeguard does not do

• No legal advice or contract drafting. Safeguard does not write warranties, indemnities or disclosure schedules, and its classifications and compliance statuses are inputs to counsel's review, not conclusions.
• No written source offers or source packages. Attribution covers notices, license texts and component data. Preparing corresponding source and running a written offer for the required period are on you.
• License findings depend on declared and detected data. Mislabeled packages, vendored code without headers, and code copied in without its license file can be missed or misread.
• It covers only what was scanned. Components added after the scan, things pulled in at install time and anything the partner adds are outside the disclosure.
• No CLI command for attribution or license reports yet, and the documented /v1 REST endpoints for licenses, suppliers, Portal and audit logs are not yet available. Use the app and the CLI scan.
• A framework readiness view is not OpenChain conformance.
• It does not handle the partner's side, such as how the partner surfaces your notices or meets its own obligations to its customers.

Common mistakes

• Signing the schedule as a static exhibit. Put the update mechanism in the contract.
• Including dev dependencies and build tools. Disclose what ships.
• Losing NOTICE files when minimizing containers or bundling binaries.
• Writing "GPL" instead of an SPDX identifier. GPL-2.0-only and GPL-2.0-or-later are different promises.
• Not stating dual license elections.
• Using version ranges. Source duties attach to exact versions, and the 2026 Minimum Elements expects exact versions.
• Leaving unknown licenses blank instead of marking and resolving them.
• "Not affected" without a justification. CSAF's VEX profile requires an impact statement for this reason.
• Emailing ZIP files, which leaves no record of who has which version.
• Forgetting the archive that a GPL-3.0 written offer may need for years.
• Letting the update duty be negotiated without the OSPO and product security in the room.

FAQ

What open source disclosure does an OEM partner expect before embedding our software?

Usually a list of every open source component in the delivered product with name, version, supplier and license (ideally an SBOM with SPDX identifiers), the compliance artifacts those licenses require, the components' known vulnerability status, and a commitment to update it all each release. Your agreement sets the exact list.

Do we have to give an OEM partner an SBOM?

No general US law requires a commercial vendor to give an OEM partner an SBOM; the requirement normally comes from the contract. CISA's 2026 Minimum Elements describes what a baseline SBOM should contain, and many partners ask because their own customers ask them.

Who is responsible for GPL source code when an OEM redistributes our binary?

Under GPL-2.0 section 3 and GPL-3.0 section 6, whoever distributes or conveys the object code owes the source obligation. When the partner ships your binary, that is the partner, which is why agreements usually require the vendor to supply source or operate the written offer. The split is a contract question for counsel.

What is OpenChain ISO/IEC 5230 and do we need to conform?

It is the international standard for open source license compliance programs, built around a bill of materials with identified licenses, an obligations review and compliance artifacts for supplied software. Conformance is not legally required, but partners recognize it, and it lasts 18 months.

What is the difference between ISO/IEC 5230 and ISO/IEC 18974?

5230 covers license compliance. 18974 applies the same structure to security assurance: detect known vulnerabilities, score them, document remediation or mitigation, and record the action per component.

How should licenses be written in an OEM disclosure?

As SPDX identifiers and expressions, such as Apache-2.0, MIT OR Apache-2.0 or GPL-2.0-only WITH Classpath-exception-2.0, with unknown licenses marked unknown.

How often should we update an OEM open source disclosure?

With every release you deliver, and whenever you find an error or a material change such as a new copyleft component. CISA's 2026 guidance says each software version or update should have an associated SBOM.

Can Safeguard write our open source warranty?

No. Safeguard produces the evidence a warranty conversation relies on: SBOMs, license classifications, attribution notices, vulnerability status and a sharing record. The wording is for your counsel.

How do we share the disclosure package with an OEM partner securely?

Use a channel with access control, expiry and an access log rather than email. Portal sharing (GA) in Safeguard supports NDA acceptance, link expiry, download limits, passwords, permission levels and revocation, with audit logs of views and downloads.

Closing the gap before the partner asks

The hardest OEM disclosures are assembled the week before signature from a spreadsheet nobody trusts. The easiest already exist because every release produced an SBOM, a license review, a notices bundle and a VEX file, published where the partner can fetch them. Build the package from data, keep the promise inside what the data shows, and the warranty becomes a description of how you work. The same evidence serves your own distribution in our open source checklist for launching a self-hosted edition of your SaaS and in getting open source risk ready for pre-IPO diligence.

A disclosure is easier to stand behind when the components inside it are already fixed. When a dependency in a release you deliver to a partner is vulnerable, with or without an upstream fix, these are the ways Safeguard helps you close the gap before that release ships.

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 is a real Safeguard CLI session: install, open the interactive terminal with safeguard, and ask it 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, then shows /permissions, /model and /scan. For an OEM disclosure, the /scan step is how you produce a release's SBOM and license results on your own machine.

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

The second demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. Safeguard is listed in the Claude connector directory as a community connector. Here, that lets a reviewer ask plain language questions about a project's components while you control which tools the assistant can reach.

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

To try it on your own release, download the app and CLI at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• OpenChain Project: ISO/IEC 5230, License Compliance
• OpenChain ISO/IEC 5230:2020 specification text (OpenChain Project, GitHub)
• OpenChain Project: ISO/IEC 18974, Security Assurance
• OpenChain ISO/IEC 18974:2023 specification text (OpenChain Project, GitHub)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA: 2026 Minimum Elements for an SBOM (PDF)
• CISA: Software Bill of Materials
• SPDX License List
• SPDX Specification 3.0.1, Annex B: SPDX license expressions
• GNU General Public License v2.0 only (SPDX License List)
• GNU General Public License v3.0 only (SPDX License List)
• GNU Affero General Public License v3.0 only (SPDX License List)
• GNU Lesser General Public License v2.1 only (SPDX License List)
• Apache License, Version 2.0 (Apache Software Foundation)
• Mozilla Public License 2.0 (Mozilla)
• The MIT License (Open Source Initiative)
• Common Security Advisory Framework Version 2.0 (OASIS)
• CycloneDX: Vulnerability Exploitability eXchange (VEX)
• Safeguard docs: License Compliance
• Safeguard docs: OSM License Compliance
• Safeguard docs: License Obligations
• Safeguard docs: OpenChain ISO 5230
• Safeguard docs: Suppliers & Licenses
• Safeguard docs: Generate SBOM
• Safeguard docs: Reachability Analysis
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Portal Sharing
• Safeguard docs: Portal My Products
• Safeguard docs: Portal SBOM Repository
• Safeguard docs: Portal Audit Trails
• Safeguard Gold Open Source

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