This section organizes the content covered in the preceding sections into practical recommendations and a checklist. Organizations adopting SBOM for the first time can follow the checklist in order, while organizations already operating one can use it to check for missing items.

Key Recommendations

Procurement and Generation

• When procuring software, specify the SBOM provision requirement in contracts and purchase terms. Specify which elements are to be provided, in what format, and when.
• Generate SBOMs in the SPDX or CycloneDX format, choosing based on your counterparty’s requirements and your own toolchain.
• Automatically generate SBOMs at build time within the SSDLC and CI/CD pipeline to ensure accuracy and timeliness.
• Put in place a workflow to regenerate the SBOM whenever a new component is introduced or an existing component is updated.

Data Quality

• Include complete metadata such as component name, version, license, and unique identifier. Because the minimum elements are only a floor, add fields to fit your own use case.
• Pin components withPURL or CPE so that traceability is not lost even when names or versions change.
• Pin the version of the generation tool, verify its provenance, and attach hashes and signatures to the output to ensure integrity.

Vulnerabilities and Licenses

• Link the SBOM to vulnerability databases and advisories to maintain continuous visibility into security posture.
• Reflect any applied patches or mitigations in your own SBOM.
• Exchange vulnerability exploitability status using VEX and CSAF, and prioritize response based on risk.
• Analyze the license compatibility of all components to identify conflicts that may arise from combining them, in advance.

Storage and Operations

• Store and transmit SBOMs securely using encryption and access control, and clearly distinguish between public and private scope.
• Check the accuracy and completeness of SBOMs through regular audits.
• Run training and awareness programs on the role of SBOM, from developers to the security team.

Adoption Checklist

A checklist for reviewing what has been done at each stage.

Next Steps

If you develop AI systems or exchange them across the supply chain, you need to add an AI-specific layer — models, datasets, and training compute — on top of the SBOM capabilities covered in this guide. The component, license, and vulnerability management practices of a general SBOM carry over directly into the software layer of an AI BOM. This is covered in detail in the separateAI SBOM Compliance Guide.

Sources

NTIA (2021).The Minimum Elements For a Software Bill of Materials (SBOM). CISA (2024).Framing Software Component Transparency, Third Edition. CERT-In.Technical Guidelines on Software Bill of Materials (SBOM). Regulation (EU) 2024/2847 — Cyber Resilience Act. (all accessed: June 14, 2026)

An SBOM creates value only when it is delivered along the supply chain, but it is also sensitive material that contains trade secrets and attack surface. Without governance that determines who shares what, and how, excessive disclosure heightens risk, and excessive restriction forfeits value.

Access Control and Disclosure Scope

Access to SBOM data is managed through Role-Based Access Control (RBAC). Because access needs differ by stakeholder, general users are granted read-only access, administrators are granted edit and update access, and sensitive information is granted restricted access.

For disclosure scope, maintaining two versions is common practice.

• Public SBOM: Contains non-sensitive information that can be shared with all stakeholders.
• Private SBOM: Contains sensitive information, such as vulnerabilities, and only approved parties can access it.

Regulation reflects this distinction as well. The EU Cyber Resilience Act does not require an SBOM to be disclosed to the general public, but requires it to be retained in case market surveillance authorities request it. Amid the tension between consumers wanting a more complete SBOM and producers wanting to reduce disclosure, the public/private split is a practical device that reconciles the two.

Secure Sharing Channels

When delivering an SBOM, both integrity and confidentiality need to be preserved.

• Use a secure protocol such as HTTPS for transmission, and ensure integrity and confidentiality through digital signatures or encryption.
• Use a sharing platform equipped with access control and audit capabilities.
• Use API integration for automated exchange between systems, and dedicated repositories for industry- or community-level sharing.

Attach a digital signature to the document so recipients can verify its authenticity and check for tampering, and clearly mark which information is public and which is private.

Roles and Responsibilities

An SBOM program works only when multiple departments share responsibility for it. It should include an executive sponsor, project leads, systems and design engineers, procurement specialists, and operations personnel, adding IT, cybersecurity, and maintenance staff as security needs require. When roles are scattered, responsibility scatters with them, so establishing clear ownership is the starting point.

The key activities in building governance are as follows.

• Identify key stakeholders: Include representatives from development, IT operations, security, procurement, legal, and business leadership, and be sure to include a cybersecurity expert.
• Define responsibilities and assign ownership: Decide who will handle SBOM generation and consumption, vulnerability monitoring, supplier engagement, and security data management, and designate a cybersecurity expert as the program owner or co-owner.
• Establish a governance structure: A governance body with participation from stakeholders across the organization develops policies, standards, and processes, and implements data protection controls.
• Train and monitor: Train personnel on SBOM security requirements and secure data handling, and continuously assess the program’s security posture through regular audits, adjusting it to evolving threats and compliance requirements.

Sources

CISA (2024).Framing Software Component Transparency, Third Edition. CERT-In.Technical Guidelines on Software Bill of Materials (SBOM). Regulation (EU) 2024/2847 — Cyber Resilience Act, Annex I Part II. (all accessed: June 14, 2026)

The most direct use of an SBOM is vulnerability management. With a component list in hand, affected assets can be looked up immediately when a new vulnerability is disclosed. But listing components in an SBOM brings along every past CVE for those components, creating a problem of exploding false positives. Vulnerability Exploitability eXchange (VEX) is what solves this problem.

SBOM-Based Vulnerability Tracking

The basic flow of tracking is simple. Each component in an SBOM is matched against vulnerability databases (NVD, CVE) using anidentifier such as PURL or CPE to map known vulnerabilities. A supplier can pre-map vulnerability information into an SBOM and provide customers with an enriched SBOM, while a consumer can link its own SBOM to vulnerability data through an API or data feed to set response priorities.

To increase effectiveness, a shift-left approach that moves checks earlier in development is recommended. Integrating security tools into the development pipeline and automatically analyzing SBOM data at early stages such as build and packaging catches vulnerabilities before release.

VEX: Sorting Out Exploitability

VEX is a document in which a manufacturer asserts “is this vulnerability actually exploitable in our product,” helping consumers make priority judgments. Where an SBOM answers “what is inside,” VEX answers “does a known vulnerability inside actually affect this product.” Even if a component has a vulnerability, it may be unexploitable if the affected code path is never invoked; VEX states this status explicitly, reducing unnecessary response effort.

A VEX document notates the vulnerability status of a specific product using the following four states.

• Not affected: No remediation is needed for this vulnerability.
• Affected: A fix or mitigating action is recommended.
• Fixed: The vulnerability fix is included in the given product version.
• Under Investigation: Whether the product is affected has not yet been confirmed and will be updated later.

VEX is not a single format; CSAF VEX, OpenVEX, and CycloneDX VEX coexist. CycloneDX is distinguished by expressing VEX natively within the format itself.

CSAF: Structuring Advisories

Common Security Advisory Framework (CSAF) 2.0 is a standard that structures security advisories in a machine-readable form, and it includes a VEX profile. OASIS approved it as a formal standard in November 2022. Where VEX communicates exploitability status, CSAF delivers a detailed advisory that includes a vulnerability description, affected versions, a severity assessment (CVSS score), and recommended mitigation steps.

The practical turning point for adoption was Red Hat. Red Hat’s Product Security team began publishing CSAF/VEX files for every CVE in its database in 2023, and has since moved to full production, publishing them on an ongoing basis.

Case Study: Log4Shell

The Log4j vulnerability (Log4Shell), disclosed in December 2021, is a case that shows how SBOM, VEX, and CSAF interlock.

Figure 1. The interplay of SBOM, VEX, and CSAF in the Log4Shell response(source: reconstructed from CERT-In technical guidelines. Retrieved 2026-06-14)

When the vulnerability was disclosed, maintainers issued a VEX stating the exploitable status, followed by a CSAF advisory containing the vulnerability description, affected versions, CVSS 10.0 (the highest severity), and mitigation steps. Organizations that included Log4j as a component integrated this VEX and CSAF data into their own SBOMs, identifying the affected parts of their systems and setting response priorities. The core point of this case is that, had an SBOM already been in place, “where is Log4j” could have been answered with a single query.

Sources

OASIS Open (2022).CSAF 2.0.https://www.oasis-open.org/2022/11/21/new-version-of-csaf-standard/. CISA.Vulnerability Exploitability eXchange (VEX).https://www.cisa.gov/sbom. OpenVEXhttps://github.com/openvex. NVD.CVE-2021-44228.https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Red Hat (2023).VEX files now available. (All retrieved: 2026-06-14)

An enterprise that has built an open source program (open source policy / process / tools / organization) conforming to all the requirements of ISO/IEC 5230 and ISO/IEC 18974 must document and declare the following two items.

(1) Confirming That Standard Requirements Are Met

ISO/IEC 5230 and ISO/IEC 18974 require a document confirming that the program meets all requirements, as follows:

To this end, an enterprise must prepare a document containing the following content:

The open source program of [Company Name] meets all the requirements of ISO/IEC 5230:2020 (open source license compliance) and ISO/IEC 18974 (open source security assurance).
This can be confirmed through the following documents and processes:
1. Open source policy document
2. Open source process document
3. Open source training and assessment records
4. SBOM (Software Bill of Materials) management system
5. Open source license compliance artifact generation and retention system
6. Open source security vulnerability management system
7. External inquiry response process records
[Date]
[Signature of Open Source Program Manager]

(2) Declaring Continued Conformance Assurance

ISO/IEC 5230 and ISO/IEC 18974 also require a document confirming that all requirements continue to be met for 18 months after obtaining conformance certification:

To this end, an enterprise must prepare and periodically update a document containing the following content:

[Company Name] guarantees that it will maintain a state of meeting all requirements for at least 18 months after obtaining conformance certification for ISO/IEC 5230:2020 (open source license compliance) and ISO/IEC 18974 (open source security assurance).
To this end, the following activities are carried out:
1. Conduct an internal audit at least every 6 months to verify that all requirements continue to be met
2. Obtain an external expert review at least once a year to assess the program's effectiveness
3. Provide ongoing training and competency assessment for program participants
4. Regularly review and update the open source policy and processes
5. Monitor and respond to changes in new technology trends and legal requirements
[Date]
[Signature of Open Source Program Manager]

An enterprise can include this document in its open source policy or publish it on a publicly accessible website. For example,SK telecom publishes this content on its own open source portal site:https://sktelecom.github.io/compliance/iso5230/ Through this documentation, an enterprise satisfies all the requirements of ISO/IEC 5230 and ISO/IEC 18974, and can guarantee ongoing management and improvement of its open source license compliance and security assurance.

]]>https://haksungjang.github.io/en/docs/ai-sbom_guide/5-tools/Sun, 09 Aug 2026 17:03:59 +0900https://haksungjang.github.io/en/docs/ai-sbom_guide/5-tools/Introduces the key features and usage of open source tools that generate and analyze AI SBOMs, with actual execution screens.<![CDATA[

This section covers open source tools that automate AI SBOM compliance. It summarizes each tool’s key features, installation, and usage together with actual execution results. This elaborates, tool by tool, on the categories seen in the automation maturity map in3.9 AI SBOM.

There is a boundary worth stating honestly. Tools generate a BOM automatically, but they cannot guarantee that the license information in the generated BOM is accurate or that no components are missing. In the tool comparison below, OWASP AIBOM Generator fills in license information from model cards, while cdxgen quickly identifies dependencies but leaves the license field empty. Look at this difference when choosing a tool.

Tools at a Glance

Each tool automates part of the generation, analysis, or management stage. No single tool solves everything, so combine tools that generate AI SBOMs (OWASP AIBOM Generator, cdxgen) with tools that analyze security (Lab700x, Trivy) and a tool that manages them (Dependency-Track).

1. Training

No matter how excellent the policy and process an enterprise builds, they are useless if none of its employees pay any attention to them. For open source policy and process to work effectively within an enterprise, employee training is essential.

An enterprise must provide practical means, such as training and internal wikis, so that every program participant is aware that an open source policy exists within the organization and can carry out the necessary activities. Here, program participants refers to all employees involved in the enterprise’s software development, distribution, and contribution activities, including software developers, release engineers, and quality engineers.

To this end, the ISO standards commonly require a documented procedure for communicating the open source policy, as follows.

Many enterprises publish their open source policy document on an internal wiki site so that any employee can check what they need. In addition, they mandate open source policy training during new hire onboarding, and provide periodic training to program participants once a year or once every two years, so that every program participant is aware that the open source policy exists.

An enterprise must write up these methods and include them in the open source policy document, as in the example below.

5. Training and Assessment
All members holding a role defined in Chapter 4 must complete the advanced open source training course offered on the [Learning Portal]. This ensures familiarity with the open source policy, the related training policy, and how to look it up. Training records and assessment results are retained on the [Learning Portal] for at least 3 years.

An enterprise must make program participants aware of its open source policy, its open-source-related objectives, how participants can contribute to making the open source program effective, and the implications of failing to comply with program requirements. To this end, the enterprise must provide training, conduct assessments to confirm that program participants have correctly understood these points, and document and retain the assessment results.

The ISO standards commonly require documented evidence showing that program participants’ awareness has been assessed, as follows.

Accordingly, an enterprise can include content such as the following example in its open source policy.

1. Purpose
(1) Purpose of the Policy
This policy provides the following principles for the entire organization involved in software development, service, and distribution at OOO Corporation (hereinafter "the Company") to properly use open source software (hereinafter "open source").
1. Principles of open source compliance / security assurance
2. Principles for contributing to external open source projects
3. Principles for releasing internal projects as open source
These principles provide a way for every member of the Company to understand the value of open source, use open source correctly, and contribute to the open source community.
Every member of the Company can check the open source policy at the following link on the internal wiki: [internal_link]
(2) Consequences of Non-Compliance
Failure to comply with this policy may result in the following situations.
- The Company may receive external requests for open source license compliance.
- The Company may be forced to unintentionally disclose source code it developed.
- The Company may be sued by open source copyright holders.
- The Company may be fined for copyright infringement or breach of contract, or ordered to halt product sales.
- The Company's reputation may be damaged.
- The Company may breach a contract with a supplier and be subject to a claim for damages.
- The Company may be exposed to a serious security incident, causing substantial harm to the Company.
For these reasons, the Company regards violations of the open source policy seriously, and members or organizations that violate it may be subject to disciplinary action.
(3) How Members Can Contribute
Every member of the Company can contribute to the effectiveness of this policy and to improving the Company's compliance level by understanding the rationale and content of this policy and faithfully carrying out the required activities.

Assessment is explained in more detail again below.

Open source training also includes content on the open source contribution policy. Even if an enterprise has created an open source contribution policy, if internal members are unaware that it exists, there is a risk that indiscriminate contribution activity could cause harm to both individuals and the company.

To address this, the ISO/IEC 5230 standard requires a documented procedure that makes all program participants aware of the existence of the open source contribution policy, as follows.

Accordingly, an enterprise must provide open source training so that all in-house developers are aware that the open source contribution policy exists.

Creating training materials from scratch can also be difficult for someone new to the role. To help with this difficulty, NCSOFT made its internal open source training materials available to anyone by publishing the lesson slides (PPT) and lecture scripts on GitHub.

Additionally, Kakao, a leading domestic platform company, has also made its open source training materials for in-house developers publicly available for anyone to view.

If an enterprise has not yet created its own training materials, making use of the open source training materials from these leading enterprises is also a good approach.

2. Assessment

Once an enterprise has assigned an owner for each role, it must confirm that the assigned owner is qualified to perform the role based on education, training, and experience. Program participants with insufficient competency must also be given training to build sufficient competency. The enterprise must then assess whether each participant has the required competency and retain the results.

To this end, the ISO standards commonly require documented evidence that program participants’ competency has been assessed, as follows.

Accordingly, an enterprise must carry out training and assessment and retain the results, as follows.

1. The enterprise provides training so that each participant can acquire the necessary competencies.
2. An assessment is conducted based on the training content.
3. The assessment results are retained by the enterprise’s training system or HR department.

When there are hundreds or more program participants, making delivering training difficult, using the enterprise’s online training and assessment system is also a good approach.

Content such as this can be included in an enterprise’s open source policy as follows.

4. Roles, Responsibilities, and Competencies
To ensure the effectiveness of this policy, the roles and responsibilities and the competencies required of the owner of each role are defined as follows.
The responsible organization/owner and the required competency level for each role are defined in [Appendix 1. Assigned Owners].
5. Training and Assessment
All members holding a role defined in Chapter 4 must complete the advanced open source training course offered on the [Learning Portal]. This ensures familiarity with the open source policy, the related training policy, and how to look it up.
Training records and assessment results are retained on the [Learning Portal] for at least 3 years.

3. Open Source License Guide

To properly comply with open source licenses, one must accurately know the requirements of each open source license. However, since it is difficult for individual software developers to grasp all of this on their own, it is advisable for the Open Source Program Manager to summarize the requirements and cautions for common use cases of frequently used open source licenses and share them within the company.

The open source license guide should include the requirements for common open source license use cases, enabling development teams to properly comply with license obligations while using open source.

To this end, the ISO/IEC 5230 standard requires a documented procedure for handling common open source license use cases for the open source components within software to be distributed, as follows.

To handle open source license use cases, a license guide organized by open source license is needed. For a general guide to open source licenses and a summary of license obligations, theLicense Guide provided by the Korea Copyright Commission can be referenced.

TheObligations by License document within SK telecom’s open source guide is also a good resource.

https://sktelecom.github.io/guide/use/obligation/gpl-2.0/

An enterprise must provide the open source license guide in a location that members can easily access and reference.

4. Awareness-Raising Activities

To continuously raise program participants’ awareness of open source license compliance and security assurance, the following activities are carried out:

(1) Regular Newsletter Publication

• The Open Source Program Manager publishes an open-source-related newsletter once a month.
• The newsletter includes the latest open source trends, license compliance cases, security vulnerability information, and more.
• It is distributed by email to all program participants and also posted on the internal intranet.

(2) Workshops and Seminars

• Open-source-related workshops or seminars are held quarterly.
• External experts are invited to give talks on open source licenses, security, and the latest technology trends.
• Program participants are encouraged to attend, and attendance records are kept.

(3) Open Source Contribution Encouragement Program

• A program encouraging program participants to contribute to external open source projects is run.
• An incentive system for contribution activity is established, and outstanding contributors are selected and rewarded quarterly.
• Contribution activities are shared within the company and reflected in performance evaluations.

5. Measuring and Improving Training Effectiveness

To continuously measure and improve the effectiveness of the open source training program, the following activities are carried out:

(1) Training Program Evaluation Metrics

• The training program is evaluated using the following quantitative and qualitative metrics:
  • Training completion rate
  • Assessment test scores
  • Reduction rate in the number of license compliance violations
  • Reduction rate in security vulnerability response time
  • Program participant satisfaction score

(2) Feedback Collection and Analysis

• Feedback is collected from participants after every training program ends.
• Opinions on the training content, instructor, and training method are collected through an online survey.
• The collected feedback is analyzed to identify areas for improvement.

(3) Establishing a Continuous Improvement Plan

• Based on the evaluation metric results and feedback analysis, a training program improvement plan is established semiannually.
• The Open Source Program Manager reports the improvement plan to the OSRB and obtains approval.
• The approved improvements are reflected in the next training program, and their effectiveness is monitored.

Through these activities, program participants’ awareness of open source can be raised, and the effectiveness of the training program can be continuously improved.

6. Summary

By building the training, assessment, awareness-raising activities, and training-effectiveness measurement and improvement process described so far, an enterprise can satisfy the key requirements of the ISO/IEC 5230 and ISO/IEC 18974 standards.

Through this training and assessment system, an enterprise can raise program participants’ understanding of open source license compliance and security assurance and continuously improve their competency. In addition, through regular assessment and improvement activities, the effectiveness of the program can be continuously enhanced.

Ultimately, this will help raise an enterprise’s level of open source management, minimize the legal risk arising from open source use, and strengthen its ability to respond to security vulnerabilities.

An SBOM workflow is not completed by a single tool. The three capabilities of generation, vulnerability matching, and lifecycle management are split across different tools, and the common conclusion of recent tool comparison analyses is that no single tool covers all three areas completely. It is more accurate to think of it as assembling a pipeline from a combination of tools.

The Division of Labor Among Generation, Management, and Scanning

Figure 1. The three roles of SBOM tools(source: compiled from tool comparison analyses, 2026-01. Retrieved 2026-06-14)

In the generation space, Anchore’s Syft is regarded as “the dedicated tool that does SBOM generation, and only that, best.” Its attestation workflow, combined with the signing tool cosign, is mature. OWASP CycloneDX’s cdxgen is distinguished by broad support for multiple languages and container images, and by a dedicated AI BOM mode.

In the management space, OWASP Dependency-Track has established itself as a platform for monitoring component usage and security/license compliance across an organization’s entire application portfolio. Eclipse SW360 is another option centered on license compliance.

In the scanning space, Grype takes an SBOM as input and matches it against vulnerabilities, while Aqua Security’s Trivy is both a scanner and an SBOM generator.

Table 1. Classification of SBOM tools by role(source: compiled from tool comparison analyses, 2026-01. Retrieved 2026-06-14)

How Far Does Automation Go

It is important to honestly distinguish between areas where automation works well and areas that people must fill in.

Table 2. Automation maturity of SBOM tasks(source: compiled from tool comparison analyses. Retrieved 2026-06-14)

Tools do generation well. Put Syft or cdxgen into the build pipeline, and the component list fills in automatically. But whether the license field of a generated SBOM is accurate, whether the obligations of a non-standard license are met, and whether obligations propagate downstream without omission are things no tool guarantees automatically. This area is filled by policy and human review.

The Tool Itself Is an Attack Surface

Before trusting an automation tool, its own integrity must be verified. In January 2026, a case was reported in which an SBOM tool was implicated in two supply chain attacks within a short period, with the damage spreading to downstream projects. On this basis, some pipeline operators removed the tool in question.

The fact that an SBOM generation tool can itself become a target of supply chain risk requires combining hashes, signatures, and attestations at the generation and verification stages. This same concern lies behind CISA’s 2025 minimum elements draft adding Tool Name, Generation Context, and Component Hash as new fields. Avoiding the paradox that “an SBOM made by an untrustworthy tool cannot be trusted” requires pinning tool versions, verifying provenance, and signing the output.

Sources

Anchore.Syfthttps://github.com/anchore/syft,Grypehttps://github.com/anchore/grype. OWASP.cdxgenhttps://github.com/CycloneDX/cdxgen,Dependency-Trackhttps://dependencytrack.org/. Aqua Security.Trivyhttps://github.com/aquasecurity/trivy. EclipseSW360https://www.eclipse.org/sw360/. (All retrieved: 2026-06-14)

This guide explains, one by one, each requirement ofAI System Bill of Materials — Compliance Management Guide for the Supply Chain (Version 1.0), published by the OpenChain AI Work Group. It walks through what verification material each clause requires, how to comply with it, and what samples and tools are ready to use.

This specification carries the same structure as ISO/IEC 5230, the open source license compliance standard — requirements, verification material, and rationale — over into the AI supply chain. It brings into scope not only code but also the licensing and transparency obligations of model weights, training datasets, and the Model Tree.

Author : OpenChain Korea Work Group /CC BY 4.0

Intended Audience

• Compliance staff at organizations that develop AI systems or exchange them through the supply chain
• Practitioners who have an open source compliance (ISO/IEC 5230) program in place and want to extend it into AI
• Legal, security, and development staff who need to check the licensing and transparency obligations of AI models and datasets

How to Use This Guide

Phased Implementation Roadmap

The 10 requirements are divided into four phases by implementation priority. Phase 1 establishes the program’s foundation, Phase 2 builds AI-specific compliance processes, Phase 3 puts operational structures in place, and Phase 4 establishes governance.

Phase 1 — Program Foundation

Goal: Define the program’s scope, establish policy, and secure competence and awareness.

Phase 2 — AI Extension Processes

Goal: Build AI-specific licensing, transparency, and SBOM processes that cover not just code but also models, weights, and datasets. This is the area where the AI SBOM Guide expands most on ISO/IEC 5230.

Phase 3 — Operational Structure

Goal: Create a channel for responding to external compliance inquiries, and assign accountability and resources to the program.

Phase 4 — Governance

Goal: Put in place a governance framework spanning the full AI system lifecycle, and reflect emerging AI regulation.

Full Clause Checklist

The body of the AI SBOM Compliance Guide consists of10 clauses and 19 verification material items in total (by this guide’s verification material numbering).

Total: 10 clauses / 19 verification material items

Automation Maturity Map

This is an honest breakdown of how far each AI SBOM compliance task is automated by tools today. For “generation,” usable open source tools already exist. Interpreting license obligations and tracking compliance with non-standard licenses, on the other hand, remain the work of people and policy. Each clause page follows this line to distinguish “what a tool handles” from “what a person must fill in.”

The installation and use of each tool is covered with execution screens and command output in theTools section.

Relationship to Other Standards

Original Specification

A Software Bill of Materials (SBOM) is a formal record of what components make up a piece of software and how those components connect within the supply chain. A US executive order compares it to the ingredient list on food packaging. Just as an ingredient list is the starting point for responding to allergies, an SBOM is the data layer on which vulnerability response, license management, and asset management all rest. An SBOM is not a security tool in itself, but without one, an organization cannot immediately answer the question, “Where in our product is this library used?”

This guide covers that data layer from beginning to end. Drawing on primary sources, it explains why SBOM has moved to the forefront of regulation and procurement, what standards and identifiers underpin it, in what order organizations adopt it and with what tools they automate it, how they manage vulnerabilities and licenses, and how they share it securely across the supply chain.

Intended Audience

• Security, development, procurement, and legal staff at organizations that develop or procure software
• Practitioners who must respond to the EU Cyber Resilience Act (CRA) or US federal procurement requirements
• Teams seeking to establish supply chain transparency and open source license compliance systems

Guide Structure

The guide is divided into eight sections. The earlier sections cover concepts, standards, and regulation, while the later sections cover the practicalities of adoption and operation. You can read only the sections you need.

Quick Starting Points

If you already understand SBOM and are looking for where to start, see4. Adoption Roadmap and8. Recommendations and Checklist first. If you are deciding which format and tools to use,2. Standards and Formats and5. Tools and Automation are good starting points. If your goal is regulatory compliance, check the jurisdiction-specific obligations in3. Regulatory Trends.

Sources and Editorial Basis

This guide is not a translation of any single document; it is a reconstruction that synthesizes current primary sources. It draws on the National Telecommunications and Information Administration (NTIA)’s 2021 minimum elements and its update by the Cybersecurity and Infrastructure Security Agency (CISA) — the 2024Framing Software Component Transparency, Third Edition, and the 2025 draft revision of the minimum elements — as well as the SPDX and CycloneDX standard specifications, the EU Cyber Resilience Act (Regulation (EU) 2024/2847), and the supply chain security guidelines of India’s CERT-In and Korea. The first edition began as a translation of CERT-In’s SBOM technical guidelines; the current edition updates that framework with the sources above and broadens it to a general practitioner’s perspective.

Every factual claim is cited to a primary source, and the materials cited were accessed on June 14, 2026.

Author :Haksung Jang

This is stage 4 of the implementation roadmap. It brings the preceding clauses together to establish a governance framework across the full AI system lifecycle, and reviews it regularly to reflect emerging AI regulations (3.10).

1. Source Code Scanning Tools

Source code scanning tools can be used in the open source identification and inspection stage of the open source process. Source code scanning tools help identify the open source included in supplied software and extract license and copyright information. These tools range from free open source-based tools to commercial tools. Each tool has its own strengths, but no tool offers a perfect feature set that solves every problem. An enterprise must therefore choose a tool suited to the characteristics and requirements of its supplied software.

Many enterprises use these automated source code scanning tools together with manual review. Two major open source source code scanning tools are introduced here.

(1) FOSSology

FOSSology is an open source project managed by the Linux Foundation, a source code scanning tool that supports a license compliance workflow.

Key features:

• Source code scanning and license identification
• Extraction of license and copyright information
• Web-based user interface
• Support for analyzing large codebases

FOSSology is free for enterprises to use and receives continuous improvement and support from the open source community.

For how to install and use FOSSology, refer to theFOSSology guide.

(2) SCANOSS

SCANOSS is a platform for identifying and managing open source software components.

Key features:

• Fast source code scanning and open source component identification
• License and vulnerability information
• Integration support via API
• Generation of the SBOM (Software Bill of Materials)

SCANOSS offers both a free and a paid version, and supports both cloud-based service and on-premises solutions.

These source code scanning tools can be used to effectively identify and manage the open source components in supplied software. However, rather than relying entirely on the tool’s results, expert review and judgment by program participants must also be part of the process.

2. Dependency Analysis Tools

Modern software development commonly uses build environments that support package managers such asGradle andMaven. In these build environments, dependency libraries needed at build time are fetched from a remote repository even without the source code, and used to compose the supplied software. These dependency libraries are included in the supplied software but are not detected by source code scanning tools. It is therefore important to use tools for dependency analysis.

(1) OSS Review Toolkit

TheOSS Review Toolkit (ORT) is a suite of tools for automating open source license compliance. ORT provides a dependency analysis tool called the Analyzer.

Key features of the Analyzer:

• Support for various package managers (Maven, Gradle, NPM, etc.)
• Generation of a project’s dependency tree
• Extraction of license and copyright information
• Generation of reports in SPDX format

(2) FOSSLight Dependency Scanner

FOSSLight Dependency Scanner, developed byLG Electronics and released as open source, is a dependency analysis tool that supports various package managers.

Key features:

• Support for various package managers including Gradle, Maven, NPM, PIP, Pub, and Cocoapods
• Extraction of open source license and version information
• Generation of the SBOM (Software Bill of Materials)

These dependency analysis tools can be used to accurately identify the open source components included in supplied software and generate an SBOM. This helps meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

3. Open Source Governance / SBOM Management Tools

Open source governance and SBOM (Software Bill of Materials) management are essential for effective open source license compliance and security assurance. The ISO/IEC 5230 and ISO/IEC 18974 standards require documenting and retaining records of the open source software components included in supplied software.

An SBOM can be managed even with a spreadsheet program, but manual management becomes difficult as the number of supplied software products and versions grows. Introducing an automated open source tool is therefore efficient.

(1) SW360

SW360 is an open source project sponsored by the Eclipse Foundation that provides the ability to track the open source inventory for each piece of supplied software.

Key features:

• Project, component, and license management
• SBOM generation and management
• Vulnerability management
• Tracking of license obligations

For how to install and use SW360, see theSW360 guide.

(2) FOSSLight

FOSSLight is a comprehensive open source management tool developed byLG Electronics and released as open source.

Key features:

• SBOM generation and management
• Open source license compliance checks
• Vulnerability management
• Open source notice generation

LG Electronics has used FOSSLight for years to manage SBOMs company-wide, and released it as open source in June 2021. It provides a Korean-language guide to help domestic enterprises use it.

Using these tools, an enterprise can effectively carry out open source governance and manage its SBOM, and can meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

4. Open Source Security Vulnerability Management Tools

To effectively manage known vulnerabilities or newly discovered vulnerabilities included in supplied software, an enterprise must build an automated tool environment. Three major open source security vulnerability management tools are introduced here.

(1) OWASP Dependency-Check

OWASP Dependency-Check is an open source tool that analyzes a project’s dependencies to detect known vulnerabilities.

Key features:

• Support for various languages and package managers (Java, .NET, JavaScript, Ruby, etc.)
• Integration with the CVE (Common Vulnerabilities and Exposures) database
• Easy integration with CI/CD pipelines
• Generation of reports in various formats such as HTML, XML, CSV, and JSON

(2) SW360

SW360 is an open source software component management tool managed by the Eclipse Foundation that also provides security vulnerability management features.

Key features:

• Automatic vulnerability checks for registered releases
• Periodic collection of CVE information (scheduled every 24 hours)
• Viewing security vulnerabilities by project
• Tracking the impact of newly published vulnerabilities on existing products

For how to manage security vulnerabilities with SW360, refer to theSW360 guide.

(3) FOSSLight

FOSSLight similarly acquires security vulnerability information automatically, automatically checks project information where a security vulnerability has been detected, and provides notifications such as email when necessary.

Using these tools, an enterprise can effectively manage open source security vulnerabilities while meeting the requirements of ISO/IEC 18974.

5. Open Source Compliance Artifact Generation Tools

The open source notice, a key open source compliance artifact, is a document that provides the copyright and license information of the open source included in supplied software. An open source notice can be written manually, but it is more efficient to use a tool that generates it automatically.

(1) onot

SK telecom has released as open source, under the nameonot, the tool it uses internally to automatically generate open source notices.Kakao also participated in the joint development by contributing key features.

onot is a tool that automatically converts an SBOM written in theSPDX document format into an open source notice format. It is a Python program that is lightweight and simple to use.

(2) FOSSLight

FOSSLight also provides a feature that automatically generates an open source notice based on the SBOM it has acquired.

Using these tools makes it possible to automate and standardize the process of generating open source notices, raising the efficiency and accuracy of the open source license compliance process. This also helps meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

6. Archiving Open Source Compliance Artifacts

Systematically archiving and managing open source compliance artifacts is very important for open source license compliance. In particular, for licenses such as GPL and LGPL that require source code disclosure, the source code must be available for at least three years after the distribution of the supplied software.

To this end, the ISO/IEC 5230 standard requires a documented procedure for archiving copies of the compliance artifacts of distributed software, as follows.

To this end, an enterprise must build a system to safely archive its open source compliance artifacts and disclose them externally when necessary.

(1) GitHub Pages

GitHub Pages is a service that lets you host a website directly from a GitHub repository. It can be used to archive and publish open source compliance artifacts.

The way to archive open source compliance artifacts using GitHub Pages is as follows:

1. Create a dedicated repository on GitHub
2. Upload the open source notice and source code to the repository
3. Activate the website through GitHub Pages settings
4. Configure it so it can be accessed externally through a public URL

Using GitHub Pages has the following benefits:

• Free to use
• Provides version control
• High availability and stability
• Easy to update and manage

This tool environment can be seen in reference on SK telecom’s open source website.

This website was developed as open source, and its source code is public, so other enterprises can easily build a similar environment.

By using GitHub Pages to archive and publish open source compliance artifacts, an enterprise can effectively fulfill its open source license obligations and improve transparency.

7. Integration with Continuous Integration/Deployment (CI/CD) Tools

Integrating open source compliance and security assurance activities into a continuous integration/deployment (CI/CD) pipeline enables automated inspection and management throughout the development process. This makes it possible to discover and resolve open source-related issues early.

(1) Jenkins Plugins

Jenkins is a widely used open source automation server that can integrate with open source compliance and security assurance tools through various plugins.

Major Jenkins plugins:

• FOSSology Plugin: Integrates FOSSology scans into a Jenkins pipeline.
• OWASP Dependency-Check Plugin: Automates checks for known vulnerabilities or newly discovered vulnerabilities.
• SW360 Plugin: Integrates SW360 with Jenkins to automate SBOM management.

Example Jenkins pipeline:

pipeline{agentanystages{stage('Checkout'){steps{checkoutscm}}stage('Dependency Scan'){steps{dependencyCheckadditionalArguments:'',odcInstallation:'Default'}}stage('License Scan'){steps{fossology()}}stage('SBOM Update'){steps{sw360UpdateProject()}}}post{always{dependencyCheckPublisherpattern:'**/dependency-check-report.xml'}}}

This pipeline sequentially performs source code checkout, dependency vulnerability scanning, license scanning, and SBOM update.

(2) GitLab CI/CD Pipeline

GitLab CI/CD is a continuous integration/deployment tool built into GitLab, with pipelines defined through a.gitlab-ci.yml file.

Example GitLab CI/CD pipeline:

stages:-scan-analyze-reportdependency_scan:stage:scanscript:-docker run --rm -v $(pwd):/src owasp/dependency-check --scan /src --format "ALL" --out /src/reportslicense_scan:stage:scanscript:-docker run --rm -v $(pwd):/project fossology/fossology:latest /usr/local/fossology/fo_cli -c /projectsbom_update:stage:analyzescript:-sw360 update-projectvulnerability_report:stage:reportscript:-generate_vulnerability_reportartifacts:reports:dependency_scanning:reports/dependency-check-report.jsonlicense_report:stage:reportscript:-generate_license_reportartifacts:reports:license_scanning:reports/license-scan-report.json

This pipeline performs dependency vulnerability scanning, license scanning, SBOM update, and generation of vulnerability and license reports.

By integrating these processes into a CI/CD pipeline, an enterprise can automate open source compliance and security assurance activities and integrate them smoothly into the development workflow. This helps effectively meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

8. Summary

Once this tool environment is in place, the key requirements of the ISO/IEC 5230 and ISO/IEC 18974 standards can be met.

Using these tools brings the following benefits:

1. Source code scanning and dependency analysis tools make it possible to accurately identify the open source included in supplied software and determine its license.

2. Open source governance and SBOM management tools make it possible to systematically manage and track the open source components in supplied software.

3. Open source security vulnerability management tools make it possible to continuously monitor and respond to known vulnerabilities or newly discovered vulnerabilities.

4. Open source compliance artifact generation and archiving tools make it possible to efficiently generate and manage the documents needed to comply with license obligations.

5. Integration with CI/CD tools makes it possible to integrate the open source management process into the development workflow and automate it.

Building this tool environment allows an enterprise to carry out open source license compliance and security assurance activities in a systematic and efficient way, and provides significant help in meeting the requirements of ISO/IEC 5230 and ISO/IEC 18974.

By making effective use of open source management tools, an enterprise can minimize the legal risk that comes with using open source, respond promptly to security vulnerabilities, and build a transparent and trustworthy software supply chain. This will ultimately lead to improved competitiveness and greater customer trust for the enterprise.

Introducing an SBOM program into an organization is not a one-time effort. A staged approach is more realistic: establish the foundation (Foundational), settle generation and integration into practice (Developing), and mature operations (Scaling). The stage breakdown below is the common framework presented by both the US NTIA and India’s CERT-In guidelines; the order of activities is only illustrative and can be adjusted to fit an organization’s security needs, timeline, and resources.

Figure 1. The three stages of SBOM adoption(source: reconstructed from NTIA 2021 and CERT-In technical guidelines; collected June 14, 2026)

Stage 1: Building the Foundation

The first SBOM an organization encounters is usually one received from a supplier during procurement. The purpose of this stage is to establish how the organization handles SBOM in the first place.

• Identify critical assets and establish a plan: Develop a plan that defines roles and responsibilities, timelines, and resource requirements, and obtain stakeholder buy-in for the new process.
• Decide on the format and minimum requirements: Before creating SBOMs, determine the format (SPDX or CycloneDX) and the minimum data requirements. This ensures a standard structure that can be processed consistently across the supply chain.
• Identify security requirements, storage, and tools: Define classification and handling procedures, and set up a secure repository for SBOMs.
• Obtain SBOMs through procurement: Specify the requirement for suppliers to provide SBOMs in purchase orders or contracts, and specify which elements are to be provided, when, and by what method.

Stage 2: Generation and Integration

This stage involves establishing secure configuration management, consistently referencing components with unique identifiers, and embedding generation itself into the development process.

• Assign unique identifiers: Pin each component withan identifier such as PURL so that traceability is not lost even if a supplier or component name changes, or a different version is released under the same name.
• Map supplier SBOMs to internal SBOMs: Create internal SBOMs based on the SBOMs suppliers provide, and record the author and timestamp to manage integrity and update history.
• Integrate with the SSDLC and CI/CD: Integrate SBOM generation into the Secure Software Development Life Cycle (SSDLC) and continuous integration/continuous deployment (CI/CD) pipeline. Generating SBOMs automatically at build time improves both accuracy and timeliness. See5. Tools and Automation for tool selection.
• Secure configuration management: Apply access control, encryption, and regular audits to manage SBOMs securely.

Stage 3: Operational Maturity and Scaling

The final stage involves fully weaving SBOM into vulnerability management and incident response, and continuously updating the program.

• Strengthen vulnerability tracking: Establish a process for cross-referencing SBOM components against vulnerability databases to assess impact and mitigation. Detailed methods are covered in6. Vulnerability Management.
• Integrate incident response: Establish a process for using SBOM to quickly determine, for a newly disclosed vulnerability, whether the organization is affected or has already been compromised.
• Maintain regular review and awareness: Periodically check that components and dependencies match the latest records, and keep the organization aware of new formats, data elements, and industry trends.

Choosing a Starting Point

Follow the three stages in order, but there is no need to aim for perfection from the start. A realistic first step is to pick one or two of the most important products, automatically generate SBOMs in the build pipeline, and feed them into a vulnerability scanner. Once you confirm the program works for one product, expanding it across the full portfolio reduces the cost of trial and error.

Sources

NTIA (2021).The Minimum Elements For a Software Bill of Materials (SBOM). CERT-In.Technical Guidelines on Software Bill of Materials (SBOM). CISA SBOM Resource Hubhttps://www.cisa.gov/sbom. (all accessed: June 14, 2026)

1. Clause Overview

Program scope determines how far compliance extends. If the scope is ambiguous, it becomes unclear which AI systems need an SBOM and which models’ licenses need review. Scope must be declared first so that every subsequent clause knows what it applies to.

3.4 requires declaring the scope of application for each program. Scope can differ by organization. Some organizations cover a single product line; others cover an entire department or the whole organization. In AI, scope determination covers not only self-developed models but also externally sourced models and datasets, and the external release of in-house models.

2. Required Activities

• Define what the program applies to (externally deployed AI systems, externally sourced models and datasets, external release of in-house models, and so on).
• Record what is excluded from application and the rationale for the exclusion.
• Keep the scope statement consistent with the scope of application in the policy document.
• Review and update the scope periodically as the business environment changes.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.4.1 Program scope statement

Compliance Method

State the program’s scope and limits in writing. Clearly note what is included, what is excluded, and if excluded, on what grounds. An AI SBOM program becomes clearer when it declares what it applies to by breaking it down into material types and activities. The table below is an example of organizing scope.

Table 1. Example of an AI SBOM program scope declaration

Considerations

• Consistency with policy: The scope statement should not conflict with the scope of application in3.1 Policy.
• Grounds for exclusion: Record the rationale for excluded items. Even an internal experimental model falls into scope once it moves to external deployment, so put a review procedure in place for that transition point.([Recommendation of this guide])
• Periodic review: Update the scope whenever a new product line or new AI service is introduced.

Sample (Scope Statement)

## AI SBOM Compliance Program Scope
### Applies To
This program applies to all AI systems, models, and services that the company deploys
externally, and to pretrained models and datasets sourced externally. It also covers
activities that release in-house models externally.
### Excluded
Models used solely for internal experimentation or research and not deployed externally
are excluded. However, if such a model transitions to external deployment, it is brought
into scope through the intake review procedure.
### Review Cycle
Scope is reviewed and updated at least once a year, or as the business environment
changes.

5. See Also

• Scope of application in the policy:3.1 Policy
• AI SBOM for material within scope:3.9 AI SBOM
• ISO/IEC 5230 scope example:ISO/IEC 5230 Compliance Guide — 3.1.4 Program Scope

This is stage 3 of the implementation roadmap. It establishes a channel to respond to external AI SBOM compliance inquiries (3.7) and assigns responsibility, personnel, and funding to the program (3.8).

This page introduces analysis and identification tools that complement AI SBOM generation. Where the generation tools (OWASP AIBOM Generator, cdxgen) record “what is in it,” these tools look at “whether it is safe” and “what version it is.” The commands and features below are organized based on each tool’s official documentation (the tools actually run in this guide areOWASP AIBOM Generator andcdxgen).

Lab700x AI SBOM Scanner — Static Analysis of Model Binaries

A tool that statically analyzes AI model files themselves to extract information. It performs deep introspection on model binaries such as.safetensors,.pt (PyTorch), and.pkl (Pickle) without executing them.

• Key features: Because it examines internal structure without executing the model, it can detect malicious code hidden in a model file (such as Pickle injection), vulnerabilities, or license violations before deployment.
• Role in AI SBOM: Used to inspect externally sourced models at the intake gate. Combined with the inbound metadata enforcement of3.5 License Obligations, it lets metadata verification and binary safety checking be performed together.

Pickle-format models carry a significant supply-chain risk because arbitrary code can execute during deserialization. Inspecting the model without executing it is the core of this tool.

Trivy — Scanning LLM Inference Server Containers

An open source scanner from Aqua Security that checks vulnerabilities in container images and filesystems. It recently added awareness of AI model infrastructure.

• Key features: Scans LLM inference server containers such as Ollama and LocalAI to collect the open source libraries they contain and their container vulnerabilities.
• Usage:

# Scan a container image (vulnerabilities)trivy image ollama/ollama:latest# Generate an SBOM (CycloneDX)trivy image --format cyclonedx --output sbom.json ollama/ollama:latest

Used in environments that deploy AI models as containers, to leave a record of the inference server’s vulnerabilities and components as an SBOM.

Syft — Identifying AI Packages and Virtual Environments

An SBOM generator from Anchore that scans containers, filesystems, and virtual environments.

• Key features: Analyzes Python virtual environments to collect the exact versions of packages used to run AI, such as PyTorch and Transformers. Outputs in SPDX and CycloneDX format.
• Usage:

# Scan a directory and output CycloneDXsyft scan dir:. -o cyclonedx-json=sbom.json# Scan a container imagesyft scan registry:python:3.11-slim -o spdx-json

Its role overlaps with cdxgen’s, so an organization already using the Anchore toolset (Syft, Grype) would naturally generate the dependency SBOM of an AI application with Syft and check vulnerabilities with Grype.

Recommended Tool Combination

No single tool solves everything. In practice, combine tools by dividing up their roles.

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• Execution results of generation tools:OWASP AIBOM Generator,cdxgen

1. Clause Overview

An AI SBOM (AI System Bill of Materials) is a list capturing the elements that make up an AI system and the information about them. Where a traditional SBOM records software components, an AI SBOM adds models, weights, datasets, and hyperparameters on top. 3.9 requires a procedure for generating and managing the AI SBOM.

The format is left open. The specification states that SPDX, CycloneDX, or any other format is acceptable. There is, however, one obligation: the AI SBOM shall account for inbound materials from third parties. If pre-trained models and datasets brought in from outside are left out, the basis for tracking license obligations (3.5) and transparency obligations disappears.

The AI SBOM area is where the line “generation is automated by tools, but accuracy and compliance judgment are filled by people” is sharpest. This page walks through the procedure along that line.

2. Activities to Perform

• Establish a procedure for identifying, tracking, reviewing, approving, and archiving the components of an AI system (models, datasets, etc.).
• Decide on an AI SBOM format (SPDX 3.0 AI Profile or CycloneDX ML-BOM recommended).([Guide Recommendation])
• Ensure models and datasets brought in from third parties are always included in the AI SBOM.
• Wire a generation tool into CI/CD to regenerate the AI SBOM repeatedly.([Guide Recommendation])
• Have a person review whether the license and provenance fields of the generated AI SBOM are accurate.([Guide Recommendation])
• Retain records (generation history, approval history) demonstrating that the procedure was followed.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.9.1 AI SBOM Management Procedure (Identification, Tracking, Review, Approval, Archiving)

How to Comply

Design the AI SBOM procedure around four stages: generation, review, approval, and archiving. Automate the generation stage with tools, and leave the review and approval stages to people. Even when a tool copies a license field straight from a model card, it cannot judge whether that license actually fits the use case, or whether something is missing or misstated.

The figure below shows the flow from AI SBOM generation to archiving.

Figure 1. Procedure from AI SBOM generation to archiving

Tool Mapping

Below are open source tools usable at each stage. “Automation level” indicates how far a tool handles that task on its own.

Installation, usage, and execution screens for each tool are covered in detail in theTools section (OWASP AIBOM Generator,cdxgen,Model/Container Scanners).

The command to generate an AI BOM with cdxgen is as follows. You can pass a Hugging Face model URL and purl, a Modelfile, or a GGUF artifact directly (cdxgen AI-BOM docs).

# Generate an AI BOM from the AI project directorycdxgen -t ai -o aibom.json .# Generate including AI/ML metadata (formulation)cdxgen -t ai --include-formulation -o aibom.json .

The OWASP AIBOM Generator takes a Hugging Face model as input, builds a CycloneDX-format AIBOM, and scores its completeness. It is maintained by the OWASP Gen AI Security Project and is also available as a Hugging Face Space (OWASP AIBOM Generator).

Hands-On — Generating with cdxgen

This is the result of actually running cdxgen against a summarization app (depending ontransformers andtorch) that loads a pre-trained model (facebook/bart-large-cnn). The tool automatically identifies 5 dependencies and produces a CycloneDX 1.7-format BOM.

$ cdxgen -t python --include-formulation -o aibom.json .CycloneDX Generator 12.5.1 (Node.js)Generated components — 5 items (CycloneDX 1.7): transformers 4.44.2 pkg:pypi/transformers@4.44.2 license: empty torch 2.4.0 pkg:pypi/torch@2.4.0 license: empty numpy 1.26.4 pkg:pypi/numpy@1.26.4 license: empty tokenizers 0.19.1 pkg:pypi/tokenizers@0.19.1 license: empty huggingface-hub 0.24.6 pkg:pypi/huggingface-hub@0.24.6 license: empty

One component from the generated BOM looks like this. The identification evidence is filled in, but thelicenses field is empty.

{"name":"transformers","version":"4.44.2","purl":"pkg:pypi/transformers@4.44.2","type":"library","evidence":{"identity":[{"field":"purl","confidence":0.5,"methods":[{"technique":"manifest-analysis","value":"requirements.txt"}]}]}}

Figure 2. cdxgen 12.5.1 execution output(run on 2026-06-13,-t python --include-formulation)

Format Sample (CycloneDX ML-BOM)

Below is a shortened example of the model component structure in a CycloneDX 1.6 ML-BOM. The key structure follows themachine-learning-model component andmodelCard in theofficial CycloneDX spec. If the license is non-standard (has no SPDX ID), state it withname.

{"bomFormat":"CycloneDX","specVersion":"1.6","components":[{"bom-ref":"model-llama31-8b","type":"machine-learning-model","group":"meta-llama","name":"Llama-3.1-8B","version":"1.0","licenses":[{"license":{"name":"Llama 3.1 Community License"}}],"modelCard":{"modelParameters":{"task":"text-generation","architectureFamily":"llama","datasets":[{"type":"dataset","name":"Public pretraining corpus","classification":"public"}]},"considerations":{"useCases":["Internal document summarization"],"technicalLimitations":["Potential for hallucination","Performance variance in Korean"]}}}]}

If you use SPDX 3.0, the AI Profile and Dataset Profile express the same information (SPDX 3.0 AI Profile). The concrete fields of each format and the technical details of generation tools are covered in theISO/IEC 42001 Guide — AI SBOM.

Considerations

• Reflect inbound materials (specification obligation): Set up a procedure that generates an SBOM entry at intake time so that models and datasets brought in from outside are never missing from the AI SBOM. This is ashall-level obligation.
• Generation by tool, review by people: Generation tools copy the license written on the model card as-is. Because model cards themselves commonly have missing or incorrect license information, have a person check the license and provenance fields of the generated AI SBOM against the original source.
• Format consistency: Pick either SPDX or CycloneDX as the organization’s default format and operate tools and repositories around it consistently. Both formats treat models and datasets as first-class components.
• CI/CD integration: The AI SBOM is not a one-time deliverable. Wire it into the pipeline so it is regenerated whenever a model or dataset changes.

3.9.2 Records Demonstrating Procedure Compliance

How to Comply

Verification material 3.9.2 is the record showing the procedure was actually followed. Alongside the AI SBOM file itself, keep a history of who generated, reviewed, and approved it and when. If it is generated automatically in CI/CD, the build logs and the generated SBOM artifact become the record, and the upload history to a management tool such as Dependency-Track also serves as evidence.

Considerations

• Retain generation history: Keep the AI SBOM from each point in time for every version of the supplied AI system to maintain traceability.
• Approval record: Record who reviewed and approved it. This connects to the lifecycle review inGovernance (3.10).

5. References

• License obligation review procedure:3.5 License Obligations
• Technical details of AI SBOM formats and generation tools:ISO/IEC 42001 Guide — AI SBOM
• SBOM management tools:Dependency-Track,cdxgen + Dependency-Track integration
• Governance and lifecycle review:3.10 Governance

1. Clause Overview

If competence (3.2) addresses “can they do it,” awareness addresses “do they know why they should.” It is not enough for participants to merely know that a policy exists. Compliance functions in practice only when participants also know how their own work contributes to the program and what happens if they fail to follow it.

3.3 requires ensuring that program participants are aware of four things: the AI SBOM policy, relevant business objectives, their own contribution to the program’s effectiveness, and the implications of not following the program’s requirements. In AI, the implications of non-conformance extend beyond copyright disputes to regulatory violations and breaches of usage restrictions, so participants must clearly recognize this.

2. Required Activities

• Ensure participants know the AI SBOM policy and where to find it.
• Communicate relevant business objectives (building trust, regulatory compliance, meeting supply-chain requirements).
• Inform participants how their own work contributes to the program.
• Inform participants of the implications of non-conformance (regulatory violations, contract termination, breaches of usage restrictions).
• Assess participants’ awareness and preserve evidence of that assessment.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.3.1 Evidence of assessed participant awareness

Compliance Method

Assess whether participants actually understand the four awareness elements and keep evidence of that assessment. If policy dissemination (3.1.2) proves that participants “were informed,” the awareness assessment proves that they “understood.” Assess through post-training comprehension quizzes, acknowledgment signatures, or interviews. Make sure the assessment does not omit the three elements the standard specifies in its verification material: the program’s objectives, one’s own contribution, and the implications of non-conformance.

Considerations

• Cover all four elements: In addition to policy awareness, include objectives, contribution, and the implications of non-conformance in the assessment. Omitting even one can be flagged during a certification audit.
• Emphasize AI-specific implications: Include regulatory violations (the EU Artificial Intelligence Act, Korea’s AI Basic Act) and breaches of non-standard license usage restrictions among the implications of non-conformance.
• Differentiate by role: Data staff and developers contribute differently, so tailor the assessment content to each role.
• Retain evidence: Preserve assessment results and acknowledgment signatures for use as verification material.

Sample (Awareness Assessment Log)

| Participant (Role) | Policy Awareness | Objectives Awareness | Contribution Awareness | Non-conformance Awareness | Assessment Method | Assessment Date |
|-------------|:--------:|:--------:|:--------:|:---------------:|----------|--------|
| Lee OO (Development) | Met | Met | Met | Met | Post-training check | 2026-03-10 |
| Park OO (Data) | Met | Met | Met | Met | Interview + signature | 2026-03-11 |

Sample acknowledgment signature form:

I have been informed of and understand our company's AI SBOM compliance policy, the program's
objectives, my own contribution, and the implications of non-conformance (regulatory violations,
license usage restriction breaches, contract termination).
Name: ____ Role: ____ Signature: ____ Date: ____

5. See Also

• Policy and dissemination procedure:3.1 Policy
• Competence by role:3.2 Competence
• ISO/IEC 5230 awareness example:ISO/IEC 5230 Compliance Guide — 3.1.3 Awareness

The regulatory standing of SBOM differs by jurisdiction. The United States takes an executive-order pathway that leverages federal procurement, the European Union takes a directly effective legislative pathway, and most other countries remain at the stage of advisory guidelines. This section covers the United States first, followed by theEU Cyber Resilience Act andother jurisdictions such as India and Korea.

Regulatory Standing by Jurisdiction at a Glance

Table 1. SBOM regulatory standing in major jurisdictions(source: primary source for each item; collected June 14, 2026)

United States: Leveraging Federal Procurement

US SBOM policy originates from an executive order. On May 12, 2021, shortly after the SolarWinds incident, Executive Order 14028 (“Improving the Nation’s Cybersecurity”) was signed and published in the Federal Register as 86 FR 26633. Section 10(j) of the order defined SBOM as “a formal record containing the details and supply chain relationships of various components used in building software,” and Section 4(f) directed the Secretary of Commerce, working with NTIA, to publish minimum elements for an SBOM within 60 days. This was the moment SBOM was elevated from a recommendation of the research community to a candidate requirement for federal procurement.

Under this mandate, NTIA published the minimum elements in July 2021, and responsibility for the work subsequently moved to CISA. Under Office of Management and Budget (OMB) Memorandum M-22-18, CISA holds the authority to update the NTIA minimum elements and has focused on tooling and operationalization. The results are the 2024Framing Software Component Transparency, Third Edition, and the 2025 draft revision of the minimum elements. Changes in the data fields between the two documents are covered inMinimum Elements.

It is important to understand the exact nature of the US pathway. Executive Order 14028 is the basis for guidance requiring vendors that supply software to the federal government to provide an SBOM; it is not a general statute that applies to all software. CISA’s two documents themselves state that they do not create new federal requirements. The normative standing remains that of a procurement criterion and technical reference. Nonetheless, because the vast federal procurement market operates on this basis, it functions as a de facto requirement for companies that supply software to the US government.

Figure 1. Lineage of US SBOM policy documents(source: Executive Order 14028, NTIA 2021, CISA 2024 and 2025; collected June 14, 2026)

Sources

The White House (2021).Executive Order 14028 — Improving the Nation’s Cybersecurity, 86 FR 26633.https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity. OMB (2022).M-22-18.https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf. CISA SBOM Resource Hubhttps://www.cisa.gov/sbom. (all accessed: June 14, 2026)

The open source process is an actionable procedure that enables an enterprise to comply with its open source policy throughout software development and distribution.

From the standpoint of open source license compliance, the enterprise carries out activities to comply with the conditions required by each license governing the open source used while developing and distributing the supplied software, producing compliance artifacts such as the open source notice and the source code to be disclosed.

For open source security assurance, the enterprise must detect the presence of Known Vulnerabilities or Newly Discovered Vulnerabilities in the supplied software, identify structural and technical threats, and carry out activities to resolve issues before release.

To achieve effective open source license compliance and security assurance, an enterprise must establish the following processes:

• Open source process
• Open source security vulnerability response process
• External inquiry response process
• Open source contribution process

Let’s look at how each process should be structured, one by one.

1. Open Source Process

An enterprise must establish an open source process for license compliance and security assurance that aligns with its software development process.

The image below is a sample open source process that an enterprise can commonly adopt and use.

The procedures to be taken at each stage, in line with the open source process above, are as follows.

(1) Open Source Identification and Inspection

In the open source identification and inspection stage, the enterprise must identify the license of the open source it intends to use, determine what obligations the license requires, and check whether Known Vulnerabilities exist.

It reviews and records which open source it intends to use, what the license is, what obligations each license imposes, and what Known Vulnerabilities exist.

The ISO/IEC 5230 standard requires a documented procedure that can address common open source license use cases for license compliance, and that reviews and records the obligations, restrictions, and rights granted by each identified license.

An example procedure for this is as follows:

1. The Open Source Program Manager creates and provides a guide on the obligations, restrictions, and rights of major open source licenses. To manage common open source license use cases, this guide must cover the following use cases:

   • Distribution in binary form
   • Distribution in source form
   • Integration with other open source that triggers additional license obligations
   • Inclusion of modified open source
   • Inclusion of open source or other software under a license incompatible with other components in the supplied software
   • Inclusion of open source with attribution requirements

2. The business unit checks the license and Known Vulnerabilities according to the criteria defined in the open source policy.

3. The business unit consults the Open Source Program Manager and the security officer with any questions. If necessary, it requests advice from external experts.

4. All decisions and their rationale are documented and retained.

To this end, an enterprise must establish a documented procedure, as in the example below, to review and record the obligations and restrictions imposed by each identified license and any Known Vulnerabilities, through the open source identification and inspection stage before releasing the supplied software.

(1) Open Source Identification
The business unit complies with the following during the software design stage:
- While designing the software, it identifies the open source expected to be used and confirms the identified licenses.
- It checks the obligations for each open source license. License-specific obligations can be found in the company's open source license guide: https://sktelecom.github.io/guide/use/obligation/
- It designs the software taking into account the source code disclosure scope required by each open source license.
The Open Source Program Manager creates and publishes a guide on the obligations, restrictions, and rights of major open source licenses so that business units across the company can refer to it. To manage common open source license use cases, this guide must cover the following use cases:
- Distribution in binary form
- Distribution in source form
- Integration with other open source that triggers additional license obligations
- Inclusion of modified open source
- Inclusion of open source or other software under a license incompatible with other components in the supplied software
- Inclusion of open source with attribution requirements
The business unit marks copyright and license notices in the source code according to company rules. The company's rules for copyright and license notices in source code can be found on the following page. (insert_link)
When reviewing the adoption of new open source, the business unit first identifies the license. It checks the license obligations, restrictions, and rights according to the company's open source license guide. If the license is not covered by the company's open source license guide, it consults the Open Source Program Manager on whether adoption is possible and what precautions apply. It creates a Jira Ticket for the inquiry.
The Open Source Program Manager analyzes the open source license obligations and provides guidance to the software development organization.
- If there are questions, it requests advice from the legal department to provide clear guidance.
- Newly analyzed license information is reflected in the company-wide license guide.
The security officer provides a guide for the company's security assurance.
(2) Source Code Inspection
The business unit requests an open source inspection according to the guidance of the IT staff and provides the source code.
The IT staff performs the open source inspection using an open source analysis tool and generates an SBOM (Software Bill of Materials).
The Open Source Program Manager reviews whether the open source license obligations can be complied with and whether there are open source license conflicts, and requests the business unit to resolve any issues found. Issues are created as Jira Tickets and assigned to the business unit.
The security officer reviews the detected Known Vulnerabilities and provides response guidance to the business unit according to predefined risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and for Critical Risk, the business unit is guided to establish a remediation plan within one week.

In the open source identification and inspection stage, a source code scan tool can be used. This is described in detail in “1. Source Code Scan Tools”.

(2) Issue Resolution

After identifying open source and confirming license and security vulnerability risks through open source identification and inspection, a procedure to resolve issues is needed. All detected issues must be resolved using the following methods:

• Remove the open source causing the issue.
• Replace it with open source under a different license to resolve the license issue.
• Replace it with a version of the open source in which the Known Vulnerability or Newly Discovered Vulnerability has been resolved.

An example of a documented process for this is as follows:

(3) Issue Resolution
The business unit resolves all issues found during the source code inspection stage.
It removes the open source causing the issue or replaces it with open source under a different license. For issues involving a Known Vulnerability or a Newly Discovered Vulnerability, it takes measures such as replacing the component with a version in which the vulnerability has been fixed.
Once the business unit resolves all issues found, it resolves the Jira Ticket issue and requests a re-review.

(3) SBOM Identification, Review, and Retention

The most fundamental part of open source license compliance activities is understanding the open source contained in the supplied software. An enterprise must establish a process to identify the open source and its licenses contained in the supplied software, and to create and manage an SBOM (Software Bill of Materials) that holds this information. This is because knowing which open source is included in each version of the supplied software is necessary to comply with the obligations required by each open source license when distributing the software. This is also an essential process for discovering and responding to open source security vulnerabilities.

All open source must be reviewed and approved before being integrated into the supplied software. In addition to the functionality and quality of the open source, it must be reviewed beforehand for its origin, whether it can meet license requirements, and whether Known Vulnerabilities or Newly Discovered Vulnerabilities have been resolved. This requires a review request → review → approval process.

The ISO standards commonly require a documented procedure ensuring that all open source software used in the supplied software is continuously recorded throughout the software life cycle, as follows.

To this end, an enterprise can reflect SBOM-related content in its open source process, as in the example below:

(4) Review
The Open Source Program Manager reviews whether all issues have been properly remediated. If necessary, it re-runs the source code inspection using an open source analysis tool.
The security officer reviews whether all serious vulnerabilities have been resolved. If vulnerabilities that are difficult to resolve remain, it reviews whether approval is possible, taking into account the type of business and the extent of service exposure.
(5) Approval
The Open Source Program Manager gives final approval or rejection of whether the open source license compliance procedure was performed properly. In the case of rejection, it explains the reason to the business unit and proposes a way to remediate it.
(6) Registration
The Open Source Program Manager finalizes the SBOM to track the list of open source used, by version, in the supplied software.
The IT staff registers the finalized SBOM in the system. The SBOM includes the list of open source contained in the supplied software along with the following information:
- The product (or service) name and version of the supplied software
- List of open source
- Open source name / version
- Open source license
The Open Source Program Manager finalizes the SBOM to track the list of open source used, by version, in the supplied software.

Tools for SBOM management are described in detail in “SBOM Management Tools”.

In addition, every process and result of this open source process must be documented. Rather than using email, using an issue tracking system such asJira orBugzilla can document this process more efficiently.

(4) Creating License Compliance Artifacts

The most fundamental part of open source license compliance activities is understanding the open source contained in the supplied software. This is to correctly meet open source license requirements, which are at the core of open source license compliance. In other words, a process must be established to produce a set of compliance artifacts for the open source contained in the supplied software.

The ISO/IEC 5230 standard requires a documented procedure describing the process for preparing compliance artifacts and providing them together with the supplied software, as follows.

Compliance artifacts are broadly divided into two types:

1. Open source notice: a document providing the full text of open source licenses and copyright information

   

• How to generate an open source notice corresponding to an SBOM compiled using a tool is further explained in “Open Source Compliance Artifact Generation Tools”.

2. Source code package to be disclosed: a package compiling the source code to be disclosed in order to fulfill the obligations of open source licenses such as GPL and LGPL that require source code disclosure

Compliance artifacts must be provided together when distributing the supplied software.

To this end, an enterprise can reflect the creation of compliance artifacts, from the notice stage through the distribution stage, in its open source process, as in the example below:

(7) Notice
The Open Source Program Manager creates an open source notice to comply with the notice obligation. The open source notice includes the following content:
- An open source contact for open source-related inquiries
- Notice content for each open source
- Copyright
- Open source license name
- Copy of the open source license
- (if applicable) a Written Offer to obtain a copy of the source code
The Open Source Program Manager creates the open source notice and delivers it to the business unit. If source code disclosure is required, it also guides the business unit on how to compile the source code to be disclosed.
The business unit includes the open source notice when distributing the product. For a product with a screen, it takes measures so that users can view it through a menu. (e.g., App > Menu > Settings > Copyright Information > Open Source Licenses)
If the business unit has used open source under a license requiring source code disclosure, such as GPL or LGPL, it checks the required scope of disclosure and compiles the source code to be disclosed.
- The source code compiled to comply with obligations under licenses such as GPL and LGPL must match the source code that makes up the binary shipped in the product. In other words, building the compiled source code must produce the same result as the binary shipped in the product.
(8) Pre-Distribution Check
The business unit submits the following compliance artifacts demonstrating that open source license compliance activities were properly performed:
1. The final open source notice included in the product
2. Materials confirming that the open source notice is included in the product (e.g., a screenshot showing the open source notice)
3. (if applicable) the source code to be disclosed (submitted compressed into a single file)
The Open Source Program Manager reviews the materials submitted by the business unit to confirm there are no issues.
(9) Distribution
The Open Source Program Manager submits the compliance artifacts submitted by the business unit to the IT staff.
The IT staff registers the compliance artifacts on the company's open source distribution site.

When distributing the supplied software, it may be difficult to enclose the source code package to be disclosed. In this case, this can be replaced by providing a Written Offer to supply the source code for at least three years. A Written Offer is generally provided through the product’s user manual, and an example is as follows:

The software included in this product contains copyrighted software
that is licensed under the GPL. A copy of that license is included
in this document on page X. You may obtain the complete Corresponding
Source code from us for a period of three years after our last shipment
of this product, which will be no earlier than 2011-08- 01, by sending
a money order or check for $5 to:
GPL Compliance Division
Our Company
Any Town, US 99999
Please write"source for product Y" in the memo line of your payment.
You may also find a copy of the source at http://www.example.com/sources/Y/.
This offer is valid to anyone in receipt of this information.
<Source: SFLC Guide to GPL Compliance>

Therefore, compliance artifacts must be retained for at least three years, and a process must be established for this.

To this end, an enterprise can consider building an open source website. Details can be found in “Open Source Compliance Artifact Retention”.

(5) Security Vulnerability Inspection and Assessment

The security officer must establish a process to inspect and assess Known Vulnerabilities or Newly Discovered Vulnerabilities in the open source software components of the supplied software. This process must include the following stages:

1. Vulnerability database search: Use a public vulnerability database such as theNational Vulnerability Database (NVD) to search for Known Vulnerabilities in the open source components in use.

2. Use of automated vulnerability scanning tools: Use a tool such asOWASP Dependency-Check to scan the dependencies of the supplied software and identify Known Vulnerabilities.

3. Vulnerability severity assessment: UseCVSS (Common Vulnerability Scoring System) to assess the severity of discovered vulnerabilities.

4. Risk analysis: Analyze the potential impact of the identified vulnerabilities on the supplied software.

5. Response plan development: Establish a response plan for each vulnerability based on its severity and risk analysis results.

(2) Source Code Inspection
The security officer reviews the detected Known Vulnerabilities and provides response guidance to the business unit according to predefined risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and for Critical Risk, the business unit is guided to establish a remediation plan within one week.
| Risk | CVSS 2.0 | CVSS 3.0 | Recommended Remediation Timeline |
|---|:---:|:---:|:---:|
| Low | 0.0 - 3.9 | 0.0 - 3.9 | - |
| Medium | 4.0 - 6.9 | 4.0 - 6.9 | - |
| High | 7.0 - 10.0 | 7.0 - 8.9 | Within 4 weeks |
| Critical | - | 9.0 - 10.0 | Within 1 week |

6. Reporting and documentation: Document the inspection results, assessment content, and response plan, and report them to relevant stakeholders.

7. Continuous monitoring: Establish a continuous monitoring system, since new vulnerabilities may be discovered or the severity of existing vulnerabilities may change.

Through this process, an enterprise can effectively manage security vulnerabilities in the supplied software and meet the requirements of ISO/IEC 18974.

2. Open Source Security Vulnerability Response Process

While developing the supplied software, an enterprise must carry out activities for security assurance, such as detecting and resolving open source security vulnerabilities.

The ISO/IEC 18974 standard requires a documented procedure for the security assurance method and a record of the actions taken, as follows.

To this end, an enterprise must have methods and procedures to detect the presence of Known Vulnerabilities or Newly Discovered Vulnerabilities in the supplied software, resolve identified risks before release, and also respond to vulnerabilities newly published after release.

First, an enterprise must detect whether Known Vulnerabilities exist in the software to be distributed and resolve identified risks before release. This procedure for detecting and resolving Known Vulnerabilities can be carried out through the open source identification, source code inspection, and issue resolution stages of theOpen Source Process.

In addition, to check whether a newly published Known Vulnerability exists in software that has already been distributed after the release of the distributed software, and to resolve it, an enterprise must establish a new security vulnerability response process.

Below is a sample process for responding when a new security vulnerability is discovered.

(1) Monitoring Known Vulnerabilities and Newly Discovered Vulnerabilities

(1) Monitoring
The IT staff builds and operates a system to monitor new security vulnerabilities. This system performs the following functions.
- It periodically collects newly published security vulnerabilities.
- If open source with a newly discovered Known Vulnerability is used in an already-released product/service, it sends a notification to the business unit responsible for that product/service. From notification through review, action, and resolution, everything is documented and recorded using the Jira Issue Tracker.

The IT staff builds and operates a system that monitors Known Vulnerabilities and Newly Discovered Vulnerabilities. This system performs the following functions:

• It periodically collects new security vulnerability information from a public vulnerability database such as theNational Vulnerability Database (NVD).
• If an open source software component with a Known Vulnerability or a Newly Discovered Vulnerability is used in already-released supplied software, it sends a notification to the business unit responsible for that supplied software.
• It uses an issue tracking system such asJira so that everything from notification through review, action, and resolution is documented and recorded.

(2) Vulnerability Assessment and Response

(2) Initial Response
The security officer provides response guidance to the business unit according to predefined risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and for Critical Risk, the business unit is guided to establish a remediation plan within one week.
If a new security vulnerability is discovered in a previously released product/service, the business unit establishes a remediation plan according to the response guidance provided by the security officer.
If there are customers under warranty, the business unit notifies them of the identified Known Vulnerability by email or other means, as necessary, according to the risk level.

The security officer assesses each vulnerability according to predefined risk/impact assessment criteria and provides response guidance to the business unit. Risk is classified byCVSS (Common Vulnerability Scoring System) score, and remediation deadlines are set according to severity.

If a Known Vulnerability or a Newly Discovered Vulnerability is identified in previously released supplied software, the business unit establishes a remediation plan according to the response guidance provided by the security officer.

If necessary, the business unit notifies customers of identified vulnerabilities according to the risk/impact score.

(3) Applying Security Testing

The IT staff builds and operates a system that applies continuous, repeated security testing to all supplied software before release. This system performs the following functions:

• It identifies structural and technical threats to the supplied software.
• It detects the presence of Known Vulnerabilities or Newly Discovered Vulnerabilities.
• It verifies that identified risks are resolved before the supplied software is released.

(4) Vulnerability Resolution and Patch Management

(3) Issue Resolution
The business unit resolves the security vulnerability issue according to the established remediation plan, by methods such as removing the problematic open source or replacing it with a patched version. Once all identified issues are resolved, it requests a re-review.
(4) Review
The IT staff uses an open source analysis tool to confirm that the issue has been properly resolved.
(5) Approval
The security officer reviews whether all serious vulnerabilities have been resolved. If vulnerabilities that are difficult to resolve remain, it reviews whether approval is possible, taking into account the type of business and the extent of service exposure.
(6) Registration
The IT staff registers the SBOM, with the open source security vulnerability resolved, in the system.

The business unit resolves the vulnerability issue according to the established remediation plan, by methods such as removing the problematic open source software component or replacing it with a patched version.

The IT staff uses an open source analysis tool to confirm that the issue has been properly resolved.

The security officer reviews whether all serious vulnerabilities have been resolved. If vulnerabilities that are difficult to resolve remain, it reviews whether approval is possible, taking into account the type of business and the extent of service exposure.

The IT staff registers the SBOM (Software Bill of Materials), with the vulnerability resolved, in the system.

(5) Customer Notification

(7) Notice
The Open Source Program Manager creates an open source notice based on the SBOM in which the open source security vulnerability has been resolved, and delivers it to the business unit.
The business unit replaces the open source notice included with the product distribution.
The IT staff registers the revised open source notice on the company's open source distribution site.
(8) Distribution
The business unit redistributes the version of the software in which the open source security vulnerability has been resolved.
The security officer identifies whether there is risk information that needs to be disclosed to third parties, and if so, delivers it to the IT staff.
The IT staff registers the identified risk information on the open source website so that third parties can review it.

The Open Source Program Manager creates an updated open source notice based on the SBOM in which the vulnerability has been resolved, and delivers it to the business unit.

The business unit notifies customers of the vulnerability resolution using the following methods:

• It replaces the open source notice included with the product distribution.
• If necessary, it notifies customers directly by email or other means.
• It redistributes the version of the supplied software in which the vulnerability has been resolved.

The IT staff registers the revised open source notice and vulnerability-related information on the company’s open source distribution site so that third parties can review them.

Through this process, continuous monitoring and response capability is maintained even after the supplied software has been released to the market.

Through this systematic approach, an organization can gain the following benefits:

1. Rapid response capability for new vulnerabilities
2. Improved transparency and trust with customers
3. Minimization and management of security risk
4. Assurance of compliance with regulatory requirements
5. Continuous improvement of product quality and security

This process also satisfies the requirements of ISO/IEC 18974 and can continuously improve the effectiveness of the organization’s open source security assurance program.

3. External Inquiry Response Process

To prevent external claims from escalating into legal action, it is important for an enterprise to respond to external inquiries and requests as quickly and accurately as possible. To this end, an enterprise must establish a process for responding quickly and effectively to external open source inquiries.

The ISO standards commonly require an internal documented procedure for responding to third-party inquiries, as follows.

The figure below is a sample process an enterprise should have in place to respond to external inquiries.

The following is the external inquiry response process presented in the open source process template:

Responding quickly and accurately to external inquiries related to open source license compliance and security assurance can greatly reduce the risk of escalation to legal action. To this end, the organization follows the process below:

(1) Receipt Notification

As soon as an inquiry is received, the Open Source Program Manager notifies the requester that the inquiry has been received. At this time, it specifies an appropriate response time. If the inquiry is unclear, it requests additional explanation to accurately understand the requester’s intent.

Major inquiries and requests include:

• Whether specific open source is used in a particular supplied software
• A request for the source code under a GPL or LGPL license mentioned in a Written Offer
• A request for clarification and source code disclosure regarding open source missing from the open source notice
• A request for missing files in the disclosed source code and instructions on how to build it
• A request for copyright notice
• An inquiry related to a Known Vulnerability or a Newly Discovered Vulnerability

The Open Source Program Manager creates an issue for the received request and records the response status in detail.

(2) Investigation Notification

The Open Source Program Manager notifies the requester that open source license compliance and security assurance are being faithfully carried out and that the inquiry is under investigation. It periodically updates and notifies the requester of the progress of the internal investigation.

(3) Internal Investigation

The Open Source Program Manager conducts an internal investigation into the request. It checks, through the SBOM and documented review history, whether the license compliance and security assurance processes were properly carried out for the relevant supplied software. If necessary, it requests advice from the legal department and the security officer.

If confirmation from a specific business unit is needed, the Open Source Program Manager requests that unit to investigate. The business unit that receives the request immediately checks whether there is a problem with the compliance artifacts and security-related matters, and reports the results.

(4) Reporting to the Requester

The Open Source Program Manager completes the internal investigation within the specified response time and notifies the requester of the results.

• If the requester’s inquiry was a mistaken claim due to a misunderstanding, it explains this without further action and closes the matter.
• If a problem is confirmed, it informs the requester of the exact method and timing for fulfilling the obligations of the relevant open source license or resolving the security vulnerability.

(5) Remediation / Notification

If an actual license compliance or security problem is found during the internal investigation, the relevant business unit carries out all procedures necessary to resolve it.

(6) Resolution Notification

After resolving the problem, it immediately notifies the requester and provides the best available means to confirm that the problem has been resolved.

(7) Process Improvement

If there was a license compliance or security problem, the case is reviewed through anOSRB (Open Source Review Board) meeting to understand how the problem occurred, and process improvement measures are established to prevent recurrence.

Through this systematic external inquiry response process, an enterprise can respond quickly and effectively to open source-related issues and minimize potential legal risk.

4. Open Source Contribution Process

If an enterprise has a policy that permits contributions to external open source projects, there must be a documented procedure governing how program participants can contribute to external projects.

The ISO/IEC 5230 standard requires a documented procedure governing open source contributions, as follows.

(1) Establishing and Communicating the Contribution Policy

The open source process template describes the establishment and communication of the contribution policy as follows:

(1) Establishing and Communicating the Contribution Policy
- A documented policy governing contributions to open source projects must be established.
- This policy must be communicated within the organization.
- There must be a process for enforcing the policy.
The Open Source Program Manager must do the following:
- Draft a documented open source contribution policy.
- Establish a documented procedure to ensure that all program participants are aware of the open source contribution policy (e.g., through training, an internal wiki, or other effective means of communication).

(2) Contribution Review and Approval Procedure

The open source process template describes the contribution review and approval procedure as follows:

(2) Contribution Review and Approval Procedure
A documented procedure governing open source contributions must be established. This procedure must include the following:
- Confirm the origin and license of the code to be contributed.
- Review whether there is a right to contribute the code.
- Review the license and contribution policy of the project to which the contribution is directed.
- If necessary, obtain a legal team review.
- Define an approval procedure for the contribution.
- Specify how an approved contribution is to be submitted.
The Open Source Program Manager must maintain records demonstrating that this procedure has been properly carried out.

Through this process, an organization can effectively manage contributions to external open source projects and minimize potential legal risk.

Theopen source contribution procedure published bySK telecom is a good example:

https://sktelecom.github.io/guide/contribute/process/

This procedure clearly shows the process from the contribution review request through approval to submission of the contribution, making it easy for program participants to understand and follow.

5. Keeping the Process Current

A process is not effective if it exists only on paper without being actually operated, or if it no longer fits the work situation or organizational structure. An enterprise must ensure that its processes are always kept up to date to match its internal organization and circumstances.

The ISO/IEC 18974 standard requires that the process be periodically reviewed and improved, as follows:

(1) Periodic Process Review

The open source process template describes periodic process review as follows:

The OSRB (Open Source Review Board) is a body composed of the Open Source Program Manager and the heads of related organizations, such as the legal team, patent team, development team, and infrastructure team, for the company's open source management.
The OSRB reviews the policy and process annually on a regular basis and improves them. All improvement processes are documented and recorded.

(2) Identifying and Implementing Improvements

The following activities are carried out to improve the process:

• The OSRB analyzes the company’s process performance, shortcomings, and best practices.
• It improves the process to reflect changes in the business environment.
• The Open Source Program Manager is responsible for managing the policy and process for open source license compliance.
• The security officer is responsible for managing the policy and process for open source security assurance.

(3) Documenting Process Updates

The process improvement and update process is documented and recorded. This must include:

• Review date and participants
• Identified improvements
• Implemented changes
• Reason for the change
• Approver of the change

These documented records can be managed using tools such asJira orConfluence.

By keeping its processes current, an enterprise can continuously improve the effectiveness of its open source license compliance and security assurance programs and meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

6. Summary

By establishing the processes described so far, an enterprise can meet the key requirements of the ISO/IEC 5230 and ISO/IEC 18974 standards.

Through establishing these processes, an enterprise can gain the following benefits:

1. Establishing an open source license compliance framework

   • Accurately understanding the open source usage status of the supplied software
   • Minimizing legal risk by complying with license obligations
   • Systematic creation and management of compliance artifacts

2. Strengthening open source security assurance

   • Continuous monitoring of Known Vulnerabilities and Newly Discovered Vulnerabilities
   • Establishing a vulnerability assessment and response framework
   • Preventing risk in advance through security testing

3. Effective response to external inquiries

   • Establishing a systematic external inquiry handling process
   • Reducing legal risk through fast and accurate response

4. Systematizing open source contribution activities

   • Ensuring consistent contribution activity through an established contribution policy
   • Protecting intellectual property through a contribution review and approval procedure

5. Continuous process improvement

   • Improving efficiency through periodic process review and improvement
   • Strengthening responsiveness to the latest open source trends and technological changes

By establishing these processes, an enterprise can systematically manage open source license compliance and security assurance, and build a foundation for continuous improvement. In addition, by having processes that align with international standard initiatives such as theOpenChain Project, it can enhance its credibility within the global software supply chain.

[Company Name] (hereinafter referred to as “the Company”) actively utilizes open source software in developing products and services that include software. To minimize open source risk, the Company must carry out (1) activities to comply with the obligations imposed by open source licenses and (2) appropriate activities to detect open source security vulnerabilities and take follow-up action, while distributing software. The Company follows the open source process to ensure these activities.

1. Open Source Process

[Company Name] (hereinafter referred to as “the Company”) actively utilizes open source software in developing products and services that include software. To minimize open source risk, the Company must carry out (1) activities to comply with the obligations imposed by open source licenses and (2) appropriate activities to detect open source security vulnerabilities and take follow-up action, while distributing supplied software. The Company follows the open source process to ensure these activities.

The open source process defines the procedures that must be carried out to comply with open source license obligations and to ensure open source security assurance, at each development stage of developing and distributing the Company’s supplied software. Program participants comply with the following 11 stages of the open source process.

Through the open source process, the Company strives to minimize open source risk and provide customers with safe and reliable supplied software.

The Open Source Program Manager periodically reviews the process at least once a year to disseminate internal best practices and improve any deficiencies.

(1) Open Source Identification

The business unit complies with the following during the software design stage:

• While designing software, identify the anticipated open source usage and confirm the identified licenses.
• Confirm the obligations for each open source license. The obligations for each license can be found in the Company’s Open Source License Guide:https://sktelecom.github.io/guide/use/obligation/
• Design the software considering the source code disclosure scope of each open source license.

The Open Source Program Manager writes and publishes a guide on the obligations, restrictions, and rights of major open source licenses so that business units across the Company can refer to it. This guide must include the following use cases so that common open source license use cases can be managed:

• Distributed in binary form
• Distributed in source form
• Integrated with other open source that triggers additional license obligations
• Includes modified open source
• Includes open source or other software under a license that is incompatible with other components within the supplied software
• Includes open source with attribution requirements

The business unit marks the copyright and license in the source code according to Company rules. The Company’s rules for marking copyright and license in source code can be found on the following page. (insert_link)

When considering the introduction of new open source, the business unit first identifies the license. It confirms the license obligations, restrictions, and rights according to the Company’s Open Source License Guide. If the license is not described in the Company’s Open Source License Guide, it inquires with the Open Source Program Manager about whether it can be introduced and any precautions. A Jira Ticket is created for the inquiry.

The Open Source Program Manager analyzes open source license obligations and provides guidance to the software development organization.

• If there is a question, requests advice from Legal to provide clear guidance.
• Reflects newly analyzed license information in the company-wide license guide.

Security provides a guide for the Company’s security assurance.

(2) Source Code Inspection

The business unit requests an open source inspection according to IT’s guidance and provides the source code.

IT performs an open source inspection using an open source analysis tool, and creates the SBOM (Software Bill of Materials).

The Open Source Program Manager reviews whether open source license obligations can be complied with and whether there are open source license conflicts, and requests the business unit to resolve any issues found. Issues are created as Jira Tickets and assigned to the business unit.

Security reviews the known vulnerabilities detected and provides response guidance to the business unit according to predefined Risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and for Critical Risk, guidance is provided to establish an action plan that can be completed within 1 week.

(3) Issue Resolution

The business unit resolves all issues found during the source code inspection stage.

It removes the open source in question, or replaces it with open source under a different license. For known vulnerability or newly discovered vulnerability issues, it takes measures such as replacing the component with a version in which the vulnerability has been fixed.

Once the business unit has resolved all issues found, it resolves the Jira Ticket issue and requests a re-review.

(4) Review

The Open Source Program Manager reviews whether all issues have been adequately addressed. If necessary, it re-performs the source code inspection using an open source analysis tool.

Security reviews whether all serious vulnerabilities have been resolved. If a vulnerability that is difficult to resolve remains, it reviews whether approval is possible considering the business type and service exposure status.

(5) Approval

The Open Source Program Manager gives final approval or rejection as to whether the open source license compliance procedure has been properly carried out. In case of rejection, it explains the reason to the business unit and proposes a method for correction.

(6) Registration

The Open Source Program Manager finalizes the SBOM to track the list of open source used in each version of the supplied software.

IT registers the finalized SBOM in the system. The SBOM includes the list of open source contained in the supplied software and the following information:

• The product (or service) name and version of the supplied software
• List of open source
  • Component name, version, license, source (URL)
  • Purpose and manner of use
  • Whether modified and details of modifications
  • Version history and key changes for each version

The registered information is periodically reviewed and updated.

(7) Notice

The Open Source Program Manager creates an open source notice to comply with the notice obligation. The open source notice includes the following content:

• Open source contact information for open source-related inquiries
• Notice content for each piece of open source
  • Copyright
  • Open source license name
  • Copy of the open source license
  • (if applicable) a Written Offer to obtain a copy of the source code

The Open Source Program Manager creates the open source notice and delivers it to the business unit. If source code disclosure is required, it guides the business unit on how to compile the source code to be disclosed.

The business unit includes the open source notice when distributing the product. For products with a screen, it takes measures so that users can view it through a menu. (e.g., App > Menu > Settings > Copyright Information > Open Source Licenses)

If the business unit has used open source under a license that requires source code disclosure, such as GPL or LGPL, it confirms the scope of source code disclosure required and compiles the source code to be disclosed.

• The source code compiled to comply with license obligations such as GPL and LGPL must match the source code that makes up the binary included in the product. In other words, building the compiled source code must produce a result identical to the binary included in the product.

(8) Pre-Distribution Confirmation

The business unit submits the following compliance artifacts demonstrating that open source license compliance activities have been properly carried out:

1. The final open source notice included in the product
2. Material confirming that the open source notice is included in the product (e.g., a screenshot showing the open source notice)
3. (if applicable) the source code to be disclosed (submitted compressed into a single file)

The Open Source Program Manager reviews the material submitted by the business unit to check for any issues.

(9) Distribution

The Open Source Program Manager submits the compliance artifacts submitted by the business unit to IT.

IT registers the compliance artifacts on the Company’s open source distribution site.

(10) Final Confirmation

The Open Source Program Manager conducts a comprehensive check to confirm that the compliance artifacts have been registered on the Company’s open source portal without issue, and that they can be downloaded externally without issue.

(11) Monitoring

The Open Source Program Manager periodically checks whether there is any supplied software for which the creation of open source license compliance artifacts is inadequate. It also operates a process to respond quickly to external inquiries. The detailed procedure for the external inquiry response process follows [2. External Inquiry Response Process].

Security operates a process to monitor and respond to known vulnerabilities or newly discovered vulnerabilities. This process must include the following:

1. A method for continuously monitoring known vulnerabilities or newly discovered vulnerabilities in the open source software components used in supplied software
2. A risk/impact assessment procedure for discovered vulnerabilities
3. A method for contacting customers and taking appropriate action, such as upgrading software components, as necessary
4. A method for maintaining continuous monitoring and response capability even after the supplied software has been released to market

The detailed procedure for this security vulnerability response process follows [2. Security Vulnerability Management Process].

2. Security Vulnerability Management Process

After supplied software has been released to market, if a known vulnerability or newly discovered vulnerability is reported, the following process is followed to take appropriate action according to the level of risk.

(1) Continuous Security Testing Before Release

IT builds and operates a system that applies continuous, repeated security testing to all supplied software before release:

1. Automated security testing:
   • Integrate automated security testing tools into the CI/CD pipeline.
   • Automatically run security tests whenever code changes.
2. Vulnerability scanning:
   • Use an SCA tool to scan for known vulnerabilities in open source components.
   • Automatically update the vulnerability database and perform scans daily.
3. Security test result review:
   • Security reviews the security test results and takes necessary action.
   • If a serious vulnerability is found, immediately notifies the development team and establishes a resolution plan.

(2) Monitoring Known Vulnerabilities and Newly Discovered Vulnerabilities

IT builds and operates a system to monitor known vulnerabilities and newly discovered vulnerabilities. To identify structural/technical threats, this system performs the following functions:

1. Automated vulnerability monitoring:
   • Analyzes newly published vulnerabilities daily and automatically identifies affected versions of supplied software.
   • Periodically collects publicly available security vulnerability information.
2. SBOM-based analysis:
   • Uses an SCA tool to perform SBOM-based analysis.
   • Integrates the SCA tool into the CI/CD pipeline to perform automated analysis.
3. Notification and record-keeping:
   • When a vulnerability is discovered, automatically sends a notification to the development lead and security lead for the affected supplied software.
   • Uses an issue tracking system so that everything from notification to review, action, and resolution is documented and recorded.

(3) Vulnerability Assessment and Response

Security assesses each vulnerability according to predefined risk/impact assessment criteria and provides response guidance to the business unit. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and the action deadline is set according to severity.

If a known vulnerability or newly discovered vulnerability is confirmed in previously released supplied software, the business unit establishes an action plan according to the response guidance provided by Security.

If necessary, the business unit notifies customers of the confirmed vulnerability according to the risk/impact score.

(4) Vulnerability Resolution and Verification

• The business unit resolves the vulnerability issue according to the established action plan.
• It resolves the vulnerability by removing the problematic open source software component or replacing it with a patched version, among other methods.
• IT uses an open source analysis tool to confirm that the issue has been properly resolved.
• Security performs additional security testing on the resolved vulnerability to verify that it has been completely resolved.
• The verification results are documented and recorded.
• Reviews whether all serious vulnerabilities have been resolved.
• If a vulnerability that is difficult to resolve remains, reviews whether approval is possible considering the business type and service exposure status.

(5) Post-Release Vulnerability Analysis and Response

IT operates an automated system to analyze vulnerabilities in released supplied software daily, even after release, for all supplied software.

• When affected supplied software is identified, it immediately sends a notification to the development lead and security lead.
• The notified person assesses the severity of the vulnerability and establishes a response plan.
• Carries out patch development, mitigation measures, and other actions according to the response plan.
• Performs verification after the action is completed and documents the results.

(6) Vulnerability Record Management

For each open source component, a vulnerability record is maintained that includes the following information:

• Vulnerability ID (e.g., CVE number)
• Vulnerability description
• Affected versions
• Severity (CVSS score)
• Date discovered
• Resolution status
• Resolution method applied
• Verification results

Vulnerability records are stored in a central database and backed up periodically.

IT registers the SBOM (Software Bill of Materials) with the vulnerability resolved in the system.

(7) Reporting and Communication

• A monthly vulnerability management report is prepared and provided to management and relevant stakeholders.
• The report includes the number of newly discovered vulnerabilities, the number of resolved vulnerabilities, the status of and action plan for unresolved vulnerabilities, and key risk factors and response strategies.
• If a serious vulnerability is discovered, it is immediately reported to the relevant department and management.

(8) Customer and Third-Party Notification

The Open Source Program Manager creates an updated open source notice based on the SBOM with the vulnerability resolved, and delivers it to the business unit.

1. Customer notification:

   The business unit notifies customers of the vulnerability resolution in the following ways:

   • Replaces the open source notice included with the product distribution.
   • Notifies customers directly by email or other means as necessary.
   • Redistributes the version of the supplied software with the vulnerability resolved.

2. Third-party disclosure:

   IT discloses risk information to third parties in the following ways:

   • Registers the revised open source notice and vulnerability-related information on the Company’s open source website.
   • Submits vulnerability information to a public vulnerability database (e.g., NVD).
   • Notifies the maintainer of the open source project of the discovered vulnerability and its resolution.

3. Notification content:

   The information provided to customers and third parties includes the following:

   • Vulnerability overview and identifier (e.g., CVE number)
   • Affected products and versions
   • Potential impact of the vulnerability and CVSS score
   • Temporary response measures
   • Patch or update availability and how to apply it
   • Contact information for obtaining further information

3. External Inquiry Response Process

Responding quickly and accurately to external inquiries related to open source license compliance and security assurance can greatly reduce the risk of escalation to litigation. To this end, the organization complies with the following process:

(1) Acknowledgment of Receipt

The Open Source Program Manager notifies the requester immediately upon receiving an inquiry that it has been received. At this time, it specifies an appropriate response time. If the inquiry is unclear, it requests additional explanation to accurately understand the requester’s intent.

Main types of inquiries and requests:

• Whether specific supplied software uses open source
• A request to provide source code under a GPL or LGPL license mentioned in a Written Offer
• A request for an explanation and source code disclosure for open source missing from the open source notice
• A request to provide missing files or build instructions for disclosed source code
• A request for copyright notation
• Inquiries related to known vulnerabilities or newly discovered vulnerabilities

The Open Source Program Manager creates an issue for the received request and records the response status in detail.

(2) Notification of Investigation

The Open Source Program Manager notifies the requester that the Company is faithfully carrying out open source license compliance and security assurance, and that the inquiry is under investigation. It provides periodic updates on the progress of the internal investigation.

(3) Internal Investigation

The Open Source Program Manager conducts an internal investigation of the request. It confirms whether the license compliance and security assurance process was properly carried out for the supplied software in question, using the SBOM and the documented review history. It requests advice from Legal and Security as needed.

If confirmation is needed from a specific business unit, the Open Source Program Manager requests the investigation from that unit. The business unit that receives the investigation request immediately checks whether there is a problem with the compliance artifacts and security-related matters, and reports the results.

(4) Report to the Requester

The Open Source Program Manager completes the internal investigation within the specified response time and notifies the requester of the results.

• If the requester’s inquiry was a false claim caused by a misunderstanding, it explains this and closes the matter without further action.
• If a problem is confirmed, it notifies the requester of the accurate method and timing for fulfilling the open source license obligation or resolving the security vulnerability.

(5) Issue Remediation / Notification

If an actual license compliance or security problem is found during the internal investigation, the relevant business unit carries out all procedures necessary to resolve it.

(6) Notification of Issue Resolution

Once the problem has been resolved, the requester is notified immediately, and provided with the best way to confirm that the problem has been resolved.

(7) Process Improvement

If there was a license compliance or security problem, the case is reviewed at an OSRB meeting to understand how the problem occurred, and process improvement measures are established to prevent recurrence.

4. Open Source Contribution Process

If the organization allows contributions to external open source projects, the following process must be carried out.

(1) Establishing and Disseminating a Contribution Policy

• A documented policy governing contributions to open source projects must be established.
• This policy must be disseminated within the organization.
• There must be a process for enforcing the policy.

The Open Source Program Manager must do the following:

• Write a documented open source contribution policy.
• Establish a documented procedure to ensure that all program participants are aware of the open source contribution policy (e.g., education, an internal wiki, or other effective means of communication).

(2) Contribution Review and Approval Procedure

A documented procedure for managing open source contributions must be established. This procedure must include the following:

• Confirm the origin and license of the code to be contributed.
• Review whether the contributor has the right to contribute the code.
• Review the license and contribution policy of the project being contributed to.
• Obtain review by the Legal team as necessary.
• Define the approval procedure for the contribution.
• Specify the submission method for approved contributions.

The Open Source Program Manager must maintain records demonstrating that this procedure has been carried out correctly.

Through this process, the organization can effectively manage contributions to external open source projects and minimize potential legal risk.

Jurisdictions outside the United States and the European Union are generally at the recommendation stage. There is no legal enforcement or sanction, but these function as best practices that influence procurement and contracting practices.

India: CERT-In Technical Guidelines

The Indian Computer Emergency Response Team (CERT-In) published theTechnical Guidelines on Software Bill of Materials (SBOM). This is a voluntary guideline aimed at government agencies, the public sector, essential services, and software producing and service companies, covering the value of SBOMs, best practices, minimum elements, and vulnerability tracking procedures. It has no legal force, but it influences government procurement and contracting practices.

In July 2025, CERT-In expanded this guideline to also cover Quantum BOM (QBOM), Cryptography BOM (CBOM), AI BOM (AIBOM), and Hardware BOM (HBOM). This is an example of how the bill of materials concept is spreading beyond software into cryptography, AI, and hardware. The expansion into AI BOM is covered further in5. Tools and Automation and in the separateAI SBOM Compliance Guide.

The first edition of this guide began as a Korean translation of this CERT-In document. The current edition updates that skeleton with current primary sources from the United States and the European Union, and broadens it to a general practitioner’s perspective.

Korea: Software Supply Chain Security Guidelines

In Korea, the Ministry of Science and ICT, the National Intelligence Service, and the Korea Internet & Security Agency (KISA), among others, published the Software Supply Chain Security Guidelines 1.0 in May 2024. It recommends SBOM generation and vulnerability inspection procedures, and the use of the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF).

However, this is only an administrative guideline, and Korea’s current legal system does not yet have legislation that imposes a mandatory reporting obligation at the product level, as the EU Cyber Resilience Act does. Even so, Korean companies exporting software to the EU and the United States must directly meet the requirements of those markets, so building SBOM capability is a practical necessity regardless of domestic regulation.

Practical Implications

The legal standing differs by jurisdiction, but the skeleton of the data required converges. A well-built SBOM system, built once, can satisfy the requirements of multiple jurisdictions at the same time. If the system is designed around the strictest requirement among your export markets (currently the EU CRA), the recommendations of other jurisdictions are largely subsumed within it.

Sources

Indian Computer Emergency Response Team (CERT-In).Technical Guidelines on Software Bill of Materials (SBOM), CIGU-2024-0002.https://www.cert-in.org.in/. Ministry of Science and ICT, National Intelligence Service, Korea Internet & Security Agency (2024).Software Supply Chain Security Guidelines 1.0.https://www.kisa.or.kr/. (all accessed: June 14, 2026)

If the same component is named differently across SBOMs, automated matching breaks down, because there is no way for a machine to know that “Apache Tomcat,” “tomcat,” and “Apache Software Foundation Tomcat” are the same thing. This is why an identifier system that consistently points to components, and a convention for notating licenses with standard codes, are both necessary.

Three Identifiers: PURL, CPE, SWID

The three identifiers used together in practice serve different roles. They are not mutually exclusive, so recording them together where possible is recommended.

Table 1. Identifiers used together in an SBOM(source: purl-spec, NIST NVD, ISO/IEC 19770-2. Retrieved 2026-06-14)

A Package URL points to a component within a package manager ecosystem in the following format.

pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1
pkg:npm/lodash@4.17.21
pkg:pypi/requests@2.31.0

Afterpkg: come the ecosystem type (maven, npm, pypi, etc.), namespace, name, and version. Because the same component can be pointed to with the same string everywhere, it links automatically to vulnerability databases and license databases.

CPE was developed by MITRE in the mid-2000s and is now maintained by NIST. It notates products under a fixed naming rule and is used to look up the vulnerabilities (CVEs) corresponding to a product. SWID is a tag format standardized as ISO/IEC 19770-2 that structurally describes a product’s version and producing/distributing entity, and it is mainly used in asset management. The CISA 2025 minimum elements draft updating “Other Unique Identifiers” to “Software Identifiers” also reflects the maturing of this identifier ecosystem.

License Notation: SPDX License Identifiers

License management is one of the earliest use cases for an SBOM. Recording exactly which license each component is distributed under is what prevents obligation violations and conflicts in advance. Free-text descriptions cannot be matched automatically, so standard codes are used.

SPDX license identifiers assign each license a unique code such asApache-2.0,MIT, orGPL-3.0-only. When multiple licenses apply together, they are combined with a license expression.

Apache-2.0 OR MIT
GPL-2.0-only WITH Classpath-exception-2.0
(MIT AND BSD-3-Clause)

OR indicates a choice among multiple licenses,AND indicates multiple licenses applying simultaneously, andWITH indicates combination with an exception clause.

The principles to follow in practice are as follows.

• The license of every individual component, not just the license of the product as a whole, must be visible.
• When encountering a license not on the standard list, assign it an identifier with a prefix indicating its source (for example, aLicenseRef- prefix) to track it.
• If the license text has been trivially modified but its meaning has not changed materially, use the same identifier as the original.
• Analyze license compatibility to identify in advance the conflicts that can arise when combining components under different licenses.

Even when a license field is auto-extracted by a tool, its accuracy is a separate matter. Precisely identifying non-standard licenses, handling dual licensing, and confirming compliance with licenses that carry field-of-use restrictions remain the responsibility of people and policy. The boundary of automation is covered in5. Tools and Automation.

Sources

Package URL specificationhttps://github.com/package-url/purl-spec. NIST.Common Platform Enumeration (CPE)https://nvd.nist.gov/products/cpe. ISO/IEC 19770-2:2015. SPDX License Listhttps://spdx.org/licenses/. SPDX License Expressionshttps://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/. (All retrieved: 2026-06-14)

Overview

cdxgen is the official SBOM generator of the OWASP CycloneDX project. It supports more than 20 languages and package managers, and the latest version offers a dedicated AI BOM mode. It automatically identifies the dependencies of AI applications (PyTorch, Transformers, and so on) and integrates well with CI/CD pipelines.

From an AI SBOM standpoint, cdxgen’s strength is speed and automation. Its weakness is that it does not fill in license information in a default run. This trait shows up in the execution result below. Where OWASP AIBOM Generator centers on model card metadata, cdxgen centers on code and dependencies. Using both together covers both models and dependencies.

Key Features

• Identifies dependencies from source code and container images to generate a CycloneDX SBOM.
• Includes AI/ML metadata (formulation) with AI BOM mode (-t ai).
• Takes Hugging Face model URLs, Modelfiles, and GGUF artifacts directly as input.
• Automatically submits SBOMs to a Dependency-Track server for continuous management.

Installation

# One-off run (requires Node.js)npx @cyclonedx/cdxgen@latest --version# Global installnpm install -g @cyclonedx/cdxgen

Usage — Generating an AI BOM

Run in AI BOM mode from the AI project directory.

# Generate an AI BOMcdxgen -t ai -o aibom.json .# Generate including AI/ML metadata (formulation)cdxgen -t ai --include-formulation -o aibom.json .

Below is the actual result of running cdxgen against a summarization app (transformers,torch dependencies) that loads a pretrained model (facebook/bart-large-cnn). It automatically identifies 5 dependencies and produces a CycloneDX 1.7 BOM.

$ cdxgen -t python --include-formulation -o aibom.json .CycloneDX Generator 12.5.1 (Node.js)Generated components — 5 entries (CycloneDX 1.7): transformers 4.44.2 pkg:pypi/transformers@4.44.2 license: empty torch 2.4.0 pkg:pypi/torch@2.4.0 license: empty numpy 1.26.4 pkg:pypi/numpy@1.26.4 license: empty tokenizers 0.19.1 pkg:pypi/tokenizers@0.19.1 license: empty huggingface-hub 0.24.6 pkg:pypi/huggingface-hub@0.24.6 license: empty

Figure 1. cdxgen execution output(cdxgen 12.5.1, run 2026-06-13)

One of the generated components looks like this. The identification evidence is filled in, but thelicenses field is empty.

{"name":"transformers","version":"4.44.2","purl":"pkg:pypi/transformers@4.44.2","type":"library","evidence":{"identity":[{"field":"purl","confidence":0.5,"methods":[{"technique":"manifest-analysis","value":"requirements.txt"}]}]}}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• Generator centered on model metadata:OWASP AIBOM Generator
• SBOM management:Dependency-Track,cdxgen + Dependency-Track integration
• Official:cdxgen AI-BOM documentation

This is stage 2 of the implementation roadmap. It is the area where the AI SBOM guide extends most significantly beyond ISO/IEC 5230, covering licensing obligations (3.5), transparency obligations (3.6), and AI SBOM generation and management (3.9).

1. Clause Overview

If competence (3.2) defines who should be able to do what, effective resourcing is what actually attaches people, time, and budget to those roles so the program runs. When policy and procedures exist only on paper and no resources back them, compliance is a name only.

3.8 requires assigning accountability for program tasks and allocating adequate resources. There are five verification materials, covering the naming of role holders, the provision of staffing and funding, access to legal expertise, an internal responsibility-assignment procedure, and a non-conformance remediation procedure. The specification references the resource-related sections of ISO/IEC 42001 Annex B (B.4.2, B.4.6) and the human oversight determination section (B.9.3).

2. Activities to Perform

• Assign accountability for the successful execution of program tasks.
• Allocate sufficient time and funding to the tasks.
• Make legal expertise on AI SBOM compliance accessible to those who need it.
• Have a procedure for reviewing and updating the policy and its supporting tasks.
• Have a procedure for reviewing and remediating non-conformances.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.8.1 Document Identifying Role Holders

How to Comply

Document, by name, the people, groups, or functions holding program roles. Including the job title alongside the name is more stable against personnel changes. The AI SBOM program needs, in addition to the usual open source roles, an AI governance lead, an AI SBOM verification owner, and a model/dataset license review owner.

Sample

| Role | Holder (Job Title) | Contact |
|------|-------------|--------|
| AI Governance Lead | Kim, OO (AI Ethics & Governance Lead) | ai-gov@company.com |
| AI SBOM Verification Owner | Lee, OO (Platform Engineer) | sbom@company.com |
| License Review Owner | Park, OO (Open Source Legal) | oss-legal@company.com |
| Security Owner | Choi, OO (Product Security) | psirt@company.com |

3.8.2 Staffing and Funding

How to Comply

Show that identified roles are actually staffed and that budget has been allocated. Record the time allocation (e.g., 30%) and the basis for the annual budget. AI SBOM compliance takes time for model/dataset review and tool operation, so estimate the per-role time allocation realistically.

Considerations

• State the time allocation: For a shared role, record the percentage of time allocated to AI SBOM work.
• Tool budget: Include the cost of AI SBOM generation/management tools and legal counsel in the budget.

Sample

| Role | Holder | Time Allocation | Annual Budget Basis | Approver / Approval Date |
|------|--------|----------|---------------|--------------|
| AI Governance Lead | Kim, OO | 30% | Personnel cost + regulatory counsel | CTO / 2026-01-15 |
| AI SBOM Verification Owner | Lee, OO | 50% | Personnel cost + tool operation | CTO / 2026-01-15 |

3.8.3 Access to Legal Expertise

How to Comply

Make legal expertise on AI SBOM compliance accessible to those who need it. Because interpreting non-standard licenses and determining regulatory obligations is legal’s job, specify the access path — internal legal counsel or an outside firm. Also define escalation criteria (which matters get escalated to legal).

Sample

- Internal: Open Source Legal Owner (Park, OO) — first-pass license review
- External: XX Law Firm, AI/IP team — non-standard license disputes, regulatory interpretation
- Escalation criteria: a license not on the policy's prohibited/conditional lists, determining
downstream disclosure obligations, matters where new regulation newly applies

3.8.4 Internal Responsibility Assignment Procedure

How to Comply

Document the procedure for assigning internal responsibility for AI SBOM compliance. Vague responsibility leads to gaps, so a RACI matrix distinguishing Responsible (R), Accountable (A), Consulted (C), and Informed (I) per task is effective.

Sample (RACI Matrix)

R Responsible, A Accountable, C Consulted, I Informed

3.8.5 Non-Conformance Review and Remediation Procedure

How to Comply

Have a procedure for reviewing and remediating non-conformances (e.g., a prohibited-license model brought in, a missing AI SBOM, a failure to meet transparency obligations). Vary the handling deadline by severity. In AI, a licensing problem sometimes surfaces after a model has already been deployed, so prepare a remediation path that includes recall or replacement.

Sample (Remediation Procedure and Severity Criteria)

Remediation procedure: identify/report → assess severity → root-cause analysis → corrective
action → recurrence prevention → record
| Severity | Example | Handling Deadline |
|--------|------|----------|
| High | A prohibited-license model is included in a product shipped externally | Immediate response (contain/replace review within 48 hours) |
| Medium | An inbound model is missing from the AI SBOM | Backfill within 7 days |
| Low | Some model card metadata is missing | Handle at the next periodic review |

5. References

• Competence definitions per role:3.2 Competence
• Governance review linked to non-conformance remediation:3.10 Governance
• ISO/IEC 5230 resourcing model:ISO/IEC 5230 Compliance Guide — 3.2.2 Effectively Resourced

1. Clause Overview

If license obligations (3.5) ask “do we have the right to use this material,” transparency obligations ask “what must we disclose about this material.” The two obligations come from different sources. License obligations are imposed by the rights holder through a contract; transparency obligations are imposed by regulation through law.

3.6 requires having a procedure to review whether there are transparency obligations imposed by regulation. The scope of review includes training, testing, and verification datasets, taking into account the model’s intended use. If the use case for the training data creates a transparency issue (e.g., a disclosure obligation to downstream recipients), appropriate risk mitigation measures must be taken. As the EU Artificial Intelligence Act begins full enforcement of transparency obligations from August 2026, the practical weight of this clause is growing.

2. Required Activities

• Maintain a procedure to identify the transparency regulations that apply to AI systems being adopted or developed.
• Review whether training, testing, and verification datasets carry disclosure obligations, based on their intended use.
• Determine risk mitigation measures where a disclosure obligation to downstream recipients exists.
• Document the transparency measures taken.
• Regularly update and reflect the latest transparency obligations set by regulators.([Recommendation of this guide])

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.6.1 Procedure to review and document transparency obligations

Compliance Method

Transparency obligations differ by regulation, so first identify which regulations apply. Once the applicable regulations are determined, derive the disclosure items each one requires and reflect those items in the AI SBOM or model card. Unlike license obligations, transparency obligations center on “disclosure,” so the output must be organized in a form that can be delivered externally.

The table below lists the main transparency obligations that intersect with the AI SBOM. The regulatory timeline and broader context are managed together in the regulatory matrix in3.10 Governance.

Table 1. Transparency obligations that intersect with the AI SBOM (as of June 2026)

The figure below shows the review flow that derives transparency obligations from a material’s intended use.

Figure 1. Transparency obligation review flow

Considerations

• Dataset provenance is central: Most transparency obligations attach to training data. A dataset’s provenance and license must be recorded in the AI SBOM to fulfill disclosure obligations. This connects directly to the AI SBOM (3.9).
• Intended use is the criterion: The same model can carry different transparency obligations depending on the use case. High-risk uses or services aimed at the general public carry heavier obligations.
• Downstream disclosure obligations: When supplying a model or system externally, review what information the recipient must be told. Risk mitigation can be fulfilled through a public summary of training data or contractual notice.
• Reflect regulatory change: Since the EU Artificial Intelligence Act applies transparency obligations from August 2026, update the procedure to match the timeline. Responsibility for the update is managed by governance (3.10).

Sample (Transparency Obligation Review Procedure)

Below is a sample of the core part of a transparency obligation review procedure document. This procedure document becomes verification material 3.6.1.

## Transparency Obligation Review Procedure
### 1. Identify Applicable Regulations
Identify applicable regulations based on the AI system's intended use and deployment
region.
(e.g., EU market deployment → EU Artificial Intelligence Act; domestic high-impact AI →
Korea's AI Basic Act)
### 2. Derive Disclosure Items
Organize each regulation's transparency obligations into disclosure items.
- Training data summary (EU Artificial Intelligence Act Article 53)
- AI-generated / interaction labeling (EU Artificial Intelligence Act Article 50, Korea's
AI Basic Act)
- Data provenance disclosure (Korea's AI Basic Act)
### 3. Downstream Review
Review the information to be conveyed to recipients on external supply, and determine the
necessary risk mitigation measures.
### 4. Reflection and Documentation
Reflect the derived disclosure items in the AI SBOM and model card, and record the
measures taken.
### 5. Responsibility and Cycle
- Review: Legal and AI governance lead
- Update: On changes to regulatory enforcement timelines, and at least semiannually

5. See Also

• Distinction from license obligations:3.5 License Obligations
• AI SBOM to hold disclosure items:3.9 AI SBOM
• Regulatory timeline and governance:3.10 Governance
• AI model licenses and labeling obligations:Enterprise Open Source Management Guide — AI Compliance

1. Clause Overview

If policy (3.1) defines what must be done, competence ensures there are people who can do it. AI SBOM compliance demands broader knowledge than open source compliance, which dealt only with code licensing. It requires judgment on the licensing of model weights and datasets, interpreting model cards, emerging AI regulation, and the usage restrictions of non-standard licenses.

3.2 requires identifying the roles and responsibilities that affect the program’s performance, determining the competence each role needs, and ensuring participants have it. The specification specifies competence in governance, security, safety, privacy, development, and supplier management functions where relevant to the use case.

2. Activities to Perform

• Identify and document the roles that affect the program’s performance and their responsibilities.
• Define the competence required for each role (governance, security, safety, privacy, development, supplier management).
• Add AI-specific competence (model/dataset licensing, model card interpretation, AI regulation) to the role-level competence definitions.
• Ensure participants are competent on the basis of education, training, and experience.
• Retain competence assessment evidence, and periodically check that the list stays up to date.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.2.1 List of Roles and Responsibilities

How to Comply

Document the roles involved in the program and the responsibilities of each. In addition to the usual open source roles, an AI SBOM program includes an AI governance role and roles that review models and datasets. Writing responsibilities out specifically makes the later work of defining competence (3.2.2) and assigning accountability (3.8.4) clearer.

Sample

| Role | Responsibility |
|------|------|
| AI Governance Lead | Approves the framework, determines regulatory obligations, chairs periodic reviews |
| AI SBOM Verification Owner | Generates, reviews, and approves the AI SBOM; reflects inbound materials |
| License Review Owner | Determines licensing obligations for models, datasets, and the model tree |
| Data Owner | Manages the provenance and licensing of training/validation datasets |

3.2.2 Competence Required per Role

How to Comply

Define the competence each role must have. Of the six functions the specification lists (governance, security, safety, privacy, development, supplier management), select the ones that apply to the role and use case, and add AI-specific competence. For example, the license review owner needs the competence to interpret the usage restrictions of non-standard licenses (Llama Community, OpenRAIL).

Sample

| Role | Required Competence |
|------|----------|
| AI Governance Lead | Governance, understanding of AI regulation (EU AI Act, Korea's AI Basic Act), risk management |
| AI SBOM Verification Owner | Development, SPDX/CycloneDX formats, model card interpretation, generation tool operation |
| License Review Owner | Supplier management, interpreting open source and non-standard licenses, model tree tracing |
| Data Owner | Privacy, dataset licensing, provenance management |

3.2.3 Competence Assessment Evidence

How to Comply

Assess whether each participant actually has the competence their role requires, and retain the evidence. Training completion, qualifications, and hands-on experience serve as the basis. Since AI regulation and licensing change quickly, periodically check the list to keep it current.

Considerations

• Diversify the basis for assessment: Use not only training completion but also practical work products (e.g., license review records) as competence evidence.
• Periodic checks: Re-review competence requirements when new regulation takes effect or new license types emerge.
• Fill gaps: When an assessment reveals a competence gap, close it with training or outside expertise (3.8 Effectively Resourced).

Sample (Competence Assessment Log)

| Participant (Role) | Role | Assessment Item | Basis | Result | Assessment Date |
|-------------|------|----------|----------|------|--------|
| Lee, OO | AI SBOM Verification Owner | Writing CycloneDX ML-BOM | Internal training + work products | Met | 2026-03-10 |
| Park, OO | License Review Owner | Interpreting non-standard licenses | 5 years of OSS legal experience | Met | 2026-03-10 |

5. References

• Procedure for attaching resources to roles:3.8 Effectively Resourced
• Securing participant awareness:3.3 Awareness
• ISO/IEC 5230 competence model:ISO/IEC 5230 Compliance Guide — 3.1.2 Competence

Since an SBOM requires machine readability, a standard format is necessary. Among the three formats specified by the US NTIA minimum elements, SPDX and CycloneDX split practical use between them. The third, the SWID tag, is used mainly in asset management; its role as an identifier is covered inIdentifiers and Licenses.

SPDX

SPDX (System Package Data Exchange) is a project under the Linux Foundation. Version 2.2.1 became an international standard as ISO/IEC 5962:2021 in August 2021. It is worth noting that the current ISO standard refers strictly to version 2.2.1.

The Linux Foundation released SPDX 3.0 on April 16, 2024, introducing a structure of purpose-specific profiles. The approach layers Security, Build, Dataset, and AI profiles on top of a core model. The AI profile carries model training and characterization information, the Dataset profile carries data provenance and licensing, and the Security profile carries vulnerability identification, severity, exploitability, and mitigation plans. A patch release, 3.0.1, followed in December of the same year. Whether SPDX 3.x is being re-standardized with ISO had not been confirmed as of June 2026.

CycloneDX

CycloneDX is a full-stack BOM standard that originated at OWASP (Open Worldwide Application Security Project). Its distinguishing feature is native support for Vulnerability Exploitability eXchange (VEX) within the format itself. International standardization proceeded through Ecma International’s technical committee TC54. Version 1.6 was published as ECMA-424 1st edition in June 2024, adding a Cryptographic Bill of Materials (CBOM) and CycloneDX Attestations, and v1.7 was announced in October 2025 and standardized as ECMA-424 2nd edition in December 2025. v1.7 added post-quantum cryptography readiness, structured citations, and support for patent objects.

CycloneDX can express software (SBOM), hardware (HBOM), services (SaaSBOM), and machine learning models (ML-BOM) all within a single format.

Comparing the Two Formats

Table 1. Comparison of the two major SBOM standard formats(source: ISO/IEC 5962:2021, Linux Foundation 2024, Ecma International ECMA-424. Retrieved 2026-06-14)

The two standards differ in design philosophy. SPDX extends its scope of application through profiles, while CycloneDX expresses it through component types and auxiliary objects. Both, however, target the same problem in that they carry component identification, licensing, and dependency relationships. Whichever you choose, conversion tools exist between the two formats, so you can choose based on the format your trading partners require and the format your own tool chain supports well. If license compliance is the focus, SPDX is the familiar starting point; if vulnerability operations is the focus, CycloneDX is.

Next, we look at theminimum elements that define what a format must contain, andidentifiers and licenses for consistently pointing to components.

Sources

ISO/IEC (2021).ISO/IEC 5962:2021 — SPDX Specification V2.2.1. The Linux Foundation (2024).SPDX 3.0 Release.https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases. Ecma International.ECMA-424 — CycloneDX Bill of Materials Specification.https://ecma-international.org/publications-and-standards/standards/ecma-424/. CycloneDX (2025).CycloneDX v1.7 Released.https://cyclonedx.org/news/cyclonedx-v1.7-released/. (All retrieved: 2026-06-14)

1. Documenting an Open Source Policy

An enterprise must establish and document an open source policy consisting of principles that let the organizations involved in developing, servicing, and delivering supplied software use open source correctly, and must propagate this policy throughout the organization.

To this end, the ISO standards commonly require a documented open source policy and security assurance policy as follows.

A typical open source policy includes the following. An enterprise must create and document an open source policy that includes these principles:

1. Principles for minimizing open source license compliance and security vulnerability risk when delivering supplied software products and services
2. Principles for contributing to external open source projects
3. Principles for releasing the enterprise’s own software as open source
4. Principles for generating and managing the Software Bill of Materials (SBOM) of open source software components
5. Principles for responding to known vulnerabilities and newly discovered vulnerabilities

The open source policy must also be propagated to program participants and reviewed and updated regularly. This ensures the policy always stays current and reflects the organization’s requirements.

2. What the Open Source Policy Must Cover

An open source policy must include the following core content:

(1) Open Source License Compliance Principles

To achieve open source license compliance, the following principles must be established:

• Identify and document all open source included in supplied software
• Determine and comply with the license obligations of each open source
• Produce compliance artifacts that satisfy license obligations
• Fulfill license obligations such as open source notices and source code disclosure

(2) Open Source Security Assurance Principles

To achieve open source security assurance, the following principles must be established:

• Monitor known vulnerabilities and newly discovered vulnerabilities in the open source components of supplied software
• Perform a risk/impact assessment when a vulnerability is found
• Respond promptly and apply patches for severe vulnerabilities
• Notify customers of vulnerability information and provide updates

(3) Responding to Open Source Risk

To minimize the license and security risks that come with using open source, the following procedures must be established:

1. Identify open source and review its license obligations
2. Design the architecture with open source licenses in mind
3. Produce open source compliance artifacts
4. Generate and manage the Software Bill of Materials (SBOM)
5. Respond to open source license compliance issues
6. Respond to open source security vulnerabilities

You can see how these principles are documented in6. Use of Open Source of [Appendix 1] the open source policy template.

1. Use of Open Source
When developing and delivering supplied software, the obligations required by each open source license must be observed. The activities carried out for this purpose are called open source license compliance.
For proper open source license compliance activities and security assurance, the software development/delivery organization must comply with the following and record and retain the entire process in an issue tracking system.
(1) Identify open source and review license obligations
When introducing open source into supplied software development, first identify what the open source license is, and review and confirm the obligations the license requires.
The company's [Open Source License Guide] includes a list of major open source licenses, and for each license, it explains the obligations required by each of the following distribution forms.
- Binary form
- Source form
- Strong/weak Copyleft
- SaaS-based delivery
- Whether modified
- Inclusion of open source requiring attribution, etc.
Software development/delivery organizations can refer to this guide when reviewing open source license obligations. If a review of an open source license not covered by this guide is needed, contact the open source program manager.
(2) Design with open source licenses in mind
Identify the coupling relationships of open source and design the software architecture so that the company's own code is not affected by open source licenses.
The company's [Open Source License Guide] explains the source code disclosure scope for each open source license and design methods for preventing disclosure of the company's own code.
(3) Produce open source compliance artifacts
The most basic element of open source license compliance activity is understanding the state of open source included in supplied software. This is precisely to properly satisfy the open source license requirements that are the core of open source license compliance. In other words, a set of compliance artifacts must be produced for the open source included in supplied software.
Open source compliance artifacts fall into two broad categories.
1. Open source notice: a document providing the full text of open source licenses and copyright information
2. Source code package to be disclosed: a package that gathers the source code to be disclosed to fulfill the obligations of open source licenses such as GPL and LGPL that require source code disclosure
To compile, distribute, and archive these compliance artifacts, the following must be observed.
- Compile the open source notice or the source code package to be disclosed according to the conditions required by each license. For example, if a license requires that the full text of the license be enclosed, providing only a link is not sufficient.
- Store the compiled artifacts in a separate repository.
- If the source code to be disclosed is provided via a written offer, publish a download link so that the repository of compiled artifacts can be accessed externally.
The company's open source process can be used to issue the open source notice and compile the source code package to be disclosed.
(4) Generate the Software Bill of Materials (SBOM)
There must be a process to generate and maintain an SBOM (Software Bill of Materials) that includes the details of each open source software component making up the supplied software.
The company's open source process can use open source tools to generate and retain the SBOM.
(5) Compliance issue response procedure
When a compliance issue is raised, the open source program manager performs the following procedure to respond promptly.
1. Acknowledge receipt of the inquiry and specify a reasonable resolution time.
2. Confirm whether the issue content actually points to a real problem. (If not, inform the person who raised the issue that it is not a problem.)
3. If it is a real problem, set a priority and decide on an appropriate response plan.
4. Carry out the response and, if necessary, appropriately supplement the open source process.
5. Preserve the above using the issue tracking system.
(6) Open source security assurance management
A documented procedure for detecting and resolving known vulnerabilities in the open source software components of supplied software must be established and maintained. This procedure must include the following.
- Apply methods for discovering the existence of known vulnerabilities
- Perform a risk/impact assessment for each discovered vulnerability
- Take appropriate action such as contacting customers or upgrading software components when necessary
The following processes must also be built.
- Identify structural and technical threats to supplied software
- Apply continuous and repeated security testing
- Confirm that identified risks have been resolved before the release of supplied software
- Secure monitoring and response capability after supplied software is released to the market
A record must be kept of the known vulnerabilities and newly discovered vulnerabilities identified for each open source software component, and of the actions taken.

(4) Internal Responsibility Assignment Procedure

The open source policy must address a procedure for internally assigning responsibility to resolve open source management issues.

The ISO standards commonly require a documented procedure for assigning internal responsibility as follows.

The open source program manager must identify license compliance issues and appropriately assign responsibility to the person in charge of each role to resolve them. Likewise, for open source security vulnerability issues, the person in charge of security identifies the issue and assigns responsibility to the appropriate personnel to resolve it.

To this end, a documented procedure for assigning internal responsibility can be reflected in the open source policy as in the example below.

4. Roles, Responsibilities, and Competencies
To ensure the policy is effective, the following defines the roles and responsibilities and the competencies the person in charge of each role must have.
(2) Open Source Program Manager
- Defines the roles necessary for open source license compliance and designates the responsible organization and person in charge of each role. Consults with the OSRB when necessary.
(6) Security Lead
- Assigns responsibility for each task so that open source security assurance can be carried out successfully.

Through this procedure, internal responsibility for open source license compliance and security assurance is clearly assigned, so that each person in charge can understand and perform their role. Consultation with theOSRB (Open Source Review Board) also helps maintain consistency with the organization’s overall open source strategy.

The internal responsibility assignment procedure must be reviewed and updated regularly, and must be able to be flexibly adjusted as the organization’s structure or projects change. This allows the efficiency and effectiveness of open source management to continuously improve.

(5) Responding to Non-Compliant Cases

An enterprise must document a procedure for promptly reviewing and responding to non-compliant cases in open source license compliance and security assurance.

ISO/IEC 5230 and ISO/IEC 18974 commonly require a documented procedure for reviewing and remediating non-compliant cases as follows.

To this end, an enterprise can reflect a documented procedure for reviewing and remediating non-compliant cases in the open source policy as in the example below.

6. Use of Open Source
(5) Compliance and Security Assurance Issue Response Procedure
When a license compliance or security assurance issue is raised, the open source program manager performs the following procedure to respond promptly:
1. Acknowledge receipt of the inquiry and specify a reasonable resolution time.
2. Confirm whether the issue content actually points to a real problem. (If not, inform the person who raised the issue that it is not a problem.)
3. If it is a real problem, set a priority and decide on an appropriate response plan.
- For license compliance issues, consult with the legal lead to establish a plan for meeting license obligations.
- For security assurance issues, consult with the security lead to establish a plan for resolving the vulnerability.
4. Carry out the response and, if necessary, appropriately supplement the open source process.
5. Record and preserve the above using the issue tracking system.
6. Analyze the root cause of the non-compliant case and establish an improvement plan to prevent recurrence.
7. Report the non-compliant case and the response outcome to the OSRB (Open Source Review Board) and, if necessary, discuss ways to improve the policy and process.

Through this procedure, an enterprise can systematically manage non-compliant cases related to open source license compliance and security assurance, and pursue continuous improvement. In addition, using a standardized format such asSPDX to manage license and security information makes it possible to identify and respond to non-compliant cases even more effectively.

(6) Staffing and Budget Support

An enterprise must provide sufficient resources for the open source program to function smoothly. Personnel for each role in the program must be appropriately staffed, and adequate budget and working time must be guaranteed. If not, a procedure to compensate for this must be put in place.

The ISO standards commonly require that the personnel for each role in the program be properly staffed and that adequate funding be provided, as follows.

To this end, an enterprise can reflect content on staffing and budget support in the open source policy as in the example below:

4. Roles, Responsibilities, and Competencies
The head of the organization responsible for each role designates a person in charge within the organization and allocates adequate time and budget for that person to fully perform the role.
- If the person in charge of each role is not adequately supported while performing the role, they must raise the issue with the open source program manager.
- The open source program manager discusses the resolution with the relevant organization head. If not resolved adequately, the open source program manager may request the OSRB to resolve the issue.
- The OSRB shares the issue with the head of the higher organization and requests resolution.

In addition, an enterprise can strengthen staffing and budget support by considering the following:

1. Assign dedicated personnel to the open source program manager
2. Secure a budget for purchasing specialized tools for open source license compliance and security assurance
3. Set a budget for training and building the competency of program participants
4. Allocate a budget for consulting with outside experts
5. Establish a regular process for reviewing personnel and budget

Through this support, an enterprise can raise the effectiveness of its open source license compliance and security assurance program and meet the requirements ofISO/IEC 5230 andISO/IEC 18974.

(7) Providing Expert Advice

When the person in charge of each role needs a professional review to resolve an open source issue, the enterprise must provide a way to request advice for this.

The ISO standards commonly require a way to use internal or external professional advice to resolve issues, as follows.

For open source license compliance issues, the company’s internal legal team is the primary owner, and if an issue is contentious, an outside law firm with attorneys specializing in open source can be used.

For open source security vulnerability issues, the company’s internal security team is the primary owner, and if an issue is complex and contentious, advice can be requested from an outside security specialist firm.

To this end, an enterprise can reflect content on providing advice in the open source policy as in the example below.

4. Roles, Responsibilities, and Competencies
(4) Legal Lead
The legal lead provides advice on legal risks and mitigation measures that may arise in the course of using open source, such as interpreting open source licenses and obligations.
- Provides a reasonable way for program participants to inquire about open source license compliance issues.
- Provides advice on license and intellectual property issues, including conflicts caused by incompatible open source licenses.
- Reviews necessary legal matters, such as open source licenses and the CLA (Contributor License Agreement), when contributing to external open source projects.
- If an issue is contentious, requests advice from an outside law firm with attorneys specializing in open source.
(6) Security Lead
The security lead operates open source security vulnerability analysis tools and builds a system so that security vulnerability analysis is smoothly performed for all supplied software.
- Provides a reasonable way for program participants to inquire about known vulnerabilities or newly discovered vulnerabilities, and uses outside professional technical advice when necessary to resolve vulnerabilities.

For reference, theOpenChain Project provides, through its partner program, a list of global law firms that offer open source-related advice:https://www.openchainproject.org/partners

Law firms registered as OpenChain partners meet the requirements set by the OpenChain Project, and in South Korea,Bae, Kim & Lee LLC is the sole registrant.

(8) Specifying Scope of Application

A single open source policy (program) does not necessarily have to apply to the entire organization. The scope of application can be set differently depending on the characteristics of each organization and product within the enterprise. For example, an organization that does not deliver any supplied software at all can be excluded from the scope of the open source program.

The ISO standards commonly require a written statement that clearly defines the scope and limits of the program, as follows.

An enterprise must clearly define the scope and limits of the open source program in view of the characteristics of the organization and products, and state this in the open source policy.

Also, as the organizational structure, products, and services change to match the business environment, situations may arise where the scope of the program needs to be determined or revised. An enterprise must establish metrics for assessing scope, and perform reviews and inspections for continuous improvement to fix shortcomings.

To this end, an enterprise must have a system for clearly defining the scope of application in the open source policy and documenting the history of activities, as follows.

2. Scope of Application
This policy applies to the following three parts.
1. It applies to all supplied software the company provides or distributes externally. However, using open source solely for internal use is not within the scope of this policy.
2. It applies when program participants contribute to external open source projects.
3. It applies when releasing internal code as open source.
The scope of application can change to match the company's business environment. In particular, to ensure continuous effectiveness, the open source program manager investigates at least once a month whether there is any supplied software distributed or serviced externally that is not covered by this policy. If even one such case is found, this is used as the basis for determining that the scope of application must be changed.
The procedure for changing the scope of application is as follows.
1. When the open source program manager determines that a change to the policy's scope of application is needed due to changes in the company's business environment, such as a new business or reorganization, a proposal for this is submitted to the OSRB.
2. The OSRB approves an appropriate level of change to the scope of application.
3. The OSRB revises the open source policy to change the scope of the policy.
The open source program manager continuously documents the history of reviews, updates, and inspections performed at least once a month to improve the scope of application, using the [Jira](https://www.atlassian.com/software/jira) Issue Tracker.

Therefore, an enterprise must have a system for clearly defining the scope of application in the open source policy and documenting the history of activities, as shown above.

(9) Responding to External Inquiries

Customers and open source copyright holders sometimes contact an enterprise regarding open source-related inquiries, requests, and claims about supplied software developed using open source. The main content of external inquiries and requests is as follows:

• Inquiries about whether open source was used in a specific piece of supplied software
• Requests to provide source code under the GPL or LGPL licenses referenced in a written offer
• Requests to explain and disclose source code for open source found in supplied software but not listed in the open source notice
• Requests to provide missing files and build instructions for source code disclosed under obligations such as GPL and LGPL
• Requests for attribution
• Inquiries and requests related to open source security vulnerabilities

An enterprise must designate a person in charge of handling these external inquiries. This is typically the open source program manager.

There have been cases where an outside open source developer, wanting to discuss an open source-related issue with a specific enterprise, could not find a way to contact the enterprise’s representative and ended up filing a legal claim directly. To prevent this, an enterprise must always publicly disclose a way for third parties to make open source-related inquiries and requests to the enterprise.

The ISO standards commonly require a publicly available way for third parties to make open source inquiries, as follows:

The following ways can be provided so that outside parties can make open source-related inquiries to the enterprise:

1. Publish a representative email address for the organization in charge of open source.
2. Use theLinux Foundation’s Open Compliance Directory.
3. If the enterprise has an open source website, publish the email address through it.

Including and publishing the representative email address of the organization in charge of open source in the open source notice enclosed with supplied software is also a good approach.

An enterprise can reflect content on responding to external inquiries in the open source policy as in the example below:

9. Responding to External Inquiries
(1) Responsibility for Responding to External Inquiries
Responding to inquiries and requests about open source from external parties is the responsibility of the open source program manager.
- The open source program manager may assign all or part of the handling of an inquiry to an appropriate program participant within the company. Legal is consulted for handling when necessary.
- Any program participant who receives an external inquiry about open source must notify the open source program manager so a prompt response can be made.
(2) Publishing Contact Information
The open source program manager publicly provides the contact information of the person in charge so that external parties can make open source-related inquiries and requests.
- Provides contact email information in the open source notice.
- Provides email information on the open source website.
- Registers contact information in the Linux Foundation's Open Compliance Directory.
(3) External Inquiry Response Procedure
Responding to external open source inquiries promptly and accurately can greatly reduce the risk of claims or legal action. To this end, the company follows the external inquiry response procedure defined in the company's open source process for responding to external open source inquiries.

SK telecom includes an open source notice in all of its supplied software. The open source notice provides the address of the SK telecom open source website together with an email address for contacting the open source program office.

TheSK telecom open source website also provides an email address for contacting the open source program office.

(10) Open Source Contribution

Global software companies value not only using open source to build products and provide services, but also the strategic value that can be created by contributing to open source projects. However, approaching this without a sufficient understanding of and strategy for the open source project ecosystem and how communities operate can unexpectedly damage the company’s reputation and create legal risk. It is therefore important for an enterprise to establish a strategy and policy for participating in and contributing to open source projects.

ISO/IEC 5230 requires a documented open source contribution policy, as follows.

This policy on open source contribution can be found in7. Open Source Contribution of the [Appendix 1] open source policy sample.

7. Open Source Contribution
The company encourages participation and contribution to external open source projects to create business value from open source. However, this process requires care to avoid unintended exposure of the company's intellectual property or infringement of third-party rights. To this end, when a program participant of the company contributes to an external open source project, the following must be observed.
(1) Review Request and Approval
From a copyright standpoint, an open source contribution grants the open source project the right to modify, use, and distribute the work. In some cases, copyright must even be assigned to the open source project. Generally, the copyright of a work created during employment is owned by the employer. In other words, a work created by a program participant is owned by the company. A program participant contributing a work to open source on their own judgment can cause unnecessary copyright infringement issues.
Therefore, if there is an open source project you wish to contribute to, follow the review request and approval procedure before the first contribution, in accordance with the open source contribution process.
However, in the following simple cases, since the risk of copyright infringement is not significant, a program participant may contribute based on their own judgment without going through the review procedure.
- A small code snippet of 10 lines or fewer
- Questions/answers on Stack Overflow
- Administrative activity on GitHub: creating issues, reviewing/approving pull requests, etc.
...

The open source contribution policy must include the contribution procedure, approval process, measures for protecting intellectual property rights, and guidance on signing aCLA (Contributor License Agreement). It must also provide guidelines for behavior when program participants engage with the open source community on behalf of the company.

(11) SBOM Generation and Management

A procedure for generating and managing theSBOM (Software Bill of Materials) must be established:

• Select the SBOM generation tool and methodology
• Ensure the accuracy and completeness of SBOM information
• Establish an SBOM update and version management process
• Define a method for sharing and distributing the SBOM

An enterprise can reflect content on SBOM generation and management in the open source policy as in the example below:

6. Use of Open Source
(4) Generate the Software Bill of Materials (SBOM)
There must be a process to generate and maintain an SBOM (Software Bill of Materials) that includes the details of each open source software component making up the supplied software.
The company's open source process can use open source tools to generate and retain the SBOM.
- The SBOM is generated using a standard format such as [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/).
- An SBOM is generated and managed for all supplied software.
- The SBOM is updated and version-controlled with each release of the supplied software.
- The accuracy of SBOM information is periodically verified.
- Preparations are made to share the SBOM with customers and regulators when necessary.

SBOM generation and management are core elements of open source license compliance and security assurance. Through this, an enterprise can accurately understand the open source components in use and respond promptly to known vulnerabilities or license issues.

An enterprise must include these SBOM-related principles in its open source policy to build a systematic SBOM management system.

3. Summary

Documenting an open source policy is the single most important process for effective open source management.

The next page provides a sample open source policy document that meets the requirements of ISO/IEC 5230 and ISO/IEC 18974 mentioned above:[Appendix 1] Open Source Policy (template)

Referring to the content above, it is necessary to establish appropriate principles for each requirement that fit the company’s situation. It is also important to go beyond documentation alone and consider actionable procedures. A policy that is words alone is of no use.

An open source policy must include the following core elements:

1. Open source license compliance principles
2. Open source security assurance principles
3. Response to open source risk
4. Internal responsibility assignment procedure
5. Response to non-compliant cases
6. Staffing and budget support plan
7. Method of providing expert advice
8. Specification of the policy’s scope of application
9. External inquiry response procedure
10. Open source contribution guidelines
11. Method for generating and managing the SBOM (Software Bill of Materials)

Establishing and documenting an open source policy that includes these elements makes it possible to meet the key requirements of the ISO/IEC 5230 and ISO/IEC 18974 standards.

A policy must not stop at documentation alone; it must actually be implemented within the organization. This requires regular review and updates, along with training for program participants. An effective open source policy will help systematically manage the organization’s use of and contribution to open source, and minimize potential legal and security risks.

This is stage 1 of the implementation roadmap. It defines the program’s scope (3.4), establishes policy (3.1), and secures the competency and awareness of participants (3.2, 3.3). All subsequent clauses operate on top of this foundation.

Overview

OWASP AIBOM Generator is an open source tool that takes a Hugging Face model ID as input, fetches model card metadata, and generates an AI SBOM in CycloneDX format. It is maintained by the OWASP Gen AI Security Project, and its distinguishing feature is scoring how complete the generated BOM is.

Where cdxgen identifies dependencies quickly but leaves the license fields empty, this tool fills in the license, author, and external references recorded in the model card. It works well as a starting point for the license review required by3.5 License Obligations.

Key Features

• Fetches metadata from Hugging Face models and generates an AIBOM in both CycloneDX 1.6 and 1.7 format.
• Evaluates the completeness of the generated BOM with a score (0–100) and a profile, broken down section by section.
• Displays model information, the model card, license, and external references in a human-readable view.
• Available both as a web UI and a command-line interface (CLI).

Usage A — Web UI

The simplest approach: just enter a model ID in the browser. Use the Hugging Face Space provided by the OWASP Gen AI Security Project, or clone the repository and run it locally.

First, enter a Hugging Face model ID (e.g.,facebook/bart-large-cnn) on the input screen and click generate.

Figure 1. OWASP AIBOM Generator input screen(GenAI Security Project, captured 2026-06-13)

Once generation finishes, the result screen shows an AIBOM summary, the completeness assessment, download buttons (CycloneDX 1.6 and 1.7), AI model information, and the model card. The completeness assessment at the top of the screen shows at a glance whether the BOM has the minimum fields needed for identification.

Figure 2. Generation result screen — model information, license (MIT), completeness assessment (Basic)(captured 2026-06-13)

The result screen offers a Human-Friendly View along with a field checklist, a score report, and a JSON view tab. Check the items needed for license obligation review and AI SBOM retention directly on screen, and download the CycloneDX file.

Usage B — Command Line (CLI)

The CLI is convenient for embedding in CI/CD or batch-processing multiple models. After installation, pass the model ID as an argument.

# Install (a Python virtual environment is recommended)pip install"git+https://github.com/GenAI-Security-Project/aibom-generator"# Generate an AIBOM from a model IDaibom facebook/bart-large-cnn -o aibom.json

Below is the actual execution result. It generates CycloneDX 1.6 and 1.7, passes schema validation, and shows the completeness score broken down by section.

$ aibom facebook/bart-large-cnn -o aibom.json✅ Successfully generated CycloneDX 1.6 SBOM — Schema Validation (1.6): Valid✅ Successfully generated CycloneDX 1.7 SBOM — Schema Validation (1.7): Valid📊 Completeness Score: 58.7/100 Profile: Basic - Required Fields: 20/20 - Metadata: 8/20 - Component Basic: 17.1/20 - Component Model Card: 6.7/30 - External References: 10/10

Figure 3. CLI execution output(aibom CLI, model facebook/bart-large-cnn, run 2026-06-13)

The model component in the generated BOM has its license and model card filled in. Unlike cdxgen’s output, thelicenses field is not empty.

{"type":"machine-learning-model","name":"bart-large-cnn","purl":"pkg:huggingface/facebook/bart-large-cnn","licenses":[{"license":{"id":"MIT"}}],"authors":[{"name":"facebook"}],"modelCard":{"modelParameters":{},"considerations":{}}}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure:3.9 AI SBOM
• License obligation review:3.5 License Obligations
• Another generation tool:cdxgen
• Official:OWASP AIBOM Generator

1. Purpose and Scope

1.1 Purpose

This policy provides principles and procedures for the Company to safely and effectively utilize open source software. The main objectives of the policy are as follows:

1. Open Source License Compliance:
   • Comply with the license obligations of open source components included in supplied software, and satisfy relevant legal requirements.
2. Open Source Security Assurance:
   • Identify security vulnerabilities in open source components included in supplied software, and minimize security risk through appropriate response measures.
3. Contribution to External Open Source Projects:
   • Promote collaboration with the open source community by contributing to external open source projects, and protect the Company’s intellectual property.
4. Open Sourcing of Internal Projects:
   • Release internal projects as open source to enhance collaboration with the open source community and promote the Company’s technical capabilities.

These principles are designed to satisfy the requirements of ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance).

1.2 Impact of Non-Compliance

If the Company fails to comply with this policy, it may face the following risks:

• Legal Risk: The Company may receive external demands for open source license compliance, and may face litigation or fines.
• Reputational Damage: The Company’s reputation may be damaged due to source code disclosure obligations or security incidents.
• Business Loss: Relationships with customers or suppliers may deteriorate due to contract violations.
• Security Incidents: Serious security incidents may occur due to known vulnerabilities or newly discovered vulnerabilities.

1.3 How Program Participants Can Contribute

All program participants of the Company must understand and comply with this policy. Participants can contribute in the following ways:

• Perform the responsibilities and obligations defined in the policy according to their role.
• Complete education related to open source licenses and security, and apply it in practice.
• Report immediately if they discover an issue that impedes compliance with the policy.

1.4 Scope

This policy applies to all software projects that the Company develops, distributes, or uses. The main scope of application is as follows:

• All supplied software provided or distributed externally.
• Activities contributing to external open source projects.
• Activities releasing internal projects as open source.

However, open source used only for internal purposes may be subject to a separate review procedure to determine whether the policy applies.

The scope of the policy is reviewed and updated periodically according to changes in the Company’s business environment.

2. Definitions

This section defines the key terms used in the policy. These definitions are necessary to help clearly understand and apply the policy.

2.1 Key Terms

1. Open Source Software:
   • Software that satisfies the Open Source Definition defined by the Open Source Initiative or the Free Software Definition defined by the Free Software Foundation. This is software with a license that allows users to freely use, modify, and distribute the software.
2. SBOM (Software Bill of Materials):
   • A list of all components, libraries, and dependencies that make up a piece of software. This is like a software “bill of materials,” and is used to ensure transparency in the software supply chain and to identify potential security vulnerabilities and license-related issues.
3. Known Vulnerability:
   • A previously discovered, publicly available security vulnerability. This can be found in databases such as NVD and CVE.
4. Newly Discovered Vulnerability:
   • A new security vulnerability that had not previously been discovered. This may be discovered while software is in use, or reported by external researchers.
5. Security Assurance:
   • Confidence that a system satisfies the requirements for security best practices and is resilient against known vulnerabilities.
6. Verification Material:
   • Material demonstrating that a given requirement of a specification has been satisfied. This may be provided in various forms such as documents, records, and test results.
7. Supplied Software:
   • All software that an organization provides or distributes to a third party.
8. Program:
   • The set of policies, processes, and personnel that make up an organization’s open source license compliance and security assurance activities.
9. Program Participant:
   • Any member of the organization or contractor responsible for defining, contributing to, or preparing supplied software. This includes software developers, release engineers, quality engineers, product marketing, and product managers.
10. Compliance Artifact:
    • Represents the output of an open source license compliance program, and is the collection of deliverables that must be provided along with supplied software. This includes attribution notices, source code, copies of licenses, copyright notices, notices of modification, and Written Offers.
11. Identified License:
    • The set of open source licenses identified by an appropriate method for identifying the open source components included in supplied software.

3. Roles and Responsibilities

This section defines the key roles and responsibilities related to open source software management. Each role is essential to ensuring the organization’s open source license compliance and security assurance.

3.1 Role Descriptions

1. Open Source Program Manager (OSPM)
   • Responsibility: Overall responsibility for the Company’s open source program.
   • Key Duties:
     • Manage open source license compliance and security assurance activities.
     • Create and maintain the SBOM.
     • Respond to external inquiries related to open source.
     • Manage internal best practices.
   • Required Competencies: Understanding of software development processes, expertise in open source licenses, communication skills.
2. Legal
   • Responsibility: Assess legal risk related to open source licenses and provide advice.
   • Key Duties:
     • Interpret and review open source license obligations.
     • Review license compatibility and provide advice on intellectual property protection.
   • Required Competencies: Expertise in software copyright, expertise in open source licenses, ability to assess legal risk.
3. IT
   • Responsibility: Operate and automate open source analysis tools.
   • Key Duties:
     • Operate open source analysis tools and integrate them into the DevOps environment.
     • Create and maintain the SBOM.
   • Required Competencies: Expertise in IT infrastructure, understanding of open source analysis tools, understanding of CI/CD pipelines.
4. Security
   • Responsibility: Operate open source security vulnerability analysis tools.
   • Key Duties:
     • Respond to known vulnerabilities and newly discovered vulnerabilities.
     • Integrate into the DevSecOps environment and perform security measures.
   • Required Competencies: Understanding of DevSecOps, understanding of security vulnerability analysis tools, ability to assess and manage risk.
5. Developer Culture
   • Responsibility: Support in-house developers in actively utilizing open source.
   • Key Duties:
     • Encourage participation in the open source community and improve developer culture.
     • Support external contribution activities.
   • Required Competencies: Understanding of software development processes, ability to design education, experience with community engagement.
6. Quality
   • Responsibility: Verify open source license obligations when distributing supplied software.
   • Key Duties:
     • Verify the creation of compliance artifacts.
     • Review compliance with license obligations before distribution.
   • Required Competencies: Understanding of software development processes, basic knowledge of compliance.
7. OSRB (Open Source Review Board)
   • Responsibility: Establish and improve policies and processes for open source management.
   • Key Duties:
     • Periodically review and improve the policy.
     • Discuss key issues and develop resolutions.
   • Required Competencies: Expertise in policy development, experience operating a governance body.
8. OSPO (Open Source Program Office)
   • Responsibility: Support contributions to external open source projects and the release of internal projects.
   • Key Duties:
     • Provide guidance for external contributions.
     • Manage the release procedure for internal projects.
   • Required Competencies: Experience with community engagement, project management skills.

3.2 Staffing and Funding

1. Appropriate staffing:
   • Assign appropriate personnel with the necessary competencies and expertise for each role.
   • The head of each department must designate a suitable person to perform the role.
2. Sufficient funding:
   • The Company provides sufficient budget and resources necessary to perform each role.
   • Budget items include education, tool licensing fees, and external consulting costs.
3. Periodic review:
   • The OSRB reviews the staffing and funding status of each role at least once a year, and recommends adjustments as needed.
   • The review results are documented and reported to the OSPO (Open Source Program Office).
4. Issue resolution procedure:
   • If a department’s person in charge lacks the necessary support (personnel or funding), they must immediately report this to the OSPM.
   • The OSPM works with the relevant departments to resolve the issue, and requests the OSRB to resolve the issue if necessary.

3.3 Internal Responsibility Assignment Procedure

1. Responsibility assignment procedure:

   a. The OSPM convenes an annual responsibility assignment meeting.

   b. Consults with each department head (Legal, IT, Security, Development, Quality, etc.) to select a person responsible for each activity.

   c. Submits the list of selected persons responsible to the OSRB (Open Source Review Board) for final approval.

2. Balance of responsibility and authority:

   • Each person responsible is granted appropriate authority necessary to perform the relevant duties.
   • They have the authority to request the resources (e.g., budget, personnel) necessary to fulfill their responsibilities.

3. Periodic review and updates:

   • The OSRB reviews the status of responsibility assignments at least once a year and makes adjustments as needed.
   • Responsibility assignments are updated immediately whenever there is a major change, such as an organizational restructuring or personnel change.

4. Documentation:

   • The results of responsibility assignment are recorded as an official document and registered in the Company’s document management system.
   • The document specifies each activity, the person responsible, their role, and the required competencies.

5. Education and awareness:

   • Provide necessary education to newly assigned persons responsible.
   • Share the results of responsibility assignment with the entire organization to raise awareness.

3.4 Current Assignees

The organization and person responsible for each role can be found in [Appendix A: Current Assignees]. The list is updated as needed.

4. Open Source License Compliance

This section describes the procedures for complying with the license obligations of open source components included in supplied software. Through this, the Company can ensure open source license compliance and minimize legal risk.

4.1 Open Source Identification and License Obligation Review

1. Open Source Identification:
   • Identify all open source components used when developing supplied software.
   • Use SCA (Software Composition Analysis) tools to automatically detect and record open source components.
2. License Obligation Review:
   • Review the licenses of identified open source components and confirm the obligations required by each license.
   • Refer to the Company’s [Open Source License Guide] to understand licenses, and work with the Legal team to resolve compatibility issues.

4.2 Design Considering Open Source Licenses

1. Software Architecture Design:
   • Design the software architecture to minimize the impact of open source licenses.
   • Identify the coupling relationship between open source components and the Company’s own code to comply with license obligations.
2. License Compatibility Review:
   • Review whether the licenses of multiple open source components are compatible with each other.
   • If incompatible licenses are used, propose alternative components or take appropriate action.

4.3 Creating and Managing Compliance Artifacts

1. Creating Open Source Notices:
   • Prepare a notice containing the copyright information and licenses of the open source components included in supplied software.
   • The notice is prepared according to the conditions required by each license, and is included in the distribution package.
2. Creating Source Code Packages for Disclosure:
   • Create the source code packages necessary to comply with licenses that require source code disclosure, such as GPL and LGPL.
   • Source code packages are securely stored in a separate repository and provided upon external request.
3. Distribution and Storage of Compliance Artifacts:
   • All compliance artifacts are distributed together with supplied software and systematically managed in an internal repository.
   • Operate a system that can provide artifacts upon external request.

4.4 Creating and Managing the SBOM

1. Creating the SBOM:
   • Create the SBOM (Software Bill of Materials) for all open source components that make up supplied software.
   • The SBOM includes the name, version, license information, and download location of each component.
2. Maintaining and Updating the SBOM:
   • The SBOM is updated with each software release and kept up to date.
   • The SBOM is securely managed in an internal repository and prepared to be provided upon external request.
3. Managing Open Source Component Records:

   • Maintain detailed records for each open source component. These records include the following information:

     a. Component identification information (name, version, source)

     b. License information and obligations

     c. Purpose and manner of use

     d. Whether modified and details of modifications

     e. Vulnerability analysis results and response measures

   • These records are periodically reviewed and updated, and managed according to documented procedures.

4. Record Verification Procedure:
   • Verify the accuracy and completeness of open source component records quarterly.
   • Verification results are documented and stored, and improvement measures are taken as needed.

4.5 Compliance Issue Response Procedure

1. Issue Identification and Response:
   • When a compliance issue occurs, the OSPM immediately identifies the issue and develops a response plan.
   • Works with the Legal team to assess the severity of the issue and determine the necessary action.
2. Maintaining Response Records:
   • All response processes are recorded and preserved through Jira or another issue tracking system.
   • Response records are periodically reviewed and used as reference material in the event of a similar problem in the future.

5. Open Source Security Assurance

This section describes the procedures for ensuring the security of open source components included in supplied software. Through this, the Company can effectively manage known vulnerabilities and newly discovered vulnerabilities, and raise the security level of its software.

5.1 Known Vulnerability Detection and Response Procedure

1. Vulnerability Detection:
   • Use SCA (Software Composition Analysis) tools to detect known vulnerabilities in each open source component included in the SBOM.
   • Regularly update vulnerability databases such as the NVD (National Vulnerability Database) and CVE (Common Vulnerabilities and Exposures) to check the latest information.
2. Vulnerability Severity Assessment:
   • Assess the severity of a vulnerability using its CVSS (Common Vulnerability Scoring System) score.
   • Determine response priority considering the exploitability of the vulnerability, its scope of impact, and its potential impact on the system.
3. Response Measures:
   • Immediately apply a patch or take mitigation measures for high-risk vulnerabilities.
   • If customers may be affected, notify customers and present a resolution plan.
4. Maintaining Response Records:
   • All vulnerabilities and response measures are recorded in a database, and reports are generated periodically.
   • Response records are used as reference material in the event of a similar problem in the future.

5.2 Newly Discovered Vulnerability Response Procedure

1. Detecting Newly Discovered Vulnerabilities:
   • Identify and assess new security vulnerabilities that had not previously been discovered.
   • Newly discovered vulnerabilities may be reported by external researchers or through internal testing.
2. Severity Assessment and Response:
   • Assess the severity of a newly discovered vulnerability using its CVSS score.
   • Determine response priority based on the assessment results and take necessary action.
   • If customers may be affected, notify customers and present a resolution plan.
3. Maintaining Response Records:
   • Newly discovered vulnerabilities and response measures are recorded in a database, and reports are generated periodically.

5.3 Continuous Monitoring and Response

1. Vulnerability Monitoring:
   • Continuously monitor software even after release to identify known vulnerabilities or newly discovered vulnerabilities.
   • Use automated tools to detect anomalies based on the latest data.
2. Response Preparation:
   • Security experts prepare the response, and receive assistance from external experts as needed.
   • The response plan is periodically reviewed and updated.
3. Reporting and Improvement:
   • All monitoring and response activities are reported periodically and shared with program participants.
   • Improve processes based on monitoring results to continuously enhance the security level.

5.4 Alignment with Internal Best Practices

1. Investigating Internal Best Practices:
   • Investigate security-related activities and processes that are successfully operated by other teams or departments within the Company.
   • Example: the information security team’s vulnerability management process, the development team’s secure coding guidelines, etc.
2. Comparing and Analyzing Processes:
   • Compare and analyze how the investigated best practices operate relative to the open source security assurance program.
   • Identify differences, weaknesses, and opportunities for improvement.
3. Integrating and Improving Processes:
   • Adjust or integrate the open source security assurance program to align with the Company’s internal best practices.
   • Example: applying the company-wide vulnerability management system to open source vulnerability management as well.
4. Assigning and Managing Responsibility:
   • The OSPM is responsible for compliance with internal best practices, and periodically reviews the operating approach and proposes improvements.

6. Education and Awareness

This section describes the education and awareness activities necessary to ensure the competency and awareness of program participants. Through this, participants can fully understand the open source policy, the goals of the related program, and their own roles and responsibilities, and raise their awareness of open source license compliance and security assurance.

6.1 Open Source Education

1. Education Objectives:
   • Help program participants use open source correctly, and understand and apply license compliance and security assurance procedures in practice.
   • Key education content:
     • The purpose and principles of the open source policy.
     • License obligations and compliance procedures.
     • How to create and use the SBOM.
     • Procedures for managing known vulnerabilities and newly discovered vulnerabilities.
2. Education Methods:
   • Completed through online courses provided on the [Learning Portal].
   • Additional education is provided in workshop or seminar format as needed.
   • Case-based learning is used to strengthen the ability to solve real-world problems.

6.2 Competency Assessment

1. Assessment Criteria:
   • Assess the competencies required for each role.
   • Assessment items:
     • Understanding of the open source policy.
     • Ability to perform compliance procedures.
     • Ability to manage security vulnerabilities.
2. Assessment Methods:
   • Measure participants’ competency through periodic tests and practical evaluations.
   • Assessment results are reflected in individual performance records, and additional education is provided as needed.

6.3 Awareness-Raising Activities

1. Periodic Newsletters and Workshops:
   • Share the latest open source trends and policy changes through a periodic newsletter.
   • Raise program participants’ understanding and promote collaboration through workshops and seminars.
2. Use of Communication Channels:
   • Share open source-related information through internal communication channels (e.g., email, internal portal).
   • Encourage collaboration and information exchange among program participants.

6.4 Record Retention

1. Education and Assessment Records:
   • All education completion records and assessment results are retained for at least 3 years.
   • This allows the Company to demonstrate that program participants have a sufficient understanding of the policy and processes.
2. Periodic Review and Updates:
   • The OSPM reviews the education content and assessment methods at least once a year and updates them as needed to reflect the latest open source trends and the organization’s requirements.

6.5 Identifying and Utilizing Expertise

1. Identifying Required Areas of Expertise:
   • Periodically identify the technical and legal areas of expertise necessary to operate the program.
   • Example: web security, cryptography, network security, systems administration, open source license interpretation, etc.
2. Preparing and Updating a List of Internal Experts:
   • Prepare a list of personnel with expertise in the relevant field within the Company, and update it periodically.
   • Record each expert’s career history, certifications, and contact information.
3. Establishing a Plan to Secure External Resources:
   • Establish a plan to utilize external experts or consulting firms for problems that are difficult to resolve internally.
   • Secure reliable external resources and clearly define contract terms.
4. Establishing a Procedure for Accessing Expertise:
   • Establish a procedure so that program participants can easily access the expertise they need.
   • Example: how to consult an internal expert, how to utilize an external consulting firm, etc.

7. Contribution to External Open Source Projects

This section describes the procedures and principles that the Company’s program participants must follow when contributing to external open source projects. Through this, the Company can actively participate in external open source projects while preventing intellectual property and copyright issues.

7.1 Contribution Procedure

1. Review Request and Approval:
   • To contribute to an external open source project, a program participant must obtain review and approval from the OSPO (Open Source Program Office).
   • The OSPO confirms that the code to be contributed does not infringe on the Company’s intellectual property, and requests review by the Legal team as needed.
2. Contribute Only Code You Have the Right to Contribute:
   • Program participants may only contribute code they have written themselves or code owned by the Company.
   • Third-party code must not be contributed without authorization.
3. Caution Regarding Exposure of Intellectual Property:
   • Take care not to include sensitive information, patents, or other Company intellectual property.
   • If the code to be contributed includes a Company patent, it must be reviewed by the OSPO and the Legal team.

7.2 Caution Regarding CLA Signing

1. CLA Review:
   • Some open source projects require contributors to sign a CLA (Contributor License Agreement).
   • Before signing a CLA, request a review from the OSPO to ensure protection of the Company’s intellectual property.
2. Prohibition on Copyright Assignment:
   • To protect its own intellectual property, the Company does not permit contributions to open source projects whose CLA terms require copyright assignment.

7.3 Copyright Notice

1. Copyright Notation:

   • When a program participant contributes code to an external open source project, the Company’s copyright must be clearly stated.

   • State the copyright and license at the top of the file as follows:

     textCopyright (c) [Year] [Company Name] SPDX-License-Identifier: [SPDX_license_name]

2. Use of Company Email:

   • When contributing to an open source project, use the Company email rather than a personal email.
   • This instills a sense of responsibility for communicating with the community on behalf of the Company.

7.4 Maintaining Contribution Records

1. Managing Contribution History:
   • Manage the entire history of contributions to external open source projects, and report it to the OSPO.
   • Contribution history is retained in an internal system (e.g., the Learning Portal) for at least 3 years.
2. Assessing Contribution Activities:
   • Contribution activities to external open source projects are reflected in program participants’ performance evaluations.
   • The OSPO periodically assesses the effectiveness of contribution activities and proposes improvement measures as needed.

8. Releasing Internal Projects as Open Source

This section describes the procedures and principles for releasing internal projects as open source. Through this, the Company can promote collaboration with the open source community, protect its intellectual property, and minimize legal risk.

8.1 Approval Procedure

1. Review and Approval:
   • To release an internal project as open source, review and approval must be obtained from the OSPO (Open Source Program Office).
   • The OSPO confirms that the code to be released does not infringe on the Company’s intellectual property, and requests review by the Legal team as needed.
2. Intellectual Property Protection:
   • Take care not to include sensitive information, patents, or other Company intellectual property.
   • For code that includes a patent, work with the Legal team to confirm whether it can be released.
3. Copyright Notice:
   • State the Company’s copyright in the code being released.
   • Example: “Copyright (c) [Year] [Company Name]”

8.2 Release Preparation

1. Code Preparation:
   • Organize and document the code to be released so it can be used externally.
   • Verify the origin of the code, and delete or modify any code that poses a potential problem.
2. Choosing an Open Source License:
   • Select an appropriate open source license under which to release the code.
   • When choosing a license, consider protection of the Company’s intellectual property and the needs of the community.
3. Securing Resources:
   • Secure the infrastructure and budget necessary to maintain and manage the project.
   • Use a project hosting platform such as GitHub to maintain transparency.

8.3 Post-Release Management

1. Community Management:
   • Collect community feedback on the released project and respond appropriately.
   • The OSPO manages the relationship with the community and actively accepts external contributions.
2. Ongoing Maintenance:
   • The released project is continuously maintained, with bug fixes and feature improvements.
   • Quality is ensured through code review, and the project collaborates with external contributors.
3. Use of Company Email:
   • Use the Company email rather than a personal email during open source activities, to maintain the Company’s representation.

8.4 Record Retention

1. Retaining Release Records:
   • All records related to a released project are retained for at least 3 years.
   • Records include the approval procedure, code versions, and community feedback.
2. Periodic Review and Updates:
   • Released projects are periodically reviewed and updated as needed.
   • Continuously improved to reflect the latest open source trends and organizational requirements.

9. Responding to External Inquiries

This section describes the procedure by which the Company responds quickly and effectively when there is an external open source-related inquiry or request, particularly one related to open source license compliance and open source security vulnerabilities. Through this, the Company can appropriately respond to external demands, minimize legal risk, and promote collaboration with the open source community.

9.1 Responsibility for Responding to External Inquiries

1. Designating the Person Responsible:
   • Responding to external open source-related inquiries and requests is handled by theOSPM.
   • As needed, works with the Legal team (for license compliance matters) or the Security team (for security vulnerability matters) to resolve the issue.
2. Inquiry Escalation Procedure:
   • Any program participant who receives an external open source-related inquiry must immediately forward it to theOSPM.
   • Depending on the nature of the inquiry, it is promptly assigned to the department responsible for license compliance or security vulnerabilities.

9.2 Publishing Contact Information

1. Public Contact Information:
   • The official contact information for theOSPM is made publicly available.
   • The contact information is registered on the following channels:
     • The open source notice
     • The Company website
     • The Linux Foundation’s Open Compliance Directory
2. Guidance on How to Make Inquiries:
   • Clearly explain how external parties can make open source-related inquiries.
   • Operate a system that can accept inquiries by email address, website inquiry form, and other means.

9.3 External Inquiry Response Procedure

1. Receiving and Confirming the Inquiry:
   • When an external inquiry is received, theOSPM immediately confirms it and specifies an appropriate resolution time.
   • Reviews the nature of the inquiry and classifies it as a license compliance or security vulnerability matter.
     • License compliance: reviewed and addressed in cooperation with the Legal team.
     • Security vulnerability: assessed for severity and addressed in cooperation with the Security team.
2. Carrying Out the Response:
   • Take appropriate response measures according to the content of the inquiry, and receive assistance from external experts as needed.
   • All response processes are recorded through an internal system (e.g., Jira Tracker).
3. Providing Feedback and Improving:
   • After responding, provide feedback to the external inquirer, and propose improvement measures as needed.
   • Analyze response records and improve processes to prevent recurring problems.

10. Measuring and Improving Program Effectiveness

This section describes the procedure for measuring and continuously improving the effectiveness of the open source program. Through this, the Company can evaluate and improve the performance of its open source license compliance and security assurance program.

10.1 Defining Performance Indicators

1. List of Performance Indicators:
   • Number of supplied software analyzed.
   • Number of known vulnerabilities and newly discovered vulnerabilities resolved.
   • Number of compliance artifacts created and distributed.
   • Response time for external inquiries.
   • Education completion rate of program participants.
   • Number of external open source contributions and released projects.
2. Setting Indicator Targets:
   • Set target values for each indicator so that the program’s performance can be evaluated.
   • Target values are set in line with the organization’s business goals and the program’s objectives.

10.2 Periodic Program Assessment

1. Assessment Cycle:
   • Conduct a program assessment at least once a year.
   • Conduct additional assessments as needed when there is a change in the business environment or a major issue occurs.
2. Assessment Procedure:
   • Document the assessment results and report them to the OSRB (Open Source Review Board).
   • Collect and reflect feedback from program participants during the assessment process.
   • Assessment results are recorded and preserved through an internal system (e.g., Jira Issue Tracker).
3. Periodic Policy Review and Renewal:
   • The policy is periodically reviewed and, if necessary, renewed to reflect the latest open source trends and the organization’s requirements.
   • This continuously improves the effectiveness of the program.

10.3 Continuous Improvement Plan

1. Identifying Areas for Improvement:
   • Identify areas that need improvement based on assessment results, and set priorities.
   • Areas needing improvement may include process efficiency, education content, response time, and more.
2. Setting Improvement Targets:
   • Set specific improvement targets and schedules.
   • The progress of improvement activities is monitored and documented.
3. Reflecting Improvement Results:
   • Reflect improvement results in the next assessment cycle to continuously enhance the program’s effectiveness.
   • Improvement results are shared with program participants to encourage continued commitment to improvement.

10.4 Integrating and Improving Internal Best Practices

1. Planning Integration Activities:
   • Identify the gaps between internal best practices and the open source security assurance program, and establish an integration plan based on this.
   • Example: integrating vulnerability management systems, standardizing code review procedures.
2. Periodic Review and Updates:
   • Review the alignment between internal best practices and the open source program at least once a year, and reflect improvements as needed.
   • The review results are reported to the OSRB (Open Source Review Board).

10.5 Assessing Personnel and Resources

1. Assessment cycle:
   • The Company assesses the staffing and funding status for each role at least once a year.
   • Assessment results are reported to the OSRB, and improvements are implemented as needed.
2. Assessment items:
   • Whether appropriate personnel have been assigned for each role.
   • Whether sufficient budget has been provided to perform each role.
   • Cases of problems caused by insufficient support, and their resolutions.
3. Establishing an improvement plan:
   • Establish a specific plan to supplement insufficient personnel or resources based on the assessment results.
   • The improvement plan is implemented upon approval by the OSRB.

11. ISO Standard Compliance Declaration and Maintenance

This section describes the procedure by which the Company complies with and maintains the requirements of ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance). Through this, the Company can ensure the continuous improvement of its open source program and compliance with the standards.

11.1 ISO Standard Compliance Declaration

1. Compliance Declaration:
   • Through this policy, the Company declares that it satisfies all the requirements of ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance).
   • The date of declaration and validity period (18 months) are clearly stated.
   • The compliance declaration may be made through Self Certification under the Linux Foundation’s OpenChain project.
2. Documenting Evidence:
   • The OSPM documents and maintains evidence of satisfaction for each requirement.
   • Evidence documents include policy documents, process descriptions, education records, compliance artifacts, and security vulnerability management records.
   • All evidence documents are stored in a central repository and retained for at least 3 years.
   • This document must be prepared within 18 months after undergoing conformance verification, and is renewed at least once a year.
3. Periodic Review and Renewal:
   • The OSRB reviews whether the requirements are satisfied at least once a year, and improves the policy and processes as needed.
   • The review results and improvements are documented and stored.
4. Preparing for External Verification:
   • Prepare to provide evidence documents to external auditors or certification bodies upon request.

11.2 Maintaining Compliance Status

1. Periodic Review:
   • The OSRB conducts an internal review of all the requirements of ISO/IEC 5230 and ISO/IEC 18974 at least once a year.
   • The review results are documented and stored, and an improvement plan is established for any items not satisfied.
2. Periodic Internal Audit:
   • Internal audits assess whether program participants are performing their roles, whether compliance artifacts are adequate, and the effectiveness of security assurance activities.
   • Based on the audit results, areas for improvement are identified and necessary action is taken.
3. Providing Education and Training:
   • Provide periodic education and training to continuously improve the competency and awareness of program participants.
   • Education content reflects the latest open source trends and the organization’s requirements, and emphasizes compliance with ISO standards.
4. Preparing to Respond to External Inquiries:
   • Maintain a system that can respond quickly and effectively to external inquiries related to ISO standard compliance.
   • Inquiry response is handled by the OSPM, who works with the Legal team as needed.
5. Periodic Policy Renewal:
   • The policy is reviewed at least once a year, and renewed to reflect the latest open source trends and the organization’s requirements.
   • The renewed policy is shared with all program participants.

Once a format is chosen, the next question is what that format must contain. The documents that define this floor are the US Minimum Elements series. Though they are recommendations, they function as the de facto standard for federal procurement, and SBOM requirements in the EU and other jurisdictions largely reference this same framework.

Lineage: From NTIA 2021 to CISA 2025

The National Telecommunications and Information Administration (NTIA) publishedThe Minimum Elements For a Software Bill of Materials (SBOM) in July 2021, under the delegation of Executive Order 14028. The document organized the minimum elements into three categories: the data fields to track per component, automation support requiring a machine-readable format, and practices and processes covering generation frequency, depth, and the like.

Stewardship of the community’s work then moved to the Cybersecurity and Infrastructure Security Agency (CISA), and two lines of revision followed. One was the third edition (September 2024) ofFraming Software Component Transparency, a reference document that defines attributes, which added License and Copyright Notice to the baseline attributes. The other was a revision of the minimum elements document itself: CISA released2025 Minimum Elements for a Software Bill of Materials as a public comment draft in August 2025, with the comment period closing on October 3, 2025. As of June 2026, this revision remains in draft status, and the date of a final version has not been confirmed.

The Data Fields and Three Categories of NTIA 2021

The NTIA 2021 minimum elements set seven per-component data fields.

The three categories are as follows.

• Data fields: The seven items above — the basic information for tracking and identifying components.
• Automation support: Specified SPDX, CycloneDX, and SWID as standard formats for automated generation and machine readability.
• Practices and processes: Covers generation frequency, depth, handling of known unknowns, distribution and delivery, access control, and how errors are accommodated.

What the CISA 2025 Draft Adds

The CISA 2025 minimum elements draft expanded the data fields to reflect the maturing state of tooling. Four core elements were newly added.

Existing items were also revised. The roles of SBOM Author and Software Producer were distinguished, “Other Unique Identifiers” was updated to “Software Identifiers,” and the access control element, previously separate, was folded into the distribution and delivery item. The trajectory of License — entering as a baseline attribute in Framing 3rd edition and hardening into a data field in the 2025 draft — shows that the SBOM is establishing itself as primary data for open source license compliance, beyond a security inventory. Behind adding Tool Name, Generation Context, and Hash together lies the concern that an SBOM produced by an untrustworthy tool cannot itself be trusted. Tool integrity is covered in5. Tools and Automation.

Practical Recommendations

The minimum elements are, as the name says, a floor. Organizations can, and should, add fields suited to their own purposes. Carrying CVE references and patch status for vulnerability identification, SPDX license identifiers and copyright notices for license management, and release and End-of-Life dates for lifecycle management, together in one SBOM, lets a single SBOM answer multiple operational questions. If you are introducing an SBOM for the first time, starting with the NTIA seven fields as a base but including the four new fields from the CISA 2025 draft — especially hash and license — from the outset saves the effort of rebuilding it later.

Sources

NTIA (2021).The Minimum Elements For a Software Bill of Materials (SBOM).https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf. CISA (2024).Framing Software Component Transparency, Third Edition.https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024. CISA (2025).2025 Minimum Elements for a Software Bill of Materials (SBOM) (public comment draft).https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom. (All retrieved: 2026-06-14)

Not all SBOMs are the same. They are divided into levels based on how deep a dependency chain they cover, and classified based on the point in the software lifecycle at which they were created. Distinguishing these two axes makes it possible to clearly decide “which SBOM to require and which SBOM to produce.”

Levels by Depth of Information

An organization does not need to commit to a single level. A common approach is to tailor the SBOM delivered to consumers to a level that omits sensitive information while still meeting security requirements, while internally maintaining a complete-level SBOM to track vulnerability updates. This reduces the risk of exposing trade secrets and intellectual property while securing both supply chain transparency and internal resilience.

The regulatory floor for obligations is also expressed in the language of levels. The EU Cyber Resilience Act requires an SBOM that “cover[s] at the very least the top-level dependencies of the product.” There is no obligation to expand the entire dependency tree, but that is clearly the direction of recommended practice.

Classification by Point of Generation

The US CISA documentTypes of Software Bill of Materials (SBOM) divides SBOM into six types aligned with the stages of the Software Development Life Cycle (SDLC). For the same product, the information captured and its accuracy differ depending on when the SBOM was generated.

Figure 1. SBOM classification by SDLC stage(source: CISA, Types of Software Bill of Materials (SBOM), 2023)

• Design SBOM: Records the components planned at the design stage, before the components actually exist.
• Source SBOM: Reflects the development environment and contains source files and dependencies.
• Build SBOM: Generated during the build process and includes information on source, dependencies, and pre-built components.
• Analyzed SBOM: Generated by inspecting the final artifact after the build.
• Deployed SBOM: A list of software installed and configured on a specific system, taking the deployment environment into account as well.
• Runtime SBOM: Monitors components while running, capturing dynamically loaded dependencies and external interactions as well.

The Build SBOM, generated at build time, is the most widely recommended in terms of accuracy and automation, because it records exactly what the build tool actually assembled. Generation timing and automation are covered in detail in5. Tools and Automation.

Sources

CISA (2023).Types of Software Bill of Materials (SBOM).https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom (accessed: June 14, 2026). This is the primary basis for the classification of the six SBOM types (Design, Source, Build, Analyzed, Deployed, Runtime). For attributes and maturity stages, see CISA (2024).Framing Software Component Transparency, Third Edition.https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024. The EU Cyber Resilience Act’s top-level dependency requirement is based on Regulation (EU) 2024/2847, Annex I Part II(1).

The first major piece of legislation to establish SBOM as an explicit legal obligation is the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847). Whereas the United States effectively mandates SBOM through the market of federal procurement, the CRA is a directly effective law that applies horizontally across products with digital elements.

Legal Basis of the SBOM Obligation

In the CRA, the SBOM obligation appears in Annex I, Part II (vulnerability handling requirements), point (1). Manufacturers must identify and document the vulnerabilities and components contained in a product, and as a means of doing so, the CRA specifies that they must “draw up a software bill of materials, in a commonly used and machine-readable format, covering at the very least the top-level dependencies of the product.”

Two points that matter in practice differ from the US pathway.

• The scope of the obligation is top-level dependencies: There is no obligation to expand the entire dependency tree; covering at least the top-level dependencies is sufficient. That said, going deeper than this is clearly the recommended direction.
• It is an obligation to retain and submit, not to disclose: There is no obligation to disclose the SBOM to the general public. It is sufficient to retain it so that it can be submitted when a market surveillance authority makes a reasoned request.

The core of the CRA is that producing an SBOM is not a recommendation but a legal obligation backed by a system of fines.

Implementation Timeline

Figure 1. Phased implementation timeline of the EU CRA(source: Regulation (EU) 2024/2847; collected June 14, 2026)

The CRA was published in the Official Journal on November 20, 2024, and entered into force on December 10, 2024. Its application is staged: the Article 14 obligation to report exploited vulnerabilities and severe incidents applies from September 11, 2026, and full application of the essential cybersecurity requirements, including SBOM, begins on December 11, 2027.

Absence of Format Implementing Rules and a Practical Reference Point

As of June 2026, no official CRA-level implementing rule for SBOM format has been published. This means there is not yet a document that establishes, as an EU-wide binding norm, which schema and fields must be used to conform to the CRA.

The current practical reference point is Technical Guideline TR-03183-2 v2.1.0, published in August 2025 by Germany’s Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI). This document provides specific field mappings for CRA-conformant SBOM for both CycloneDX and SPDX. Note, however, that this is a German guideline, not an EU-wide binding norm.

Considerations for Open Source

The CRA uses commercial activity as its applicability criterion, and in principle excludes non-commercial open source that is distributed free of charge without commercial activity. This is a mechanism to avoid imposing manufacturer-level obligations directly on open source maintainers. However, the obligations still apply in full to manufacturers who integrate open source into a product and supply it commercially, so obtaining and managing SBOMs for open source components remains the manufacturer’s responsibility.

Sources

European Parliament and Council (2024).Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024.https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng. European Commission, DG CNECT.Cyber Resilience Act.https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. BSI.Technical Guideline TR-03183-2. (all accessed: June 14, 2026)

Appendix 1. Personnel Assignments

1. Clause Overview

Organizations that exchange AI systems in the supply chain need to verify each other’s compliance. That requires a publicly available channel for external inquiries, and readiness on the organization’s side to respond to them. Access secures both directions.

3.7 requires two things: publicly identifying a means by which a third party can make an AI SBOM compliance inquiry, and maintaining an internal procedure to respond effectively to that inquiry. In AI, AI-specific information — model and dataset licenses, training data provenance, model cards — is added to the subject matter of such inquiries.

2. Required Activities

• Publicly identify a means (e.g., a public email address) by which a third party can make an AI SBOM compliance inquiry.
• Post the public means somewhere externally discoverable, such as a product notice or website.
• Document the internal procedure for receiving, classifying, and responding to external inquiries.
• Define the responsible party and the response deadline.
• Record the history of inquiries and responses.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.7.1 Publicly identified means of external inquiry

Compliance Method

Identify a public contact means that anyone can find. A role-based email address (a job function address, not an individual) is stable. Post it in locations such as the product notice, the open source/AI policy page on the company website, or the contact field of the model card. Stating a response deadline alongside it builds trust.

Sample

AI Compliance Inquiries: ai-compliance@company.com
We accept inquiries regarding the components of the AI systems we provide, model and
dataset licenses, and AI SBOMs. We send an initial reply within 14 business days of
receipt.
(Posted at: product notice, company website AI policy page, model card contact field)

3.7.2 Internal inquiry response procedure

Compliance Method

Document the internal procedure from receiving an external inquiry to answering it. Define the stages of intake, classification, assignment, review, reply, and recording, with a deadline for each stage. Because AI SBOM inquiries need to reference model cards or license review records, the AI SBOM verification lead and the license review lead respond together.

The figure below shows the external inquiry response flow.

Figure 1. External AI SBOM compliance inquiry response flow

Considerations

• Set deadlines: Define both an initial reply deadline (e.g., 14 days) and a final answer deadline (e.g., 60 days).
• Protect AI-specific information: Set a standard for how far to disclose sensitive information such as model weights or training data when answering inquiries. Define the boundary between trade secrets and transparency obligations (3.6).([Recommendation of this guide])
• Retain history: Record the inquiry content, the reply, and the processing time as verification material.

Sample (Response Procedure Outline)

## AI SBOM Compliance Inquiry Response Procedure
1. Intake: Register inquiries received at ai-compliance@.
2. Classification: Classify as AI SBOM request / license inquiry / transparency
obligation inquiry.
3. Assignment: Assign to the AI SBOM verification lead or the license review lead based
on classification.
4. Review and Reply: Reply after checking the relevant AI SBOM and model card. Follow the
disclosure standard for sensitive information. Involve legal review if needed.
5. Record: Retain the inquiry, reply, and processing time.
Deadlines: 14 days for the initial reply, 60 days for the final answer.

5. See Also

• Role and resources of the response lead:3.8 Effective Resource Allocation
• AI SBOM used in replies:3.9 AI SBOM
• Disclosure scope and transparency obligations:3.6 Transparency Obligations
• ISO/IEC 5230 external inquiry example:ISO/IEC 5230 Compliance Guide — 3.2.1 Responding to External Inquiries

1. Clause Overview

License obligations are where the AI SBOM Guide expands most on ISO/IEC 5230. Where traditional open source compliance reviewed the licenses of code, AI expands the review to four fronts: an AI system’s code, model weights, datasets (including training, testing, and validation datasets), and the license of the AI system itself. It is common for a model to be derived from several other models, so each parent model sitting in the Model Tree can carry its own distinct license.

3.5 requires a procedure for reviewing these licenses to determine, in light of the AI system’s intended use, the obligations, restrictions, and rights each license grants. The review covers both obligations inherited from upstream and obligations passed downstream.

2. Activities to Perform

• Establish a procedure for identifying the licenses of code, weights, datasets, and the AI system itself.
• Track the license of each parent model in the model tree, and document the obligations, restrictions, and rights of each license.
• Perform an initial identification pass on source code and dependencies with automated scanning tools.([Guide Recommendation])
• Route model weights, datasets, and non-standard licenses to legal or governance review.([Guide Recommendation])
• Set up an intake procedure that requires license metadata to accompany any model or dataset brought in from outside.([Guide Recommendation])
• Record the review results (obligations, restrictions, rights) in the AI SBOM for tracking.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.5.1 License Obligation Review and Documentation Procedure

How to Comply

Design the review procedure around the premise that the level of automation differs by material type. Source code and dependency licenses can be identified to a large degree with automated scanning tools such as FOSSology, ScanCode, and the OSS Review Toolkit. But the licensing of model weights and datasets, and the derivation relationships in the model tree, fall outside the reach of these tools or are identified with low accuracy. The usage-purpose restrictions of non-standard licenses require human interpretation. A realistic division of labor is therefore to do an initial identification pass with automated scanning, and route models, datasets, and non-standard licenses to legal or governance review.

The figure below shows the decision flow for determining license obligations as materials come in.

Figure 1. Decision flow for license obligation review

Considerations

• Enforce metadata at the intake gate: The largest cause of missed license obligations is license drift — the loss of provenance and license information as a model propagates downstream. One study reports that a substantial share of restriction clauses disappear in the transition from model to application (arXiv:2509.09873). Rather than trying to reconstruct this downstream, it is more effective to block the intake of materials lacking license metadata at the internal model/dataset registry.([Guide Recommendation])
• Decide non-standard licenses through policy in advance: The behavioral use restrictions of the Llama Community License or the OpenRAIL family are hard to track automatically for compliance after the fact. Decide them at intake time using the allowed/prohibited lists in3.1 Policy.([Guide Recommendation])
• Trace the model tree: Check the model card to see which parent model an incoming model was derived from, and review whether the parent model’s license obligations propagate downstream.
• Check dataset usage restrictions: Check whether a non-commercial-licensed dataset such as CC-BY-NC was used to train a commercial product. Dataset license omissions and misstatements are common, so cross-check against the original text.
• Recognize the limits of automation: Do not treat automated scan results as the final judgment. Tools help with identification; people handle the interpretation of obligations and conflict determination.

Sample

Below is a sample of the core part of a license obligation review procedure document. This procedure document becomes verification material 3.5.1.

## AI License Obligation Review Procedure
### 1. Scope of Review
- AI system code and dependencies
- Model weights (imported models, fine-tuned models)
- Datasets (training, testing, validation)
- Licenses of parent models in the model tree
### 2. Review Steps
1) Automated identification: scan code and dependencies for licenses using an SCA tool.
2) Metadata collection: collect licenses for models and datasets from model cards and
datasheets. Hold intake if metadata is missing.
3) Classification: check identified licenses against the policy's allowed/conditional/
prohibited lists.
4) Legal review: route non-standard or unclear licenses to legal/governance review to
interpret the obligations.
5) Recording: record upstream and downstream obligations, restrictions, and rights in
the AI SBOM.
### 3. Responsibility and Frequency
- Initial identification: development staff
- Interpreting obligations: legal / AI governance lead
- Re-review: when a model or dataset is replaced, and at least once a quarter

5. References

• Policy for allowed/prohibited license lists:3.1 Policy
• AI SBOM for recording review results:3.9 AI SBOM
• Automated scanning tools:Tools — FOSSology,SCANOSS
• AI model/dataset licensing strategy:Enterprise Open Source Management Guide — AI Compliance

1. Clause Overview

Governance is the framework that ties all the preceding clauses together to ensure the AI system’s lifecycle is developed, deployed, and managed responsibly from end to end. Where policy (3.1) sets the principles and license obligations (3.5) and the AI SBOM (3.9) build individual processes, governance manages these so they keep operating consistently through regulatory change and model replacement.

3.10 requires an AI governance framework, policies, and practices. The specification emphasizes compliance with emerging AI laws such as the EU AI Act, the Hiroshima AI Process, and China’s Global AI Governance Initiative, and addresses ethical considerations, risk management, and transparency together. The core is to review a framework, once built, periodically so it reflects the latest regulation and model changes.

2. Activities to Perform

• Write a governance framework document that spans the full AI system lifecycle.
• Include emerging AI regulation tracking, risk management, transparency, and ethical considerations in the framework.
• Have a procedure for periodically reviewing and updating the framework.
• Monitor the risks that come with the ongoing use of AI systems and training data.
• Reflect events such as model tree changes, regulatory enforcement, and OSAID classification changes in governance.([Guide Recommendation])

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.10.1 AI Governance Framework and Periodic Review Procedure

How to Comply

The governance framework covers three things: tracking emerging regulation to derive obligations, monitoring the AI system lifecycle, and a procedure for periodically reviewing the framework itself. Because regulation changes quickly, the framework must be a living system built for updates, not a fixed document.

The three axes the specification names differ in character. The EU AI Act imposes concrete, article-level obligations; the Hiroshima AI Process runs voluntary transparency reporting; and China’s initiative is closer to a policy declaration. Governance distinguishes these differences and tracks each accordingly.

The table below lists the major regulations to track from an AI SBOM perspective. The full regulatory matrix and its ISO/IEC 42001 context are covered inISO/IEC 42001 Guide — Organizational Context and Leadership.

Table 1. Major AI regulations intersecting with AI SBOM (as of 2026-06)

Lifecycle monitoring means placing governance checkpoints along the flow from development to retirement. The figure below shows lifecycle governance built around the AI SBOM.

Figure 1. Lifecycle governance built around the AI SBOM

Considerations

• Assign regulatory-tracking responsibility: Specify in governance who tracks emerging regulation and derives obligations from it. The EU AI Act’s obligations expand in stages in August 2026 and 2027, so manage the timing.
• Manage model tree changes: When an imported model moves to a new version or a parent model is replaced, license obligations can change. Register the change as a governance review event.([Guide Recommendation])
• Update OSAID classification: The distinction between “open source AI” and “open weight” (OSAID 1.0) affects model licensing judgments. Include classification changes in the periodic review.
• State the review cycle: Review model and dataset changes quarterly, and regulation and the overall framework annually. Record the review completion date and reviewer.
• Connect to other clauses: Governance ties together the regulatory review under the transparency obligation (3.6) and the lifecycle management under the AI SBOM (3.9) from above. Connect them rather than building duplicate procedures.

Sample (Governance Framework and Annual Review Plan)

Below is a sample of the core part of a governance framework document and periodic review plan. This document becomes verification material 3.10.1.

## AI Governance Framework
### 1. Scope and Purpose
Manages licensing, transparency, risk, and regulatory compliance across the full
lifecycle of an AI system — intake, development, deployment, operation, and
retirement.
### 2. Governance Structure
- AI Governance Lead: approves the framework, makes the final call on regulatory obligations
- Regulatory Tracking Owner: monitors emerging AI regulation, derives obligations
- AI SBOM Verification Owner: runs the generation, review, and approval procedure
- Legal: interprets non-standard licenses and regulation
### 3. Periodic Review Plan
| Frequency | Review Item | Owner | Deliverable |
|------|----------|------|--------|
| Quarterly | Model/dataset changes, model tree licensing | AI SBOM Verification Owner | Change review record |
| Semiannual | Non-standard license classification, OSAID updates | Legal | Updated classification |
| Annual | Regulatory enforcement schedule, overall framework, policy alignment | AI Governance Lead | Revised framework |
### 4. Change Management
When a model tree change, new regulation taking effect, or a license policy change
occurs, convene an ad hoc review rather than waiting for the periodic review. Record
the review outcome and action taken in the change history.

5. References

• Policy foundation:3.1 Policy
• Transparency obligations and regulatory review:3.6 Transparency Obligations
• AI SBOM lifecycle management:3.9 AI SBOM
• Full regulatory matrix and ISO/IEC 42001 context:ISO/IEC 42001 Guide — Organizational Context and Leadership

1. Clause Overview

Without an AI SBOM policy, an organization ends up deploying AI systems while developers remain unaware of the licensing obligations attached to models and datasets. In AI, what needs to be tracked goes beyond code. Model weights, training datasets, and the model tree derived from other models each carry their own license, and non-standard licenses that restrict the purpose of use — such as the Llama Community License or the RAIL family — are common. Missing these obligations leads to copyright disputes, violations of usage restrictions, and terminated business contracts.

To prevent this risk, 3.1 requires establishing a documented policy that governs AI SBOM compliance and communicating it so that program participants are aware of its existence. This policy must reflect business strategy, the legal requirements of relevant jurisdictions, and the level of risk appropriate to the use case. All subsequent clauses (competence, license obligations, AI SBOM, governance, and so on) operate on top of this policy.

2. Activities to Perform

• Draft and formalize a policy document that governs AI SBOM compliance.
• Define the scope of application in the policy (AI systems deployed externally, external models/datasets brought in, internal models released publicly, etc.).
• Reflect business strategy, the legal requirements of relevant jurisdictions, and the risk level for each use case in the policy.
• Include in the policy a list of licenses allowed or prohibited for models and datasets.([Guide Recommendation] Because compliance with non-standard licenses is hard to track automatically after the fact, decide it through policy at intake time.)
• Establish and document a procedure for communicating the policy to program participants (development, legal, security, data staff, etc.).
• Retain records that prove the policy was communicated (training completion, notice history, etc.).
• Include in the policy a procedure for periodically reviewing it and re-communicating it when it changes.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.1.1 Documented AI SBOM Policy

How to Comply

The AI SBOM policy is a formal document that captures the principles and procedures by which the organization manages the licensing and transparency obligations of its AI systems. The policy should include its purpose, scope, roles and responsibilities, principles for reviewing model and dataset licenses, AI SBOM management, how transparency obligations are addressed, and the review cycle. Because this document itself is verification material 3.1.1, manage it as a formal document with recorded version and approval history.

For an organization that already has an ISO/IEC 5230 open source policy, it is more efficient to add an AI-related section to the existing policy than to create a separate new one. Add that models and datasets fall within the scope of license review, how non-standard licenses are handled, and what format is used to manage the AI SBOM.

A policy is not a document to be written once and left alone. Because the AI regulatory landscape changes quickly, conduct a periodic review at least once a year and record the change history.

Considerations

• State the AI-specific scope explicitly: Clearly state in the policy that license review covers not only code but also model weights, training/testing/validation datasets, and the derivation relationships in the model tree.
• Allowed/prohibited license lists: Divide model and dataset licenses into allowed and prohibited lists, based on whether commercial use is permitted and whether there are behavioral use restrictions, and set this in the policy in advance.([Guide Recommendation])
• Approval procedure: Have the legal team or the AI governance lead give final approval, and record the approval date and approver.
• Version control: Maintain the document version and change history so that previous versions can be compared during an audit.
• Periodic review: Review at least once a year, and record the review completion date and reviewer.

Sample

Below is a sample of the scope of application and the allowed/prohibited license lists for an AI SBOM policy. This text becomes a core component of verification material 3.1.1. Check the actual terms of each license against its original text, then classify it to fit the organization’s use case.

## 1. Purpose and Scope
This policy defines the compliance principles and procedures for the company to
develop and deploy AI systems safely and responsibly. It is designed to satisfy
the requirements of ISO/IEC 5230 (open source license compliance) and the
OpenChain AI SBOM Compliance Guide.
Scope:
- All AI systems, models, and services distributed externally.
- Pre-trained models and datasets brought in from outside.
- Activities that release internal models to the outside.
## 2. Model/Dataset License Classification
Licenses for models and datasets being brought in are reviewed against the
classification below. A license not in this classification goes through review
by the AI governance lead before being brought in.
- Allowed (commercial use permitted, no behavioral restrictions): Apache-2.0, MIT, BSD, CC-BY-4.0, etc.
- Conditionally allowed (use after review): licenses with restrictions on purpose or
scale of use, such as the Llama Community License, the Gemma Terms of Use,
and the OpenRAIL family
- Prohibited (non-commercial only, etc.): using a CC-BY-NC dataset in a commercial product, etc.

3.1.2 Policy Awareness Procedure

How to Comply

Writing the policy document alone is not enough. A communication procedure must be established and documented so that program participants actually become aware the policy exists. This communication procedure document itself is verification material 3.1.2. Because AI systems involve not just developers but also data staff, legal, and security, design the channel so the policy reaches all of them.

Include AI SBOM policy guidance in onboarding for new hires, and use internal wiki postings and email notices for existing employees. To prove that the policy was communicated, retain evidence such as notice history and training completion records for at least three years.

Considerations

• Use multiple channels: Use two or more channels, such as an internal wiki, email notices, and onboarding training.
• Include AI-related roles: Include dataset owners and model operators as recipients as well.
• When the policy changes: Have a separate procedure to notify participants of changes immediately.
• Retain evidence: Keep notice history and training completion certificates for at least three years.

Sample

Below is a sample policy communication notice email. Retaining the send history serves as evidence for verification material 3.1.2.

Subject: [AI Compliance] AI SBOM Policy Notice and Acknowledgment Request
To: Employees involved in AI system development, operations, and data
From: AI Compliance Officer
Hello,
Our AI SBOM compliance policy has been established (or revised).
All employees involved in using, bringing in, or deploying AI models and
datasets are asked to review and familiarize themselves with the policy
document below.
- Policy document: [internal portal link]
- Key contents: model/dataset license classification, license obligation
review procedure, AI SBOM management, transparency obligation response
- Policy version: v1.0 (effective date: YYYY-MM-DD)
Contact: AI Compliance Officer (ai-compliance@company.com)

5. References

• License obligation review procedure:3.5 License Obligations
• Basic structure of an open source policy:ISO/IEC 5230 Compliance Guide — 3.1.1 Policy
• AI license management strategy:Enterprise Open Source Management Guide — AI Compliance

What Is an SBOM

A Software Bill of Materials (SBOM) is a machine-readable list of all the components and libraries that make up a software product, along with the dependency relationships among them. It carries over the manufacturing concept of a Bill of Materials into software. Just as a finished vehicle has a specification sheet recording which parts came from which supplier, an SBOM records which open source and commercial components, at which versions, went into an application.

Most modern software is filled more with components brought in from outside than with code written in-house. Those external components can carry vulnerabilities, come with license obligations attached, and in turn depend on still other components. An SBOM makes this chain of dependencies visible, providing a common data layer that security, license management, and asset management can all reference.

Why It Matters: The Collapse of Supply Chain Trust

Two supply chain incidents raised the SBOM onto the policy agenda. In the SolarWinds incident that came to light in December 2020, attackers poisoned the legitimate update path of the Orion software itself. A backdoor spread along with that update to the many organizations that trusted and installed it. It was a structure in which a compromise at a single point upstream in the supply chain spread across the entire downstream.

A year later, in December 2021, a remote code execution vulnerability in the Java logging library Log4j (CVE-2021-44228, commonly known as Log4Shell) was disclosed. What this incident exposed was not a breach itself but an absence of visibility. Log4j was buried deep as an indirect dependency in countless products, so few organizations could give an immediate answer to the question, “where in our products does this library exist?” If every piece of software had already had a machine-readable component list in place, determining the scope of impact would have taken a single query. This experience gave direct momentum to the SBOM agenda.

After that, the SBOM moved beyond recommendation into regulation. The United States opened a path to requiring SBOMs for software delivered to the federal government through Executive Order 14028 in 2021, and the European Union made producing an SBOM a legal obligation through the Cyber Resilience Act (CRA). The detailed regulatory landscape is covered in3. Regulatory Landscape.

Benefits of an SBOM

The value of an SBOM is not limited to security alone. The same data — a component list — serves multiple purposes at once.

• Vulnerability management and incident response: When a new vulnerability is disclosed, affected components can be looked up immediately to set response priorities.
• Supply chain risk management: The provenance and trustworthiness of external components are assessed and reflected in procurement and supplier management.
• License compliance: Tracking the license of each component prevents obligation violations and conflicts in advance.
• Regulatory compliance: Meets transparency requirements and provides the evidence needed for regulatory reporting and audits.
• Asset management and operational efficiency: Knowing exactly what is in use makes lifecycle management easier.

Who Creates and Uses It

The value of an SBOM does not come from a single organization producing it alone; it is realized when it flows along the supply chain. The third edition of CISA’sFraming Software Component Transparency organizes the actors around an SBOM into three perspectives: producers (Produce) who make software, choosers (Choose) who select which software to use, and operators (Operate) who run it. It is common for a single organization to hold all three roles at once, as with a company that develops its own products while also bringing in external libraries and operating infrastructure.

The core of this structure is the chain of supplier-consumer relationships. When an upstream producer creates an SBOM and passes it downstream, the downstream chooser uses it to assess risk before adoption, and the operator looks up the scope of impact immediately when a new vulnerability is disclosed. What Log4Shell showed was precisely a break in this chain. Because producers had not passed along a component list, operators could not know what libraries existed in their own assets.

Interests diverge subtly across actors. Consumers want a deeper, more complete SBOM, while producers, concerned about trade secrets and attack surface exposure, want to narrow the scope of disclosure. Where regulation sets the floor of obligation, and how it adjusts the scope of disclosure, are the mechanisms that resolve this tension. Sharing and disclosure scope are covered in7. Sharing and Governance.

The next section looks atlevels and types according to the depth of information an SBOM carries.

Sources

The factual basis for this section is compiled in this guide’s background research materials. Executive Order 14028 (86 FR 26633, May 12, 2021), CVE-2021-44228 (NVD), and the third edition of CISA’sFraming Software Component Transparency (September 3, 2024) were used as primary sources. For the full set of sources, see3. Regulatory Landscape and the bottom of each section.

First, an enterprise must establish an organization responsible for open source management.

The following should be considered when forming the organization:

• Roles and responsibilities of the organization
• Competencies required for each role
• The organization/person responsible for each role

1. Defining the Roles and Responsibilities of the Organization

The ISO standards commonly require a document that describes the roles and responsibilities of the various participants in the program, as follows.

Open Source Program Manager

To build an open source management system, an enterprise first needs someone responsible for leading and carrying it out. This person is called by titles such asOpen Source Program Manager orOpen Source Compliance Officer; this guide uses the termOpen Source Program Manager.

The Open Source Program Manager is in charge of the enterprise’s Open Source Program Office (OSPO).Open Source Program Office refers to the organization responsible for an enterprise’s open source management, and is also referred to by the termOpen Source Secretariat.

A person with the following competencies can be considered well-suited for the role of Open Source Program Manager.

• Understanding of the open source ecosystem and development experience
• Broad understanding of the enterprise’s business
• Passion and communication skills to spread effective open source use among employees

It is best for the Open Source Program Manager to be guaranteed the ability to perform the role full-time whenever possible.

Global ICT enterprises are making efforts to hire capable Open Source Program Managers of this kind. Various job postings can be found at the following site:https://github.com/todogroup/job-descriptions

Documenting Roles and Responsibilities

An enterprise must define each role needed for the OSPO and determine what responsibilities to assign to it.

In a small enterprise, it is possible for the Open Source Program Manager alone to perform all the roles. Depending on the size of the enterprise, an IT staff member to operate open source tools may also be needed, and a legal role may be required to provide specialized legal counsel.

In general, the following roles are needed to build an enterprise’s open source management system.

• Legal
• IT
• Security
• Developer Relations

To this end, the roles and responsibilities that make up the OSPO must be documented as follows.

2. Defining Required Competencies

Once each role and its responsibilities have been defined, the essential competencies that the person performing that role must have need to be identified.

The ISO standards commonly require a document that describes the competencies needed for each role, as follows.

This is because it is necessary to assess whether the person assigned to each role has the competencies to perform it, and to provide training if needed.

To this end, an enterprise must document the competencies needed for each role, as follows.

3. Assigning Owners

The Open Source Program Manager consults with the relevant departments to assign an owner for each role and document this. To do so, the goals and direction for building the open source compliance system must be reported to the top decision-maker, such as the CEO, in order to obtain the necessary support.

The organization and owners related to open source do not necessarily need to work on open source full-time. It is also possible to form a virtual organization in the form of an OSRB (Open Source Review Board) to carry out the necessary roles.

The ISO standards commonly require a document naming the persons, groups, or functions responsible for each role in the program, as follows.

To this end, an enterprise must document the names of the persons, groups, or functions responsible for each role in the program, as follows.

A documented sample of roles, responsibilities, required competencies, and owner assignments can be found on the next page.[Appendix 1] Open Source Policy (Sample) - Appendix 1. Assigned Owners

SK telecom has formed anOSRB to create open source policies and processes within the company, and collaborates to prepare response plans when issues arise.

4. Summary

A documented sample of roles, responsibilities, required competencies, and owner assignments can be found in the open source policy template document:Appendix 1. Assigned Owners

An enterprise can refer to this to organize its open source management structure to fit its own situation.

By designating and documenting the OSPO organization in this way, an enterprise satisfies the requirements marked in red below among the ISO standard specifications.

In fact, more important than the documentation itself is appointing an owner who will faithfully carry out the actual work, and supporting that owner in acquiring the necessary competencies.

Taking part in systematic training, such as theOpen Source License Professional Training offered by the Korea Copyright Commission or theNIPA Open Software Management Academy, is also very helpful.

The roles of the Open Source Program Manager and the Security role are becoming increasingly important. The Open Source Program Manager must also have a basic understanding of open source security assurance, and the Security role needs an understanding of new security requirements such asSBOM (Software Bill of Materials) management.

In addition, continuous learning and staying current with the latest trends are becoming important across every role. The open source ecosystem and related technologies and regulations are changing rapidly, so each owner must continuously update their knowledge in their own field. Participating in international communities such asOpenChain or theTODO Group, or attendingdomestic open source conferences, is also a good approach.

1. What Is the OpenChain Project?

Today, software continues to grow in scale and complexity. Developing a single piece of software can involve not only software built in-house but also a variety of software spanning the software supply chain, including open source, third-party software, and vendor SDKs.

If even a single organization within this complex software supply chain fails to comply with open source license obligations or fails to provide accurate information about its open source use, the enterprise distributing the final software has no choice but to fail at meeting its own open source license obligations. This can result in lawsuits and even the suspension of product sales.

In December 2009, a lawsuit arose involving the open source projectBusybox. Busybox is open source licensed under GPL-2.0 that is widely used in embedded systems, and 14 companies, including two South Korean companies, became subject to the lawsuit. A notable point in this case is that among the defendants were companies that were sued despite not developing the product themselves but only distributing it.

In such a complex software supply chain environment, it is very difficult for any single enterprise, no matter how excellent its processes are, to achieve perfect open source compliance on its own. Ultimately, for an enterprise to properly implement open source compliance, every member of the software supply chain must comply with license obligations and provide accurate open source information. This kind of trust must be built across the entire supply chain.

TheOpenChain project, part of theLinux Foundation, was founded on the belief that concisely and consistently defining the core requirements enterprises must meet for open source compliance, and having everyone comply with them, can build trust in open source licensing across the entire software supply chain.

At an open source conference in Europe in 2016, Dave Marr, an open source attorney at Qualcomm, emphasized exactly this point. To raise one enterprise’s level of open source compliance, the compliance level of every member across the software supply chain must be raised. He further suggested that, to achieve this, leading enterprises that already have a solid understanding of open source and have established policies and processes should openly share their assets and know-how so that anyone could reference them. Conference attendees agreed with the idea that “open source compliance is not an area where enterprises can differentiate their profits. Enterprises want an appropriate level of risk management while investing minimal resources. That is why the more enterprises share their assets with one another, the more everyone can achieve compliance together with fewer resources.” This is how the OpenChain project (then called a Work Group) began, with numerous global enterprises participating, includingQualcomm,Siemens,Wind River,ARM, andAdobe.

The OpenChain project provides three main things to help enterprises more easily achieve open source compliance.

1. OpenChain Specification
2. OpenChain Conformance Certification
3. Documentation Resources

Let’s look at how enterprises can make use of each of these, one by one.

2. The OpenChain Specification and ISO/IEC Standards

The OpenChain Specification is a 10-page document that defines the core requirements for open source compliance. Version 1.0 of the OpenChain Specification was published in 2016. The OpenChain Specification is designed to be suitable for any enterprise, regardless of size or industry.

In 2020, version 2.1 of the specification was released, defining the six core requirements that enterprises must fulfill to achieve open source compliance, along with the list of materials needed to demonstrate them.

1. Program Establishment
2. Defining and Supporting Related Tasks
3. Reviewing and Approving Open Source Content
4. Creating and Delivering Compliance Artifacts
5. Understanding Open Source Community Engagement
6. Conformance to Specification Requirements

For an enterprise just starting out with open source compliance, a good strategy is to raise its maturity level by fulfilling these OpenChain Specification requirements one by one.

In December 2020, this OpenChain Specification was formally registered asISO/IEC 5230:2020, the international standard for open source compliance.

The OpenChain Specification, which had served as a de facto standard for the previous four years, was converted into the formal international standard ISO/IEC 5230:2020 — the first international standard to define open source compliance and process management. As a result, interest among global IT enterprises in complying with ISO/IEC 5230 is rising, and more enterprises are expected to require ISO/IEC 5230 compliance from their suppliers across the software supply chain.

In 2023,ISO/IEC 18974, a new standard for open source security assurance, was published. This standard is based on the OpenChain Security Assurance Specification and defines the core requirements for managing known security vulnerabilities in open source software. ISO/IEC 18974 covers the following key areas:

1. Identifying the core areas requiring security processes
2. How to assign roles and responsibilities
3. How to ensure the sustainability of the process

Like ISO/IEC 5230, ISO/IEC 18974 is concise and easy to understand, and it is backed by the global community, providing free reference materials and conformance resources.

Together, these two standards support organizations in effectively managing both license compliance and security assurance for open source software. Where ISO/IEC 5230 focuses on license compliance, ISO/IEC 18974 focuses on vulnerability management, making the two mutually complementary.

3. How to Certify to the ISO/IEC Standards

If an enterprise complies with all the requirements of both ISO/IEC 5230 and ISO/IEC 18974, it can be certified as having an open source program conforming to these standards. An open source program refers to the set of management systems — including policies, processes, and personnel — that an enterprise uses to carry out its open source compliance and security assurance activities.

The image below lists the item numbers required by ISO/IEC 5230. An enterprise that fulfills all these items can be recognized as having built a transparent and trustworthy open source governance system within the software supply chain.

TheOpenChain project proposes three certification methods:

• Self-Certification
• Independent Assessment
• Third-Party Certification

Let’s look at each method.

(1) Self-Certification

Self-certification is the method most recommended by the OpenChain project and has the advantage of incurring no cost. The OpenChain Project provides anISO/IEC 5230 self-certification website so that enterprises can verify on their own whether they comply with the OpenChain Specification. An enterprise’s open source manager can sign up on this website and begin the online self-certification process. Self-certification proceeds by answering Yes/No questions, as shown below.

If an enterprise has built its open source compliance system well enough to answer Yes to every question in the OpenChain self-certification, it can submit the result on the website (Conforming Submission). After a brief question-and-answer verification process with theLinux Foundation, it can then declare ISO/IEC 5230 certification.

By making this certification declaration, an enterprise is recognized within the global software supply chain as having an open source program that conforms to ISO/IEC 5230.

The OpenChain project recommends the self-certification method. For reference, most enterprises that have declared OpenChain conformance have also adopted self-certification.

In addition, going through the self-certification process lets an enterprise determine what is lacking and what additional activities are needed. This guide explains, by major component — organization, policy, process, and so on — how to meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

For an enterprise that lacks the capability to make improvements on its own using only this guide, the independent assessment method can be considered.

(2) Independent Assessment

In an independent assessment, an independent organization outside the enterprise inspects and evaluates the enterprise’s open source compliance and security assurance status from an impartial standpoint. What distinguishes independent assessment is that it does not stop at producing an assessment report, but also provides consulting to address the gaps identified. (It does not, however, issue an official certificate.)

By receiving impartial assessment and consulting from an independent organization, an enterprise can raise its compliance and security assurance level, and through the iterative process of undergoing independent assessment again, refine its policies and build out its processes.

Eventually, the enterprise reaches a level where it can obtain ISO/IEC 5230 and ISO/IEC 18974 certification, at which point it can move into the process of obtaining self-certification or third-party certification. In this way, independent assessment provides evaluation and consulting to raise an enterprise’s open source compliance and security assurance level, supporting the enterprise in holding a conformant ISO/IEC 5230 and ISO/IEC 18974 program and obtaining certification.

Companies that provide independent assessment includeAlektoMetis andSource Code Control, among others.

In South Korea, theConformance Group, a subgroup of the OpenChain Korea Work Group, is a community where enterprises discuss and share methods for achieving ISO/IEC 5230 and ISO/IEC 18974 conformance on their own. Anyone who is a member of the OpenChain Korea Work Group can participate and get help.

(3) Third-Party Certification

An enterprise wishing to demonstrate a more reliable and transparent level of open source compliance and security assurance to buyers in the software supply chain can obtain a certificate from a third-party certification body and use it for promotional purposes. In addition, some buyers who demand stronger assurance of open source compliance and security may come to require third-party certification from their suppliers.

As of 2024, OpenChain’s authorized third-party certification bodies areORCRO,PWC,TÜV SÜD,Synopsys, andBureau Veritas.

These bodies provide assessments to verify conformant ISO/IEC 5230 and ISO/IEC 18974 programs and issue certificates to enterprises that pass.

As of 2024, buyers or organizations that mandatorily require third-party certification are not yet common. However, some experts in the European automotive industry predict that it will not be long before ISO/IEC 5230 and ISO/IEC 18974 become mandatory for automotive software suppliers, much likeASPICE (Automotive SPICE, an international standard process model for automotive software development).

In addition, detailed self-certification methods can be found in the following slides:

• OpenChain Korea 9th Meeting - How to Self Certify

4. OpenChain Resources

TheOpenChain project provides a variety of documentation resources that enterprises need to build a compliance program, including policy document templates and training materials. These materials are designed to support conformance with the OpenChain Specification and general open source compliance activities, and are provided under the CC-0 license so that anyone can use them freely.

Much of this guide was also written based on materials published by OpenChain. If an enterprise’s open source manager needs policies, processes, or training materials, they should look to the OpenChain Resources first. These materials are also translated into Korean and published. TheOpenChain Korea Work Group leads this translation effort. Anyone interested canparticipate in the Korean translation.

The OpenChain project also provides additional resources by running various webinars and study groups:

1. Webinars: The OpenChain project regularly hosts webinars to share the latest trends and best practices in open source compliance and security. These webinars can be found on theOpenChain website, where recordings are also available.

2. Training Materials: The OpenChain project provides acomprehensive training curriculum to help enterprises develop internal training programs. This material covers a range of topics, from the basic concepts of open source software to license compliance and security assurance.

By making use of these various resources, an enterprise can build and maintain a strong open source program that conforms to the ISO/IEC 5230 and ISO/IEC 18974 standards.

5. Trends in ISO/IEC Standard Adoption

Adoption of the ISO/IEC 5230 and ISO/IEC 18974 standards is showing a gradually expanding trend across the global software supply chain.

In early 2021, news emerged that a German automaker had begun requiring its parts suppliers to have an ISO/IEC 5230 compliance plan. In response, a European open source professor predicted that “it is clear that buyers in the software supply chain will increasingly require suppliers to comply with ISO/IEC 5230,” adding that “in the automotive industry, it will come to occupy the same position as ASPICE.”

Reflecting this outlook, in May 2021,Scania, part of the Volkswagen Group, incorporated a requirement for ISO/IEC 5230 compliance into its own corporate standard (STD 4589) that suppliers must follow.

Also, in July 2021,Bosch, an automotive and industrial technology company, declared that all of its group companies would have an ISO/IEC 5230-compliant program by the end of the year. The industry outlook is that it is only a matter of time before every automaker, and other industries as well, begin requiring ISO/IEC 5230 within their software supply chains.

In 2023, ISO/IEC 18974, a new standard for open source security assurance, was published. This standard defines the core requirements for managing known security vulnerabilities in open source software. Together with ISO/IEC 5230, ISO/IEC 18974 supports organizations in effectively managing both license compliance and security assurance for open source software.

As of 2024, this trend is accelerating further. For example,KT announced in October 2024 that it had obtained ISO/IEC 18974 certification. This shows that South Korean enterprises, too, are actively adopting international standards for open source security management.

The activities of theOpenChain Korea Work Group are also becoming more active. At its 22nd regular meeting held in June 2024, discussions covered the state of readiness for the ISO/IEC 18974 open source security standard and SBOM-based software supply chain management guidelines. This shows that South Korean enterprises are actively embracing the ISO/IEC 5230 and ISO/IEC 18974 standards.

This trend is expected to continue. As the complexity of the software supply chain increases and security threats grow, the importance of international standards such as ISO/IEC 5230 and ISO/IEC 18974 is likely to grow further. By complying with these standards, enterprises will be able to increase transparency in their open source use and effectively manage security risk.

OSV-SCALIBR (Software Composition Analysis LIBRary) is an open source software composition analysis library developed by Google. It supports various programming languages and aims to provide fast and accurate analysis results. It offers core functionality for generating a Software Bill of Materials (SBOM), but because it is provided as a library rather than as a standalone executable, users need to write their own code to integrate it.

1 Introduction to OSV-SCALIBR

• Key Features:
  • Support for various programming languages (Python, Go, Java, etc.)
  • Analysis of package manifest files (requirements.txt, pom.xml, go.mod, etc.)
  • Dependency information extraction
  • Vulnerability information integration (using the OSV database)
  • Fast analysis speed
• Advantages:
  • Support for various programming languages
  • Fast analysis speed
  • Provides the latest vulnerability information through OSV database integration
  • Flexible integration possibilities
  • Open source license
• Disadvantages:
  • Provided as a library rather than as a standalone executable
  • Users need to write their own code to integrate it
  • SBOM generation functionality must be implemented directly
  • Lack of documentation and community support

2 Installing OSV-SCALIBR

Because OSV-SCALIBR is provided as a library, you need to install it through the package manager appropriate for the programming language you intend to use. This guide explains how to install it in a Python environment.

1. Confirm Python and pip Are Installed:

   • Before installing OSV-SCALIBR, confirm that Python and pip are installed on the system.
   • Run the following command in the command prompt or terminal to check the Python version.

   python --version

   • Python 3.7 or higher must be installed.
   • To check the pip version, run the following command.

   pip --version

   • If Python and pip are not installed, download and install them from the official Python website (https://www.python.org/downloads/).

2. Install OSV-SCALIBR:

   • Run the following command to install the OSV-SCALIBR library.

   pip install osv-db

3. Verify the Installation:

   • Run the Python interpreter and enter the following code to confirm that OSV-SCALIBR was installed correctly.

   importosvprint(osv.__version__)

   • If the OSV-SCALIBR version information is printed, the installation completed successfully.

3 OSV-SCALIBR Usage Guide

Because OSV-SCALIBR is provided as a library, you need to write your own code to generate an SBOM. The following is a basic example of generating an SBOM using OSV-SCALIBR in a Python environment.

1. Install Required Libraries:

   • In addition toosv-db, install the libraries needed to generate an SBOM (e.g.,spdx-tools).

   pip install spdx-tools

2. Write the Code:

   • The following is example code that extracts dependency information from arequirements.txt file, checks vulnerability information using OSV-SCALIBR, and then generates an SBOM in SPDX format.

   importosvfromspdx_tools.spdx.modelimportDocument,Packagefromspdx_tools.spdx.builderimportBuilderfromspdx_tools.spdx.validation.document_validatorimportvalidate_fullimportosdefcreate_sbom_from_requirements(requirements_file):""" Extracts dependency information from a requirements.txt file, checks vulnerability information using OSV-SCALIBR, and then generates an SBOM in SPDX format. """# 1. Read the requirements.txt filedependencies=[]withopen(requirements_file,"r")asf:forlineinf:line=line.strip()iflineandnotline.startswith("#"):package_name,package_version=line.split("==")dependencies.append((package_name,package_version))# 2. Create the OSV API clientclient=osv.Client()# 3. Create the SPDX documentdocument=Document(spdx_version="SPDX-2.2",data_license="CC0-1.0",spdx_id="SPDXRef-DOCUMENT",name="SBOM for "+requirements_file,)document.creators=["Tool: OSV-SCALIBR Example Script","Organization: Your Organization"]# 4. Add package information and check vulnerability informationforpackage_name,package_versionindependencies:# Query vulnerability information using the OSV APIvulnerabilities=client.get_vulnerabilities(package_name,package_version)# Create the packagepackage=Package(name=package_name,spdx_id=f"SPDXRef-Package-{package_name}",version=package_version,# TODO: License information needs to be added.)# If vulnerability information exists, add a commentifvulnerabilities:comment=f"Vulnerabilities found:{len(vulnerabilities)}"package.comment=commentdocument.packages.append(package)# 5. Validate and outputvalidation_messages=validate_full(document)ifvalidation_messages:print("Validation errors:")formessageinvalidation_messages:print(message)else:# Convert the SPDX document to a string (using spdx-tools)fromspdx_tools.spdx.writer.write_anythingimportwrite_anythingoutput_file="sbom.spdx"write_anything(document,output_file,"tag",check_licenses=False)print(f"SPDX document generated successfully! File:{output_file}")# Example run# The requirements.txt file must be in the current directory.ifos.path.exists("requirements.txt"):create_sbom_from_requirements("requirements.txt")else:print("Error: could not find the requirements.txt file.")

3. Run the Code:

   • Save the code above as a Python file (e.g.,sbom_generator.py), and run the following command.

   python sbom_generator.py

4. Check the Results:

   • If the code runs successfully, asbom.spdx file is generated. This file contains the SBOM written in SPDX format.

4 Precautions When Using OSV-SCALIBR

• Because OSV-SCALIBR is provided as a library, you need to write your own code to generate an SBOM.
• Because OSV-SCALIBR does not provide every function needed for SBOM generation, you need to implement the required functionality yourself or use it together with other libraries.
• OSV-SCALIBR’s documentation can be somewhat lacking, and community support may not be very active.
• The code example generates an SBOM based on arequirements.txt file, but a real environment may need support for various package managers.
• The code example does not add license information directly. In an actual SBOM, you need to accurately determine and add the license information for each package.

5 Example of a Generated SBOM (Inferred)

An SBOM (in SPDX format) generated using OSV-SCALIBR would have a structure like the following. (The actual content depends on the contents of therequirements.txt file.)

SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
Name: SBOM for requirements.txt
Creator: Tool: OSV-SCALIBR Example Script
Created: 2025-02-11T00:00:00Z
# Package Information
PackageName: requests
SPDXID: SPDXRef-Package-requests
PackageVersion: 2.28.1
# Comment: Vulnerability found: 1 (may vary depending on the OSV database)
PackageName: urllib3
SPDXID: SPDXRef-Package-urllib3
PackageVersion: 1.24.13
# Relationships
# (Dependency relationship information between each package)

Note: the example above merely shows the format of an SBOM that OSV-SCALIBR could generate; the actual SBOM content depends on the code and the dependency analysis results. Additional information such as license information and origin information needs to be added by modifying the code directly.

6 Additional Information

• OSV-SCALIBR GitHub repository: (no information)
• OSV (Open Source Vulnerabilities) database:https://osv.dev/
• SPDX official website:https://spdx.dev/

Caution: because OSV-SCALIBR is a library, this guide alone may not be enough to complete SBOM generation. It requires an understanding of Python programming and SBOM generation, along with additional code.

FOSSLight is an open source project led by LG Electronics that uses various scanners to analyze source code, binaries, and dependencies, and generates a Software Bill of Materials (SBOM). In particular, FOSSLight Hub supports the compliance process by providing open source management, license management, and vulnerability management functions.

1 Introduction to FOSSLight

• Key Features:
  • Integration of various scanners: integrates and uses various open source scanners such as ScanCode Toolkit, SPDX Tools, CycloneDX, and Fossology
  • Support for various analysis targets: supports various analysis targets such as source code, binaries, container images, and Linux packages
  • SBOM generation and management: generates and manages SBOMs in various formats (SPDX, CycloneDX, Excel, Text)
  • License information detection and management: accurately detects and manages open source license information
  • Vulnerability information integration: integrates with external vulnerability databases such as NVD and CVE to provide vulnerability information
  • FOSSLight Hub: provides open source management, license management, and vulnerability management functions through a web-based UI
• Advantages:
  • High extensibility: various scanners can be integrated and used as plugins
  • Web-based UI: provides a user-friendly interface through FOSSLight Hub
  • Support for various report formats: reports can be generated in various formats such as SPDX, CycloneDX, Excel, and Text
  • Open source license
• Disadvantages:
  • Complex initial setup: initial setup can be somewhat complex because various scanners need to be integrated
  • FOSSLight Hub installation required: FOSSLight Hub must be installed separately to use the web-based UI

2 Installing FOSSLight

FOSSLight consists of FOSSLight Scanner and FOSSLight Hub. FOSSLight Scanner runs various scanners to generate analysis results, while FOSSLight Hub provides a web-based UI that integrates, manages, and visualizes the scanner results.

This section explains how to install FOSSLight Scanner and FOSSLight Hub together using Docker Compose.

1. Install Docker and Docker Compose:

   • Before installing FOSSLight, confirm that Docker and Docker Compose are installed on the system.
   • Docker installation instructions vary by operating system, so refer to the official Docker documentation (https://docs.docker.com/get-docker/).
   • Docker Compose is a tool for running and managing multiple containers simultaneously using Docker. For Docker Compose installation instructions, refer to the official Docker documentation (https://docs.docker.com/compose/install/).

2. Clone the FOSSLight Repository:

   • Run the following command to clone the FOSSLight GitHub repository.

   git clone <https://github.com/fosslight/fosslight_hub.git>cd fosslight_hub

3. Configure the Docker Compose File:

   • Thefosslight_hub directory contains adocker-compose.yml file. You can open this file in a text editor and change the FOSSLight Hub configuration.

   version:"3.7"services:fosslight_db:image:mariadb:10.6.4container_name:fosslight_dbvolumes:-fosslight_db:/var/lib/mysqlrestart:alwaysenvironment:-MYSQL_ROOT_PASSWORD=fosslight-MYSQL_DATABASE=fosslight_db-MYSQL_USER=fosslight-MYSQL_PASSWORD=fosslightfosslight_web:image:fosslight/fosslight_hub:latestcontainer_name:fosslight_webports:-"8080:8080"restart:alwaysenvironment:-FOSSLightDB_HOST=fosslight_db-FOSSLightDB_PORT=3306-FOSSLightDB_USER=fosslight-FOSSLightDB_PASSWORD=fosslight-FOSSLightDB_NAME=fosslight_dbdepends_on:-fosslight_dbfosslight_scanner:image:fosslight/fosslight_scanner:latestcontainer_name:fosslight_scannerrestart:alwaysvolumes:-./upload:/home/fosslight_scanner/upload-./result:/home/fosslight_scanner/resultvolumes:fosslight_db:

   • You can change the port number, database settings, and so on as needed.

4. Run FOSSLight:

   • Run the following command to start FOSSLight.

   docker-compose up -d

   • This command runs FOSSLight Hub, FOSSLight Scanner, and the MariaDB database as Docker containers.

5. Verify the FOSSLight Installation:

   • In a web browser, accesshttp://localhost:8080 to confirm that you can reach FOSSLight Hub.
   • If the FOSSLight Hub web UI is displayed, the installation completed successfully.

   Figure 2.1: FOSSLight Hub Web UI

   (Insert screenshot of the FOSSLight Hub web UI)

3 FOSSLight Usage Guide

FOSSLight can be used through a web UI (FOSSLight Hub) and a CLI (FOSSLight Scanner).

3.1 Using FOSSLight Hub

FOSSLight Hub provides functionality, through a web UI, to manage open source projects, check scan results, and generate various reports.

1. Register a Project:

   • Access FOSSLight Hub and register a new project.
   • Enter information such as the project name, description, and owner.

   Figure 2.2: FOSSLight Hub Project Registration Screen

   (Insert screenshot of the FOSSLight Hub project registration screen)

2. Upload Scan Results:

   • Upload the scan results generated using FOSSLight Scanner to FOSSLight Hub.
   • The scan result file must be in SPDX, CycloneDX, or FOSSLight JSON format.

   Figure 2.3: FOSSLight Hub Scan Result Upload Screen

   (Insert screenshot of the FOSSLight Hub scan result upload screen)

3. Check Scan Results:

   • Check the uploaded scan results.
   • FOSSLight Hub visually presents SBOM information, license information, and vulnerability information.

   Figure 2.4: FOSSLight Hub Scan Result Review Screen

   (Insert screenshot of the FOSSLight Hub scan result review screen)

4. Generate Reports:

   • Generate various reports based on the scan results.
   • You can choose the report format: SPDX, CycloneDX, Excel, or Text.

   Figure 2.5: FOSSLight Hub Report Generation Screen

   (Insert screenshot of the FOSSLight Hub report generation screen)

3.2 Using FOSSLight Scanner

FOSSLight Scanner provides functionality, through the CLI, to scan source code, binaries, and container images and generate an SBOM.

1. Run a Scan:

   • Run the following command to execute a scan.

   docker run --rm -v$(pwd)/upload:/home/fosslight_scanner/upload -v$(pwd)/result:/home/fosslight_scanner/result fosslight/fosslight_scanner -p /home/fosslight_scanner/upload/<scan target> -o /home/fosslight_scanner/result/<result file name> -f <result format>

   • Each option is explained as follows.
     • -rm: automatically removes the container after it runs.
     • v $(pwd)/upload:/home/fosslight_scanner/upload: shares theupload directory in the current directory with the/home/fosslight_scanner/upload directory inside the container. You need to copy the file or directory to be scanned into this directory.
     • v $(pwd)/result:/home/fosslight_scanner/result: shares theresult directory in the current directory with the/home/fosslight_scanner/result directory inside the container. The scan result file is saved to this directory.
     • p /home/fosslight_scanner/upload/<scan target>: specifies the path to the file or directory to be scanned.
     • o /home/fosslight_scanner/result/<result file name>: specifies the name of the scan result file.
     • f <result format>: specifies the scan result format (spdx, cyclonedx, fosslight_json).
   • Example:

   docker run --rm -v$(pwd)/upload:/home/fosslight_scanner/upload -v$(pwd)/result:/home/fosslight_scanner/result fosslight/fosslight_scanner -p /home/fosslight_scanner/upload/my_project -o /home/fosslight_scanner/result/my_project_sbom.json -f fosslight_json

2. Check the Scan Results:

   • Once the scan completes, the scan result file is generated in theresult directory.
   • You can check the scan result file using a text editor or FOSSLight Hub.

4 Precautions When Using FOSSLight

• Because FOSSLight integrates and uses various scanners, you need to understand the characteristics and usage of each scanner.
• Because FOSSLight Hub requires a web server and a database, you need to install it with system resource requirements in mind.
• FOSSLight Scanner requires permission to access the file or directory being scanned.

5 Troubleshooting

• Docker execution error: confirm that Docker is installed correctly, and check for permission issues.
  • Try running with administrator privileges using thesudo docker run ... command.
• Scan error: confirm that the path to the file or directory being scanned is correct, and check that you have permission to access that file or directory.
• FOSSLight Hub access error: confirm that the Docker container is running properly, and check that the port forwarding is configured correctly.

6 Additional Information

• FOSSLight official website:https://fosslight.org/
• FOSSLight GitHub repository:https://github.com/fosslight/fosslight_hub
• SPDX official website:https://spdx.dev/
• CycloneDX official website:https://cyclonedx.org/

(Updated on August 29, 2023.)

A company that develops and distributes products containing open source needs to collect and track information such as the version and license of the open source used, for each product and release version. This allows the company to carry out proper open source compliance activities.

In particular, when a security vulnerability is reported for a specific open source version at NVD (https://nvd.nist.gov/vuln), a company that cannot trace which products use that version ends up unable to determine which products need the security patch applied, leaving its products exposed to the vulnerability.

This makes tracking open source information a necessity. Companies address this either by building their own system or by purchasing and using a commercial service. SW360 is open source software sponsored by the Eclipse Foundation, providing a web application and repository for collecting and tracking software Bill of Materials (BOM) information.

Key Features

SW360 provides a web-based UI, and its key functions are as follows.

• Tracking components used in a product
• Security vulnerability assessment
• License obligation management
• Generating legal documents such as notices

Installation

SW360 is composed as follows.

• Frontend : Liferay-(Tomcat-)based portal application
• Backend : Tomcat-based thrift service
• Database : CouchDB

For details on the project structure and the software required for installation, see the Required software section of the README. :https://github.com/eclipse-sw360/sw360

SW360 offers the following installation methods. Users can choose one of them for installation.

1. Can be deployed via Docker. :https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md
2. Can install SW360’s components individually. :https://github.com/eclipse/sw360
3. Vagrant-based (https://www.vagrantup.com/) installation: Vagrant is a tool for managing virtualized instances, and sw360vagrant provides an environment for deploying SW360 all at once. :https://github.com/sw360/sw360vagrant
   • The Vagrant-based installation guide can be foundhere. (Note: because the code has changed since the guide was written, it may not work correctly.)

This guide introduces the method of deploying withDocker. For details, refer to the README. :https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md

1. Download the Code

Download the code to build the Docker image. The tested code can be obtained here. :https://github.com/haksungjang/sw360/tree/docker_build

git clone -b docker_build https://github.com/haksungjang/sw360.git

2. Build

First, installDocker. (Note that apaid purchase may be required for corporate developer use.)

Build by runningdocker_build.sh as shown below.

cd sw360./docker_build.sh

Once the build completes successfully, you can check the created images as shown below.

docker image lsREPOSITORY TAG IMAGE ID CREATED SIZEeclipse-sw360/sw360 18-development ab0fd848bf808 minutes ago 2.95GBeclipse-sw360/sw360 latest ab0fd848bf808 minutes ago 2.95GBghcr.io/eclipse-sw360/sw360 18-development ab0fd848bf808 minutes ago 2.95GBghcr.io/eclipse-sw360/sw360 latest ab0fd848bf808 minutes ago 2.95GBeclipse-sw360/binaries 18-development aa7debf0a1fc8 minutes ago 347MBeclipse-sw360/binaries latest aa7debf0a1fc8 minutes ago 347MBghcr.io/eclipse-sw360/binaries 18-development aa7debf0a1fc8 minutes ago 347MBghcr.io/eclipse-sw360/binaries latest aa7debf0a1fc8 minutes ago 347MBeclipse-sw360/base 18-development e5147733fc8837 minutes ago 1.52GBeclipse-sw360/base latest e5147733fc8837 minutes ago 1.52GBghcr.io/eclipse-sw360/base 18-development e5147733fc8837 minutes ago 1.52GBghcr.io/eclipse-sw360/base latest e5147733fc8837 minutes ago 1.52GBghcr.io/eclipse-sw360/thrift 0.18.1 0012d79980584 weeks ago 152MBghcr.io/eclipse-sw360/thrift latest 0012d79980584 weeks ago 152MBeclipse-sw360/thrift 0.18.1 0012d79980584 weeks ago 152MBeclipse-sw360/thrift latest 0012d79980584 weeks ago 152MB

3. Run

Run the created images with thedocker-compose up command.

docker-compose up

Once it runs successfully, you can see three containers running as shown below.

docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4299fd39010c eclipse-sw360/sw360 "/app/entry_point.sh" 3 minutes ago Up 3 minutes 0.0.0.0:8080->8080/tcp, 0.0.0.0:11311->11311/tcp sw360
13fd5696b140 postgres:14 "docker-entrypoint.s…" 3 minutes ago Up 3 minutes (healthy) 0.0.0.0:5438->5432/tcp sw360-postgresdb-1
7bb70f2daaf4 couchdb "tini -- /docker-ent…" 3 minutes ago Up 3 minutes (healthy) 4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp sw360-couchdb-1

At this point, accessinghttp://localhost:8080/ takes you to the following screen.

Configuration

After installing SW360 successfully, you need to perform the initial configuration following the procedure below. For details, see:SW360 Initial Setup Configuration

1. User and Login Configuration

Log in with the following account to perform the configuration.

• id :setup@sw360.org
• pw : sw360fossy

Once you log in, a Not Found message appears as shown below.

Click the item icon (cube shape) in the upper right of the screen and select theControl Panel tab.

EnableSECURITY >Password Policies >Default Password Policy >PASSWORD CHANGES >Change Requried.

Then, back in theControl Panel tab, selectCONFIGURATION >Instance Settings. This shows thePLATFORM menu.

There, selectUsers. Then go into theDefault User Associations menu, checkApply to Existing Users, andSave.

Now, underInstance Settings >PLATFORM, selectUser Authentication. Go intoGeneral and uncheck all items. (You can check and enable any items needed for administrative purposes.) ThenSave.

Finally, you need to enable jQuery and Font Awesome. To do this, go intoCONFIGURATION >System Settings in theControl Panel tab, where you can findThird Party underPLATFORM.

Go intoThird Party and enableJQuery andFont Awesome respectively.

Restart your browser for the changes to take effect.

2. Import LAR Files

To configure SW360, you need to import the*.lar files. To do this, you need to go into the menu, and the menu button is in the upper left of the screen.

In the menu, go intoPublishing >Import.

Click the+ button on the right to upload a LAR file. The LAR files are located under thefrontend/configuration folder in the SW360 source files. (e.g.,https://github.com/haksungjang/sw360/tree/docker_build/frontend/configuration)

First, upload thePublic_Pages_7_4_3_18_GA18.lar file and click theContinue button.

On the File Summary screen, you can see the details of the uploaded LAR file.

ChangeAUTHORSHIP OF THE CONTENT at the bottom toUse the Current User as Author and click theImport button.

You can then see that the import completed successfully.

Similarly, import thePrivate_Pages_7_4_3_18_GA18.lar file. On the File Summary screen, changePAGES >Private Pages as shown below.

Then select thePERMISSIONS,UPDATE DATA, andAUTHORSHIP OF THE CONTENT items as shown in the image below, and click theImport button to perform the import.

After completing this, click theHome button at the top of the menu.

This takes you to theWelcome to SW360! screen shown below.

Click theStart button to go into the SW360 main screen. (All items are empty at this point.)

3. User Account Configuration (for Testing)

In the SW360 menu, selectAdmin >User.

In theUPLOAD USERS menu at the bottom of the screen, upload the user list for testing. (The user list for testing can be downloaded here. :test_users_with_passwords_12345.csv )

You can then see that a list of 9 users has been uploaded, as shown below.

Try logging in again with theuser@@sw360.org account, one of the users shown in the list. The password is12345.

Basic Workflow

1. Registering Licenses

When you first install SW360, you need to first register the open source licenses you use frequently. A license includes the following information.

• Full Name
• Short Name
• License Type
• GPL-2.0 Compatibility (e.g., yes, no)
• License Text

Selecting Menu > Licenses > Add License takes you to the Create License screen shown below.

Registering licenses one by one manually like this can be quite tedious, but fortunately SW360 provides a feature to import the SPDX License List all at once. Click Menu > Admin < Import SPDX Information.

The SPDX License List is then automatically registered shortly after. At Menu > Licenses, you can confirm that 338 licenses have been registered.

2. Registering Components and Releases

In SW360, a Component is a single unit of software. Various forms of software can fall into this category, for example:

• Open source software
• Libraries
• Third-party software

A Component includes the following information.

• Component Name
• Main Licenses
• Categories (e.g., Library, Cloud, Mobile, …)
• Component Type (e.g., OSS, Internal, InnerSource, Service, Freeware)
• Default Vendor
• Homepage URL

A Release is the unit that refers to a single Version within a Component. Accordingly, one Component can have multiple Releases. A Release is created and managed under a single Component.

A Release includes the following information.

• Component Name
• Version
• License
• Download URL
• CPE ID (e.g., cpe:2.3:a:apache:maven:3.0.4)

For example, if you need to register zlib-1.2.8, you first register zlib as a Component, then register zlib 1.2.8 as a Release. Selecting Menu > Components > Add Component takes you to the Create Component screen, where you can register information about zlib.

Once you create the Component, you can register information for the zlib-1.2.8 version at Components > Releases > Add Release.

When versions 1.2.8 and 1.2.11 are each registered as Releases under the single zlib Component, the Release Overview screen shows 2 Releases existing, as below.

SW360 provides a feature for importing information for multiple Components at once. At Menu > Admin > Import / Export, you can enter the Component information you want to register into the CSV template and then import it.

Note that, as of February 2020, this feature may not yet work reliably.

3. Creating a Project

A Project refers to a single product. Depending on the type of business, it may be a product, a service, or software. Under a Project, you register and manage the Components/Releases used in the product.

When creating a Project, you register the following information.

• Project Name
• Version
• Project type (e.g., Product, Customer Project, Service, Internal Project, InnerSource)

You can create a Project via Menu > Projects > Add Project.

Once you create the Project, register the Releases or sub-Projects it includes. Selecting the Project at Menu > Projects lets you register Linked Projects and Linked Releases under “Linked Releases and Projects.”

The following is the screen after registering OpenSSL 1.0.1 and zlib 1.2.8 as Linked Releases in a Project named SuperCalc.

4. Security Vulnerability Management

SW360 can automatically check whether registered Releases have security vulnerabilities. To do this, SW360 provides a feature for scheduling periodic collection of CVE information. At Menu > Admin > Schedule, you can set a schedule to collect CVE SEARCH information every 24 hours.

Once this schedule is set, SW360 collects CVE information from the CVE Search site (https://cve.circl.lu/) at the scheduled time. The collected CVE information can be checked at Menu > Vulnerabilities.

Once the Vulnerabilities information has been collected, you can query whether a created Project has security vulnerabilities. In the SuperCalc Project created above, you can confirm that 85 security vulnerabilities were reported.

By registering and managing the software a company develops and distributes in SW360 this way, you can manage it in a form that minimizes risk not only for open source compliance but also for security vulnerabilities.

SW360 also offers most of its functionality via a REST API in addition to the Web Interface above, making integration with other tools such as FOSSology possible. :https://github.com/eclipse/sw360/wiki/Dev-REST-API

In other words, integrating this into DevOps by, for example, importing the analysis results of a source code scanning tool into SW360, and automating the registration of Projects and Releases, would greatly increase efficiency.

For open source compliance, you can use a source code scanning tool to detect the open source and license information contained within software.

The Linux Foundation’s FOSSology project developed this scanning tool and released it as open source so that anyone can use it freely.

Key Features

FOSSology is a web-based program that lets users log in to the website and upload individual files or software packages. FOSSology detects license text and copyright information within the uploaded files. Developers should use FOSSology when they want to check what license a piece of open source carries and what its copyright information looks like. FOSSology scans every file in an uploaded open source package, automatically detects license-related text and copyright information in each file, and generates a report from it. For more details on FOSSology’s key features, refer to the following page. :https://www.fossology.org/features/

Installation

To use FOSSology within a company, you need to build a FOSSology server in-house. This requires installing FOSSology on a Linux-based server system. FOSSology can be installed in the following three ways.

1. Using Docker
2. Using Vagrant and VirtualBox
3. Installing via a source build

This section explains the simplest method, using Docker.

FOSSology publishes a containerized Docker image through Docker Hub (https://hub.docker.com/). :https://hub.docker.com/r/fossology/fossology

The pre-built Docker image can be run using the following command.

$ docker run -p 8081:80 fossology/fossology

The Docker image can be accessed with the following URL and account information. : http://[IP_OF_DOCKER_HOST]:8081/repo

• Username : fossy
• Passwd : fossy

For more details on installation, refer to the following page. :https://github.com/fossology/fossology/blob/master/README.md

Test Server

If it is difficult to build a system on which to install FOSSology, you can use the test server provided by the FOSSology Project. The FOSSology project provides an environment for testing. (The test server may go down without notice.)

Users can access the FOSSology test server with the following account to try out FOSSology’s features.

Basic Workflow

The basic usage procedure for FOSSology is as follows.

• To check the license and copyright information of the open source you want to use, compress its source code into a single file and upload it to FOSSology.
• To do this, select Menu > Upload > From File.

• Select the file to upload and click the Upload button.
• Once the upload completes, the Job Agent automatically performs the analysis.
• You can check the Status of the analysis in progress at Menu > Jobs > My Recent Jobs.

• Once the analysis completes, you can check the results at Menu > Browse.

• Selecting an individual file lets you see what license-related text FOSSology has detected.

• At Menu > Browser > select a file or directory > Copyright/Email/Url/Author, you can see the Copyright/Email/Url/Author information FOSSology detected.

After checking whether these analysis results are valid, users can exclude incorrectly detected items from the analysis results. FOSSology describes this as the Clearing process; for more details, refer to the following page. :https://www.fossology.org/get-started/basic-workflow/

Using the method above, you can easily check what license the open source you want to use carries and what its copyright information is.