OpenChain ISO/IEC 18974 Explained: Security Assurance for Open Source

ISO/IEC 18974:2023 is the OpenChain security assurance specification: an international standard that defines the minimum process an organization needs to find, track and respond to known vulnerabilities in the open source software it ships. It asks for a written policy, named and trained roles, a software bill of materials for each supplied product, a public way to ask about vulnerabilities, and records of every decision.

It does not tell you which tools to use or how fast to patch. It tells you which processes must exist, and which records prove they exist. Conformance can be self-certified for free, or confirmed by an independent assessor, and it lasts 18 months before you must reaffirm it.

This post goes one level deeper than our earlier pieces on the licence side of OpenChain: what ISO/IEC 5230 is and when buyers ask for it, whether a startup should care about OpenChain 5230, and open source licence obligations, OpenChain and attribution. Those cover licence compliance. This one is only about the security sibling. We read the full English text of ISO/IEC 18974 that the OpenChain Project publishes on GitHub (which the project states is functionally identical to the ISO edition), the earlier 1.0, 1.1 and draft 2.0 texts in the same repository, the OpenChain security assurance and licence compliance pages, the OpenChain announcements of March 2023, December 2023 and September 2025, the official self-certification checklist, the OpenChain adoption guide and CRA checklist in the project's reference library, NIST SP 800-218 (the Secure Software Development Framework), the European Commission's Cyber Resilience Act pages, the NTIA SBOM minimum elements report, RFC 9116, and the CycloneDX tool documentation. Clause numbers below follow the ISO text.

Key takeaways

• ISO/IEC 18974:2023 is a process standard, not a technical one. It defines what a quality open source security assurance program must have, not how to build it. The OpenChain text says it focuses on the "what" and "why" rather than the "how" and "when".
• Its scope is deliberately narrow: checking open source in software you supply to others against publicly known vulnerabilities such as CVEs, platform vulnerability alerts and package manager alerts.
• It grew from the OpenChain Security Assurance Reference Guide (2021 and 2022), became the OpenChain Security Assurance Specification 1.0 and 1.1 in late 2022, entered ISO as DIS 18974 in March 2023, and OpenChain announced its publication as ISO/IEC 18974:2023 on 19 December 2023.
• Clause 4 has four requirement groups: program foundation (4.1), relevant tasks defined and supported (4.2), open source software content review and approval (4.3), and adherence to the specification requirements (4.4). Each requirement lists the verification materials, meaning records, that prove it.
• The concrete obligations are a written policy, defined roles with assessed competence, awareness, a scope statement with metrics, eight documented security methods, a public point of contact for vulnerability inquiries, adequate resourcing, a continuously maintained SBOM, and a per component record of every known vulnerability and the action taken, including "no action".
• Conformance can be self-certified by answering yes to every checklist question, or obtained through an independent assessment or third-party certification from an OpenChain partner. Either way it is valid for 18 months.
• ISO/IEC 18974 covers a useful slice of the EU Cyber Resilience Act's vulnerability handling requirements and NIST SSDF practices, but it is not a substitute for either. The CRA adds legal reporting deadlines, support periods and conformity assessment that 18974 does not touch.

What is ISO/IEC 18974, and where did it come from?

ISO/IEC 18974:2023 carries the formal title "OpenChain security assurance specification". Its scope clause says it 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. The key word is exchanging. The standard is about software you hand to someone else: a customer, a partner, a downstream integrator, or the public.

The OpenChain Project is a Linux Foundation project. Its first standard, the OpenChain Specification for open source licence compliance, was released as version 1.0 in October 2016, submitted to the ISO/IEC JTC 1 PAS Transposition Process in April 2020, and became ISO/IEC 5230:2020 in December 2020, according to the OpenChain licence compliance page. ISO/IEC 5230 identifies the inbound, internal and outbound points in a software supply chain where a process, a policy or training should exist.

The introduction to ISO/IEC 18974 explains what happened next. The community noticed ISO/IEC 5230 being used in the security domain, because the inventory you build for licence compliance is the same inventory you need to answer the question "do we ship anything with a known vulnerability?". So the community drafted a security version of the same process model.

The timeline, from reference guide to international standard

Every date below was checked against the OpenChain Project's own pages and repositories.

Two practical points come out of this history. First, if a supplier tells you it conformed to "OpenChain Security Assurance 1.1" or "ISO/IEC DIS 18974", that is the same set of requirements. The December 2023 announcement states that those earlier variants are functionally identical to ISO/IEC 18974:2023, and the March 2023 announcement told adopters that a DIS adoption would also be valid for the final standard. Second, ISO's own catalogue page blocks scripted access, so we could not read the exact ISO publication month from iso.org. The OpenChain announcement of 19 December 2023 is the primary date we can confirm, and the standard's own designation fixes the year as 2023.

Why the OpenChain text and the ISO text are interchangeable

ISO sells its edition. OpenChain publishes the same requirements under a Creative Commons Attribution 4.0 licence on GitHub, with a note that the document may differ slightly in formatting from the ISO edition "but it contains the same requirements and is functionally identical". The OpenChain security assurance page goes further: conformance to one is conformance to the other. For a team building a program, that means you can work from the free text and cite ISO/IEC 18974:2023 in contracts and questionnaires.

How is ISO/IEC 18974 structured?

The document follows the usual ISO layout: scope (clause 1), normative references (clause 2), terms and definitions (clause 3), and requirements (clause 4). Clause 4 is where the work lives. It contains 11 requirements in four groups. Each requirement has three parts: the requirement text, the verification materials (records that show the requirement is met), and a short rationale.

The OpenChain Project describes the result in three ideas: the key places to have security processes, how to assign roles and responsibilities, and how to keep the processes sustainable. That maps neatly onto the clause groups. Clause 4.3 is the "places", 4.1.2 and 4.2.2 are the "roles", and 4.1.4 and 4.4 are the "sustainability".

The definitions that change how you read the rest

Clause 3 has 14 definitions. Five of them shape the program more than any requirement does.

• Supplied software (3.13) is software an organization distributes or makes available to third parties, such as other organizations or individuals. Internal tools that never leave your company are not supplied software. A hosted service is a judgement call that you should settle in your scope statement, because "makes available" can be read to include software customers use over a network.
• Known vulnerability (3.5) is a security vulnerability previously discovered in publicly available open source components, including CVEs, platform vulnerability alerts and package manager alerts. Newly discovered vulnerability (3.6) is one just discovered. The program has to handle both, including the second kind turning up in software you already shipped.
• Component record (3.1) is a data set with supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and a timestamp, "as defined by NTIA minimum elements". Those are exactly the seven baseline data fields in the July 2021 NTIA report, which 18974 lists as a normative reference.
• Software bill of materials (3.12) is information in a structured format "such as SPDX" that allows the exchange of information about a software package, which might usefully include name, version, origin, licence, copyright and known vulnerabilities. SPDX is named as an example, not a mandate. A CycloneDX SBOM that carries the NTIA fields serves the same purpose.
• Program participant (3.9) is any employee or contractor who defines, contributes to or is responsible for preparing supplied software. The note to that definition lists software developers, release engineers, quality engineers, product marketing, product management and procurement. Procurement is in there on purpose: the people who buy components are part of the supply chain.

The other definitions are worth knowing for audits. Customer agreement (3.2) means relevant customers regard your processes for finding, tracking and fixing security issues as sufficient. Security testing (3.11) is analysis that helps you understand software in the context of known vulnerabilities. Verification materials (3.14) are the records that show a requirement is satisfied, and the introduction is explicit that they do not have to be public. You may share them under a non-disclosure agreement if you choose.

The normative references are short: the Free Software Definition, the Open Source Definition, and the NTIA minimum elements report. The bibliography adds ISO/IEC 5230, ISO/IEC 5962 (SPDX 2.2.1), and the CISA Known Exploited Vulnerabilities catalog.

What does ISO/IEC 18974 require in practice?

This section walks through each requirement in plain language, with the record an assessor or a customer would expect to see.

A written policy that people know about (4.1.1 and 4.1.3)

You need a documented open source software security assurance policy covering supplied software, and a documented procedure for making participants aware of it (verification materials 4.1.1.1 and 4.1.1.2). The policy and the way you communicate it need a review process so they stay current.

Clause 4.1.1 does not dictate policy content. Its rationale notes that other clauses impose their own requirements, so in practice the policy ends up stating your scope, your risk scoring approach, your response targets, who owns what, and where the public contact lives. A two page document is enough for a small team if it says those things clearly.

Awareness (4.1.3) asks for documented evidence of assessed awareness. Participants must know the policy, the program objectives, their own contribution, and the implications of non-conformance. "Assessed" is the important word: an email blast with no acknowledgement is weak evidence. A short quiz, a signed acknowledgement in onboarding, or a training completion record is stronger.

Roles, competence and resourcing (4.1.2 and 4.2.2)

Clause 4.1.2 asks for six records: a list of roles and responsibilities, the competencies each role needs, a list of participants and their roles, evidence of assessed competence for each participant, evidence of periodic reviews and process changes, and verification that processes match current internal practice and assignments.

Clause 4.2.2 then asks you to show the roles are real. You need named people, groups or functions in each role, evidence the roles are staffed and funded, an identified source of expertise on known vulnerabilities, and a documented procedure that assigns internal responsibility for security assurance.

A typical role set for a mid-sized product team looks like this.

One person can hold several roles. The standard cares that each role exists, has an owner, and has evidence behind it.

A scope with metrics (4.1.4)

The program needs a written statement of scope and limits (4.1.4.1), a set of metrics it should achieve in order to improve (4.1.4.2), and documented evidence from each review, update or audit that shows continuous improvement (4.1.4.3).

Scope is the most useful lever in the whole standard. The text says a program can cover a product line, a department or the whole organization, and that scope can change over time. A recent conformance notice on the OpenChain site, from October 2026, shows how narrow a valid scope can be: one company scoped its self-certified program to a single publicly distributed software development kit and the open source components supplied with it, and stated that internal systems were out of scope. That is legitimate. What is not legitimate is claiming company-wide conformance when only one product is covered.

Metrics are left to you. Sensible ones include the share of releases shipped with an archived SBOM, the median time from a critical known vulnerability being published to a decision being recorded, the share of supported releases rescanned in the last 30 days, and the number of public inquiries answered within your stated target.

Eight security methods (4.1.5)

Clause 4.1.5 is the closest the standard gets to technical practice. It requires a documented procedure (4.1.5.1) for each of these methods:

1. Identifying structural and technical threats to the supplied software.
2. Detecting known vulnerabilities in the supplied software.
3. Following up on identified known vulnerabilities.
4. Communicating identified known vulnerabilities to customers when warranted.
5. Analyzing supplied software for newly published known vulnerabilities after release.
6. Continuous and repeated security testing of all supplied software before release.
7. Verifying that identified risks have been addressed before release.
8. Exporting information about identified risks to third parties as appropriate.

Methods 2, 3, 5 and 7 are where most teams spend their effort, because they turn into a pre-release gate and a post-release monitoring job. Method 1 is often met with a lightweight threat model per product. Method 8 is usually met by sharing SBOMs and vulnerability status with customers, for example as a VEX document or an advisory.

A public point of contact (4.2.1)

You must publicly identify a way for third parties to ask how a known vulnerability affects your software (4.2.1.1), such as a monitored email address or web portal, and you need an internal documented procedure for responding (4.2.1.2). The rationale is that third parties need a reasonable, secure way to reach you, and you need to be ready to answer.

The simplest way to publish that contact is a security.txt file at /.well-known/security.txt, defined by RFC 9116 (April 2022). It must include at least one Contact field and an Expires field. A product page or documentation page with a security contact also satisfies the wording.

An SBOM for every piece of supplied software (4.3.1)

A process must exist to create and maintain a bill of materials that includes each open source component in the supplied software. The verification materials are a documented procedure that ensures all open source in the supplied software is continuously recorded across its lifecycle, including an archive of all open source used (4.3.1.1), and the component records that show the procedure was followed (4.3.1.2).

Three phrases in that text matter. "Continuously recorded" means once per release is a minimum, not a one-off inventory. "Across the lifecycle" means you keep the SBOM for every release still supported, not just the latest. "An archive of all open source software used" means you keep the components or a reliable reference to them, which also helps when you need to rebuild an old release to patch it.

A record for every vulnerability decision (4.3.2)

This is the heart of the standard. For each open source component in the SBOM, the program must:

• apply a method to detect known vulnerabilities;
• assign a risk or impact score to each one;
• determine and document remediation or mitigation steps suited to how the software is used;
• obtain customer agreement on the proposed resolution where necessary, at or above a predetermined level (the text gives "all severity scores above 4.5" as an example threshold);
• take action according to the score, such as contacting customers, upgrading the component, or no further action;
• act on newly discovered vulnerabilities in software already distributed;
• monitor supplied software after release and respond to disclosures.

The records are a documented procedure (4.3.2.1) and, for each component, a record of the identified known vulnerabilities and the actions taken, "including even if no action was required" (4.3.2.2). That last phrase is where many programs fail an assessment. A dashboard that shows today's open findings is not enough. You need the history: which vulnerability, which release, what score, what decision, who decided, when, and why.

Completeness and an 18 month clock (4.4)

Clause 4.4.1 says partial conformance is not conformance: the organization must affirm that the program in its stated scope meets every requirement. Clause 4.4.2 says conformance with this version lasts 18 months from the date conformance validation was obtained. To keep claiming it, you reaffirm at least every 18 months, and you need a document showing you did.

How does ISO/IEC 18974 relate to ISO/IEC 5230?

The two standards are siblings with the same skeleton. The 18974 text says it was "built from the source material" of ISO/IEC 5230 (specifically OpenChain 2.1), and the clause groups line up: program foundation, relevant tasks defined and supported, open source content review and approval, and adherence. The OpenChain December 2023 announcement calls 18974 a "sister standard" to 5230.

Because the inventory is shared, many organizations run one program that conforms to both. The OpenChain adoption guide in the project's reference library (still marked as a draft) covers both standards together, and the October 2026 conformance notice mentioned earlier was a joint 5230 and 18974 self-certification. If you already have a 5230 program, 18974 adds three things: risk scoring and decisions per vulnerability, post-release monitoring, and a public security contact with a response procedure.

The OpenChain reference material and self-certification

The OpenChain Project publishes its specifications under CC-BY-4.0 and its reference material under CC0, according to the legal notice on its site. The reference library on GitHub includes:

• the ISO/IEC 18974 self-certification checklist in several languages, including English, German, Japanese, Korean and simplified Chinese;
• an adoption guide for all OpenChain standards, organized by company or team size;
• open source policy templates (the published ones target ISO/IEC 5230, but the policy structure carries over);
• training and explainer material for internal teams;
• an SBOM quality management folder;
• a community CRA compliance checklist mapped to the Cyber Resilience Act and aligned with 18974 and 5230.

The self-certification checklist is a list of yes or no statements, one or more per clause. The English version dated 18 August 2025 states the rule plainly: an organization can self-certify by answering yes to all questions, and if it cannot, it does not yet meet the standard. It also reminds you that you alone are responsible for the accuracy of the answers. After self-certifying you can optionally submit your organization to the OpenChain "Community of Conformance" list.

How does ISO/IEC 18974 map to the EU CRA, NIST SSDF and supplier questionnaires?

ISO/IEC 18974 is small, and that is the point. It sits underneath larger frameworks as the process layer for one specific risk: known vulnerabilities in open source you ship.

The EU Cyber Resilience Act

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024, according to the European Commission. Reporting obligations under Article 14 apply from 11 September 2026, the notification of conformity assessment bodies (Chapter IV) from 11 June 2026, and the main obligations from 11 December 2027.

Annex I of the CRA has two parts. Part II holds the vulnerability handling requirements: manufacturers must ensure, for the support period, that vulnerabilities in the product, including its components, are handled effectively. The Commission's summary also sets out the reporting clock for actively exploited vulnerabilities: an early warning within 24 hours, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. The OpenChain CRA checklist, which maps each item to the regulation, records that Annex I Part II expects an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies, a coordinated vulnerability disclosure policy, and a contact address for reporting potential vulnerabilities. Check the regulation text on EUR-Lex for the exact wording before you quote it in a contract.

In September 2025 the OpenChain Project reported that ISO/IEC 18974 had been cited in a CEN and CENELEC webinar about CRA security controls, alongside ISO/IEC 29147 (vulnerability disclosure), ISO/IEC 30111 (vulnerability handling processes) and ISO/IEC TR 5895 (multi-party coordinated disclosure). OpenChain describes this as recognition of its standard, not as harmonized standard status. Treat 18974 as helpful evidence for CRA readiness, not as a presumption of conformity.

The community CRA checklist in the OpenChain reference library is candid about the gaps. Its coverage table marks SBOM generation, vulnerability monitoring and risk decisions as covered by 18974, and marks product classification, risk assessment, harmonized standards tracking, the Article 14 notification chain to national CSIRTs and ENISA, the open source steward role, and the support period obligations as not covered or only partly covered. Note that this checklist refers to 18974 sections using the OpenChain specification's own numbering, which differs from the ISO clause numbers used in this post.

NIST SP 800-218, the Secure Software Development Framework

NIST published SSDF version 1.1 as SP 800-218 in February 2022. It is broader than 18974, covering the whole secure development lifecycle, but several practices line up directly.

A team that already produces SSDF attestation evidence will find most of the 18974 records already exist. The usual gaps are the per component decision history and the 18 month reaffirmation.

Supplier questionnaires

Customer security questionnaires usually ask some version of these questions: Do you produce an SBOM? Can you share it? How do you track vulnerabilities in third-party components? What is your patch time for critical issues? How do customers report a vulnerability to you? Do you notify customers?

ISO/IEC 18974 does not answer them for you, but a conformant program produces the documents that do. The policy answers the governance questions, the SBOM procedure and archives answer the inventory questions, the 4.3.2 records answer the tracking questions, the 4.2.1 contact answers the reporting question, and method 4 of clause 4.1.5 answers the notification question. Some buyers will accept "we self-certified to ISO/IEC 18974:2023 in this scope on this date" as a summary answer, then ask for selected verification materials under NDA.

Comparison: 18974, 5230, SSDF and CRA vulnerability handling

What does conformance look like for a small company versus a large supplier?

The standard is the same for everyone. What changes is how you meet it and how you prove it.

Self-certification

Self-certification is free. You read the checklist, confirm every statement is true for your stated scope, keep the verification materials, and optionally register on the OpenChain conformance list. Nobody audits you at that point. The credibility comes from the records you can produce when a customer asks.

Independent assessment and third-party certification

The OpenChain partners page lists law firms, consultancies and certification bodies, and separates third-party certifiers from other partners. An independent assessment means an outside party reviews your program against the checklist. Third-party certification means an accredited body certifies it. Large suppliers selling into regulated industries, or into customers who require external evidence, tend to choose one of these routes.

Scaling the same requirements

The OpenChain adoption guide, a draft in the reference library, suggests that size changes the options, not the obligations. For 18974 it recommends that every organization start by tracking CVEs in its open source components, prioritize by severity, component criticality and likelihood of exploitation, and choose between upgrading, patching or compensating controls. Smaller organizations focus on critical issues with free or low-cost tooling; medium ones add structure, dedicated people and commercial tooling; large ones connect vulnerability management to wider risk programs, automate patching and audit regularly.

Step by step: build a minimal ISO/IEC 18974 program

This walkthrough builds the smallest program that can honestly answer yes to every checklist question for one product. It uses free tools and the OpenChain reference material. Adapt the commands to your ecosystems.

Step 1: Write the scope statement and policy

Create a security-assurance/ folder in a repository the program owners control. Start with the scope (4.1.4.1).

# Open source security assurance program: scope

Program owner: Head of Engineering
Effective: 2026-11-01
Standard: ISO/IEC 18974:2023

In scope:
- Product "example-agent" (CLI and SDK), all releases under support
- Open source components distributed with those releases

Out of scope:
- Internal tools and infrastructure not distributed to third parties
- Third-party hosted services we consume

Metrics (reviewed quarterly):
- 100% of releases have an archived SBOM
- Median time from critical known vulnerability publication to recorded decision: 3 business days or less
- 100% of supported releases rescanned in the last 30 days
- Public security inquiries acknowledged within 2 business days

Then write the policy (4.1.1.1). Keep it short: purpose, scope reference, roles, scoring method, response targets, customer communication, review cycle. Add how participants learn about it (4.1.1.2), for example "linked from the engineering onboarding checklist; acknowledgement recorded in the HR system".

Step 2: Define roles and record competence

Create a roles.md with the roles, responsibilities and required competencies (4.1.2.1 and 4.1.2.2), and a participants.csv that maps people to roles (4.1.2.3). Record how competence was assessed (4.1.2.4), for example a completed internal course or a reviewed triage exercise.

name,role,competence_evidence,assessed_on,next_review
A. Rivera,Program manager,Completed OpenChain overview + policy review,2026-10-20,2027-04-20
J. Chen,Release engineer,Walkthrough of SBOM pipeline,2026-10-21,2027-04-21
S. Patel,Vulnerability triage,Triage exercise reviewed by program manager,2026-10-22,2027-04-22

Step 3: Publish a security contact

Publish an RFC 9116 file at https://example.com/.well-known/security.txt (4.2.1.1).

Contact: mailto:security@example.com
Expires: 2027-10-31T23:59:59Z
Policy: https://example.com/security/policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

Write the internal response procedure (4.2.1.2): who watches the inbox, how quickly you acknowledge, how you check the SBOM archive to answer "are we affected?", and when you escalate.

Step 4: Generate an SBOM for every release

Use the CycloneDX tools for each ecosystem you ship. These commands come from each project's documentation.

# Node.js project (CycloneDX npm tool)
npx @cyclonedx/cyclonedx-npm --output-format JSON --output-file sbom.cdx.json

# Python project (CycloneDX Python tool, installed with pipx)
pipx install cyclonedx-bom
cyclonedx-py environment --output-format JSON -o sbom-python.cdx.json

# Go application (CycloneDX gomod tool)
go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod app -json -output sbom-go.cdx.json -licenses -main cmd/example-agent .

For Maven, the CycloneDX Maven plugin generates an SBOM during the build. Whatever the tool, check the output carries the NTIA fields that clause 3.1 names: supplier, component name, version, a unique identifier such as a package URL, dependency relationships, the SBOM author and a timestamp.

Step 5: Gate releases on known vulnerabilities and archive the evidence

Automate the SBOM and the pre-release check in CI so every tagged release produces both (4.3.1 and methods 2, 6 and 7 of 4.1.5). This GitHub Actions example uses ecosystem audit tools and stores the outputs as release assets.

name: release-evidence
on:
  push:
    tags: ["v*"]
permissions:
  contents: write
jobs:
  sbom-and-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm ci
      - name: Generate SBOM
        run: npx @cyclonedx/cyclonedx-npm --output-format JSON --output-file sbom.cdx.json
      - name: Check for known vulnerabilities
        run: npm audit --omit=dev --json > audit.json || true
      - name: Fail on high or critical without a recorded decision
        run: node security-assurance/check-decisions.js audit.json security-assurance/decisions.yaml
      - name: Attach evidence to the release
        env:
          GH_TOKEN: ${{ github.token }}
        run: gh release upload "${GITHUB_REF_NAME}" sbom.cdx.json audit.json security-assurance/decisions.yaml --clobber

The check-decisions.js script is yours to write: it should fail the build when a high or critical finding has no matching decision in the decisions file. That is how "verify that identified risks will have been addressed before release" becomes a control rather than a promise. For Python, pip-audit, published under the Python Packaging Authority, plays the same role; for Go, govulncheck from the Go project reports known vulnerabilities in the modules you depend on and highlights the ones your code calls.

Step 6: Record every decision, including "no action"

Keep a version-controlled decisions file per product (4.3.2.2). One entry per vulnerability per component per release line.

- id: CVE-2026-00000        # example placeholder
  component: pkg:npm/example-lib@2.3.1
  releases: ["v1.8.0", "v1.8.1"]
  detected: 2026-10-22
  source: package manager advisory
  score: 7.5               # CVSS base score from the advisory
  exploited_in_wild: false # checked against the CISA KEV catalog
  analysis: Vulnerable function is not called by example-agent
  decision: upgrade in next release; no customer notice
  customer_agreement_needed: false   # threshold in policy: score >= 9.0
  decided_by: S. Patel
  decided_on: 2026-10-23
  closed_in: v1.8.2

Your policy sets the threshold for customer agreement and notification. The standard's example of "above 4.5" is only an example. Pick a threshold you can defend, and write down why.

Step 7: Monitor released software

Schedule a job that rescans the archived SBOMs of every supported release against current advisories (method 5 of 4.1.5 and the monitoring line of 4.3.2). A daily or weekly schedule is common. New matches feed the same decisions file. If a newly discovered vulnerability affects a release customers already run, your score and policy decide whether to notify them.

Step 8: Run a review, then self-certify

Hold a review with the program owner, record the minutes (4.1.2.5 and 4.1.4.3), and walk through the self-certification checklist line by line. Where an answer is "not yet", fix it. When every answer is yes, write and sign the affirmation (4.4.1.1), note the date, and set a reminder for at least 16 months later so the 18 month reaffirmation (4.4.2.1) does not lapse. Then, if you want, submit your organization to the OpenChain conformance list.

What 18974 does not cover

Being clear about the edges helps you avoid overclaiming.

• Your own code. The standard is about open source components. Flaws in code you wrote are handled by your secure development practices, such as the SSDF.
• How fast to fix. There are no mandated response times. You set targets in your policy, and the metrics in 4.1.4 track them.
• Legal reporting. There are no regulator notification duties. The CRA's 24 hour, 72 hour and 14 day reporting clock is separate.
• Support periods. 18974 does not require a minimum support period. The CRA does.
• Software you do not supply. Internal tools and consumed services are outside the definition of supplied software.
• Specific tools or formats. SPDX is an example, not a requirement, and no scanning approach is mandated.

Common mistakes

• Claiming conformance for the whole company when the program covers one product. The scope statement defines what you can claim. Say "ISO/IEC 18974:2023 conformant for product X" if that is the truth.
• Treating the SBOM as a one-time export. Clause 4.3.1 says continuously recorded across the lifecycle. An SBOM from last year's audit does not cover this month's release.
• Keeping only open findings. The 4.3.2.2 record must include decisions where no action was needed. Without that history you cannot prove the process ran.
• Scoring without context. The standard asks for remediation steps suited to how the software is used. A severity score copied from an advisory, with no note on whether the vulnerable code is reachable or exposed, is weak evidence.
• A security inbox nobody reads. A public contact with no internal response procedure fails 4.2.1.2, and a missed report is worse than none.
• Forgetting procurement and product management. The definition of program participant includes them. If they are not in your roles and awareness records, the program has a gap.
• Letting the 18 month window lapse. A program that conformed two years ago and has not been reaffirmed is no longer conformant under 4.4.2.
• Calling 18974 a CRA presumption of conformity. It is referenced in CRA standards discussions, but it is not a harmonized standard. Use it as supporting evidence.
• Ignoring released versions. Method 5 of 4.1.5 covers software after release. Scanning only the main branch misses every customer on an older version.

FAQ

Is ISO/IEC 18974 a certification?

It is a standard, and you can show conformance to it in two ways. You can self-certify for free using the OpenChain checklist, or you can use an independent assessment or third-party certification from an OpenChain partner. Either way, conformance with this version lasts 18 months from the date it was obtained.

When was ISO/IEC 18974 published?

The standard carries the designation ISO/IEC 18974:2023. The OpenChain Project, the Linux Foundation and the Joint Development Foundation announced its publication on 19 December 2023. It was previously available as ISO/IEC DIS 18974 from March 2023 and as the OpenChain Security Assurance Specification 1.1 from October 2022.

Is ISO/IEC 18974 free?

The ISO edition is sold by ISO. The OpenChain Project publishes a functionally identical version under CC-BY-4.0 on GitHub, and states that conformance to one is conformance to the other. The self-certification checklist and reference material are free.

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

ISO/IEC 5230 covers open source licence compliance. ISO/IEC 18974 covers security assurance for known vulnerabilities in open source. They share the same structure and both need an inventory of open source in supplied software, so many organizations run one program that conforms to both.

Does ISO/IEC 18974 require an SBOM?

Yes. Clause 4.3.1 requires a process for creating and maintaining a bill of materials that includes each open source component in the supplied software, continuously recorded across its lifecycle, with an archive of the open source used. SPDX is given as an example format; other structured formats that carry the NTIA minimum elements serve the same purpose.

Does ISO/IEC 18974 satisfy the EU Cyber Resilience Act?

No single standard does that today. ISO/IEC 18974 covers part of the CRA's vulnerability handling requirements, such as inventory, monitoring and a contact point. The CRA adds product classification, risk assessment, reporting deadlines from 11 September 2026, support periods and conformity assessment from 11 December 2027. OpenChain reported in September 2025 that 18974 was cited in CEN and CENELEC CRA standards work, which is recognition, not a presumption of conformity.

Does ISO/IEC 18974 apply to SaaS products?

The standard applies to supplied software, defined as software you distribute or make available to third parties. Whether a hosted service counts depends on how you define scope, so state it explicitly in your scope statement. Many SaaS providers include the client libraries, agents and SDKs they distribute, even when the hosted service is handled under a separate program.

How long does it take to implement ISO/IEC 18974?

That depends on what you already have. A team with SBOM generation in CI and a vulnerability triage habit can often write the missing policy, roles and records in a few weeks for one product. A large supplier rolling it out across many product lines usually phases scope over several quarters.

Do we have to publish our vulnerability records?

No. The standard's introduction says verification materials do not have to be public. You may share them with customers, often under an NDA. What must be public is the way for third parties to ask about known vulnerabilities.

What risk score threshold does ISO/IEC 18974 require?

None. The text asks you to assign a risk or impact score to each known vulnerability and act on it, and gives "all severity scores above 4.5" only as an example of a predetermined threshold for customer agreement. You set and justify your own threshold in your policy.

Where Safeguard fits

ISO/IEC 18974 is a process standard, so no product can make you conformant. Your policy, roles, training records and signed affirmation are yours to write. What a platform can do is produce and keep some of the records the standard asks for, with less manual work.

Safeguard scans repositories, container images and SBOM files and builds the component inventory that clause 4.3.1 depends on. It matches components against vulnerability databases, uses reachability analysis to show whether your code calls the vulnerable path, and shows which projects contain a given component and version, which is the question a 4.2.1 inquiry usually asks. Policies and gates evaluated in the platform can block a release that carries an unresolved finding, which supports methods 6 and 7 of clause 4.1.5. The Safeguard CLI runs the same scans locally or in CI, and its results are JSON you can archive with each release. Safeguard does not write your policy, run your training, operate your security inbox, or file CRA reports for you, and the decision record for each vulnerability is still a human judgement your program owns.

ISO/IEC 18974 asks you to decide on, and act on, every known vulnerability in the open source you ship, and clause 4.3.2 lists upgrading the component as a typical action. The faster a decided fix reaches your releases, the shorter the window your records have to explain, so the remediation side matters as much as the paperwork.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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. You ask it to fix a lodash CVE; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and prints a summary without pushing anything. In an 18974 program that is the "upgrade software component" action from clause 4.3.2, carried out with a human approving each step, and the summary becomes part of your decision record.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. That is the shape of the post-release monitoring job in step 7: scans that run on infrastructure you control, against the releases you still support.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For a program manager answering a 4.2.1 inquiry, that means asking in plain language which projects contain a component version, then checking the answer against your own records before replying.

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

To try it on your own code, download Safeguard and follow the CLI documentation.

Quick check

Sources

• OpenChain Project: ISO/IEC 18974 security assurance page
• OpenChain: ISO/IEC 18974:2023 English text on GitHub
• OpenChain Security Assurance Specification repository (1.0, 1.1, DIS and draft 2.0 texts)
• OpenChain: draft Security Assurance Specification 2.0
• OpenChain news: Introducing ISO/IEC DIS 18974 (16 March 2023)
• OpenChain news: OpenChain welcomes ISO/IEC 18974 (19 December 2023)
• OpenChain news: Update on OpenChain ISO/IEC 18974 and the CRA (18 September 2025)
• OpenChain Project: ISO/IEC 5230 licence compliance page
• OpenChain: ISO/IEC 18974 self-certification checklist (English)
• OpenChain: Adoption guide for all OpenChain standards (draft)
• OpenChain: Reference material library
• OpenChain: CRA compliance requirements and checklist
• OpenChain Project: Conformance news
• OpenChain Project: Partners
• NIST SP 800-218, Secure Software Development Framework version 1.1
• NIST SP 800-218 full text (PDF)
• European Commission: Cyber Resilience Act summary
• European Commission: Cyber Resilience Act policy page
• NTIA: The Minimum Elements for a Software Bill of Materials (July 2021)
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• CISA Known Exploited Vulnerabilities catalog
• CycloneDX npm tool
• CycloneDX Python tool
• CycloneDX Go module tool

Last reviewed: 24 October 2026. ISO/IEC 18974 is under revision in the OpenChain community and CRA guidance is still being published; check the OpenChain security assurance page and the Commission's CRA pages for the latest status.