ISO/IEC 18974 (OpenChain Security Assurance Specification), explained

ISO/IEC 18974:2023, "Information technology — OpenChain security assurance specification," is a short, free, International Standard that sets out what a quality open source software security assurance program must do: track what open source you use, check it against known vulnerabilities, and be able to affirm you did so. Published by ISO/IEC JTC 1 on 14 December 2023, it is the security-focused sister standard to the earlier OpenChain licence-compliance standard, ISO/IEC 5230:2020, and is maintained day to day by the OpenChain Project (a Linux Foundation / Joint Development Foundation initiative), not by ISO itself.

What it is, and who maintains it

OpenChain's own announcement of the standard's publication describes ISO/IEC 18974 as the result of "over seven years of work in building simple, effective process management specifications for the open source supply chain," developed as "OpenChain Security Assurance 1.1" and taken through ISO/IEC JTC 1's PAS (Publicly Available Specification) Transposition ballot process before receiving its ISO/IEC number. The specification's own scope statement, published in the OpenChain Project's text of the standard, reads: "This specification contains the key requirements of a quality open source software security assurance program that establishes trust between organizations exchanging software solutions comprised of open source software." Unlike most ISO standards, where ISO and its national member bodies are the only source of the text, OpenChain's own GitHub repository hosts the identical specification text under a Creative Commons Attribution 4.0 (CC-BY-4.0) licence — free to read, quote and reuse with attribution — alongside the ISO-branded paid PDF sold through the ISO and IEC webstores.

The four requirement clauses

The specification is short by ISO standards: the ISO catalogue lists the published edition at 8 pages. Its substantive content sits in four top-level clauses, per the OpenChain Project's own published text:

Clause	Requirement area	What it covers
4.1 Program foundation	Governance	A written open source security assurance policy with internal communication and review; defined roles with documented competence; participant awareness of the policy and the consequences of non-conformance; a defined program scope with improvement metrics; and standard practices for threat identification, vulnerability detection and post-release monitoring
4.2 Relevant tasks defined and supported	Resourcing and intake	A public mechanism through which anyone can inquire about or report a vulnerability, with an internal response procedure; and assigned accountability, staffing, funding and technical expertise to actually run the program
4.3 Open source software content review and approval	Inventory and remediation	A documented, continuously maintained software bill of materials process; and vulnerability detection, risk scoring, remediation and post-release monitoring for the open source content identified
4.4 Adherence to the specification requirements	Conformance	An organisational affirmation that every requirement above is satisfied, valid for an 18-month conformance period before re-affirmation is required

Clause 4.1's last sub-requirement and clause 4.3's content review sit close together in practice: an organisation needs a working SBOM-style inventory (4.3.1) before it can run the threat-identification and vulnerability-monitoring practices clause 4.1.5 and 4.3.2 both call for.

Not an SBOM format — a process standard that assumes one

ISO/IEC 18974 does not define a file format for listing components. Clause 4.3.1 requires only that an organisation have "documented procedures for continuous component tracking and archival" — it is deliberately silent on which machine-readable format carries that inventory. In practice, most organisations satisfy it with an existing SBOM format: CycloneDX, standardised as ECMA-424, or SPDX, standardised as ISO/IEC 5962:2021. See CycloneDX vs SPDX for SBOM formats and firmware SBOM without source code for how to build that inventory for an embedded or firmware product specifically — ISO/IEC 18974 then adds the vulnerability-detection, risk-scoring and remediation process on top of whatever inventory format you choose.

How it relates to ISO/IEC 5230 (licence compliance)

ISO/IEC 18974 is explicitly the younger sibling of ISO/IEC 5230:2020, OpenChain's earlier International Standard for open source licence compliance — the two share the same OpenChain governance model, the same self-certification approach, and (per OpenChain's own description) "a direct pedigree based on decades of open source management experience." The split matters operationally: 5230 is about whether you are honouring the licence obligations of the open source you ship (attribution, source availability, copyleft terms), while 18974 is about whether you are tracking and fixing known vulnerabilities in that same open source. An organisation that only conforms to one has solved half the open source supply-chain problem.

Conformance: self-certification, not third-party audit

Per clause 4.4, an organisation "conforms" to ISO/IEC 18974 by affirming it meets every one of the specification's requirements. OpenChain runs this as a self-certification model — the organisation records its own conformance, typically through OpenChain's published conformance registry — rather than requiring a paid third-party certification body, which is a deliberate design choice to keep the standard accessible to organisations of any size. Conformance is valid for 18 months (clause 4.4.2) before the organisation must re-affirm against the specification's current text. Each requirement also calls for "verification materials" (records) that demonstrate it was met; OpenChain's own description notes these records are not required to be made public, though an organisation can choose to share them with counterparties, including under an NDA.

A workable starting point

1. Pick or confirm your SBOM mechanism first (CycloneDX or SPDX) — clause 4.3.1 needs a documented, continuously maintained component inventory before the vulnerability-detection requirements in 4.1.5 and 4.3.2 can run against real data.
2. Publish a public vulnerability-inquiry channel (clause 4.2.1) alongside your existing vulnerability disclosure policy — many organisations satisfy both with the same security contact. See vulnerability disclosure policy template.
3. Write the policy and assign roles before claiming conformance (clause 4.1): a self-certification claim with no documented policy or named accountable owner will not survive a counterparty's own review of your verification materials.
4. Calendar the 18-month re-affirmation (clause 4.4.2) the same way you would a certificate renewal, so conformance does not quietly lapse.
5. Pair it with ISO/IEC 5230 if licence compliance matters to your buyers too — the two standards are designed to be adopted together, and several of the same internal roles and records can serve both.

SoftWSP's firmware and device assessments build the open source component inventory and vulnerability-tracking evidence that ISO/IEC 18974's clause 4.3 calls for, alongside CycloneDX/SPDX SBOM output: see Device & Firmware Security.

This guide summarises the OpenChain Project's own freely published (CC-BY-4.0) text of ISO/IEC 18974:2023; it is not a substitute for the ISO-branded publication or formal conformance guidance, and does not constitute compliance or legal advice.