Guide on OpenChain KWG

FOSSLight

Mon, 01 Jan 0001 00:00:00 +0000

FOSSLight is an open source project led by LG Electronics. It analyzes source code, binaries, and dependencies using various scanners to generate an SBOM (Software Bill of Materials). FOSSLight Hub provides open source management, license management, and vulnerability management features to support the compliance process.

Official website: https://fosslight.org/
GitHub: https://github.com/fosslight/fosslight_hub
License: Apache-2.0

1. Features

Multiple scanner integration: Integrates ScanCode Toolkit, SPDX Tools, CycloneDX, FOSSology, and other open source scanners
Wide scan target support: Source code, binaries, container images, Linux packages, and more
SBOM generation and management: Creates and manages SBOMs in various formats (SPDX, CycloneDX, Excel, Text)
License detection and management: Accurately detects and manages open source license information
Vulnerability integration: Links to external vulnerability databases such as NVD and CVE
FOSSLight Hub: Web-based UI providing open source management, license management, and vulnerability management

2. Installation

FOSSLight consists of FOSSLight Scanner and FOSSLight Hub. The easiest way to install both is using Docker Compose.

OSV-SCALIBR

Mon, 01 Jan 0001 00:00:00 +0000

OSV-SCALIBR (Open Source Vulnerabilities - Software Composition Analysis LIBRary) is an open source software composition analysis tool developed by Google. It scans filesystems, container images, and binaries to identify included packages and detects known vulnerabilities by cross-referencing the OSV (Open Source Vulnerabilities) database. It also supports SBOM generation in SPDX format.

GitHub: https://github.com/google/osv-scalibr
License: Apache-2.0

1. Features

Multiple scan targets: Local filesystem, container images, archive files
Wide ecosystem support: Go, Python, Java (Maven), JavaScript (npm), Rust, Ruby, and more
OSV DB integration: Cross-references scan results with the OSV database to provide CVE and other vulnerability information
SBOM output: Exports results in SPDX 2.3 format
CLI and library: Provided as both a standalone binary (CLI) and a Go library

2. Installation

Build with Go 1.21 or later:

cdxgen

Mon, 01 Jan 0001 00:00:00 +0000

cdxgen is an open source SBOM generation tool managed by OWASP (Open Web Application Security Project). It analyzes source code, build artifacts, and container images to automatically generate SBOMs in CycloneDX format.

GitHub: https://github.com/CycloneDX/cdxgen
License: Apache-2.0

Features

Wide language and ecosystem support: Java (Maven/Gradle), Node.js, Python, Go, Rust, PHP, Ruby, .NET, and 20+ more
Multiple scan targets: Source code directories, container images, GitHub repositories
CycloneDX standard output: Supports CycloneDX 1.4/1.5/1.6 in JSON and XML formats
REPL mode: Interactive interface for exploring and querying SBOMs
CI/CD integration: Easy integration with GitHub Actions, GitLab CI, and other major pipelines

Installation

Install with Node.js 18 or later:

Syft

Mon, 01 Jan 0001 00:00:00 +0000

Syft is an open source SBOM generation CLI tool developed by Anchore. It scans container images, filesystems, and archives to identify included packages and generates SBOMs in SPDX or CycloneDX format.

GitHub: https://github.com/anchore/syft
License: Apache-2.0

Features

Multiple scan targets: Container images (Docker, OCI), local filesystems, tar archives
Wide ecosystem support: Alpine (apk), Debian/Ubuntu (dpkg), RPM, Python, Java, Go, Node.js, Ruby, Rust, and more
Standard output formats: SPDX 2.2/2.3 (JSON, tag-value), CycloneDX 1.4/1.5 (JSON, XML), Syft JSON
Grype integration: Pairs naturally with Anchore’s Grype vulnerability scanner for SBOM-based vulnerability analysis
Easy installation: Single binary distribution, no additional runtime required

Installation

Script Installation (Linux/macOS)

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Homebrew (macOS)

brew install syft

Docker

docker pull anchore/syft

Basic Usage

(1) Scan a Container Image

# Scan a Docker image and output SPDX JSON
syft ubuntu:22.04 -o spdx-json=sbom.spdx.json

# Output as CycloneDX JSON
syft ubuntu:22.04 -o cyclonedx-json=sbom.cdx.json

(2) Scan a Local Directory

syft dir:/path/to/project -o spdx-json=sbom.spdx.json

(3) View Results in Terminal

# Print package list to terminal
syft ubuntu:22.04

# Output as JSON to stdout
syft ubuntu:22.04 -o json

(4) Vulnerability Scanning with Grype

# Generate SBOM with Syft and analyze vulnerabilities with Grype
syft ubuntu:22.04 -o json | grype

CI/CD Integration Example

# GitHub Actions example
- name: Generate SBOM with Syft
 uses: anchore/sbom-action@v0
 with:
 image: myapp:latest
 format: spdx-json
 output-file: sbom.spdx.json
- name: Upload SBOM
 uses: actions/upload-artifact@v4
 with:
 name: sbom
 path: sbom.spdx.json

References

Syft GitHub: https://github.com/anchore/syft
Grype (vulnerability scanner): https://github.com/anchore/grype
SPDX Standard: https://spdx.dev/
CycloneDX Standard: https://cyclonedx.org/

Dependency-Track

Mon, 01 Jan 0001 00:00:00 +0000

Dependency-Track is an open source SBOM management and vulnerability analysis platform managed by OWASP. It continuously monitors component-level vulnerabilities based on uploaded SBOMs (CycloneDX, SPDX) and automatically evaluates policy violations.

GitHub: https://github.com/DependencyTrack/dependency-track
Official docs: https://docs.dependencytrack.org/
License: Apache-2.0

Features

SBOM-based continuous monitoring: Automatically tracks the latest vulnerabilities per component after uploading SBOMs in SPDX or CycloneDX format
Multiple vulnerability data sources: NVD, OSV, GitHub Advisories, VulnDB, and more
Policy engine: Define rules for license policies, vulnerability severity thresholds, and component allowlists for automatic evaluation
REST API: Integrate with CI/CD pipelines to automatically upload SBOMs and receive feedback at build time
Web UI dashboard: View per-project risk scores, vulnerability status, and license distribution at a glance
Notifications: Send new vulnerability alerts via Slack, email, Webhook, and other channels

Installation

Using Docker Compose is the simplest approach:

Building an Automated Open Source Management Environment: cdxgen + Dependency-Track

Mon, 01 Jan 0001 00:00:00 +0000

For companies just starting with open source management, we recommend the cdxgen + Dependency-Track combination as a toolset that can establish a basic automation environment within a single day.

This guide walks you through every step, from installation and configuration to setting up a license and vulnerability inspection environment and running day-to-day operations.

Why cdxgen + Dependency-Track

Open source management comes down to two essentials.

Know what is inside — generating an SBOM (Software Bill of Materials)
Continuously monitor risk — detecting vulnerabilities (CVEs) and license policy violations

cdxgen handles the first, and Dependency-Track handles the second. Both tools are free open source under the Apache-2.0 license.

SCANOSS

Mon, 01 Jan 0001 00:00:00 +0000

SCANOSS is a Software Composition Analysis (SCA) tool that can identify open source components not only at the file level but down to the snippet (code fragment) level. It detects license and copyright information by matching against a knowledge base (OSSKB, Open Source Knowledge Base) that indexes more than 100 million files, and automatically generates SBOMs in CycloneDX and SPDX formats.

GitHub: https://github.com/scanoss
Official site: https://www.scanoss.com
License: Apache-2.0

1. Key features

Snippet-level matching: Can trace the origin even when a portion of code, rather than an entire file, has been copied or modified
Large-scale knowledge base: OSSKB indexes more than 100 million open source files — covering major package repositories and GitHub
Automatic SBOM generation: Supports CycloneDX (JSON/XML) and SPDX format output
Both CLI & REST API: Provides both the scanoss-py (Python) CLI and a REST API, making automation integration easy
CI/CD pipeline integration: Can scan with a single command in CI environments such as GitHub Actions

2. Installation

Install via pip in a Python 3.8 or later environment.

§3.1 Program Foundation

Mon, 01 Jan 0001 00:00:00 +0000

§3.1.1 Policy

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

A company without an Open Source Policy risks distributing software while developers are unaware of their open source license obligations. This can lead to serious legal and business risks, such as copyright infringement lawsuits, mandatory source code disclosure, and termination of business contracts. §3.1.1 requires organizations to establish a documented policy governing open source license compliance for supplied software and to communicate it so that all Program Participants within the organization are aware of the policy’s existence. This clause forms the foundation of the entire ISO/IEC 5230 program; all subsequent clauses (competence, processes, artifacts, etc.) operate on top of this policy.

§3.2.1 External Inquiry Response

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

Companies distributing software may receive inquiries from third parties (customers, open source copyright holders, researchers, etc.) regarding open source license compliance. Failure to respond to these inquiries in a timely manner risks escalation into copyright infringement disputes. §3.2.1 requires organizations to establish a publicly available means of contact for receiving external inquiries and to document a procedure internally for systematically responding to those inquiries. This clause requires both a public channel (Verification Material 3.2.1.1) and an internal response procedure (Verification Material 3.2.1.2).

§3.3.1 SBOM

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

Without knowing what open source components are included in the supplied software, it is impossible to fulfill license obligations or respond to security vulnerabilities. §3.3.1 requires the establishment of a procedure for identifying, tracking, reviewing, approving, and archiving the open source components that make up supplied software, and maintaining component records (SBOM) that demonstrate the procedure has actually been followed. This clause forms the foundation for operating the SBOM, which is the core infrastructure of open source license compliance and Security Assurance.

§3.4.1 Artifacts

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

To fulfill license obligations, Compliance Artifacts such as notices and source code packages must actually be prepared and provided with the software. §3.4.1 requires the establishment of a procedure for preparing the Compliance Artifacts required by the identified licenses and distributing them with the supplied software, as well as a procedure for retaining copies of the artifacts for a certain period. This clause connects the results of the §3.3 review and approval stage to actual distribution and archiving.

§3.5.1 Contributions

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

Many companies contribute code, documentation, bug reports, and more to external open source projects. Contribution activities build community trust and expand technical influence, but they also carry the risk of unintentionally disclosing company code or patents. §3.5.1 requires organizations that allow external open source contributions to establish a documented policy and procedure governing contributions, and to ensure that Program Participants are aware of their existence. This clause does not apply to organizations that do not allow contributions, but if they do, all three verification materials must be in place.

§3.6.1 Conformance

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

To receive official recognition of ISO/IEC 5230 conformance, the program defined in §3.1.4 must be confirmed in a document as satisfying all requirements of this specification. §3.6.1 is the stage for officially affirming that all clauses from §3.1 through §3.5 have been satisfied. This clause is the final confirmation procedure that completes adherence to the specification, requiring the organization’s official confirmation that the program satisfies all requirements of ISO/IEC 5230:2020 version 2.1.

§4.1 Program Foundation

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.1 Policy

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

§4.1.1 corresponds to ISO/IEC 5230 §3.1.1 (License Compliance Policy), but the focus shifts to Security Assurance. A policy that systematically manages known and newly discovered vulnerabilities in open source components of the supplied software must be documented and communicated internally. The key difference from ISO/IEC 5230 §3.1.1 is the requirement for a periodic review process for the policy itself and its communication method. It is not enough to establish a policy; a review system must be in place to ensure the policy always remains valid and up to date.

§4.2.1 Access

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

§4.2.1 has the same structure as ISO/IEC 5230 §3.2.1 (External Inquiry Response), but the focus shifts from license compliance inquiries to vulnerability inquiries. A publicly visible channel must be established for third parties to make inquiries about known or newly discovered vulnerabilities in the supplied software, and an internal procedure for systematically handling these inquiries must be documented. Since the security vulnerability reporting channel is connected to the Coordinated Vulnerability Disclosure (CVD) procedure, a system for safely receiving and processing vulnerabilities discovered by security researchers or customers is required.

§4.3.1 SBOM

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

§4.3.1 has the same basic structure as ISO/IEC 5230 §3.3.1 (SBOM), but the emphasis differs. While 5230 covers the SBOM for license management of open source components, §4.3.1 of 18974 emphasizes continuously recording and retaining the SBOM throughout the entire software lifecycle. In particular, the SBOM must be maintained even after deployment so it can be integrated with the vulnerability monitoring in §4.3.2 Security Assurance. Without an SBOM, post-deployment impact analysis for newly published CVEs (§4.1.5 Method 5) cannot be performed.

§4.4.1 Completeness

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

§4.4.1 corresponds to ISO/IEC 5230 §3.6.1 (Conformance). A document must be prepared affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974. The structure is the same as 5230 §3.6.1, but the difference is that the subject of confirmation covers all 25 Verification Material items of 18974. When preparing for ISO/IEC 5230 and 18974 certification simultaneously, it is efficient to conduct an integrated review of the common items of both standards and then additionally confirm the 9 items exclusive to 18974 (marked with ★).

0. Exploring OpenChain

Mon, 01 Jan 0001 00:00:00 +0000

1. What is the OpenChain Project?

Software today is growing ever larger and more complex. Developing a single piece of software may involve not only internally developed code but also open source, third-party software, vendor SDKs, and a wide variety of software across the software supply chain.

If even one organization in this complex software supply chain fails to comply with open source license obligations or does not provide accurate open source information, the company ultimately distributing the software will inevitably fail to meet its open source license compliance obligations. This can lead to lawsuits and the suspension of product sales.

Appendix

Mon, 01 Jan 0001 00:00:00 +0000

Appendix 1. Roster of Responsible Personnel

No	Role	Responsibility	Required competencies	Owning organization	Owner
1	Open Source Program Manager (OSPM)	Holds overall responsibility for the company’s open source program.	Understanding of the software development process Understanding of copyright and patents Expert knowledge of open source license compliance Communication skills	Open Source Management Team	[Name]
2	Legal	Assesses legal risks related to open source licenses and provides legal counsel.	Understanding of the open source ecosystem Expert knowledge of software copyright Expert knowledge of open source licenses Ability to assess legal risk	Legal Team	[Name]
3	IT	Operates and automates open source analysis tools.	Understanding of the open source license compliance process Understanding of open source analysis tools Expert knowledge of IT infrastructure Understanding of automation and CI/CD pipelines	IT Team	[Name]
4	Security	Operates open source security vulnerability analysis tools.	Understanding of DevSecOps Understanding of open source security vulnerability analysis tools Expert knowledge of known vulnerabilities and newly discovered vulnerabilities Ability to assess and manage risk	Security Team	[Name]
5	Development Culture	Supports in-house developers in actively using open source.	Understanding of the software development process Basic knowledge of open source license compliance Ability to design education and training Experience participating in open source communities	Development Team	[Name]
6	Quality	Verifies open source license obligations when distributing Supplied Software.	Understanding of the software development process Basic knowledge of open source license compliance Understanding of the open source policy Basic knowledge of open source licenses	Quality Assurance Team	[Name]
7	OSRB (Open Source Review Board)	Establishes and improves policies and processes for open source management.	Expert knowledge of open source policies and processes Experience operating a review board	OSRB	[Name]
8	OSPO (Open Source Program Office)	Supports contributions to external open source projects and the release of in-house projects as open source.	Experience participating in open source communities Ability to manage open source projects	OSPO	[Name]

onot

Mon, 01 Jan 0001 00:00:00 +0000

An open source notice file is a compliance artifact that provides users with copyright and license information for open source components included in supplied software. Writing notice files manually is error-prone and time-consuming. onot automates this process.

SK Telecom developed onot internally and released it as open source under the name onot. Kakao also contributed major features through collaborative development.

Features

onot takes an SBOM in SPDX format as input and automatically converts it into an open source notice file. It is Python-based, lightweight, and easy to use.

TRUSCA

Mon, 01 Jan 0001 00:00:00 +0000

Managing the vulnerabilities and licenses of open source components calls for an SCA (Software Composition Analysis) tool. Several commercial products exist, but some organizations look for an open source tool they can install and run on their own infrastructure.

TRUSCA is a self-hosted SCA portal published for that purpose. Released under Apache 2.0, it brings vulnerabilities (CVE), license compliance, and SBOM management into a single screen. It is developed by Trusted OSS, a project that grew out of KWG community work.

§3.1.2 Competence

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

For an open source program to actually function, the people assigned to relevant roles must have the competence to perform those roles. If roles and responsibilities are only written in documents and the people responsible have no basic knowledge of open source license or security vulnerability management, the policies and processes will be nominal. §3.1.2 requires the organization to identify the roles involved in the program, define the competence required for each role, evaluate and record whether participants actually possess that competence. This clause advances the role structure defined in §3.1.1 Policy into a concrete competence framework.

§3.2 Relevant Tasks

Mon, 01 Jan 0001 00:00:00 +0000

§3.2.2 Effective Resources

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

For an open source program to actually function, it is not enough to just define roles. Actual personnel must be assigned to each role, and sufficient time and budget must be provided to carry out the work. §3.2.2 requires organizations to document the persons responsible for each program role, confirm that staffing and budget are appropriately allocated, and to have a method for accessing legal expertise, a procedure for assigning internal responsibilities, and a procedure for handling non-compliance cases. This clause consists of five verification material items and is the stage that implements the role structure defined in §3.1 Program Foundation into an actual operational framework.

§3.3.2 License Compliance

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

License obligations for open source components vary depending on the distribution format (binary, source code), whether modifications were made, and how they are combined with other components. §3.3.2 requires the program to have the capability to handle the common open source license use cases for open source components in the supplied software. This clause goes beyond simply identifying licenses to establishing procedures that define how to fulfill obligations for various distribution scenarios.

§3.6.2 Duration

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

ISO/IEC 5230 conformance does not remain valid indefinitely once obtained. When a new version of the specification is published, a program that was conformant against the previous version retains its conformance for only 18 months after the new version is published. §3.6.2 requires organizations to maintain a document confirming that the program meets all requirements of the specification within the past 18 months of obtaining conformance. This clause serves as a mechanism to ensure that open source compliance programs remain continuously operational rather than stopping at formal certification.

§4.1.2 Competence

Mon, 01 Jan 0001 00:00:00 +0000

★ 18974 Exclusive Items — Documented Evidence Strength

§4.1.2.3·§4.1.2.5·§4.1.2.6 are ISO 18974 exclusive (★) items requiring Documented Evidence. A simple procedure document is insufficient — you must retain actual execution records (participant list, review meeting minutes, internal best practice comparison results). For a detailed explanation of the strength difference, see §4.1.5 Standard Practices — Documented Evidence Notice.

1. Clause Overview

§4.1.2 has the same basic structure as ISO/IEC 5230 §3.1.2 (Competence), but requires 3 additional Verification Material items. While 5230 requires three items — a list of roles, a definition of competencies per role, and evidence of competency assessment — 18974 additionally requires a list of participants and their role mappings (4.1.2.3), evidence of periodic review and process changes (4.1.2.5), and verification of alignment with internal best practices (4.1.2.6). These three additional items require demonstrating that the competence framework is not merely formal, but is actively kept up to date and aligned with industry standards.

§4.2 Relevant Tasks

Mon, 01 Jan 0001 00:00:00 +0000

§4.2.2 Effectively Resourced

Mon, 01 Jan 0001 00:00:00 +0000

★ 18974 Exclusive Items — Documented Evidence Strength

§4.2.2.3 is an ISO 18974 exclusive (★) item requiring Documented Evidence. The method for accessing vulnerability resolution resources is not merely a procedure document — you must retain actual resource utilization records (security advisory contracts, account issuance records, access logs). For a detailed explanation of the strength difference, see §4.1.5 Standard Practices — Documented Evidence Notice.

1. Clause Overview

§4.2.2 corresponds to ISO/IEC 5230 §3.2.2 (Effectively Resourced) but has two key differences. First, while 5230 requires 5 Verification Materials, 18974 requires 4. The §3.2.2.5 item from 5230 (procedure for reviewing and correcting non-compliance cases) is absorbed into §4.1.5 Standard Practice Implementation in 18974. Second, §3.2.2.3 (method for accessing legal expertise) is replaced in §4.2.2.3 by vulnerability resolution expertise. Rather than legal expertise for license matters, the organization must secure technical and security expertise capable of actually resolving known vulnerabilities and document how that expertise is accessed.

§4.3.2 Security Assurance

Mon, 01 Jan 0001 00:00:00 +0000

★ 18974 Exclusive Items — Documented Evidence Strength

§4.3.2.1·§4.3.2.2 are ISO 18974 exclusive (★) items requiring Documented Evidence. Not merely a “vulnerability response procedure document,” but actual execution records for each CVE (scan results, CVSS scores, remediation history, VEX issuance, customer notification history) must be retained. For a detailed explanation of the strength difference, see §4.1.5 Standard Practices — Documented Evidence Notice.

1. Clause Overview

§4.3.2 is the core clause of ISO/IEC 18974 and is a new clause exclusive to 18974 that does not exist in ISO/IEC 5230. It requires establishing a procedure covering the entire process — vulnerability detection → risk assessment → remediation decision → customer consent (where applicable) → remediation → post-deployment newly disclosed vulnerability response → continuous monitoring — for each open source component in the SBOM, and maintaining implementation records. If §4.1.5 requires the existence of vulnerability handling methods, §4.3.2 requires that those methods have actually been applied to each component with records retained.

§4.4.2 Duration

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

§4.4.2 has the same structure as ISO/IEC 5230 §3.6.2 (Duration). It requires organizations to maintain a retrospective document confirming that all requirements of the specification have been met during the past 18 months of obtaining conformance (this is a past-fact confirmation, not a future commitment). When a new version of the specification is published, conformance under the previous version is maintained for a grace period of 18 months, during which it is recommended to update to the latest version.

ISO/IEC 5230 Conformance Guide

Mon, 01 Jan 0001 00:00:00 +0000

This guide walks through each requirement clause of ISO/IEC 5230 (OpenChain License Compliance) one by one. It explains what verification materials each clause requires, how to comply, and what sample documents can be used directly.

Author : OpenChain Korea Work Group / CC BY 4.0

Target Audience

Open source compliance officers and open source program managers
Personnel at companies preparing for ISO/IEC 5230 certification
Practitioners who want to review their existing open source management framework against ISO standards

How to Use This Guide

Relationship with the Enterprise Open Source Management Guide

The Enterprise Open Source Management Guide explains how to implement open source management in practice (policies, processes, tools, and organization).

This guide (ISO/IEC 5230 Conformance Guide) organizes, clause by clause, what must be demonstrated for certification.

Guide	Focus	When to Use
Enterprise Open Source Management Guide	Practical implementation (How to implement)	When building an open source management framework from scratch
ISO/IEC 5230 Conformance Guide	Verification material criteria by clause (What to prove)	When preparing for certification or conducting a self-assessment

The two guides are complementary. Each clause page provides cross-links to the corresponding section of the Enterprise Open Source Management Guide.

§3.1.3 Awareness

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

Even participants with the right roles and competencies will only participate in a perfunctory manner if they do not understand the purpose of the open source program and the meaning of their own contribution to the overall compliance framework. §3.1.3 requires the organization to evaluate and record that Program Participants actually understand the program’s objectives, how they contribute, and the consequences of failing to follow the program’s requirements. This clause is the next step after §3.1.2 Competence (possessing knowledge and skills), forming the practical motivation by connecting the competence participants hold to the program’s purpose.

§3.3 Content Review and Approval

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.3 Awareness

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

§4.1.3 has the same Verification Material structure as ISO/IEC 5230 §3.1.3 (Awareness). It requires that awareness of program objectives, how individuals contribute to the program, and the implications of non-compliance be assessed and recorded for Program Participants. The difference from 5230 is that the focus of the awareness assessment shifts to Security Assurance. Participants must be aware not only of license compliance but also of the vulnerability management process, CVD procedures, and CVSS-based response criteria.

§4.3 Content Review and Approval

Mon, 01 Jan 0001 00:00:00 +0000

ISO/IEC 18974 Conformance Guide

Mon, 01 Jan 0001 00:00:00 +0000

This guide explains each requirement clause of ISO/IEC 18974 (OpenChain Security Assurance) one by one. It describes what Verification Materials each clause requires, how to comply, and what sample documents can be used immediately.

Author : OpenChain Korea Work Group / CC BY 4.0

Target Audience

Security managers and open source program managers at organizations establishing an open source security assurance framework for the first time
Engineers building open source vulnerability management processes in DevSecOps environments
Organization staff preparing to add ISO/IEC 18974 certification after obtaining ISO/IEC 5230 certification

Relationship with ISO/IEC 5230

ISO/IEC 18974 adds a security layer on top of ISO/IEC 5230

ISO/IEC 5230 (License Compliance) covers the foundational program for systematically managing open source license obligations.

ISO/IEC 18974 (Security Assurance) adds a security layer of vulnerability detection, assessment, and response on top of that foundation. The two standards share core infrastructure such as policy, competence, and SBOM, and 18974 extends and deepens this from a security perspective.

Category	ISO/IEC 5230	ISO/IEC 18974
Purpose	License Compliance	Security Assurance
Verification Materials	24 items	25 items
Common Foundation Clauses	—	16 (corresponding to 5230)
18974-Exclusive Clauses	—	9 (security-specific)
Key Additional Elements	—	Vulnerability detection, response, and CVD procedures

§3.1.4 Program Scope

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

If it is unclear whether the open source program applies to the entire organization or only to specific product lines or business units, the boundaries of compliance activities become vague and accountability becomes unclear. §3.1.4 requires a documented written statement that clearly defines which software, organizational units, and distribution channels the open source program applies to, and what is outside the scope. The scope may vary depending on the organization’s size and business model, and this clause requires that choice to be explicitly recorded.

§3.4 Compliance Artifacts

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.4 Program Scope

Mon, 01 Jan 0001 00:00:00 +0000

★ 18974 Exclusive Items — Documented Evidence Strength

§4.1.4.2·§4.1.4.3 are ISO 18974 exclusive (★) items requiring Documented Evidence. Metrics must include actual measurement data; continuous improvement must retain review/audit meeting minutes. For a detailed explanation of the strength difference, see §4.1.5 Standard Practices — Documented Evidence Notice.

1. Clause Overview

§4.1.4 is the clause from ISO/IEC 5230 §3.1.4 (Program Scope) with 2 additional Verification Materials. While 5230 only requires a written statement that clearly defines the program’s scope, 18974 additionally requires a set of performance metrics the program seeks to improve upon (4.1.4.2) and documented evidence from each review, update, or audit demonstrating continuous improvement (4.1.4.3). These two items are intended to demonstrate that the security assurance program is not static compliance, but a system with measurable goals that continuously improves.

§4.4 Conformance

Mon, 01 Jan 0001 00:00:00 +0000

4. Tools

Mon, 01 Jan 0001 00:00:00 +0000

Requirements covered by this section

ISO/IEC 5230: 3.3.1.2
ISO/IEC 18974: 4.3.1.2

1. Source Code Scanning Tools

In the open source identification and inspection stages of the open source process, you can use source code scanning tools. Source code scanning tools help identify the open source included in the supplied software and extract license and copyright information. These tools range from open source-based tools that can be used for free to commercial tools. Each tool has its strengths, but no tool provides a perfect solution to all problems. Therefore, companies should select the appropriate tool that fits the characteristics and requirements of their supplied software.

§3.1.5 License Obligations

Mon, 01 Jan 0001 00:00:00 +0000

1. Clause Overview

The most critical task when including open source components in software is accurately understanding the obligations, restrictions, and rights imposed by the licenses applied to those components. Distributing without reviewing license obligations can result in serious legal risks such as mandatory source code disclosure, missing copyright notices, and patent clause violations. §3.1.5 requires the establishment of a procedure for reviewing all identified licenses to determine their obligations, restrictions, and rights, and for recording the results. This procedure forms the foundation of the §3.3.2 License Compliance process.

§3.5 Community Engagement

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.5 Standard Practice Implementation

Mon, 01 Jan 0001 00:00:00 +0000

Evidence Strength for ISO 18974 Exclusive (★) Items — Documented Evidence

Unlike ISO/IEC 5230, ISO/IEC 18974 requires “Documented Evidence” for its 9 exclusive items (★: §4.1.2.3·4.1.2.5·4.1.2.6·4.1.4.2·4.1.4.3·§4.1.5.1·4.2.2.3·4.3.2.1·4.3.2.2). This is a stronger evidence level than the documented procedure or document required for general items.

Strength	ISO Expression	Compliance Level	Certification Audit
Weak	`document`	Artifact existence	Format review
Medium	`documented procedure`	Documented procedure + intent to follow	Procedure body review
Strong	`Documented Evidence`	Procedure + records of actual execution (evidence pack)	Verification of actual execution evidence: logs, tickets, issue tracking results, etc.

§4.1.5.1 requires not merely “procedure documents” for each of the 8 methods, but also records of activities actually performed (scan logs, tickets, approval history, VEX issuance records, etc.) to pass certification.

ISO/IEC 5230 vs 18974 Comparison

Mon, 01 Jan 0001 00:00:00 +0000

1. Relationship Between the Two Standards

ISO/IEC 5230 and ISO/IEC 18974 are both international open source standards led by the OpenChain Project, but they address different problems. 5230 covers open source license compliance (fulfillment of copyright obligations, SBOM management, and distribution of Compliance Artifacts), while 18974 covers open source security assurance (vulnerability detection, assessment, response, and CVD). The two standards do not have a complete superset/subset relationship. They share 9 common clauses covering policy, competence, SBOM, and similar areas, but each has its own exclusive clauses — 5230 has clauses for license compliance, artifacts, and contributions, while 18974 has clauses for Standard Practice Implementation and Security Assurance.

Trusted OSS

Mon, 01 Jan 0001 00:00:00 +0000

Trusted OSS grew out of KWG community work and was published by the author of this guide. Its documentation is released under CC BY 4.0 and its code under MIT and Apache 2.0.

Site: https://trustedoss.github.io/en/

Trusted OSS covers four areas.

Generating self-certification deliverables

It produces the documents required for ISO/IEC 5230 and ISO/IEC 18974 self-certification through a conversation with an AI agent: organizational setup, policy, processes, SBOM analysis, vulnerability reports, training curricula, and a draft conformance statement. It follows the same six steps described in the open source management guide.

§3.6 Adherence to the Specification

Mon, 01 Jan 0001 00:00:00 +0000

7. AI Compliance

Mon, 01 Jan 0001 00:00:00 +0000

Requirements Covered in This Section

ISO/IEC 42001: §5.2 (AI Policy) · §6.1.2 (AI Risk Assessment) · §7.5 (Documentation) · §8.5 (AI Lifecycle) · §8.6 (AI Data) · §8.8 (External AI Procurement)

AI systems make extensive use of open source frameworks, pre-trained models, and open datasets. Companies that operate an open source management system (ISO/IEC 5230 · 18974) must apply open source compliance principles during the AI system development phase as well. In addition, development environments that leverage AI coding tools (GitHub Copilot, Claude Code, Cursor, etc.) require a new management framework to address license contamination and the introduction of vulnerable packages.

Training Slides

Mon, 01 Jan 0001 00:00:00 +0000

Training Slides

This page provides a training deck covering the full enterprise open source governance process. It reorganizes the Enterprise Open Source Management Guide into a 4-hour training format.

Open in full screen →

Course Structure

Part	Title	Key Topics
Part 0	Introduction	Course objectives · 4-hour roadmap
Part 1	Understanding the Standards	ISO/IEC 5230 · 18974 · 42001 + OpenChain
Part 2	Six Core Elements	Organization · policy · process · tools · training · conformance
Part 3	AI Compliance	Global AI regulations · model licensing · AI SBOM · supply chain security
Part 4	Live Demo	SBOM generation → Dependency-Track → VEX triage
Part 5	Closing	Recap · next steps · Q&A

Slide count: ~99 slides
Estimated duration: 4 hours (Part 3 AI expanded to 75 minutes)
Audience: Enterprise open source compliance officers, legal teams, OSPOs

License

These slides are released under the CC-BY-4.0 license. You are free to use them as internal corporate training materials.