Guide

• 1: [2025] Enterprise Open Source Management Guide Based on ISO Standards
• 1.1: 0. Understanding OpenChain
• 1.2: 1. Organization
• 1.3: 2. Policy
• 1.4: 3. Process
• 1.5: 4. Tools
• 1.6: 5. Training
• 1.7: 6. Conformance Declaration
• 2: A Guide to Building Enterprise Open Source Governance Based on the International Standard ISO/IEC 5230
• 2.1: 1. Understanding ISO/IEC 5230
• 2.2: 2. Essential Elements
• 2.3: 3. Organization (Personnel)
• 2.4: 4. Policy
• 2.5: 5. Process
• 2.6: 6. Tools
• 2.7: 7. Training/Assessment
• 2.8: 8. Declaration of Conformance
• 2.9: Appendix
• 2.9.1: 1. Open Source Policy (Sample)
• 2.9.2: 2. Open Source Compliance Process (Sample)
• 2.9.3: 3. Tools (FOSSology, SW360)
• 2.9.3.1: FOSSology
• 2.9.3.2: SW360
• 3: Open Source Security Assurance: A Guide to Enterprise Adoption and Certification of ISO/IEC 18974
• 3.1: 1. Why Does Open Source Security Matter?
• 3.2: 2. Key Requirements of ISO/IEC 18974
• 3.3: 3. How to Implement ISO/IEC 18974
• 3.3.1: 3.1 Program Foundation
• 3.3.2: 3.2 Relevant Tasks Defined and Supported
• 3.3.3: 3.3 Open Source Software Content Review and Approval
• 3.3.4: 3.4 Adherence to the specification requirements
• 3.4: 4. Comparison and Integration with ISO/IEC 5230
• 3.5: 5. Implementation Considerations by Organizational Characteristics
• 3.6: 6. ISO/IEC 18974 Self-Certification Process
• 3.7: 7. Case Studies and Success Strategies
• 3.8: 8. Conclusion and Future Outlook
• 4: Enterprise Open Source Compliance Guide Using OpenChain
• 5: Open Source Audits in Merger and Acquisition (M&A) Transactions
• 5.1: Chapter 1. Introduction
• 5.2: Chapter 2. Common Open Source Usage Scenarios
• 5.3: Chapter 3. Open Source Audits
• 5.4: Chapter 4. Estimating Audit Scope
• 5.5: Chapter 5. Audit Methods
• 5.6: Chapter 6. Notes on the Final Report
• 5.7: Chapter 7. Security and Version Control
• 5.8: Chapter 8. Pre- and Post-Acquisition Remediation
• 5.9: Chapter 9. Preparing for an Audit as a Target Company
• 5.10: Chapter 10. Preparing for an Audit as the Acquirer
• 5.11: Chapter 11. Recommended Compliance-Related Development Practices
• 5.12: Chapter 12. Conclusion
• 6: A Practical Guide to SBOM (Software Bill of Materials)
• 6.1: SBOM Overview
• 6.1.1: SBOM Levels and Classification
• 6.2: Standards and Formats
• 6.2.1: Minimum Elements of an SBOM
• 6.2.2: Identifiers and Licenses
• 6.3: Regulatory Trends
• 6.3.1: EU Cyber Resilience Act (CRA)
• 6.3.2: India, Korea, and Other Jurisdictions
• 6.4: Adoption Roadmap
• 6.5: Tools and Automation
• 6.6: Vulnerability Management and VEX
• 6.7: Sharing and Governance
• 6.8: Recommendations and Checklist
• 7: AI SBOM Compliance Guide
• 7.1: Program Foundation
• 7.1.1: 3.1 Policy
• 7.1.2: 3.2 Competence
• 7.1.3: 3.3 Awareness
• 7.1.4: 3.4 Program Scope
• 7.2: AI Extension Process
• 7.2.1: 3.5 License Obligations
• 7.2.2: 3.6 Transparency Obligations
• 7.2.3: 3.9 AI SBOM
• 7.3: Operations
• 7.3.1: 3.7 Access
• 7.3.2: 3.8 Effectively Resourced
• 7.4: Governance
• 7.4.1: 3.10 Governance
• 7.5: Tools
• 7.5.1: OWASP AIBOM Generator
• 7.5.2: cdxgen
• 7.5.3: Model and Container Scanners (Lab700x, Trivy, Syft)
• 8: Templates
• 8.1: Open Source Policy
• 8.1.1: Appendix
• 8.2: Open Source Process
• 9: Tools
• 9.1: FOSSology
• 9.2: SW360
• 9.3: FOSSLight
• 9.4: OSV-SCALIBR

1 - [2025] Enterprise Open Source Management Guide Based on ISO Standards

International Standards for Open Source Management

There are two ISO international standards for open source management:

1. ISO/IEC 5230: OpenChain Specification - the international standard for open source compliance
2. ISO/IEC 18974: OpenChain Security Assurance Specification - the international standard for open source security

OpenChain and ISO/IEC 5230

ISO/IEC 5230 is the sole international standard for open source compliance, defining the core requirements enterprises must meet to build an effective open source program. For details, see the Understanding OpenChain page.

Enterprise Open Source Management Approach

By complying with the requirements of ISO/IEC 5230 and ISO/IEC 18974, an enterprise can build an effective open source management system. To do so, an enterprise must have the following six core elements:

1. Organization: Establish a dedicated organization for open source management
2. Policy: Establish and document a clear open source policy
3. Process: Build systematic processes for open source use, contribution, and distribution
4. Tools: Adopt automated tools for open source scanning, tracking, and management
5. Training: Conduct training for employees to raise open source awareness and build competency
6. Conformance: Maintain standard conformance through continuous monitoring and improvement

This guide provides detailed methods and examples for how enterprises can concretely implement each element.

References

This guide was written with reference to the following authoritative sources:

1.1 - 0. Understanding OpenChain

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 project Busybox. 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.

The OpenChain project, part of the Linux 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, including Qualcomm, Siemens, Wind River, ARM, and Adobe.

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 as ISO/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.

The OpenChain 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 an ISO/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 the Linux 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 include AlektoMetis and Source Code Control, among others.

In South Korea, the Conformance 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 are ORCRO, PWC, TÜV SÜD, Synopsys, and Bureau 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 like ASPICE (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

The OpenChain 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. The OpenChain Korea Work Group leads this translation effort. Anyone interested can participate 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 the OpenChain website, where recordings are also available.

2. Training Materials: The OpenChain project provides a comprehensive 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 the OpenChain 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.

1.2 - 1. Organization

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 as Open Source Program Manager or Open Source Compliance Officer; this guide uses the term Open 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 term Open 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 an OSRB 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 the Open Source License Professional Training offered by the Korea Copyright Commission or the NIPA 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 as SBOM (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 as OpenChain or the TODO Group, or attending domestic open source conferences, is also a good approach.

1.3 - 2. Policy

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 in 6. 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 the OSRB (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 as SPDX 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 of ISO/IEC 5230 and ISO/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, the OpenChain 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 the Linux 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.

The SK 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 in 7. 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 a CLA (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 the SBOM (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.

1.4 - 3. Process

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 as Jira or Bugzilla 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 the National 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 as OWASP Dependency-Check to scan the dependencies of the supplied software and identify Known Vulnerabilities.

3. Vulnerability severity assessment: Use CVSS (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 the Open 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 the National 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 as Jira 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 by CVSS (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 an OSRB (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.

The open source contribution procedure published by SK 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 as Jira or Confluence.

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 the OpenChain Project, it can enhance its credibility within the global software supply chain.

1.5 - 4. Tools

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 the FOSSology 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 as Gradle and Maven. 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

The OSS 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 by LG 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 the SW360 guide.

(2) FOSSLight

FOSSLight is a comprehensive open source management tool developed by LG 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 the SW360 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 name onot, 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 the SPDX 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 {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Dependency Scan') {
            steps {
                dependencyCheck additionalArguments: '', odcInstallation: 'Default'
            }
        }
        stage('License Scan') {
            steps {
                fossology()
            }
        }
        stage('SBOM Update') {
            steps {
                sw360UpdateProject()
            }
        }
    }
    post {
        always {
            dependencyCheckPublisher pattern: '**/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
  - report

dependency_scan:
  stage: scan
  script:
    - docker run --rm -v $(pwd):/src owasp/dependency-check --scan /src --format "ALL" --out /src/reports

license_scan:
  stage: scan
  script:
    - docker run --rm -v $(pwd):/project fossology/fossology:latest /usr/local/fossology/fo_cli -c /project

sbom_update:
  stage: analyze
  script:
    - sw360 update-project

vulnerability_report:
  stage: report
  script:
    - generate_vulnerability_report
  artifacts:
    reports:
      dependency_scanning: reports/dependency-check-report.json

license_report:
  stage: report
  script:
    - generate_license_report
  artifacts:
    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.

1.6 - 5. Training

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, the License Guide provided by the Korea Copyright Commission can be referenced.

The Obligations 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.

1.7 - 6. Conformance Declaration

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.

2 - A Guide to Building Enterprise Open Source Governance Based on the International Standard ISO/IEC 5230

References

This guide references the following materials.

1. OpenChain Project Website
2. OpenChain Open Source Policy Template
3. Open Source Compliance In The Enterprise

2.1 - 1. Understanding ISO/IEC 5230

What is ISO/IEC 5230?

ISO/IEC 5230 is a specification created by the Linux Foundation’s OpenChain Project that defines the minimum core requirements for ensuring trustworthy open source compliance across the software supply chain.

Today’s software keeps growing in scale and complexity. Building a single piece of software can involve not only software developed in-house but also a wide range of software from across the supply chain, including open source, third-party software, and vendor SDKs.

If even one organization in this complex software supply chain fails to comply with its open source license obligations or fails to provide accurate information about its open source usage, the company distributing the final software has no choice but to fail at open source license compliance as well. This can result in lawsuits that force the company to halt sales of its product.

In December 2009, there was a lawsuit involving the open source project Busybox. Busybox is a GPL-2.0-licensed open source project widely used in embedded systems, and 14 companies, including two Korean companies, were named as defendants. What stood out about this case is that even companies that had not developed the product themselves, but had merely distributed it, were sued.

In such a complex software supply chain environment, it is extremely difficult for any single company, no matter how excellent its processes are, to achieve complete open source compliance on its own. In the end, for a company to properly implement open source compliance, every participant in 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.

The Linux Foundation’s OpenChain project was founded on the belief that if the core requirements a company must meet for open source compliance are defined concisely and consistently, and everyone complies with them, trust regarding open source licensing can be built 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 a company’s level of open source compliance, the level of open source compliance of every participant in the software supply chain must be raised. He also suggested that, to achieve this, advanced companies that already understand open source well and have established policies and processes could open up 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 companies can differentiate their competitive advantage. Companies want an adequate level of risk management while investing minimal resources. That is why the more companies share their assets with one another, the more everyone can achieve compliance with fewer resources.” That is how the OpenChain project (then a Work Group) began, with the participation of numerous global companies including Qualcomm, Siemens, Wind River, ARM, and Adobe.

The OpenChain project provides companies with three main things to make it easier to achieve open source compliance.

1. The OpenChain Specification¹
2. OpenChain Conformance Certification²
3. Reference materials³

Let’s look at how companies can use each of these.

The OpenChain Specification and ISO/IEC 5230

The OpenChain Specification is a 10-page document that defines the core requirements for open source compliance. OpenChain Specification version 1.0 was released in 2016. The OpenChain Specification is designed to be applicable to any company, regardless of its size or industry.

Version 2.1 of the specification was released in 2020, and it defines six core requirements that a company must fulfill to achieve open source compliance, along with a list of the evidence needed to demonstrate each.

1. Establishing the program
2. Defining and supporting relevant roles
3. Reviewing and approving open source content
4. Creating and delivering compliance artifacts
5. Understanding engagement with open source communities
6. Complying with the specification’s requirements

For a company 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 as the international standard⁴ for open source compliance.

The OpenChain Specification, which had been 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 in ISO/IEC 5230 compliance is growing among global IT companies, and more companies are expected to require their suppliers in the software supply chain to comply with ISO/IEC 5230.

How to Get Certified for ISO/IEC 5230

If a company complies with all of the requirements in ISO/IEC 5230, it can be certified as having an open source program that conforms to ISO/IEC 5230. An open source program refers to the set of management systems, including policies, processes, and personnel, that a company puts in place to carry out open source compliance activities.

The image below lists the item numbers required by ISO/IEC 5230. A company that satisfies all of these items can be recognized as having built a transparent and trustworthy open source governance system across its software supply chain.

The OpenChain 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 it has the advantage of being free of charge. The OpenChain Project provides an OpenChain self-certification website so that companies can check for themselves whether they comply with the OpenChain Specification². A company’s open source manager can sign up on the OpenChain self-certification website and begin the online self-certification process. Self certification proceeds by answering Yes/No questions as shown below.

If a company has built a solid open source compliance system and can answer Yes to every question in OpenChain self-certification, it can submit these results on the website as a Conforming Submission. After a simple Q&A-style confirmation process by the Linux Foundation, the company can then declare ISO/IEC 5230 certification.

Once this certification declaration is made, the company is recognized in the Global Software Supply Chain as having an open source program that conforms to ISO/IEC 5230.

The OpenChain project recommends the self-certification approach. For reference, most companies that have declared OpenChain conformance have also adopted self certification.

Furthermore, through the self-certification process, a company can determine what it lacks and what additional activities are needed. This guide explains how to comply with the ISO/IEC 5230 requirements, organized by key components such as organization, policy, and process.

If a company lacks the capability to fill these gaps on its own using the guide alone, it can consider the independent assessment method.

2. Independent Assessment

In independent assessment, an independent organization outside the company examines and evaluates the company’s open source compliance status from a fair, external perspective. What distinguishes independent assessment is that it does not stop at producing an assessment report, but also provides consulting to help address the gaps that are identified. (Note, however, that it does not issue an official certificate.)

Through fair assessment and consulting from an independent organization, a company can raise its compliance level, and by repeating independent assessments, it can refine its policies and build out its processes.

Eventually, the company reaches a level at which it can obtain ISO/IEC 5230 certification, at which point it can proceed to self certification or third-party certification. In this way, independent assessment provides the evaluation and consulting needed to raise a company’s open source compliance level, supporting the company as it works to build an ISO/IEC 5230 conforming program and obtain certification.

Companies that provide independent assessment include AlektoMetis⁵ and Source Code Control⁶.

In Korea, the Conformance Group⁷, a subgroup of the OpenChain Korea Work Group, is a community where companies discuss and share methods for achieving ISO/IEC 5230 compliance among themselves. Any member of the OpenChain Korea Work Group can join and get help.

3. Third-Party Certification

If a company wants to demonstrate a more reliable and transparent level of open source compliance to buyers in the software supply chain, it can obtain a certificate from a third-party certification body and use it for promotional purposes. It is also expected that some buyers who demand stronger assurance of open source compliance reliability may require their suppliers to obtain third-party certification.

As of October 2021, OpenChain’s authorized third-party certification bodies are ORCRO⁸, PWC⁹, TÜV SÜD¹⁰, Synopsys¹¹, and Bureau Veritas¹².

These bodies provide assessments to confirm ISO/IEC 5230 conforming programs and issue certificates to companies that pass.

As of October 2021, there still appear to be no buyers or institutions that mandatorily require third-party certification. However, some experts in the European automotive industry predict that it will not be long before ISO/IEC 5230 becomes mandatory for automotive software suppliers, much like ASPICE (Automotive SPICE)¹³, the international standard process model for automotive software development.

For more detail on the self-certification method, you can also refer to the following slides.

• https://openchain-project.github.io/OpenChain-KWG/meeting/9th/OpenChain_Korea_20210311_howto.pptx

OpenChain Resources

The OpenChain project provides a variety of reference materials that companies need to build a compliance program, including policy document templates and training materials. These materials are designed to help organizations comply with the OpenChain Specification and support common open source compliance activities, and they are provided under a CC-0 license so that anyone can use them freely.

Much of the content in this guide was also written based on materials published by OpenChain. If a company’s open source manager needs policies, processes, or training materials, they should first check the OpenChain Resources. These materials are also translated into Korean and published. The OpenChain Korea Work Group¹⁴ leads this translation effort. Anyone interested can participate in the Korean translation work¹⁵.

The ISO/IEC 5230 Trend

In early 2021, news emerged that a German automaker had begun requiring its parts suppliers to plan for ISO/IEC 5230 compliance, and a European open source professor said, “It is clear that buyers in the software supply chain will increasingly require suppliers to comply with ISO/IEC 5230 going forward,” adding, “In the automotive industry, it will become like A-SPICE.”

Reflecting this trend, in May 2021, Scania, part of the Volkswagen Group, included a requirement for ISO/IEC 5230 compliance in 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 conforming program by the end of the year. Industry observers suggest it is only a matter of time before all automakers and companies in other industries begin requiring ISO/IEC 5230 within their software supply chains.

2.2 - 2. Essential Elements

Essential Elements of an Open Source Governance System

To build an efficient open source governance system, a company needs the following elements.

Among these elements, to build an open source governance system that fully meets all the requirements of ISO/IEC 5230, a company must basically have the following five elements in place. This section explains the details of each.

1. Organization (Personnel)
2. Policy
3. Process
4. Tools
5. Training/Assessment

2.3 - 3. Organization (Personnel)

Defining Roles and Responsibilities

To build a company’s open source governance system, a responsible person who takes charge of and carries out this task is needed first. This person may be called an Open Source Program Manager, Open Source Compliance Officer, or similar title, and is responsible for the company’s overall open source compliance.

A person with the following competencies is well suited for this role.

• Understanding of the open source ecosystem and development experience
• Broad understanding of the company’s business
• Passion and communication skills to spread effective open source use among the company’s members

It is best to ensure that the Open Source Program Manager can perform this role full-time whenever possible.

Global ICT companies are working to hire excellent Open Source Program Managers like this, and various job postings can be found at the following site: https://github.com/todogroup/job-descriptions

To build an open source governance system, a company must define the necessity of each role and determine what responsibilities should be assigned. In the case of a small company, it is possible for the Open Source Program Manager alone to perform all roles. Depending on the size of the company, an infrastructure officer to operate open source tools may also be needed, and a legal officer role to provide professional legal advice may be required.

In general, the following roles are needed to build a company’s open source governance system.

• Legal officer
• Infrastructure officer
• Development culture officer
• Security officer

By doing this, a company can prepare the following evidence materials required by ISO/IEC 5230.

Defining Required Competencies

Once each role and its responsibilities have been defined, the required competencies that personnel performing that role must have need to be identified. This is because the person in charge of each role must be assessed for whether they have the competency to perform that role, and training must be provided if needed.

By doing this, a company can prepare the following evidence materials required by ISO/IEC 5230.

Assigning Personnel

The Open Source Program Manager consults with the relevant departments to assign personnel for each role and documents this. Of course, to do this, the goals and direction for building the open source compliance system must be reported to top decision-makers such as the CEO in order to receive the necessary support.

The open source-related organization and personnel do not necessarily need to participate in open source work full-time. It is fine to form a virtual organization in the form of an OSRB (Open Source Review Board) to perform the necessary roles.

SK telecom has formed an OSRB to create open source policies and processes within the company and to prepare response measures when issues arise.

By doing this, a company can prepare the following evidence materials required by ISO/IEC 5230.

The table below is a sample personnel roster specifying the roles of the open source-related organization and personnel, along with the required competencies. A company can refer to this to organize and document its open source organization.

This content can also be found on the following page. : https://haksungjang.github.io/docs/openchain/#appendix-1-담당자-현황

Organizing in this way satisfies the following three requirements of ISO/IEC 5230.

2.4 - 4. Policy

Documenting the Open Source Policy

A company must establish and document an open source policy consisting of principles for the correct use of open source by every organization involved in software development, service delivery, and distribution, and must disseminate it throughout the organization.

A typical open source policy includes the following.

• Principles for building and distributing software products and services using open source
• Principles for contributing to external open source communities
• Principles for releasing the company’s software as open source

The following page provides a sample open source policy document that satisfies the ISO/IEC 5230 requirements: “Appendix 1. Sample Open Source Policy”

Each company can modify this sample policy to fit its own business strategy and environment.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Defining the Scope

A single open source policy (program) does not necessarily have to apply to the entire organization. The scope of application can vary depending on the characteristics of each organization and product within the company. Different open source programs can be applied by organization or by product. Likewise, an organization that does not distribute software at all can be excluded from the scope of the open source program. A company should clearly define the scope and limits of its open source program based on the characteristics of its organizations and products, and specify this in its open source policy.

As a company’s organizations, products, and services change to fit its business environment, situations may arise where the scope of the program needs to be determined or revised. A company should have a procedure in place to respond to this, such as the following example.

1. When starting a new project, the open source program manager determines whether the project falls within the scope of the program.
2. If it is determined not to fall within scope, a proposal to bring the project into the scope of the program is submitted to the OSRB.
3. If the OSRB accepts the proposal, the scope of the program is revised accordingly.
4. In addition, if the open source program manager determines that a review of the program’s scope is needed, they can initiate a review of the program’s scope through the same process.

The following example content can be included in an open source policy.

2. Scope
This policy applies to the following three areas.

1) It applies to all products the company provides or distributes externally.
   However, using open source solely for internal purposes is not
   within the scope of this policy.
2) It applies when a member contributes to an external open source project.
3) It applies when releasing internal code as open source.

The scope can be changed to fit the company's business environment,
and the procedure for doing so is as follows.

1) If the open source program manager determines that a change in the
   policy's scope is needed due to changes in the company's business
   environment, such as new business or organizational restructuring,
   they submit a proposal for this to the OSRB.
2) The OSRB approves an appropriate level of change to the scope.
3) The OSRB revises the open source policy to change the policy's scope.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Designating a Point of Contact for External Inquiries / Publishing Contact Information

Customers and open source copyright holders sometimes raise open source-related inquiries, requests, or claims to a company regarding products or services developed using open source. The main content of such external inquiries and requests includes the following.

• Inquiries about whether open source was used in a specific product or service
• Requests for the source code provided under a Written Offer for GPL or LGPL licensed code
• Requests for an explanation or the release of source code for open source found in a product that was not disclosed in the open source notice
• Requests for missing files or build instructions for source code released to satisfy GPL, LGPL, or similar obligations
• Requests for copyright attribution

A company must designate a person responsible for handling these external inquiries. This is typically the open source program manager.

Also, external open source developers sometimes want to contact a company’s point of contact to discuss an open source compliance issue but cannot find a way to reach them, and end up filing a legal claim directly. To prevent this, a company must always publicly disclose a way for third parties to make open source-related inquiries and requests to the company.

The ways in which external parties can make open source-related inquiries to a company are (1) publishing the email address of the company’s open source program manager, or (2) using the Linux Foundation’s Open Compliance Directory.

It is also good practice to publish the representative email address of the company’s open source program office in the open source notice that accompanies its products and services.

This content can be reflected in the open source policy as shown in the example below.

1. Responding to External Inquiries
(1) Responsibility for Responding to External Inquiries
The open source program manager is responsible for responding to
inquiries and requests about open source compliance from outside
the company.

The open source program manager can assign all or part of the
handling of an inquiry to an appropriate person within [Company].
If necessary, the legal team is consulted for handling.
Anyone who receives an external inquiry about open source
compliance should notify the open source program manager so that
a prompt response can be made.

(2) Publishing Contact Information
The open source program manager publicly provides the contact
information of the responsible person so that external parties
can make open source-related inquiries and requests.

* Provide contact email address information in the open source notice.
* Register contact information in the Linux Foundation's Open
  Compliance Directory.

(3) Procedure for Responding to External Inquiries
Responding quickly and accurately to external open source
compliance inquiries can greatly reduce the risk of escalation
to litigation. To this end, the company complies with the
external inquiry response procedure defined in the open source
compliance process to respond to external open source compliance
inquiries.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Providing Staffing, Budget, and Other Support

A company must provide sufficient resources so that its open source program can function smoothly. It must appropriately staff each role within the program and ensure adequate budget and working hours. If it cannot, it must have a procedure in place to compensate for this. The following example wording can be added to the open source policy document.

4. Roles, Responsibilities, and Competencies

The head of the organization responsible for each role designates
a person in charge within the organization and allocates
appropriate time and budget so that person can carry out the role
faithfully. If a person responsible for a role feels they are not
receiving adequate support in carrying it out, they must raise the
issue with the open source program manager. The open source
program manager discusses resolving the issue with the relevant
head of organization. If it is not resolved appropriately, the
open source program manager can ask the OSRB to help resolve the
issue. The OSRB shares the issue with the head of the higher-level
organization and requests a resolution.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Providing Legal Counsel

A company must provide a way for the person responsible for each role to seek legal counsel when a legal review is needed to resolve an open source compliance issue. This should first be provided through the company’s in-house legal team, and for particularly sensitive issues, an outside law firm with open source-specialized attorneys can be used. An example of an open source policy for this is as follows.

4. Roles, Responsibilities, and Competencies

(2) Open Source Program Manager
* The open source program manager provides a way for members to
  obtain open source-related legal counsel.
* The open source program manager decides whether to engage an
  outside law firm. The effectiveness and appropriateness of
  outside legal counsel is evaluated and reviewed annually by the
  open source program manager.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

For reference, through its partner program, the OpenChain project provides a list of global law firms that offer open source-related legal counsel: https://www.openchainproject.org/partners

Law firms registered as OpenChain partners meet the requirements set by the OpenChain project, and Bae, Kim & Lee LLC is currently the only law firm registered from Korea.

Procedure for Assigning Internal Responsibility

There must be a procedure for assigning internal responsibility for open source compliance. This is the role of the open source program manager. The open source program manager must identify issues and appropriately assign them to the person responsible for each role. To this end, a company can describe this content in its open source policy document as follows.

4. Roles, Responsibilities, and Competencies

(2) Open Source Program Manager

The open source program manager is overall responsible for the
company's open source program. To ensure open source compliance
for products and services that use open source, they are
responsible for the following.

* Define the roles needed for open source compliance and
designate the responsible organization and person for each role.
Consult with the OSRB as needed.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Handling Non-Compliant Cases

A company must document a procedure for promptly reviewing and responding to non-compliant cases. The following example can be included in an open source policy for reference.

1. Open Source Use

(5) Compliance Issue Remediation 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 an appropriate
   resolution time.
2. Confirm whether the issue content points to an actual problem.
   (If not, inform the person who raised the issue that it is not
   a problem.)
3. If it is an actual problem, determine priority and decide on an
   appropriate response.
4. Carry out the response, and if necessary, appropriately update
   the open source compliance process.
5. Retain the above content using the Jira Tracker.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Open Source Contribution Policy

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

For this open source contribution policy, you can refer to 7. Open Source Contribution in the NIPA OpenChain Guide’s Appendix 1. Sample Open Source Policy.

Doing so allows a company to prepare the following evidence required by ISO/IEC 5230.

Once a company establishes an open source policy that includes the content above, it satisfies the following ISO/IEC 5230 requirements.

2.5 - 5. Process

Process is the actionable procedure that enables a company to comply with its open source policy during software development and deployment. Simply put, the open source compliance process consists of activities to comply with the conditions required by each license for the open source used while developing and distributing software, and it produces artifacts such as open source notices and source code to be disclosed.

Breaking down the open source compliance process into more detail gives the diagram below.

The image below is a sample open source compliance process that a company can generally adopt and use.

For more details, refer to the following page. : https://haksungjang.github.io/docs/openchain/#부록-2-샘플-오픈소스-컴플라이언스-프로세스

This chapter describes the components that the open source compliance process should include.

Open Source Identification and Auditing

To determine whether open source can be used, it is first necessary to identify the license of the open source to be used and check the obligations required by the license. Whether open source was used, what the license is, and what obligations each license imposes must be reviewed and recorded. An example procedure for this is as follows.

1. The development department performs a preliminary evaluation of the license according to the criteria defined in the open source policy.
2. Any questions are directed to the Open Source Program Manager, and if necessary, the Open Source Program Manager requests advice from an external legal expert.
3. All internal and external decision results and related grounds are retained.

The Identification, Auditing, Resolving Issues, Review, and Approval steps in “Appendix 2. Sample Open Source Compliance Process"’s 1. Identification of Open Source are an example of a documented procedure for reviewing and recording the obligations and restrictions imposed by each identified license.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Source code scanning tools can be used at the open source identification and auditing stage. This is explained in detail in “6. Tools”.

Open Source BOM Identification, Review, and Archiving

The most fundamental part of open source compliance activities is understanding the status of open source contained in Supplied Software. A process must be established for creating and managing a Bill of Materials (BOM) that identifies the open source and its licenses included in Supplied Software and contains that information. This is because knowing which open source is included in each version of Supplied Software is necessary to comply with the obligations required by each open source license when distributing the software.

All open source must be reviewed and approved before being integrated into Supplied Software. A prior review is needed not only for the function and quality of the open source but also for whether its origin and license requirements can be met. This requires a process of review request → review → approval.

Appendix 2. Sample Open Source Compliance Process describes the entire process for a company’s open source compliance. The BOM is created and managed through the steps from 1. Identification of Open Source to 6. Registration.

Tools for managing the open source BOM are explained in detail in “6. Tools”.

In addition, all processes and results of this open source compliance process must be documented. Using an issue tracking system such as Jira or Bugzilla, rather than email, can document this process more efficiently.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Generating Open Source Compliance Artifacts

As mentioned above, the most fundamental part of open source compliance activities is understanding the status of open source contained in Supplied Software. This is precisely to correctly fulfill the open source license requirements that are the core of open source compliance. In other words, a process must be established for generating a set of compliance artifacts for the open source contained in Supplied Software.

Compliance artifacts are broadly divided into two types.

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

   

   • How to generate an open source notice corresponding to the open source BOM collected using a tool is further explained in “6. Tools”.

2. Source code package to be disclosed: A package that collects 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 Supplied Software is distributed. Compliance artifacts are generated and distributed through the Notices and Distribution steps of “Appendix 2. Sample Open Source Compliance Process”.

If it is difficult to enclose the source code package to be disclosed when distributing Supplied Software, this can be replaced by providing a Written Offer to provide 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 do this, a company should consider building an open source website, which is explained in detail in “6. Tools”.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Responding to External Inquiries

To avoid facing legal action due to external claims, it is important for a company to respond to external inquiries and requests as quickly and accurately as possible. To do this, a company must have a process in place to respond quickly and effectively to external open source inquiries.

The figure below is the process a company should have in place to respond to external inquiries.

https://haksungjang.github.io/docs/openchain/#2-외부-문의-대응-프로세스

Details can be found in “Appendix 2. Sample Open Source Compliance Process, 2. External Inquiry Response Process”.

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Open Source Contribution Process

If a company has a policy that allows contributions to external open source projects, there must be a documented procedure governing the process by which internal developers can contribute to external projects.

The open source contribution process published by SK telecom is a good example.

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

Having such a procedure in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Building the process up to this point results in compliance with the ISO/IEC 5230 requirements as shown below.

2.6 - 6. Tools

Source Code Scanning Tools

Source code scanning tools can be used in the open source identification and auditing stage of the open source compliance process. Source code scanning tools range from free, open source-based tools to commercial tools, and each tool has its own strengths, but none provides complete functionality that can solve every problem. Therefore, a company must select the tool that best fits the characteristics and requirements of its product.

Many companies use these automated source code scanning tools alongside manual review. The Linux Foundation’s FOSSology project is a source code scanning tool released as open source, which companies can easily use for free.

For how to install and use FOSSology, refer to Appendix 3. Open Source Tools.

Dependency Analysis Tools

Modern software development uses build environments that support package managers such as Gradle and Maven. In these build environments, even without the source code present, the dependency libraries needed at build time are fetched from a remote location to compose Supplied Software. These dependency libraries are included in Supplied Software but are not detected by source code scanning tools. Therefore, it is also important to use tools for dependency analysis.

The open source OSS Review Toolkit provides a dependency analysis tool called Analyzer.

In addition, LG Electronics released FOSSLight Dependency Scanner as open source. FOSSLight Dependency Scanner supports various package managers such as Gradle, Maven, NPM, PIP, Pub, and Cocoapods.

Open Source BOM Management Tools

Clause 3.3.1.2 of the ISO/IEC 5230 specification requires that the open source BOM list contained in Supplied Software be documented and retained. The open source BOM can be managed using a spreadsheet program such as Excel. However, when the number and versions of Supplied Software exceed several hundred, managing this manually is not easy. It is advisable to adopt an open source automation tool for this purpose.

SW360, an open source project sponsored by the Eclipse Foundation, provides functionality to track the list of open source included in each Supplied Software.

For how to install and use SW360, refer to Appendix 3. Open Source Tools.

In addition, FOSSLight, the open source released by LG Electronics mentioned above, also provides functionality for open source BOM management.

LG Electronics developed FOSSLight in-house and has used it to manage the open source BOM for Supplied Software across its entire business divisions for several years, and in June 2021 announced that it had released it as open source for anyone to use.

Detailed installation and usage instructions are provided in a Korean-language guide, which is expected to be of great help to domestic Korean companies.

Adopting such a tool allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Generating Open Source Compliance Artifacts

Among the open source compliance artifacts, it is advisable to use a tool that automatically generates the open source notice rather than creating it manually.

Registering the open source BOM in FOSSLight automatically generates the open source notice. The open source notice generated by FOSSLight also includes a Written Offer for the source code to be disclosed.

In addition, SK telecom plans to release its internal open source notice auto-generation tool as open source, so using it in the future would also be a good option.

Archiving Open Source Artifacts

It is advisable for a company to build an open source website and register open source compliance artifacts there, so external customers can conveniently download the open source notice and source code package for Supplied Software at any time.

SK telecom’s open source website can be referred to as an example.

In particular, this website was developed as open source and its source code is publicly available, so other companies can easily build a similar website.

Building such a tool environment allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Building the tool environment up to this point results in compliance with the ISO/IEC 5230 requirements as shown below.

2.7 - 7. Training/Assessment

Training

No matter how excellent a policy and process a company has built, it will be useless if none of the company’s members pay attention to it. For the open source policy and open source compliance process to work effectively in a company, training its members is important.

A company must provide practical means, such as training and an internal wiki, so that all Program participants are aware that the organization has an open source policy and can carry out the necessary activities. Here, Program participants refers to all employees involved in the company’s software development, distribution, and contribution, including software developers, deployment engineers, and quality engineers.

Many companies publish their open source policy document on an internal wiki site so that any employee can check what is needed. In addition, they make training on the open source policy mandatory during new employee orientation and provide periodic training to Program participants annually or once every two years, so that all Program participants are aware of the existence of the open source policy. That is, a company should include such methods in its open source policy document, written as in the example below.

1. Training and Assessment

All Software Distribution participants must complete the mandatory open source
training provided on the [Learning Portal] every year.
This ensures familiarity with the open source policy, related training policy, and
how to look it up. Training records are retained on the [Learning Portal].

Building such a training environment allows a company to prepare the following evidence materials required by ISO/IEC 5230.

In addition, a company must make Program participants aware of the company’s open source policy, open source-related objectives, how participants can contribute to an effective open source program, and the implications of failing to comply with Program requirements. To do this, a company provides training and conducts an assessment to confirm that Program participants have understood correctly. The assessment results are documented and retained.

A company can include content such as the example below in its open source policy for this purpose.

1. Purpose
  (1) Purpose of the policy
    This policy provides the following principles so that the entire organization
    involved in the company's software development, service, and distribution can
    make proper use of open source.

    1) Principles for performing compliance in consideration of open source licenses
    2) Principles for contributing to external open source projects
    3) Principles for releasing internal projects as open source

   These principles provide a way for all members of the company to understand the
   value of open source, use open source correctly, and contribute to the open
   source community.

  (2) Impact of non-compliance
   Failure to comply with this policy may result in the following situations.
   * Receiving demands from external parties for open source license compliance.
   * Being forced to disclose company-developed source code against its wishes.
   * Facing legal action from open source copyright holders.
   * Being fined or receiving a product sales suspension order for copyright
     infringement and breach of contract.
   * Loss of company reputation.
   * Breach of contract with suppliers, resulting in claims for damages.
  For these reasons, the company takes 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
    All members can contribute to the effectiveness of the policy and the
    improvement of the company's compliance level by understanding the basis
    and content of this policy and faithfully carrying out the necessary
    activities.

Assessment is explained in more detail below.

Including such training content in the policy allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Open source training also includes content about the open source contribution policy. Even if an open source contribution policy has been created, if internal members are unaware of its existence, there is a risk that indiscriminate contribution activities could cause harm to individuals and the company. Open source training is provided so that all internal developers are aware of the existence of the open source contribution policy.

Providing training on the contribution policy in this way allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Creating new training materials from scratch can also be a difficult task for someone just starting this role. To help with this difficulty, NCSOFT published its internal open source training materials, including the lecture slides (PPT) and lecture script, on GitHub so anyone can use them.

In addition, Kakao, a leading domestic platform company, has also released its open source training materials for internal developers so that anyone can view them.

If training materials have not yet been created, using the open source training materials of these companies with excellent open source management practices is also a good option.

Assessment

Once a company has assigned personnel to each role, it must confirm that the assigned personnel are qualified to perform the role based on education, training, and experience. Training must also be provided to Program participants with insufficient competency so they can acquire sufficient competency. The company must also assess whether each participant has the necessary competency and retain the results.

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

When there are several hundred or more Program participants, making training difficult to provide, using the company’s online training and assessment system is also a good option.

Such content can be included in a company’s open source policy as follows.

4. Roles, Responsibilities, and Competencies
To ensure the effectiveness of this policy, the roles, responsibilities, and the
competencies required of the person in charge of each role are defined as follows.
The organization/person in charge of each role and the required competency level
are defined in "Appendix 1. Personnel Roster".

5. Training and Assessment
All members responsible for each role defined in Chapter 4 must complete the
open source training provided on the [Learning Portal].
Training records and assessment results are retained on the [Learning Portal]
for at least three years.

Having such a training and assessment system in place allows a company to prepare the following evidence materials required by ISO/IEC 5230.

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, it is advisable for the Open Source Program Manager to organize the requirements and precautions for common use cases of frequently used open source licenses and share them internally within the company.

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

For general guidance on open source licenses and summarized license obligation materials, the License Guide provided by the Korea Copyright Commission can be referenced.

The License Obligations document in SK telecom’s open source guide is also a good resource.

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

Providing such an open source license guide allows a company to prepare the following evidence materials required by ISO/IEC 5230.

Building the environment for training, assessment, and guide provision up to this point results in compliance with the ISO/IEC 5230 requirements as shown below.

2.8 - 8. Declaration of Conformance

A company that has built an open source program (open source policy / process / tools / organization) that complies with all requirements of the ISO/IEC 5230 specification except Clause 6 may prepare and publish a document stating the following two items.

1. That the company’s open source program meets all requirements of OpenChain Specification 2.1
2. That the company’s open source program guarantees it has maintained compliance with all requirements of OpenChain Specification 2.1 for at least 18 months after obtaining conformance certification

A company can either include the above content in its open source policy or publish it on a publicly available website.

As shown in the image below, you can refer to how SK telecom published this content on its open source portal site. https://sktelecom.github.io/compliance/iso5230/

By documenting in this way that all requirements of ISO/IEC 5230 are guaranteed to be met, a company can prepare the following evidence materials required by ISO/IEC 5230.

Once this is completed, a company finally meets all the requirements of ISO/IEC 5230.

2.9 - Appendix

2.9.1 - 1. Open Source Policy (Sample)

1. Purpose

(1) Purpose of the Policy_(3.1.3.1)

This policy provides the following principles for the correct use of open source software (hereinafter “Open Source”) by every organization at [Company Name], Inc. (hereinafter “the Company”) that is involved in software development, service delivery, and distribution.

1. Principles for carrying out compliance with open source licenses
2. Principles for contributing to external open source projects
3. Principles for releasing internal projects as open source

These principles give every member of the Company a way to understand the value of open source, use open source correctly, and contribute to open source communities.

All members of the Company can find the open source policy at the following link on the internal wiki: [internal_link]_(3.1.1.1)

(2) Impact of Non-Compliance

Failure to comply with this policy can result in the following situations.

• The Company receives demands from outside parties to comply with open source licenses.
• The Company is forced to release source code it did not intend to release.
• The Company faces legal action from open source copyright holders.
• The Company is fined for copyright infringement or breach of contract, or is ordered to stop selling a product.
• The Company’s reputation suffers.
• The Company breaches a contract with a supplier and faces a claim for damages.

For these reasons, the Company treats violations of this open source policy as serious, and members or organizations that violate it may be subject to disciplinary action.

(3) How Members Can Contribute

All members of the Company can contribute to the effectiveness of this policy and to raising the Company’s compliance level by understanding the rationale and content of this policy and faithfully carrying out the required activities.

2. Scope_(3.1.4.1)

This policy applies to the following three areas.

1. It applies to [all products the Company provides or distributes externally]. However, using open source solely for internal purposes is not within the scope of this policy.
2. It applies when a member contributes to an external open source project.
3. It applies when releasing internal code as open source.

The scope can be changed to fit the Company’s business environment, and the procedure for doing so is as follows.

1. If the open source program manager determines that a change in the policy’s scope is needed due to changes in the Company’s business environment, such as new business or organizational restructuring, they submit a proposal for this to the OSRB.
2. The OSRB approves an appropriate level of change to the scope.
3. The OSRB revises the open source policy to change the policy’s scope.

3. Terminology

• BOM (Bill of Materials)
• Software distribution participant: refers to any employee involved in the Company’s development, distribution, or contribution of software, including software developers, release engineers, and quality engineers.
• …

4. Roles, Responsibilities, and Competencies_(3.1.2.1)

To ensure the effectiveness of this policy, the following roles, responsibilities, and the competencies required of each role’s assignee are defined.

The organization/person responsible for each role and the required competency level are defined in [Appendix 1. Roster of Responsible Parties]._(3.1.2.2)

• The open source program manager periodically updates the roster to fit the Company’s business situation._(3.2.2.1)
• The head of the organization responsible for each role designates a person in charge within the organization and allocates appropriate time and budget so that person can carry out the role faithfully._(3.2.2.2)
  • If a person responsible for a role feels they are not receiving adequate support in carrying it out, they must raise the issue with the open source program manager.
  • The open source program manager discusses resolving the issue with the relevant head of organization. If it is not resolved appropriately, the open source program manager can ask the OSRB to help resolve the issue.
  • The OSRB shares the issue with the head of the higher-level organization and requests a resolution.

(1) OSRB

The OSRB (Open Source Review Board) is a body composed of the open source program manager and the heads of relevant organizations, including Legal, Patents, Development, and Infrastructure, formed for the Company’s open source compliance.

• It creates the policies and processes for open source compliance and defines the roles and responsibilities within the Company for carrying them out.
• When an open source compliance issue arises within the Company, it discusses solutions and prepares a response.
• When necessary, it reports issues to executive leadership and obtains feedback on risk mitigation measures.

(2) Open Source Program Manager

The open source program manager is overall responsible for the Company’s open source program. To ensure open source compliance for products and services that use open source, they are responsible for the following._(3.2.2.4)

• Define the roles needed for open source compliance and designate the responsible organization and person for each role. Consult with the OSRB as needed.
• Organize and evaluate open source compliance training.
• Chair the OSRB and direct its activities.
• Respond to inquiries and requests from outside parties about open source use and compliance.
• Review and approve requests to use open source.
• Maintain records of the open source BOM.
• Provide members with a way to obtain open source-related legal counsel._(3.2.2.3)
• Maintain a repository for open source notices and source code releases.

(3) OSPO

The OSPO (Open Source Program Office) supports and fosters the growth of open source activity both inside and outside the Company.

• Establishes, improves, and disseminates the open source policy.
• Provides guidance for contributing code to external open source projects.
• Provides guidance for releasing internal projects as open source.
• Develops and operates the open source portal.
• Develops and selects open source tooling.
• Sponsors open source project events.
• Manages relationships with open source communities.

(4) Legal

Legal provides counsel on the legal risks that can arise in the course of using open source, and on mitigation measures, including interpreting open source licenses and obligations.

• Provides counsel on license and intellectual property issues, including conflicts arising from incompatible open source licenses.
• Reviews the legal matters required for contributing to external open source projects, including the open source license and the CLA (Contributor License Agreement).

(5) IT Infrastructure

IT Infrastructure operates and automates open source analysis tooling, and builds the systems needed to ensure license analysis is carried out smoothly for all distributed software.

• Operates open source license analysis tooling.
• Integrates with the DevOps environment to automate license analysis.
• Builds the systems and processes needed to ensure license analysis is performed on all distributed software.
• Obtains and maintains the open source BOM for all distributed software.

(6) Security

Security operates open source security vulnerability analysis tooling and builds the systems needed to ensure security vulnerability analysis is carried out smoothly for all distributed software.

• Operates open source security vulnerability analysis tooling.
• Integrates with the DevSecOps environment to automate open source security vulnerability analysis.
• Builds the systems and processes needed to ensure open source security vulnerability analysis is performed on all distributed software.

(7) Developer Relations

Developer Relations supports in-house developers so they can actively use open source, participate in internal and external communities, and adopt leading development practices.

• Encourages participation in open source communities.
• Fosters a culture that recognizes active external open source project activity as an internal accomplishment.
• Builds a development culture that makes the Company attractive to open source developers.

(8) Quality

The organization responsible for quality, such as QA, confirms that open source license obligations were properly carried out when software is distributed.

• Confirms that open source compliance activities were carried out at each stage of the development process.
• Confirms that the artifacts required by the open source licenses were produced.
• Confirms that the open source notice and any source code to be released are provided together with the distributed software.
• Notifies the software development/distribution organization of any issues found so they can be corrected immediately.

5. Training and Assessment

Every software distribution participant must complete the mandatory open source training provided on the [Learning Portal] each year. This ensures they are familiar with the open source policy, the related training policy, and how to look it up. Training records are retained on the [Learning Portal]._(3.1.1.2)

Every member responsible for a role defined in Section 4 must complete the advanced open source training course provided on the [Learning Portal]. Training records and assessment results are retained on the [Learning Portal] for at least three years._(3.1.2.3)

6. Open Source Use

To develop and distribute products and services using open source, the obligations required by each open source license must be complied with. This activity is called open source compliance.

To carry out open source compliance correctly, the software development/distribution organization must comply with the following._(3.3.1.1)

• Every step of the open source compliance process is recorded and retained in the Jira Tracker.

(1) Identifying Open Source and Reviewing License Obligations

When introducing open source into product/service development, first identify what open source license applies, 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 separately explains the obligations required for each of the following distribution forms._(3.3.2.1)

• Binary form
• Source form
• Strong/weak copyleft
• SaaS-based delivery
• Whether modified
• Inclusion of open source requiring attribution, and so on.

The software development/distribution organization can refer to this guide when reviewing open source license obligations. If a review is needed for an open source license not covered in this guide, contact the open source program manager.

(2) Designing with Open Source Licenses in Mind

Identify the combination relationships of open source components and design the software architecture so that the Company’s own code is not affected by open source license terms.

The Company’s [Open Source License Guide] explains, for each open source license, the scope of source code disclosure it requires and design methods for preventing disclosure of the Company’s own code.

(3) Producing Open Source Compliance Artifacts

The most basic part of open source compliance activity is understanding the open source contained in distributed software. This is precisely so that the open source license requirements at the core of open source compliance can be correctly satisfied. In other words, a set of compliance artifacts must be produced for the open source contained in distributed software._(3.4.1.1)

Open source compliance artifacts fall into two broad categories.

1. Open source notice: a document providing the full text of each open source license and copyright information
2. Source code package to be released: a package assembling the source code to be released to fulfill the obligations of open source licenses that require source code disclosure, such as GPL and LGPL

To assemble, distribute, and store these compliance artifacts, the following must be complied with._(3.4.1.2)

• Assemble the open source notice and the source code package to be released according to the conditions each license requires. For example, if a license requires that the full text of the license be included, providing only a link is not sufficient.
• Store the assembled artifacts in a separate repository.
• When providing source code to be released through a Written Offer, publish a download link so that external parties can access the repository of assembled artifacts.

The Company’s open source compliance process can be used to issue the open source notice and assemble the source code package to be released.

(4) Producing the Open Source BOM (Bill of Materials)

The open source contained in distributed software (BOM: Bill of Materials) must be produced and maintained._(3.3.1.2)

The Company’s open source compliance process can be used to produce and retain the open source BOM using open source tooling.

(5) Compliance Issue Remediation Procedure

When a compliance issue is raised, the open source program manager performs the following procedure to respond promptly._(3.2.2.5)

1. Acknowledge receipt of the inquiry and specify an appropriate resolution time.
2. Confirm whether the issue content points to an actual problem. (If not, inform the person who raised the issue that it is not a problem.)
3. If it is an actual problem, determine priority and decide on an appropriate response.
4. Carry out the response, and if necessary, appropriately update the open source compliance process.
5. Retain the above content using the Jira Tracker.

7. Open Source Contribution

The Company encourages participation in and contribution to external open source projects to create business value from open source. However, approaching this without sufficient understanding of and strategy for the open source project ecosystem and how communities operate can lead to unintended exposure of the Company’s intellectual property or infringement of third-party rights. For this reason, when a member of the Company contributes to an external open source project, the following must be complied with._(3.5.1.1)

(1) Requesting Review and Approval

From a copyright standpoint, an open source contribution grants the open source project the right to modify, use, and distribute the contributed work. In some cases, it may even require assigning your copyright to the open source project. However, the copyright to a work created during a period of employment generally belongs to the employer. In other words, a work created by a Company member belongs to the Company. If a member contributes a work to open source on their own judgment, it can create unnecessary copyright infringement issues.

Therefore, if there is an open source project you wish to contribute to, follow the review request and approval procedure defined by the open source contribution process before making your first contribution.

However, for the following kinds of simple content, the copyright infringement risk is low, so members may contribute based on their own judgment without going through the review procedure.

• Small code snippets of 10 lines or fewer
• Questions and answers on Stack Overflow
• Administrative activity on GitHub, such as creating issues or reviewing/approving pull requests

(2) Contribute Only Code You Have the Right to Contribute

Contribute only code you have the right to contribute. That is, contribute code you wrote yourself. Do not contribute third-party code on your own judgment.

(3) Beware of Intellectual Property Exposure

Do not contribute code or documents that raise concerns about exposing the Company’s intellectual property, such as sensitive information or patents.

• If the code you wish to contribute includes a Company patent, you must confirm whether it is acceptable to contribute that patent to the project under an open source license. If anything is unclear, contact the OSPO.

(4) Caution with CLA Signatures

Some open source projects require every contributor to sign a CLA (Contributor License Agreement). This is an agreement used to obtain contributors’ consent in order to reduce copyright disputes that can arise as a project manages the works of many contributors. Projects led by large corporations commonly require a CLA signature.

CLAs vary by project, but they generally include agreement to the following.

• I (or my employer) have the right to contribute the contribution I intend to contribute to the project. (That is, I am the author of this contribution.)
• I (or my employer) grant the project the right to modify, distribute, and manage my contribution.
• I (or my employer) will not revoke the granted rights.
• I (or my employer) grant the project the right to change its license in the future as needed.

In addition, though rare, some CLAs also require agreement to the following condition.

• I (or my employer), upon contributing my contribution, simultaneously assign my copyright in it to the project or the organization managing the project.

To protect its own intellectual property, the Company does not permit contributions to open source projects that require copyright assignment. To make this determination, a Company member must request a review from the OSPO before signing, if the open source project they wish to contribute to requires a CLA signature.

(5) Copyright Notice

The intellectual property of a work created by a member during their employment generally belongs to the Company. Accordingly, when a member contributes code to an external open source project, they must indicate the Company’s copyright.

When contributing one or more files, indicate the copyright and license at the top of the file as follows.

Copyright (c) {$year} {$Company}
SPDX-License-Identifier: {$SPDX_license_name}

Here, $SPDX_license_name is written according to the license policy of the relevant open source project.

However, if you are only modifying existing code, such as for a bug fix, there is no need to add a copyright notice for that code change.

(6) Use of Company Email

Do not use a personal email address when contributing to open source projects; use your Company email address. This (1) gives members a sense of responsibility as they communicate with the community on the Company’s behalf, and (2) helps improve the Company’s recognition as one that actively contributes to open source communities.

8. Open Source Release

The Company respects the value of collaboration with open source communities and encourages releasing internal software as open source projects. However, there are some rules that must be followed to protect the Company’s intellectual property and prevent unintended copyright infringement.

(1) Approval

From a copyright standpoint, an open source release grants anyone the right to modify, use, and distribute the work through an open source license. The copyright to a work created during a period of employment generally belongs to the employer. In other words, a work created by a Company member belongs to the Company. If a member releases a work as open source on their own judgment, it can create unnecessary copyright infringement issues.

Therefore, if you wish to release software as open source, follow the review request and approval procedure under the Company’s open source release policy.

If anything about the release process seems questionable, do not hesitate to contact the OSPO.

(2) Release Only Code You Have the Right to Release

One of the worst situations that can arise in an open source project is the inclusion of legally problematic code in the project. Code the Company does not have the right to distribute, or code that infringes another company’s IP such as a patent, can create legal problems. Therefore, when preparing code for release, verify the origin of all code and remove any code that raises concerns.

(3) Beware of Intellectual Property Exposure

Do not release code or documents that raise concerns about exposing the company’s intellectual property, such as sensitive information or patents.

If the code you wish to release includes a Company patent, confirm whether it is acceptable to release that patent under an open source license. If anything is unclear, contact the OSPO.

(4) Release Useful Code

For a project to succeed, it must also be useful to others. If a similar project already exists, participate in the existing project rather than creating a new one.

The open source you plan to release should be expected to (1) provide differentiated value to the open source community, (2) solve a problem the community has not yet solved, and (3) draw positive attention by showcasing our technical capability.

• Do not release code as open source if it has not been used in an actual product or service.
• Do not release code that addresses a problem the open source community has already solved. In such cases, contribute to the existing open source project instead.

(5) Securing Resources

Secure the resources, including developers, that need to be committed to the project.

• Initially, a level of developer effort similar to a typical internal project is needed.
• Developers are needed who can quickly review external contributions.
• Roles from Legal and Marketing are also needed.
• Secure budget for the infrastructure required to maintain and manage the project. This includes tools for project hosting, such as GitHub.

If an environment with sufficient resource support cannot be created, do not release the software as open source.

(6) Use of Company Email

Do not use a personal email address for open source release activity; use your Company email address. This (1) gives members a sense of responsibility as they communicate with the community on the Company’s behalf, and (2) helps improve the Company’s recognition as a company that actively releases open source.

9. Responding to External Inquiries

(1) Responsibility for Responding to External Inquiries

The open source program manager is responsible for responding to inquiries and requests about open source compliance from outside the Company._(3.2.1.2)

• The open source program manager can assign all or part of the handling of an inquiry to an appropriate person within the Company. If necessary, the legal team is consulted for handling.
• Anyone who receives an external inquiry about open source compliance should notify the open source program manager so that a prompt response can be made.

(2) Publishing Contact Information

The open source program manager publicly provides the contact information of the responsible person so that external parties can make open source-related inquiries and requests._(3.2.1.1)

• Provide contact email address information in the open source notice.
• Register contact information in the Linux Foundation’s Open Compliance Directory.

(3) Procedure for Responding to External Inquiries

Responding quickly and accurately to external open source compliance inquiries can greatly reduce the risk of escalation to litigation. To this end, the Company complies with the external inquiry response procedure defined in the Company’s open source compliance process to respond to external open source compliance inquiries._(3.2.1.2)

10. OpenChain

The Company supports the spirit of the Linux Foundation’s OpenChain project and actively participates in it to raise the level of open source compliance across the software supply chain.

• By applying this open source policy, the Company ensures compliance with ISO/IEC 5230:2020 as of October 1, 2021._(3.6.1.1)
• The Company ensures that, for at least 18 months after obtaining conformance certification, it satisfies all requirements of OpenChain Specification version 2.1 and ISO/IEC 5230:2020._(3.6.2.1)
• The Company reviews conformance at intervals of at least 18 months and revises and updates the policy as needed.

Appendix 1. Roster of Responsible Parties

2.9.2 - 2. Open Source Compliance Process (Sample)

OOO Corporation (hereinafter “the Company”) actively utilizes open source software (hereinafter “open source”) while developing products and services that include software. The Company must carry out activities to comply with the obligations imposed by open source licenses when distributing software, and this is called open source compliance.

1. Process for Software Product Development/Distribution

The open source compliance process defines the procedures that must be performed to comply with open source license obligations at each development stage as the Company develops and distributes software products and services. All members involved in software product development/distribution comply with the following 10 steps of the open source compliance process.

1. Identification of Open Source_{Identification of Open Source}

The development department complies with the following during the software design stage.

• While designing the software, identify the anticipated open source usage status and check the licenses.
• Check the obligations for each open source license. License-specific obligations can be found in the Company’s open source license guide.
• 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 development departments across the company can reference it.

The development department marks copyright and license notices in the source code in accordance with company rules. The Company’s rules for copyright and license notation within source code can be found on the following page. : (insert_link)

When reviewing the adoption of new open source, the development department 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, the department inquires with the Open Source Program Manager about whether adoption is possible and any precautions. The inquiry is made by creating a Jira Ticket.

The Open Source Program Manager analyzes the open source license obligations and guides the software development organization accordingly.

• If there are questions, advice is requested from the legal officer to provide clear guidance.
• Newly analyzed license information is reflected in the company-wide license guide.

2. Auditing Source Code_{Auditing Source Code}

The development department provides the source code according to the infrastructure officer’s guidance and requests an open source check.

The infrastructure officer performs the open source check using an open source analysis tool and generates the open source BOM.

The Open Source Program Manager reviews whether the open source license obligations can be met and whether there are open source license conflicts, and if there are issues, requests the development department to resolve them. Issues are created as Jira Tickets and assigned to the development department.

3. Resolving Issues_{Resolving Issues}

The development department resolves all issues found during the source code auditing stage. It takes actions such as removing the problematic open source or replacing it with open source under a different license.

Once the development department resolves all identified issues, it resolves the Jira Ticket issue and requests a re-review.

4. Reviews_Reviews

The Open Source Program Manager reviews whether all issues have been properly addressed. If necessary, the source code audit is performed again using the open source analysis tool.

5. Approval_Approval

The Open Source Program Manager gives final approval or rejection of whether the open source compliance procedure was properly performed. In case of rejection, an explanation of the reason and a suggested method of correction are proposed to the development department.

6. Registration_Registration

The Open Source Program Manager finalizes the BOM for tracking the list of open source used in each version of the software.

The infrastructure officer registers the finalized BOM in the system. The BOM includes the list of open source contained in the Supplied Software and the following information.

• The name and version of the product (or service) of the Supplied Software
• List of open source
  • Open source name / version
  • Open source license

7. Notices_Notices

The Open Source Program Manager generates an open source notice to comply with the notice obligation. The open source notice includes the following items.

• 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 generates the open source notice and delivers it to the development department. If source code disclosure is required at this time, the department guides the development department on how to collect the source code to be disclosed.

The development department encloses the open source notice when distributing the product. For products with a screen, measures are taken so users can check it through a menu. (e.g., App > Menu > Settings > Copyright Information > Open Source Licenses)

If the development department has used open source under a license that requires source code disclosure, such as GPL or LGPL, it checks the scope of source code disclosure and collects the source code to be disclosed.

• The source code collected to comply with license obligations such as GPL and LGPL must match the source code that composes the binary installed on the product. That is, building the collected source code must produce the same binary as the one installed on the product.

8. Pre-Distribution Verifications_{Pre-Distribution Verifications}

The development department submits the following artifacts to demonstrate that open source 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 screen capture image 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 development department to confirm there are no issues.

9. Distribution_Distribution

The Open Source Program Manager submits the compliance artifacts submitted by the development department to the infrastructure officer.

The infrastructure officer registers the compliance artifacts on the Company’s open source distribution site.

10. Final Verifications_{Final Verifications}

The Open Source Program Manager conducts a comprehensive check, including whether the compliance artifacts were properly registered on the Company’s open source portal without issues and whether they can be downloaded externally without problems.

2. External Inquiry Response Process

Responding quickly and accurately to external open source compliance inquiries can greatly reduce the risk of escalation to litigation. To this end, the Company complies with the following process to respond to external open source compliance inquiries.

1. Acknowledge_Acknowledge

Upon receiving an inquiry, the Open Source Program Manager immediately notifies the requester that the inquiry has been received. At this time, the expected date of action is also communicated. Since it is important to accurately understand the requester’s intent, additional clarification is requested if the inquiry is unclear.

The main types of inquiries and requests that require a response are as follows.

• Inquiries about whether open source is used in a specific product or service
• Requests for source code under a GPL or LGPL license mentioned in a Written Offer
• Requests for explanation and source code disclosure for open source found in a product but not specified in the open source notice
• Requests to provide files missing from source code disclosed under GPL, LGPL, and similar obligations, and how to build it
• Requests for copyright attribution

The Open Source Program Manager creates a Jira Issue for the received request and records all response activities in detail.

2. Inform_Inform

The Open Source Program Manager informs the requester that the Company is faithfully performing open source compliance and is investigating the requester’s inquiry. It is advisable to notify the requester whenever there is an update to the progress of the internal investigation.

3. Investigate_Investigate

The Open Source Program Manager conducts an internal investigation of the request. Whether the compliance process was properly performed for the version of the product in question is confirmed through the BOM and documented review history. Advice is requested from the legal officer if needed.

If confirmation is needed from a specific development department, the Open Source Program Manager requests the development department to investigate. The development department that receives the investigation request immediately checks whether there is a problem with the compliance artifacts and reports the results to the Open Source Program Manager.

4. Report_Report

The open source compliance officer completes the internal investigation within the expected action date and notifies the requester of the results.

• If the requester’s inquiry was a mistaken claim due to a misunderstanding, the requester is notified of this without further action, and the case is closed.
• If the issue is confirmed, the requester is informed of the exact method and timing for fulfilling the obligations of the relevant open source license.

5. Rectify_Rectify

If an actual compliance problem is found during the internal investigation, the relevant development department performs all procedures necessary to resolve the compliance issue.

6. Report_Report

After the problem is resolved, the requester is notified immediately, and the best available method to confirm the resolution is provided.

7. Improve_Improve

When a compliance problem occurred, the case is reviewed at an OSRB meeting, the circumstances leading to the problem are identified, and the process is improved to prevent recurrence.

2.9.3 - 3. Tools (FOSSology, SW360)

Open source compliance activities require not only policies, processes, and training materials, but also a variety of tools and systems for source code scanning, dependency analysis, and open source Bill of Materials management. As a result, many companies are investing significant resources in adopting and operating these tools and systems. Companies that are just starting open source compliance face difficulties not only with process but also with cost.

To address these difficulties, in June 2019, the OpenChain Tooling Work Group was launched, led by open source compliance tool experts from companies participating in the OpenChain project, including Siemens, Bosch, Toshiba, Fujitsu, and Hitachi.

The OpenChain Tooling Work Group was formed so that open source experts from various companies could work together to solve issues and share results, reducing open source compliance costs and producing high-quality compliance outcomes.

Specifically, it aims to build a turn-key open source tool chain by leveraging existing open source projects such as FOSSology, SW360, Software Heritage, ClearlyDefined, and SPDX, and to make this freely available to all companies. (https://groups.io/g/oss-based-compliance-tooling)

This section introduces FOSSology and SW360 and provides a brief guide on how to use them.

2.9.3.1 - FOSSology

For open source compliance, a source code scanning tool can be used to detect the open source and license information contained within software.

The Linux Foundation’s FOSSology project is a tool that develops this kind of scanning tool and has released it as open source so that anyone can use it freely.

Key Features

FOSSology is a web-based program that allows users to log in to the website and upload individual files or software packages. FOSSology detects license text and copyright information within the uploaded files. It is a good idea for developers to use FOSSology when they want to check the license and copyright information of the open source they intend to use. FOSSology scans all files within the open source package uploaded by the developer, automatically detects license-related text and copyright information in each file, and generates this as a report. 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, a FOSSology server must be built in-house. To do this, FOSSology must be installed on a Linux-based server system. FOSSology can be installed using the following three methods.

1. Using Docker
2. Using Vagrant and VirtualBox
3. Installing via a source build

Here, the simplest method, using Docker, is explained.

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 using 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 to install FOSSology, the test server provided by the FOSSology Project can be used. The FOSSology project provides an environment for testing. (The test server may be discontinued 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 the open source’s 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 is complete, the analysis is automatically performed by the Job Agent.
• The status of the analysis in progress can be checked at menu > Jobs > My Recent Jobs.

• Once the analysis is complete, the results can be checked at menu > Browse.

• Selecting an individual file allows you to check the license-related text detected by FOSSology.

• menu > Browser > select a file or directory > Copyright/Email/Url/Author shows the Copyright/Email/Url/Author information detected by FOSSology.

After checking whether the results analyzed in this way by FOSSology are valid, users can exclude incorrectly detected items from the analysis results. FOSSology describes this as the Clearing process, and for more details, refer to the following page: https://www.fossology.org/get-started/basic-workflow/

In this way, you can easily check what the license of the open source you want to use is and what the copyright information looks like.

2.9.3.2 - SW360

A company that develops and distributes products containing open source must collect and track information such as the version and license of the open source used in each product and each release version. This allows the company to carry out proper open source compliance activities.

In particular, when a security vulnerability is reported in the NVD (https://nvd.nist.gov/vuln) for a specific open source version, if a company cannot trace which products use that version, it has no way of knowing which products need the security patch, leaving those products exposed to the security vulnerability.

For this reason, tracking open source information is essential. Companies build their own systems for this or purchase commercial services. SW360 is an open source project sponsored by the Eclipse Foundation that provides a web application and repository for collecting and tracking software BOM information.

Key Features

SW360 provides a web-based UI, and its key features 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 of the following.

• 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/blob/master/README.md

SW360 offers the following three installation methods. Users can choose whichever one suits them.

1. Vagrant (https://www.vagrantup.com/)-based 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
2. The components of SW360 can be installed individually. : https://github.com/eclipse/sw360
3. It can be deployed via Docker. : https://github.com/sw360/sw360chores

Here, we introduce how to install and deploy SW360 on a CentOS 7.6 system using the Vagrant-based method. For more detail, refer to the README. : https://github.com/sw360/sw360vagrant/blob/master/README.md

1) Prerequisites

To install SW360 on a Vagrant box, you must first install openjdk, VirtualBox, and Vagrant. First, install openjdk 1.8.0.

$ yum install java-1.8.0-openjdk
$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)"
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Install VirtualBox.

$ sudo wget https://download.virtualbox.org/virtualbox/rpm/el/virtualbox.repo -P /etc/yum.repos.d
$ sudo yum install VirtualBox-5.2

If, when installing VirtualBox on CentOS 7, you get a “kernel module is not loaded” error, resolve it by installing kernel-devel and then reinstalling VirtualBox.

$ sudo yum install https://centos7.iuscommunity.org/ius-release.rpm
$ sudo yum install dkms
$ sudo yum install kernel-devel
# reboot
$ sudo /sbin/vboxconfig
$ systemctl status vboxdrv
● vboxdrv.service - VirtualBox Linux kernel module
   Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2020-02-19 09:06:02 KST; 20min ago

Install Vagrant and the vagrant-aws plugin.

$ sudo yum install https://releases.hashicorp.com/vagrant/2.2.6/vagrant_2.2.6_x86_64.rpm 
# install the vagrant-aws plugin
$ vagrant plugin install vagrant-aws

Then, clone the sw360vagrant code.

$ git clone https://github.com/sw360/sw360vagrant.git

2) Downloading Dependencies

To reduce the time it takes to build the Vagrant box, download the dependency packages in advance.

$ cd sw360vagrant
$ ./download-packages.sh

The following packages are then downloaded into the ./shared/package folder.

• Liferay 7.2.1 CE GA2 with Tomcat (9.0.17)
• Postgresql-42.2.9 ODBC client for Java as *.jar file
• 11 *.jar files required by SW360
• Thrift 0.11
• A box images from the Ubuntu 16.04 LTS (xenial-server-cloudimg-amd64-vagrant.box)

3) Creating the Base Box

Now, create the base box with the following commands.

$ cd generate-box
$ ./generate_box.sh

This step can take several tens of minutes.

4) Running the Box

Run the box with the following commands.

# If you have built a vagrant box from this directory earlier, you will have to destroy it first via
$ vagrant destroy
$ cd ../sw360-single
$ vagrant up

Running the box configures Liferay, PostgreSQL, and CouchDB. If it runs without issue, you can access the Liferay screen at https://localhost:8443/.

5) Deploying the SW360 Layout

The final step is deploying the SW360 layout on Liferay. This step is not yet automated, so an administrator must perform it manually. Access https://localhost:8443/ and log in with the following account.

• id : setup@sw360.org
• pw : sw360fossy

After that, follow the instructions on the following site to deploy the layout. https://github.com/eclipse/sw360/wiki/Deploy-Liferay7

Once the deployment is complete, you will see a screen like the following.

Basic Workflow

1) Registering Licenses

The first time you install SW360, you must register the open source licenses you commonly use. 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 this way can be quite tedious, but fortunately SW360 provides a feature to import the entire SPDX License List at once. Click Menu > Admin < Import SPDX Information.

The SPDX License List is then registered automatically. You can confirm that 338 licenses have been registered under Menu > Licenses.

2) Registering Components and Releases

In SW360, a Component is a single unit of software. It can correspond to various kinds of software, including the following.

• 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 a unit that points to a single version of a Component. A single Component can therefore have multiple Releases. A Release is created and managed under a 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, to register zlib-1.2.8, you would first register zlib as a Component, and 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 have created the Component, you can register information for the zlib-1.2.8 version at Components > Releases > Add Release.

After registering versions 1.2.8 and 1.2.11 as separate Releases under the single Component zlib, the Release Overview screen shows the following two Releases.

SW360 also provides a feature for importing information for multiple Components at once. You can enter the Component information you want to register into the CSV template under Menu > Admin > Import / Export and 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 could be a product, a service, or software. A Project registers and manages 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.

After creating a Project, register the Releases or sub-Projects it includes. Selecting the Project under 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 under a Project called SuperCalc.

4. Security Vulnerability Management

SW360 can automatically check whether a registered Release has a security vulnerability. To do this, SW360 provides a feature for scheduling periodic collection of CVE information. Under Menu > Admin > Schedule, you can set up a schedule to collect CVE SEARCH information every 24 hours.

With this schedule set, SW360 collects CVE information at the scheduled time from the CVE Search site (https://cve.circl.lu/). The collected CVE information can be viewed under Menu > Vulnerabilities.

Once Vulnerabilities information has been collected, you can check whether a created Project has any security vulnerabilities. In the SuperCalc Project created above, you can see that 85 security vulnerabilities have been reported.

By registering and managing the software a company develops and distributes in SW360 this way, it becomes possible to manage not only open source compliance but also security vulnerability risk in a way that minimizes it.

SW360 also exposes most of its features as a REST API in addition to the web interface above, making it possible to integrate with other tools such as FOSSology. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

In other words, by importing the analysis results of a source code scanning tool into SW360 and integrating it into DevOps to automate the registration of Projects and Releases, efficiency can be increased significantly.

3 - Open Source Security Assurance: A Guide to Enterprise Adoption and Certification of ISO/IEC 18974

Open Source Security Assurance: A Guide to Enterprise Adoption and Certification of ISO/IEC 18974 provides guidance for the safe use of open source software (OSS), which has become an essential element in modern software development environments. This guide presents effective solutions to the security concerns that have grown more pressing alongside the increasing use of open source software, and details the step-by-step procedures and key strategies for obtaining certification to the international standard ISO/IEC 18974.

The main objectives of this guide are as follows.

1. Understanding the ISO/IEC 18974 standard: Clearly explains the core requirements and implementation methods of ISO/IEC 18974 so that organizations can effectively build an open source security management system.
2. Presenting tailored strategies by organizational characteristics: Provides customized approaches so that organizations of various sizes and characteristics — large enterprises, small and medium-sized enterprises, and startups — can successfully implement ISO/IEC 18974.
3. Providing practical guidelines and templates: Offers concrete guidelines and templates needed at each stage — policy development, SBOM (Software Bill of Materials) management, vulnerability response, and more — to support practical application.
4. Sharing success stories and lessons learned: Analyzes the cases of companies that have successfully obtained ISO/IEC 18974 certification and shares the factors behind their successes and failures, helping organizations reduce trial and error and obtain certification efficiently.

The primary intended readers of this guide are as follows.

• Open source software security managers
• Software developers and engineers
• Chief Information Security Officers (CISOs) and IT managers
• Legal and compliance officers
• Open Source Program Office (OSPO) staff

Through this guide, readers will be able to effectively understand the ISO/IEC 18974 standard, strengthen their organization’s open source security management capabilities, and further contribute to building a safe and trustworthy software development ecosystem.

References

This guide was written with reference to the following materials.

1. ISO/IEC 18974:2023, Information technology - Open source supply chain security assurance
2. ISO/IEC 5230:2020, Information technology - OpenChain Specification
3. The Linux Foundation, OpenChain Project: https://www.openchainproject.org/
4. National Institute of Standards and Technology (NIST), National Vulnerability Database (NVD): https://nvd.nist.gov/
5. Common Vulnerabilities and Exposures (CVE): https://cve.mitre.org/
6. OWASP (Open Web Application Security Project): https://owasp.org/
7. PwC, Understanding the open source security ISO 18974: https://www.pwc.de/en/digitale-transformation/open-source-software-management-and-compliance/understanding-the-open-source-security-iso-18974.html
8. The Momentum, Integrating DevSecOps: A Guide to Development, Security and Operations: https://www.themomentum.ai/blog/integrating-devsecops-a-guide-to-development-security-and-operations
9. Enterprise Networking Planet, Integrating IT Security With DevSecOps Best Practices: https://www.enterprisenetworkingplanet.com/management/integrating-it-security-with-devsecops-best-practices/
10. Synopsys, What is Software Composition Analysis?: https://www.synopsys.com/glossary/what-is-software-composition-analysis.html
11. GuideM, DORA vs. ISO 27001: https://www.guidem.com/en/dora-vs-iso-27001/
12. Overseas Information Security Trends, Policy Trends in Strengthening Cyber Resilience Among Major Countries: https://www.kisa.or.kr/cmm/fms/FileDown.do?atchFileId=FILE_0000000000024149&fileSn=1

3.1 - 1. Why Does Open Source Security Matter?

This chapter introduces the concepts of open source software and security assurance, and explains the background, purpose, importance, and certification benefits of the ISO/IEC 18974 standard.

1.1 The Concepts of Open Source Software and Security Assurance

Open source software (OSS, Open Source Software) refers to software whose source code is published, allowing anyone to freely use, modify, and distribute it. This offers the advantages of transparency, collaboration, and innovation, but it also carries security risks.

Characteristics of Open Source Software

• Published source code
• Free use, modification, and distribution
• Community-based development
• Cost efficiency

Table 1.1: Advantages and Disadvantages of Open Source Software

Open source has become an essential element in modern software development. Many companies use open source components rather than developing everything in-house, reducing development time and cost. However, this has introduced new risks into the software supply chain.

The main security risks arising from the use of open source are as follows.

1. Known vulnerabilities (CVE, Common Vulnerabilities and Exposures): Systems can be exposed to attacks that exploit publicly disclosed vulnerabilities registered in databases such as CVE.
   • Example: The Log4Shell vulnerability (CVE-2021-44228), which occurred in 2021, was found in Apache Log4j, a widely used open source logging library, and had a serious impact on countless systems worldwide. This vulnerability allowed attackers to execute remote code.
2. Insertion of malicious code: If malicious code is inserted into an open source repository, systems that download and use it can become infected.
3. Legal problems from license violations: Failing to comply with open source license terms can lead to legal disputes such as copyright infringement.
4. Use of unsupported components: Open source components that are no longer maintained make it difficult to respond to new vulnerabilities, increasing security risk.

‘Security assurance’ is needed to manage these risks. Security assurance is the process of confirming that software operates safely as intended and is free of known vulnerabilities or malicious code. This is essential for risk mitigation, building trust, and regulatory compliance.

1.2 Background and Objectives of the ISO/IEC 18974 Standard

ISO/IEC 18974 is the international standard for open source security assurance. This standard originated in the Linux Foundation’s OpenChain project and defines the core requirements for managing the security of open source software.

The background to the development of the ISO/IEC 18974 standard is as follows.

• Growing use of open source and the resulting security risk: As the use of open source increases, attempts to exploit security vulnerabilities are also increasing.
• Rise in software supply chain attacks: Cases such as SolarWinds and Log4Shell, which caused large-scale damage by attacking the software supply chain, are increasing.
• Recognition among companies of the need for systematic open source security management: Companies are recognizing the security risks that come with using open source and feel the need to build a systematic management system.

The main objectives of the ISO/IEC 18974 standard are as follows.

1. Providing a standardized framework for open source security management: Supports organizations in building consistent processes and procedures for open source security management.
2. Improving an organization’s open source security processes: Provides criteria by which an organization can assess and improve its own level of open source security management.
3. Strengthening the overall security of the software supply chain: Encourages all participants in the supply chain to comply with open source security requirements, raising the overall level of security.

1.3 The Purpose and Importance of ISO/IEC 18974

The main purpose of ISO/IEC 18974 is to enable organizations to build a system for effectively managing known security vulnerabilities in open source software. This standard identifies the following core areas.

1. The key points at which security processes are needed
2. How roles and responsibilities are assigned
3. How the sustainability of the process is ensured

In the global software industry, ISO/IEC 18974 serves as a benchmark for open source security management. It provides companies with a tool to objectively assess and improve their open source management capabilities.

Compliance with the standard has a positive effect on an organization’s sustainability.

• Cost savings from fewer security incidents: Managing vulnerabilities proactively reduces the likelihood of security incidents and lowers recovery costs when incidents do occur.
• Improved customer trust: Demonstrating the ability to develop and deliver safe software builds customer trust.
• Easier regulatory compliance: Helps organizations comply with privacy regulations such as GDPR and CCPA.
• Competitive advantage: Meets the requirements of security-conscious customers, providing an edge over competitors.

1.4 Benefits of ISO/IEC 18974 Certification

Through ISO/IEC 18974 certification, companies can obtain the following benefits.

1. Building a systematic open source management system
   • Establishing consistent security policies and processes
   • Systematic identification, tracking, and control of open source components
   • Building a process for generating and managing an SBOM (Software Bill of Materials)
2. Improved supply chain trust
   • Strengthened trust relationships with partners and customers
   • Business stability secured through reduced security risk
   • Objective criteria for evaluating suppliers
3. Recognition of open source management capability
   • Demonstrating open source management capability at a global level
   • Enhanced corporate image and brand value
   • Creation of new business opportunities
4. Reduced legal liability
   • Compliance with license obligations and prevention of infringement
   • Reduced litigation risk
   • Easier regulatory compliance (e.g., DORA, EU Cyber Resilience Act)

Summary

ISO/IEC 18974 underscores the importance of open source security management and provides companies with a framework for carrying it out systematically. By complying with this standard, companies can make full use of the benefits of open source while effectively managing the associated risks.

3.2 - 2. Key Requirements of ISO/IEC 18974

ISO/IEC 18974 defines the key requirements for open source software security assurance. This standard provides the guidance organizations need to build a framework for effectively managing known security vulnerabilities in open source software. For details on each requirement, refer to the appendix.

2.1 Program Foundation

This section defines the fundamental requirements for policy, competence, awareness, resources, and measurement for an open source security assurance program. The program foundation provides the basis for an organization to effectively implement and continually maintain ISO/IEC 18974.

2.1.1 Policy

The organization shall establish a documented policy that governs open source software security assurance of supplied software. This policy shall be shared with all relevant parties within the organization, and the policy and its method of communication shall undergo a review process to ensure they remain current and relevant.

Table 2.1: Policy Requirement and Verification Materials

Considerations for Establishing the Policy

• Scope: Clearly define the scope of open source software to which the policy applies (e.g., all internally developed projects, external supply chains, etc.).
• Roles and Responsibilities: Clearly define the responsibilities of all roles involved in open source security management (e.g., developers, security team, legal team, management).
• Process: Provide guidance on key processes such as open source use approval, SBOM (Software Bill of Materials) management, vulnerability management, and license compliance.
• Compliance: Specify the monitoring and audit procedures for policy compliance.
• Exceptions: Define the procedure for handling exceptions to the policy.

2.1.2 Competence

The organization shall identify the roles and responsibilities that affect the performance and effectiveness of the program, and determine the competence required of program participants who fulfill each role. It shall also ensure that program participants have appropriate education, training, and/or experience.

Table 2.2: Competence Requirement and Verification Materials

Considerations for Building Competence

• Role Definition: Define all roles related to open source security management (e.g., open source lead, developers, security engineers), and clarify the technical and legal knowledge required for each role.
• Education and Training: Provide education and training programs to build the competence required for each role. For example, secure coding training for developers, open source license training for the legal team, and the like.
• Experience: Support the accumulation of open source security management experience through participation in actual projects. Encourage the sharing of experience through mentoring programs, code reviews, and similar activities.
• Assessment: Conduct regular competence assessments to gauge the level of program participants and address any gaps.

2.1.3 Awareness

The organization shall ensure that program participants are aware of the open source software security assurance policy, relevant program objectives, their contribution to the effectiveness of the program, and the implications of not following the program’s requirements.

Table 2.3: Awareness Requirement and Verification Materials

Activities to Raise Awareness

• Regular Training: Conduct regular training on open source security policy and related processes.
• Communication: Share open source security information and announce the latest threats and vulnerabilities through internal bulletin boards, newsletters, email, and similar channels.
• Encouraging Participation: Encourage participation in open source security workshops, conferences, and study groups.
• Recognition: Establish a recognition program for employees who contribute to open source security.

2.1.4 Resources

The organization shall provide the resources needed for the establishment, implementation, maintenance, and improvement of the open source security assurance program. These resources include human resources, technical resources, and financial resources.

Table 2.4: Resources Requirement and Verification Materials

Considerations for Providing Resources

• Human Resources: Secure the necessary personnel, such as open source security experts, developers, and legal experts, and provide appropriate education and training suited to each role.
• Technical Resources: Introduce and maintain the necessary technical tools, such as SBOM generation tools, vulnerability scanners, and license checking tools.
• Financial Resources: Secure the budget needed to operate the program and allocate it appropriately.

2.1.5 Measurement

The organization shall establish metrics for measuring the effectiveness of the open source security assurance program, and measure and analyze them regularly. The measurement results shall be used to improve the program.

Table 2.5: Measurement Requirement and Verification Materials

Considerations for Measurement

• Metric Selection: Select appropriate metrics related to the program’s objectives (e.g., vulnerability resolution time, SBOM accuracy, policy compliance rate).
• Data Collection: Regularly collect data for the selected metrics.
• Result Analysis: Analyze the collected data to evaluate the effectiveness of the program and identify areas that need improvement.

2.2 Relevant Tasks Defined and Supported

This section covers the requirements for defining and supporting the relevant tasks needed to effectively operate the open source security assurance program. The organization shall clearly define and support the relevant tasks so that the program’s purpose is achieved and participants can access the information and tools they need.

2.2.1 Access

The organization shall identify internal and external issues that are relevant to the purpose of the program and that affect its ability to achieve that purpose. It shall also ensure that program participants can access the information and tools needed to meet the program requirements.

Table 2.6: Access Requirement and Verification Materials

Considerations for Ensuring Access

• Identifying Internal Issues: Identify factors within the organization, such as policies, processes, technology, and personnel, that may affect the program.
  • Examples: “Absence of a clear policy on open source use,” “Shortage of security team staff,” “Inadequate SBOM generation tools,” and the like.
• Identifying External Issues: Analyze how changes in the external environment, such as laws, regulations, industry trends, and the competitive landscape, may affect the program.
  • Examples: “Emergence of new open source licenses,” “Increase in software supply chain attacks,” “Strengthening of privacy regulations,” and the like.
• Information Sharing: Build an information-sharing system so that program participants can easily access the information they need (e.g., open source security policy, SBOM (Software Bill of Materials), vulnerability information).
  • Examples: Use internal wikis, collaboration tools, and knowledge management systems to improve access to information.
• Providing Tools: Provide the tools program participants need to perform their work effectively (e.g., SBOM generation tools, vulnerability scanners, license checking tools).
  • Examples: Provide the development team with open source analysis tools integrated into the IDE (Integrated Development Environment), and provide the security team with specialized vulnerability scanning tools.

2.2.2 Effectively Resourced

The organization shall determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the program. These resources include human resources, technical resources, and financial resources.

Table 2.7: Effectively Resourced Requirement and Verification Materials

Considerations for Resource Allocation

• Human Resources: Secure the personnel needed to operate the program and provide appropriate education and training suited to each role.
  • Examples: Hiring open source security experts, running security training programs for developers.
• Technical Resources: Introduce and maintain the necessary technical tools, such as SBOM generation tools, vulnerability scanners, and license checking tools.
  • Examples: Introducing a cloud-based SBOM management system, building automated vulnerability scanning tools.
• Financial Resources: Secure the budget needed to operate the program and allocate it appropriately.
  • Examples: Securing a budget for purchasing open source security tools, securing a budget for running training programs.
• Process: Document the resource allocation process and review it regularly to improve efficiency.
  • Examples: When establishing the annual budget plan, allocate a separate budget for open source security and manage the execution details.

2.3 Open Source Software Content Review and Approval

This section covers the requirements for the review and approval process an organization needs to safely use open source software. An effective review and approval process allows an organization to identify and manage security vulnerabilities, license violations, and other risks in advance.

2.3.1 SBOM (Software Bill of Materials)

The organization shall establish a process for creating and managing a Software Bill of Materials (SBOM) that includes each open source component (and its identified licenses) comprising the supplied software. The SBOM ensures transparency of software components and facilitates vulnerability management and license compliance.

Table 2.8: SBOM (Software Bill of Materials) Requirement and Verification Materials

Considerations for SBOM Management

• SBOM Generation Tools: Select and introduce appropriate tools to automate SBOM generation (e.g., SPDX Tools, CycloneDX, Syft).
• SBOM Format: Use a standardized SBOM format (e.g., SPDX, CycloneDX) to ensure interoperability.
• SBOM Content: Define the essential information that must be included in the SBOM (e.g., component name, version, license, origin).
• SBOM Updates: Build a process to update the SBOM whenever software components change.
• SBOM Storage and Sharing: Define how the SBOM is securely stored and shared with the necessary stakeholders.

2.3.2 Security Assurance

The organization shall establish a process for identifying and managing known vulnerabilities in the open source components included in the supplied software. This allows the organization to quickly identify and respond to vulnerabilities, minimizing security risk.

Table 2.9: Security Assurance Requirement and Verification Materials

Considerations for Security Assurance

• Vulnerability Scanning: Use automated vulnerability scanning tools to periodically check open source components for vulnerabilities (e.g., OWASP Dependency-Check, Snyk, Black Duck).
• Vulnerability Databases: Use up-to-date vulnerability databases (e.g., the National Vulnerability Database (NVD), Common Vulnerabilities and Exposures (CVE)) to obtain information on known vulnerabilities.
• Vulnerability Assessment: Evaluate the severity, impact, and exploitability of discovered vulnerabilities to determine response priority.
• Patch Management: Apply patches for vulnerabilities promptly and verify the results of the patch application.
• Exception Handling: When applying a patch is difficult, take appropriate mitigation measures (e.g., changing Web Application Firewall (WAF) settings, modifying code).

2.3.3 Review and Approval

The organization shall establish a process for reviewing and approving the use of open source components. This allows the organization to assess security, license, and technical risk, and ensures that only safe and appropriate open source components are used.

Table 2.10: Review and Approval Requirement and Verification Materials

Considerations for the Review and Approval Process

• Review Criteria: Define clear criteria for evaluating open source components, such as security, license, and technical fitness.
• Review Body: Conduct the review through an Open Source Review Board (OSRB) or a designated person in charge.
• Approval Procedure: Define the procedure for approving or rejecting the use of an open source component based on the review results.
• Record Management: Document the review and approval results and systematically manage the related information.

2.4 Conformance to Document Requirements

This section covers what an organization needs to build a process for continually conforming to and improving upon the requirements of the ISO/IEC 18974 standard. Conformance to the standard’s requirements is essential for maintaining and continually improving the effectiveness of the open source security management system.

2.4.1 Program Conformance

The organization shall establish a process for verifying that its own open source security assurance program meets the requirements of the ISO/IEC 18974 document. This process may include regular internal audits, self-assessments, and, where necessary, external verification.

Table 2.11: Program Conformance Requirement and Verification Materials

Considerations for Verifying Program Conformance:

• Internal Audit: Verify through regular internal audits that program operations conform to ISO/IEC 18974 requirements. The audit cycle can be adjusted based on the organization’s size and complexity (e.g., quarterly, semi-annually, annually).
• Self-Assessment: Use self-assessment to identify the program’s strengths and weaknesses and find opportunities for improvement. The self-certification checklist provided by the OpenChain Project can be used for self-assessment.
• External Verification: Where necessary, have the program’s conformance verified by an external expert or certification body. This can increase the program’s credibility and build trust with customers and partners.
• Documentation: Document all procedures and records used to determine program conformance. This ensures transparency during audits and reviews and supports continual improvement.

2.4.2 Continuous Improvement

The organization shall continually improve the open source security assurance program to ensure its suitability, adequacy, and effectiveness. Continuous improvement is essential for responding to the changing threat landscape and maximizing the program’s effectiveness.

Table 2.12: Continuous Improvement Requirement and Verification Materials

Considerations for Continuous Improvement:

• Feedback Collection: Collect feedback on program operations from various stakeholders (e.g., developers, security team, legal team, management).
• Data Analysis: Analyze the collected feedback and program operation data to identify areas that need improvement.
• Improvement Plan Development: Develop specific plans for the identified areas of improvement and define actionable steps.
• Execution and Review: Execute the improvement plan and measure the results to evaluate its effectiveness.
• Process Integration: Reflect effective improvements in the program’s operating processes to ensure continuous improvement.

3.3 - 3. How to Implement ISO/IEC 18974

This section explains the processes needed to effectively implement an open source software security assurance program in accordance with the requirements of ISO/IEC 18974, along with how to prepare Verification Materials. This chapter organizes its subsections to align with Section 4, Requirements, of ISO/IEC 18974, and presents concrete implementation methods and Verification Materials preparation approaches for each requirement.

3.3.1 - 3.1 Program Foundation

The core of the ISO/IEC 18974 standard is building a systematic foundation for an organization to safely manage open source software. This foundation encompasses not only technical aspects but also various factors such as organizational culture, policy, and workforce competence. The 3.1 Program Foundation chapter explains in detail the essential elements for building this foundation.

3.1.1 Policy

An open source software security assurance policy is a core document for an organization to use open source safely and effectively. This policy guides all members of the organization to take responsibility for open source use, understand the associated risks, and comply with the required procedures. Therefore, the policy should be written in clear, easy-to-understand language and managed so that all members of the organization can easily access it.

3.1.1.1 Documented Open Source Software Security Assurance Policy

ISO/IEC 18974

• 4.1.1.1: A documented open source software security assurance policy

Self-Certification Checklist

• We have a documented policy governing the open source security assurance of Supplied Software.

A documented open source software security assurance policy is the core document that provides an organization’s formal guidance on open source use. This policy presents the standards for all members of the organization to safely use and manage open source, and helps minimize legal and security risks.

Example Policy Content

• Open source usage approval procedure: Clearly defines the review and approval procedure required before using open source.
• SBOM (Software Bill of Materials) management: Specifies how to generate and manage the list of open source components.
• Vulnerability management: Defines the procedure for detecting and responding to vulnerabilities in open source components.
• License compliance: Provides guidance for complying with open source license terms.
• Contribution policy: Presents guidelines on how the organization contributes to open source projects.
• Exception handling procedure: Defines the procedure for handling exceptional situations where complying with the policy is difficult.

The policy should be tailored to the size and characteristics of the organization. For example, a large organization may need a more detailed and complex policy, while a small organization may prefer a more concise and flexible policy.

In addition, the policy should be reviewed and updated regularly, and should reflect the latest laws and security threat trends.

This guide provides an open source policy template that satisfies all ISO/IEC 18974 requirements: Open Source Policy Template

3.1.1.2 Documented Procedure to Make Program Participants Aware of the Security Assurance Policy

ISO/IEC 18974

• 4.1.1.2: A documented procedure to make program participants aware of the security assurance policy.

Self-Certification Checklist

• We have a documented procedure to communicate the existence of the open source policy to all Software Staff.

No matter how well a policy is written, it cannot be effective if members of the organization are unaware of its existence or do not understand its content. Therefore, an organization must establish a documented procedure to effectively communicate the security assurance policy to all program participants.

Example Procedures

• New employee training: Mandatory open source policy training is provided to new employees.
• Regular training: Regular training on the open source policy (e.g., once a year) is conducted for existing employees.
• Policy publication: The policy document is posted on an internal wiki, portal, or other accessible location.
• FAQ: An FAQ document summarizing questions and answers about the policy is provided.
• Newsletter: The latest open source information and policy changes are shared through a newsletter.
• Awareness campaigns: Awareness campaigns emphasizing the importance of open source security are conducted regularly.

Training should not simply convey the policy content, but should be conducted in a way that encourages participants’ engagement and improves their understanding through actual case studies, workshops, quizzes, and similar activities. In addition, training materials should use visual elements to improve readability and be provided in a way that suits various learning styles.

Example Improvement Plan

• Improve the training program: Update the training content to reflect the latest trends and real-world cases, and strengthen participatory learning elements.
• Strengthen communication channels: Use internal communication channels to continuously share policy-related information and provide answers to questions.
• Expand awareness campaigns: Expand awareness campaigns that emphasize the importance of open source security, and encourage participation through various events.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.1.2 Competence

The success of an open source software security assurance program depends heavily on the competence of the members participating in the program. Clearly defining the competencies required for each role and supporting members in acquiring those competencies is essential to raising an organization’s level of open source security.

3.1.2.1 Documented List of Roles and Responsibilities

ISO/IEC 18974

• 4.1.2.1: A documented list of roles with corresponding responsibilities for the different program participants;

Self-Certification Checklist

• We have identified the roles and responsibilities that affect the performance and effectiveness of the Program.

Clearly defining and documenting the roles and responsibilities of all members participating in the open source security assurance program is the first step toward effective program operation. Only when each member clearly understands their own role and responsibilities can effective collaboration be achieved to reach the program’s objectives.

Implementation Methods and Considerations

• Comprehensive role definition: Define all roles participating in the program, such as program manager, legal counsel, security expert, and developer.
• Clear specification of responsibilities: Specify concretely, for each role, the tasks to be performed, decision-making authority, information-sharing obligations, and so on.
• Reflecting the organizational structure: The definition of roles and responsibilities should reflect the organization’s structure and culture.
• Regular review: Review and revise the definition of roles and responsibilities regularly in response to organizational changes, program updates, and the like.

Example (Based on Personnel Assignments) - Sample Roles and Responsibilities Document:

See Open Source Policy Template Appendix 1. Personnel Assignments for detailed examples.

3.1.2.2 Document Defining the Competencies Required for Each Role

ISO/IEC 18974

• 4.1.2.2: A document that identifies the competencies for each role;

Self-Certification Checklist

• We have identified and documented the competencies required for each role.

Defining the competencies required for each role is essential for placing the right people and developing the necessary education and training programs. Competency definitions should include not only technical knowledge but also non-technical competencies such as problem-solving ability, communication skills, and collaboration ability.

Implementation Methods and Considerations

• Concrete competency definitions: Specify concretely the knowledge, skills, experience, certifications, and the like required for each role.
• Measurable criteria: Present measurable criteria that can be used to assess the level of competence.
• Regular assessment: Regularly assess members’ competence levels and provide necessary education and training opportunities.
• Reflecting the latest information: Continuously update competency requirements as new technologies or threats emerge.

Example (Based on Personnel Assignments) - Sample Required Competencies by Role

See Open Source Policy Template Appendix 1. Personnel Assignments for detailed examples.

Through this approach, an organization can secure personnel suited to each role and strengthen members’ competence through continuous education and training.

3.1.2.3 List of Participants and Their Roles

ISO/IEC 18974

• 4.1.2.3: List of participants and their roles;

Self-Certification Checklist

• We have identified and documented a list of Program Participants and how they fill their respective roles.

Maintaining a list that clearly records the names and roles of all members participating in the open source security assurance program is essential for clarifying accountability and building an efficient communication system. This list improves the transparency of program operations and supports a rapid response when an emergency occurs.

Implementation Methods and Considerations

• Keeping information current: If the list of participants changes due to organizational restructuring, personnel changes, or the like, it should be updated immediately.
• Access permission management: Manage access permissions to the participant list appropriately to maintain information security.
• Accuracy of information: Accurately record and manage participant names, roles, contact information, and the like.

Example (Based on Personnel Assignments) - Sample List of Participants and Roles

See Open Source Policy Template Appendix 1. Personnel Assignments for detailed examples.

3.1.2.4 Documented Evidence of Assessed Competence for Each Participant

ISO/IEC 18974

• 4.1.2.4: Documented evidence of assessed competence for each program participant;

Self-Certification Checklist

• We have documented the assessed competence for each Program Participant.

Assessing whether the competencies required for each role are actually held is very important for ensuring the effectiveness of the program. Competency assessment should go beyond simply checking whether a certification is held, and should comprehensively assess actual job performance ability, problem-solving ability, and adaptability to change.

Implementation Methods and Considerations

• Use a variety of assessment methods: Assess competence using a variety of methods, such as written exams, practical assessments, interviews, and 360-degree evaluations.
• Conduct regular assessments: Assess competence regularly, at least once a year, and provide additional education or training opportunities as needed.
• Utilize assessment results: Reflect assessment results in individual competency development plans, compensation, promotion, and the like.

Example (Based on Personnel Assignments) - Sample Competence Assessment Results

Example Improvement Plan

• Develop competency-strengthening programs: Develop and operate education, training, and mentoring programs to strengthen the competencies required for each role.
• Support certification acquisition: Encourage the acquisition of related certifications and provide necessary support, such as exam fee support and study materials.
• Provide career development opportunities: Support members in gaining practical experience by providing opportunities to participate in various projects.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.1.2.5 Recording Process Reviews and Changes

ISO/IEC 18974

• 4.1.2.5: Documented evidence of periodic reviews and changes made to the process;

Self-Certification Checklist

• We have a way to document periodic reviews and changes made to our processes.

An open source security assurance program must be continuously improved to keep pace with an ever-changing threat landscape and technology trends. To this end, an organization must build a system for periodically reviewing roles and responsibilities, competency requirements, and the like, and applying changes as needed. These reviews and changes must be documented and managed, and it must be possible to verify the program’s progress through change history tracking.

Implementation Methods and Considerations

• Set a regular review cycle: Conduct reviews at least once a year, or as needed from time to time. The review cycle is determined by considering the organization’s characteristics, the scale of open source use, the frequency of security threats, and the like.
• Define the review scope: Clearly define the review scope, including role and responsibility definitions, competency requirements, training programs, and assessment methods.
• Establish a review procedure: Document a review procedure that includes the purpose of the review, participants, review method, and result reporting.
• Manage changes: Record changes made based on review results in detail, specifying the reason for the change, the content of the change, and the timing of application.
• Manage history: Systematically manage the change history so that past decisions and the current state can be compared and analyzed.

Sample Evidence

• Process review meeting minutes: Record in detail the meeting attendees, discussion content, and decisions made.
• Change report: Specify the reason for the change, the content of the change, and the roles and processes affected.
• Updated policy document: Kept up to date to reflect changes.
• Process improvement proposal: Record proposed content for program improvement and document the review results.
• Competency assessment result analysis report: Analyze competency assessment results and use them to improve training programs.

Sample Table: Process Review and Change Record

Example Improvement Plan

• Build an automated change management system: Introduce a system that automates change tracking, approval workflow management, and history management.
• Conduct regular audits: Conduct regular audits to assess process compliance and effectiveness.
• Expand stakeholder participation: Involve various stakeholders (developers, security experts, legal counsel, and the like) in the review process to gather diverse opinions.
• Collect continuous feedback: Collect feedback from program participants and reflect it in process improvement.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.1.2.6 Verifying Alignment with Company Internal Best Practices

ISO/IEC 18974

• 4.1.2.6: Documented verification that these processes are current with company internal best practices and who is assigned to accomplish them.

Self-Certification Checklist

• We have a way to verify that our processes align with current company best practices and staff assignments.

To maximize the effectiveness of the open source security assurance program, it is important that the way the program is operated remains consistent with other security-related activities and best practices within the company. This helps the program integrate with the organization’s overall security strategy to create synergy and avoid unnecessary duplication.

Implementation Methods and Considerations

• Survey internal best practices:
  • Survey security-related activities or processes that other teams or departments in the organization are operating successfully.
  • Example: the information security team’s security vulnerability management process, the development team’s secure coding guidelines, and the like.
• Compare and analyze processes:
  • Compare and analyze the surveyed best practices against how the open source security assurance program is operated.
  • Identify strengths, weaknesses, and opportunities for improvement.
• Integrate and improve processes:
  • Adjust 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, conducting open source code reviews in accordance with internal coding conventions, and the like.
• Assign and manage an owner:
  • Assign an owner responsible for compliance with internal best practices and clarify that role.
  • The owner regularly reviews how the program is operated and proposes improvements.

Sample Evidence

• Best practice survey report: Record in detail the survey targets, survey method, and analysis results.
• Process comparison and analysis report: Clearly present strengths, weaknesses, and opportunities for improvement.
• Process improvement plan: Specify concrete improvement targets, an implementation plan, and an assessment method.
• Owner assignment document: Clearly define the owner’s name, role, and responsibilities.

Sample Table: Verifying Alignment with Company Internal Best Practices

Example Improvement Plan

• Strengthen the security training program: Include open source security content in the company-wide security training program and expand the training audience and hours.
• Strengthen the access control policy: Minimize access permissions to open source-related systems and conduct regular access permission reviews.
• Integrate audit processes: Integrate audits of open source-related activities into the company-wide audit process, conduct audits regularly, and derive improvements.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

Through this approach, an organization can align its open source security assurance program with the company’s internal best practices, thereby increasing the program’s effectiveness and raising the organization’s overall level of security.

3.1.3 Awareness

For an open source security assurance program to operate successfully, raising the awareness of program participants is essential. Program participants must clearly understand the organization’s open source policy, the program’s objectives, and their own roles and responsibilities. They must also be fully aware of the impact that can result from failing to comply with the program’s requirements.

3.1.3.1 Documented Evidence of Assessed Awareness of Program Participants

ISO/IEC 18974

• 4.1.3.1: Documented evidence of assessed awareness for the program participants - which should include the program’s objectives, one’s contribution within the program, and implications of program non-conformance.

Self-Certification Checklist

• We have documented the awareness of our Program Participants on the following topics:
  • The open source security assurance policy and where to find it;
  • Relevant open source objectives;
  • Contributions expected to ensure the effectiveness of the Program;
  • The implications of failing to follow the Program requirements.

To confirm whether program participants are sufficiently aware of open source-related policies and procedures and the importance of security, an organization must conduct regular assessments and document the results. Such assessments can be used to measure the program’s effectiveness and, if necessary, improve the training program.

Implementation Methods and Considerations

• Use a variety of assessment methods:
  • Multiple-choice exams: Assess knowledge related to the open source policy, licenses, and security.
  • Case studies: Present scenarios that could actually occur and have participants choose an appropriate response.
  • Surveys: Gather program participants’ opinions on their level of awareness, satisfaction, and areas for improvement.
• Structure of assessment content:
  • Policy understanding: Assess understanding of the purpose, scope of application, and key content of the open source policy.
  • License understanding: Assess understanding of the major types of open source licenses and their obligations.
  • Security vulnerability response procedure: Assess understanding of the reporting and handling procedure when a vulnerability is found.
  • Contribution method: Assess understanding of the procedures and guidelines for contributing to open source projects.
• Analysis of assessment results:
  • Analyze the assessment results to identify the strengths and weaknesses of program participants.
  • Provide additional education or training for areas of weakness.
• Use of assessment results:
  • Improve the training program: Supplement the training content and improve the training method based on the assessment results.
  • Improve processes: Improve the open source management process based on the assessment results.

Sample Evidence

• Training program materials: Specify the training content, audience, and schedule.
• Assessment methods: Include exam papers, questionnaires, case study materials, and the like.
• Assessment result report: Include assessment scores, analysis content, and an improvement plan.
• List of training attendees: Record the names and signatures of the people who participated in the training.

Example (Based on Personnel Assignments)

Example Improvement Plan

• Diversify training content: Develop training content in a variety of formats, such as videos, infographics, and games, to increase participation.
• Provide customized training: Provide customized training focused on the knowledge and skills required for each role.
• Build a feedback system: Collect feedback on the training program and reflect it in improvements.
• Introduce a reward system: Provide rewards to people who contribute to open source security to motivate them.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

Through this approach, an organization can raise the awareness level of program participants and contribute to spreading an open source security culture.

3.1.4 Program Scope

Clearly defining the scope of the open source security assurance program is very important for efficiently allocating the organization’s resources and effectively achieving the program’s objectives. The scope of the program should be carefully determined by considering the organization’s size, business characteristics, and the scale of open source use.

3.1.4.1 Written Statement Clearly Defining the Scope and Limits of the Program

ISO/IEC 18974

• 4.1.4.1: A written statement that clearly defines the scope and limits of the program;

Self-Certification Checklist

• We have a written statement clearly defining the scope and limits of the Program.

A written statement that clearly defines the scope and limits of the program contributes to preventing confusion and clarifying accountability by clearly distinguishing what the program applies to and what it does not. This statement must remain consistent with the program’s objectives and be written so that all members of the organization can easily understand it.

Implementation Methods and Considerations

• Comprehensive definition: Clearly list all the targets to which the program applies (e.g., all software projects, specific teams, specific product lines, specific technology stacks).
• Clear exceptions: Specifically state the exceptions to which the program does not apply. Example: open source used only for internal testing, personal projects, and the like.
• Possibility of scope adjustment: State that the scope of the program can be adjusted according to changes in the organization’s circumstances, and briefly describe the scope adjustment procedure.

Example (Considering Organization Size and Business Characteristics)

• Large organization:
  • Scope of application: “Applies to open source components included in all software projects developed, deployed, or used by all business units of the company.”
  • Exception: “However, open source used only for research and development purposes may be excluded from the scope of this program. In this case, prior approval from the OSPO is required.”
• Small organization:
  • Scope of application: “Applies to open source components included in the company’s flagship products.”
  • Exception: “Open source used in internal management systems is excluded from the scope of this program.”

Sample Table: Program Scope Definition

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.1.4.2 Set of Metrics to Achieve for Program Improvement

ISO/IEC 18974

• 4.1.4.2: A set of metrics the program shall achieve to improve;

Self-Certification Checklist

• We have a set of metrics to measure Program performance.

To continuously measure and improve the effectiveness of the open source security assurance program, it is essential to set specific, measurable metrics. These metrics are used to assess whether the program’s objectives are being achieved, identify areas for improvement, and track progress.

Implementation Methods and Considerations

• SMART metrics: Metrics should be Specific, Measurable, Achievable, Relevant, and Time-bound.
• Linking to key objectives: Metrics should be directly linked to the program’s key objectives (e.g., risk reduction, cost savings, efficiency improvement).
• Data collection and analysis: A system for collecting and analyzing the data needed to measure the metrics must be built.
• Regular review: The appropriateness of the metrics should be reviewed regularly and adjusted as needed.

Example Metrics

Data Collection Methods

• Use automated tools: Automatically collect data using SBOM generation tools, vulnerability scanners, license inspection tools, and the like.
• Regular audits: Verify data accuracy through manual audits and collect information that automated tools fail to capture.
• Surveys: Gather program participants’ opinions and collect subjective data.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.1.4.3 Documented Evidence from Reviews, Updates, or Audits to Demonstrate Continuous Improvement

ISO/IEC 18974

• 4.1.4.3: Documented evidence from each review, update, or audit to demonstrate continuous improvement.

Self-Certification Checklist

• We have Documented Evidence from each review, update, or audit to demonstrate continuous improvement.

An open source security assurance program is not built and maintained as a one-time effort; its effectiveness must be maintained and strengthened through continuous review and improvement. The program’s scope, policy, and procedures must be continuously reviewed and updated to keep pace with the changing threat landscape, new technology trends, and changes in the organization’s business requirements. These review, update, and audit activities must be documented and managed, and serve as important evidence demonstrating the program’s continuous improvement.

Implementation Methods and Considerations

• Regular review meetings: Hold regular review meetings attended by program management, security experts, legal counsel, and other relevant stakeholders. The meetings discuss the program’s effectiveness, problems, and improvements, and decide on necessary actions.
• Conduct internal audits: Conduct regular internal audits to assess the program’s operational status, policy compliance, and level of risk management. Audits may be conducted by an independent audit team or external experts.
• Collect and analyze feedback: Collect and analyze feedback from program participants, development teams, and users, and use it to improve the program. Gather diverse opinions using surveys, interviews, suggestion systems, and the like.
• Change management process: When changing the program’s scope, policy, or procedures, clearly record the reason for the change, the content of the change, and the affected parties, and notify relevant stakeholders of the changes.
• Documentation and history management: Document and manage all review, update, and audit activities so that the change history can be tracked.

Sample Evidence

• Review meeting minutes: Record in detail the meeting attendees, discussion content, decisions, and execution plan.
• Internal audit report: Include the audit scope, audit method, audit results, and improvement recommendations.
• Feedback analysis report: Analyze the collected feedback content and derive key improvements.
• Change management record: Specify the reason for the change, the content of the change, and the timing of application.
• Updated policy document: Kept up to date to reflect changes.

Sample Table: Continuous Improvement Activity Record

Example Improvement Plan

• Introduce automation tools: Introduce tools that automate repetitive tasks such as SBOM generation, vulnerability scanning, and license inspection, thereby improving efficiency.
• Strengthen the training program: Operate a regular training program to strengthen the competencies of program participants, and share the latest information and technology trends.
• Use threat intelligence: Collect and analyze the latest security threat information and reflect it in the program.
• Use external experts: Seek advice from external experts as needed and obtain professional technical support.
• Community participation: Actively participate in the open source community to identify the latest information and technology trends, and collaborate with other organizations for the program.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.1.5 Standard Practice Implementation

To build a secure open source software supply chain, an organization must manage the risks it has identified on its own and implement standardized procedures that strengthen security throughout the software development process. These procedures must focus not only on systematically responding to Known Vulnerabilities, but also on preventing security threats that may arise in the future.

3.1.5.1 Method to Identify Structural and Technical Threats to Supplied Software

ISO/IEC 18974

• Method to identify structural and technical threats to the supplied software;

Self-Certification Checklist

• We have a method to identify structural and technical threats to the Supplied Software;

Identifying structural and technical threats to Supplied Software is an essential process for discovering and resolving potential security issues at an early stage of development. This process must consider various factors, such as design flaws in the software architecture, inappropriate technology stack choices, and unsafe coding practices. From an open source software security assurance standpoint, particular focus should be placed on identifying security vulnerabilities that can arise from the use of open source components.

Implementation Methods and Considerations

1. Use SCA (Software Composition Analysis) tools:
   • SBOM-based analysis: Use an SCA tool to generate a list (SBOM) of all open source components used in the software and identify each component’s Known Vulnerabilities.
   • Integration with vulnerability databases: Integrate the SCA tool with vulnerability databases such as the NVD (National Vulnerability Database) and CVE (Common Vulnerabilities and Exposures) to make use of the latest vulnerability information.
   • Automated analysis: Integrate the SCA tool into the CI/CD pipeline to automatically perform analysis when code changes and detect new vulnerabilities.
2. Architecture risk analysis:
   • Inter-component dependency analysis: Analyze the software architecture to understand the dependency relationships between components and identify potential security risks.
   • Data flow analysis: Analyze how data moves and is processed within the system to assess the possibility of data leakage or tampering.
   • Authentication and authorization review: Identify security vulnerabilities in authentication and authorization mechanisms and apply appropriate security measures.

Example

• Identify a Known Vulnerability (e.g., CVE-2017-5638) in the Apache Struts 2 framework and assess the vulnerability’s impact on the organization’s system.
• In a microservices architecture, review the authentication and authorization mechanism used for inter-service communication, and apply security measures to prevent unauthorized access between services.
• Verify whether the version of an open source component in use is the latest, and identify components that are no longer maintained.

Implementation Considerations

• Keeping information current: Vulnerability databases must be continuously updated.
• Automation: Automate the threat identification process as much as possible to improve efficiency.
• Use of experts: Obtain the help of security experts as needed to assess and respond to threats.

Automation Tool Options

Among the automation tools available as open source for SBOM generation/management and vulnerability identification are FOSSLight, SW360, and OSV-SCALIBR. See the guides below for how to install and use these tools.

• FOSSLight
• SW360
• OSV-SCALIBR

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

Through this approach, an organization can effectively identify structural and technical threats to Supplied Software and minimize the security risk arising from open source use.

3.1.5.2 Method to Detect Known Vulnerabilities in Supplied Software

ISO/IEC 18974

• Method for detecting existence of known vulnerabilities in supplied software;

Self-Certification Checklist

• We have a method for detecting existence of Known Vulnerabilities in Supplied Software;

Detecting Known Vulnerabilities in the open source components included in Supplied Software is very important for protecting the organization’s systems from potential attacks. This process includes using a vulnerability database to check the Known Vulnerability information for each component included in the SBOM, assessing the severity of the vulnerabilities, and taking appropriate response measures. Effective vulnerability detection methods are as follows.

Implementation Methods and Considerations

• Automated vulnerability scanning:
  • Integrate an SCA tool into the CI/CD pipeline to automatically perform a vulnerability scan whenever code changes.
  • Share the scan results with the development team, security team, and legal team, and take immediate response action as needed.
• Integration with vulnerability databases:
  • Integrate the SCA tool with the NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures), and other trusted vulnerability databases.
  • Vulnerability databases must be continuously updated with the latest information.
• Severity-based classification:
  • Use the CVSS (Common Vulnerability Scoring System) score to automatically classify the severity of vulnerabilities.
  • Determine the vulnerability response priority based on severity and take the necessary action.
• Manual verification:
  • For high-risk vulnerabilities detected by automated tools, a security expert performs manual verification.
  • Manual verification helps reduce false positives and identify vulnerabilities that automated tools fail to detect.

Example

• Use an SCA tool to detect a vulnerability in the Apache Struts 2 framework and check the CVSS score to assess its severity.
• For high-risk vulnerabilities, a security expert directly reviews the code and analyzes the likelihood of exploitation.
• When a vulnerability is found, the development team immediately applies a patch or takes mitigation measures.

Implementation Considerations

• Accuracy: Tools must be selected and configured to reduce false positives and accurately detect actual security threats.
• Automation: Configure the process to be integrated into the development process and run automatically.
• Keeping information current: Vulnerability databases must be continuously updated with the latest information.

Automation Tool Options

Among the tools available as open source that provide automated vulnerability scanning functionality integrated with vulnerability databases are FOSSLight, SW360, and OSV-SCALIBR. See the guides below for how to install and use these tools.

• FOSSLight
• SW360
• OSV-SCALIBR

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

Through this approach, an organization can effectively detect Known Vulnerabilities in the open source components included in Supplied Software and protect its systems from potential attacks.

3.1.5.3 Method to Follow Up on Identified Known Vulnerabilities

ISO/IEC 18974

• Method for following up on identified known vulnerabilities;

Self-Certification Checklist

• We have a method for following up on identified Known Vulnerabilities;

Once a vulnerability is found in an open source component, the organization’s systems and data must be protected through prompt and systematic follow-up action. This involves more than simply applying a patch; it includes a series of steps such as assessing the severity of the vulnerability, determining the response priority, selecting an appropriate resolution, and verifying the result. Effective follow-up methods are as follows.

Implementation Methods and Considerations

1. Establish vulnerability severity assessment criteria:
   • Use the CVSS (Common Vulnerability Scoring System) score to assess the severity of a vulnerability.
   • Classify severity into High, Medium, Low, and the like, and set a response deadline for each severity level.
   • Example:
     • CVSS 7.0 or higher: High (respond within 24 hours)
     • CVSS 4.0 to 6.9: Medium (respond within 7 days)
     • CVSS 0.1 to 3.9: Low (respond within 30 days)
2. Define a vulnerability response process:
   • Define a clear response process that includes reporting, assessment, resolution, and verification stages when a vulnerability is found.
   • Assign an owner for each stage and clearly specify responsibility and authority.
   • Document the process and share it with all relevant members.
3. Establish a method for setting vulnerability resolution priority:
   • Determine the resolution priority by considering the vulnerability’s severity, scope of impact, and likelihood of exploitation.
   • Resolve vulnerabilities that affect systems of high business importance first.
   • Respond immediately to vulnerabilities for which publicly known exploit code exists.
4. Vulnerability resolution methods:
   • Apply a patch: If possible, upgrade to the latest version of the open source component that resolves the vulnerability.
   • Mitigation measures: If a patch cannot be applied immediately, reduce risk through temporary mitigation measures. (e.g., changing WAF settings, restricting access)
   • Component replacement: If the vulnerability is severe and applying a patch is difficult, consider replacing the component with a different one.

Example

• For a high-risk vulnerability (CVE-2017-5638) in the Apache Struts 2 framework discovered through an SCA tool, the security team immediately assesses the severity, and the development team upgrades to the latest version within 24 hours.
• If the upgrade is not possible, the WAF (Web Application Firewall) settings are changed to block attacks that exploit the vulnerability.
• All discovered vulnerabilities are registered and managed in an issue tracking system (e.g., Jira), and the resolution process is tracked.

Implementation Considerations

• Automation: Automate the process from vulnerability detection through resolution as much as possible to improve efficiency.
• Collaboration: Respond promptly through close collaboration between the development team, security team, and operations team.
• Continuous monitoring: Continue monitoring after a vulnerability is resolved to prevent recurrence.

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

Through this approach, an organization can systematically follow up on identified Known Vulnerabilities and keep its systems secure.

3.1.5.4 Method to Communicate Identified Known Vulnerabilities to Customers

ISO/IEC 18974

• Method to communicate identified known vulnerabilities to customer base when warranted;

Self-Certification Checklist

• We have a method to communicate identified Known Vulnerabilities to customer base when warranted;

To minimize the impact on customers of Known Vulnerabilities identified in open source components, transparent and prompt communication is essential. An organization must build a system for communicating vulnerability information, scope of impact, and response measures to customers clearly and in a timely manner. This helps maintain customer trust, protect the brand image, and reduce legal liability.

Implementation Methods and Considerations

1. Establish a customer communication process:
   • Clearly define the procedure for communicating information to customers when a vulnerability occurs.
   • The procedure should include criteria for deciding on disclosure, the method of communication, and owner assignment.
2. Define vulnerability disclosure criteria:
   • Clearly define the criteria for what level of severity a vulnerability must have to be disclosed to customers.
   • The decision on whether to disclose is generally based on the CVSS (Common Vulnerability Scoring System) score.
3. Maintain a customer contact database:
   • Maintain up-to-date customer contact information so that vulnerability information can be communicated promptly.
   • Use customer segmentation so that information can be communicated only to affected customers.

Communication methods:

• Email: The most common method, allowing information to be communicated promptly.
• Customer portal: Allows customers to directly check vulnerability information and download response measures.
• Website notice: Discloses general vulnerability information and directs customers to the customer portal for details.

Content of the communication:

• Vulnerability summary: Explains the vulnerability in easy-to-understand terms.
• Impact: Clearly explains the potential impact of the vulnerability on customer systems.
• Resolution: Provides a patch, mitigation measure, or other resolution, if available.
• Contact: Specifies the owner or department the customer can contact for additional questions or support.

Implementation Considerations

• Timeliness: Communicate information to customers as quickly as possible.
• Accuracy: Provide accurate and reliable information.
• Transparency: Honestly disclose the severity and impact of the vulnerability.
• Consistency: Provide consistent information to all customers.

Example

• When a remote code execution vulnerability is discovered in the Apache Struts 2 framework, send an email to affected customers and guide them to apply the patch for the vulnerability.
• Post detailed information about the vulnerability on the customer portal and provide answers to frequently asked questions.
• If necessary, call the customer directly to explain the situation and support the patch application.

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

Through this approach, an organization can effectively communicate information about identified Known Vulnerabilities to customers, maintain customer trust, and protect its brand image.

3.1.5.5 Method to Analyze Supplied Software for Newly Published Known Vulnerabilities After Release

ISO/IEC 18974

• Method for analyzing supplied software for newly published known vulnerabilities post release of the supplied software;

Self-Certification Checklist

• We have a method for analyzing Supplied Software for newly published Known Vulnerabilities post release of the Supplied Software;

New vulnerabilities can be discovered even after Supplied Software has been released. Such vulnerabilities can penetrate a system through unexpected attack paths or bypass existing security measures. Therefore, an organization must have a system in place to continuously monitor and analyze new vulnerabilities even after Supplied Software has been released. This is essential for minimizing potential damage through a prompt response and maintaining customer trust.

Implementation Methods and Considerations

1. Build a vulnerability monitoring system:
   • Continuously monitor the NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures), and other trusted vulnerability information sources.
   • Use automated tools to collect new vulnerability information and identify vulnerabilities that could affect the organization’s systems.
2. Initial classification and impact analysis:
   • After identifying new vulnerability information, check whether the vulnerability exists in an open source component used in the organization’s systems.
   • Assess the vulnerability’s severity, likelihood of exploitation, and potential impact on the system.
3. Detailed analysis and reproduction:
   • For vulnerabilities that are likely to have an impact, perform a detailed analysis and attempt to reproduce the vulnerability based on a real-world attack scenario.
   • Use the reproduction result to understand the vulnerability’s actual level of risk and develop an appropriate response.
4. Develop a response plan:
   • Based on the vulnerability analysis results, decide on a patch application, mitigation measure, or other response.
   • The response plan should consider not only technical aspects but also business impact, legal requirements, and customer communication strategy.
5. Execute and verify the response:
   • Immediately execute the necessary action according to the established response plan.
   • After applying a patch or taking mitigation measures, always re-verify the vulnerability to confirm that the issue has been resolved.
6. Customer notification (as needed):
   • If the vulnerability has a significant impact on customers, notify them of the fact and guide them on the necessary action.
   • Communication with customers should be transparent and prompt.

Implementation Considerations

• Automation: Automate the vulnerability monitoring, initial classification, and impact analysis processes as much as possible to improve efficiency.
• Use of experts: Detailed analysis, reproduction, and development of a response plan require the specialized knowledge and experience of security experts.
• Collaboration: Enable a prompt and effective response through close collaboration between the development team, security team, operations team, and legal team.
• Documentation: Record the vulnerability analysis results, response plan, and execution results in detail so that they can be referenced when a similar issue occurs in the future.

Example

• Confirm information that a new vulnerability (e.g., CVE-2025-XXXX) has been discovered in the Apache Struts 2 framework via the NVD.
• Use an SCA tool to check whether the vulnerability exists in the version of Struts 2 used in the organization’s systems.
• Check the vulnerability’s CVSS score and assess its severity.
• A security expert reproduces the vulnerability and analyzes the actual likelihood of attack.
• Coordinate with the development team to determine the timing of patch application, and apply the patch to the system together with the operations team.
• Rerun the vulnerability scanner to confirm that the vulnerability has been resolved.
• If the vulnerability is likely to have a significant impact on customers, send them an email and guide them on the necessary action.

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

Through this approach, an organization can respond promptly to newly discovered vulnerabilities after the release of Supplied Software and keep its systems secure.

3.1.5.6 Method for Continuous and Repeated Security Testing Before Release

ISO/IEC 18974

• Method for continuous and repeated security testing to be applied for all supplied software before release;

Self-Certification Checklist

• We have a method for continuous and repeated Security Testing is applied for all Supplied Software before release;

To provide secure software, it is not enough to perform security testing just once before release. Continuous and repeated security testing is essential for strengthening security throughout the software development lifecycle (SDLC) and for identifying and resolving potential vulnerabilities before release. In particular, when open source components are used, such testing plays an important role in confirming open source license compliance and identifying potential security vulnerabilities.

Implementation Methods and Considerations

1. Integrate into the CI/CD pipeline:
   • Integrate security testing into the CI/CD pipeline so that tests run automatically whenever code changes.
   • This allows security issues to be discovered and resolved from the early stages of development.
2. Use SCA tools:
   • Use an SCA (Software Composition Analysis) tool to scan open source components for vulnerabilities and confirm license compliance.
   • Integrate the SCA tool into the CI/CD pipeline so that it runs automatically during the build process.
3. Regular manual review:
   • Since automated tools alone may not discover all security issues, conduct regular manual security reviews.
   • Manual review may include code review, architecture review, penetration testing, and the like.
4. Analyze and improve test results:
   • Analyze the security test results and develop a plan to resolve discovered vulnerabilities.
   • Share the test results with the development team, security team, and operations team, and resolve issues collaboratively.
   • Continuously improve the testing process to enable more effective testing.

Specific Examples

• Automate vulnerability scanning: Integrate a vulnerability scanning tool such as OWASP Dependency-Check into the CI/CD pipeline to automatically scan open source components for vulnerabilities during the build process.
• Automate license inspection: Integrate a license inspection tool such as FOSSology into the CI/CD pipeline to automatically inspect open source components for license compliance during the build process.
• Mandate code review: Mandate code review for all code changes and make an effort to find security vulnerabilities.
• Perform penetration testing: Commission external security experts to perform penetration testing on the system before release, and identify potential security vulnerabilities.

Implementation Considerations

• Test scope: Security testing must be performed on all open source components and custom code.
• Test cycle: Security testing must be performed whenever code changes and before release.
• Test environment: Build a test environment similar to the actual production environment to increase the reliability of the test results.

Automation Tool Options

Among the tools available as open source that enable continuous and repeated security testing before release are FOSSLight, SW360, and OSV-SCALIBR. See the guides below for how to install and use these tools.

• FOSSLight
• SW360
• OSV-SCALIBR

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

Through this approach, an organization can identify and resolve potential security vulnerabilities before release, providing more secure software.

3.1.5.7 Method to Verify That Identified Risks Are Addressed Before Release of Supplied Software

ISO/IEC 18974

• Method to verify that identified risks will have been addressed before release of supplied software;

Self-Certification Checklist

• We have a method to verify that identified risks will have been addressed before release of Supplied Software;

Resolving the Known Vulnerabilities discovered by an SCA (Software Composition Analysis) tool before releasing Supplied Software is very important for ensuring the security level of the final product. This includes activities such as patching or removing vulnerable open source components, with the goal of preventing similar issues from occurring in the future.

Implementation Methods and Considerations

1. Identify vulnerabilities using an SCA tool:
   • Integrate the SCA tool into the CI/CD pipeline to continuously scan for vulnerabilities.
   • Perform a final scan before release to identify all Known Vulnerabilities.
2. Define a vulnerability resolution process:
   • Decide on a resolution method, such as applying a patch or removing the component, for each identified vulnerability.
   • Set priorities based on severity and resolve high-risk vulnerabilities first.
3. Establish a resolution verification procedure:
   • After applying a patch, perform a rescan to confirm that the vulnerability has been resolved.
   • When a component is removed, confirm that the corresponding functionality has been properly replaced.
4. Final security approval procedure:
   • After confirming that all high-risk vulnerabilities have been resolved, obtain final approval from the security lead.
   • Document any residual risk and establish a management plan.

Specific Examples

• When a Known Vulnerability (e.g., CVE-2017-5638) in the Apache Struts 2 framework is found by an SCA tool, upgrade to the latest patched version.
• When an open source library that is no longer maintained is found, remove the library and replace it with an alternative library.

Implementation Considerations

• Automation: Automate the scanning and result analysis of the SCA tool to improve efficiency.
• Continuous monitoring: Continue monitoring for and responding to new vulnerabilities even after release.
• Documentation: Document the vulnerability resolution process and results in detail for future reference.

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

Through this approach, an organization can effectively resolve Known Vulnerabilities before the release of Supplied Software and significantly improve the security level of the final product.

3.1.5.8 Method to Communicate Identified Risks to Third Parties

ISO/IEC 18974

• Method to export information about identified risks to third parties as appropriate.

Self-Certification Checklist

• We have a method to export information about identified risks to third parties as appropriate.

Security risks present in an organization’s Supplied Software can affect not only the organization itself but also various stakeholders, such as customers who use the software, partners, and the open source community. Therefore, an organization must appropriately communicate identified risks to third parties so that risks can be managed jointly and the security of the overall software supply chain can be strengthened. This process must be carried out in a transparent and responsible manner, and must comply with relevant laws and contractual terms.

Implementation Methods and Considerations

1. Risk assessment and classification:
   • Assess the identified risk’s severity, scope of impact, and likelihood of propagation to determine which third parties the information should be communicated to.
   • Information must be shared immediately for high-risk vulnerabilities that could result in personal information leakage, system failure, financial loss, or the like.
2. Define information sharing criteria:
   • Clearly define what information is to be shared and in what manner.
   • Information must be written concisely and clearly, and should include a non-technical explanation along with technical content.
   • Includes a description of the vulnerability, its impact, the resolution method, and contact information.
3. Build communication channels:
   • Build communication channels for safely sharing information with third parties.
   • Email, a customer portal, a security bulletin board, and the like can be used.
   • Apply encrypted communication, access permission management, data loss prevention technology, and the like for information security.
4. Comply with legal and contractual obligations:
   • Comply with relevant laws (e.g., personal information protection law) and contractual terms (e.g., confidentiality clauses) when sharing information.
   • Coordinate with the legal team to perform a legal review of information sharing.
5. Assign an owner:
   • Assign an owner who oversees the risk information sharing process.
   • The owner is responsible for information-sharing decisions, review of the information content, and communication with third parties.

Specific Examples

• Open source community:
  • Report vulnerabilities found in internally developed code to the relevant open source project and collaborate on patch development.
  • Consider using a Cybersecurity Vulnerability Information Sharing Program.
• Customers:
  • When a cybersecurity vulnerability occurs, notify customers immediately and inform them of the vulnerability’s impact and resolution.
  • If necessary, provide remote support for customer systems to help with patch application.
• Suppliers:
  • When a vulnerability is found in software or hardware they have provided, inform customers of the fact and provide a patch or update.

Implementation Considerations

• Timeliness: Share information as quickly as possible so that third parties can take appropriate action.
• Accuracy: Provide accurate and reliable information.
• Transparency: Honestly disclose the severity and impact of the vulnerability.

Documentation Approach

Include the following content in the open source process. (Reference: Open Source Process Template)

3.3.2 - 3.2 Relevant Tasks Defined and Supported

For an open source security assurance program to operate effectively, all relevant tasks must be clearly defined and the necessary resources must be properly allocated. This is essential for securing the personnel, budget, and technical expertise needed to operate the program, and for supporting its continual improvement.

3.2.1 Access

Providing third parties with access to make enquiries about known vulnerabilities affecting an organization’s software is critical to increasing transparency, strengthening collaboration with the community, and quickly resolving potential security issues.

3.2.1.1 Publicly Visible Method for Vulnerability Enquiries

ISO/IEC 18974

• 4.2.1.1: Publicly visible method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal that is monitored by program participants);
• 4.2.1.1 Publicly visible method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal that is monitored by program participants)

Self-Certification Checklist

• We have a method to allow third parties to make Known Vulnerability or Newly Discovered Vulnerability enquires (e.g., via an email address or web portal that is monitored by Program Participants);
• We have a method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal).

The organization shall make it possible to provide information about software vulnerabilities through a method that anyone can easily access. This can be implemented through the organization’s website, a dedicated security page, or a separate bug bounty platform. What matters is that the method for providing information is clear, easy to find, and continuously monitored.

Implementation Methods and Considerations

• Dedicated Email Address:
  • Create a dedicated email address for vulnerability reports, such as security@example.com, and publish it on the website.
  • The email address shall be continuously monitored by the security team or the relevant person in charge.
• Web-Based Reporting Form:
  • Provide a web-based reporting form where the information needed for a vulnerability report (e.g., software name, version, vulnerability description, reproduction steps) can be entered.
  • The reporting form shall be easy to use and include clear instructions.
• Security Page:
  • Publish a security page on the website that includes the organization’s security policy, vulnerability reporting procedure, and related contact information.
  • Provide a link on the website’s main page so the security page can be easily found.
• Bug Bounty Program:
  • Run a bug bounty program that encourages external security experts to test the organization’s systems and discover vulnerabilities.
  • A bug bounty program provides rewards for vulnerability reports and encourages researchers to participate.

Examples

• Post a statement on the website such as: “If you discover a security vulnerability in our company’s products, please contact us at security@example.com. For details, see the security page.”
• The vulnerability reporting web form includes the following fields:
  • Reporter information (name, email address)
  • Affected product and version
  • Vulnerability description
  • Reproduction steps
  • Supporting evidence (screenshots, log files, etc.)

Documentation Approach

Include content on security vulnerabilities when responding to external enquiries, as shown below, within the open source policy. (Reference: Open Source Policy Template)

3.2.1.2 Internal Procedure for Responding to Vulnerability Enquiries

ISO/IEC 18974

• 4.2.1.2: An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.
• 4.2.1.2 An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries exists.

Self-Certification Checklist

• We have an internal documented procedure for responding to third party Known Vulnerability or Newly Discovered Vulnerability inquiries.
• We have documented the internal procedure for responding to external inquiries.

When a vulnerability enquiry is received from outside the organization, it is critical to have a procedure in place for responding to it in a systematic and efficient manner internally. This procedure covers the entire process of enquiry receipt, analysis, resolution, and reporting, and must clearly define the person responsible and the deadline for each stage. It must also account for information security and legal liability, so that sensitive information can be handled and shared securely.

Implementation Methods and Considerations

• Forming a Response Team:
  • Designate a responsible team or person in charge to receive and handle vulnerability enquiries.
  • The response team may include security experts, developers, and legal personnel.
• Defining the Process:
  • Document the entire process, including the stages of receiving, classifying, analyzing, resolving, and reporting vulnerability enquiries.
  • Clearly define the person responsible and the deadline for each stage.
• Severity Assessment Criteria:
  • Establish criteria for assessing the severity of a vulnerability.
  • The Common Vulnerability Scoring System (CVSS) score can be used to objectively assess the severity of a vulnerability.
• Response Procedure:
  • Establish different response procedures depending on the severity of the vulnerability.
  • Respond immediately to high-risk vulnerabilities, and consider monitoring or a long-term resolution plan for low-risk vulnerabilities.
• Communication Guidelines:
  • Establish guidelines on how to inform the person who reported the vulnerability of progress and how to request additional information.
  • Communication with the reporter shall be transparent and prompt.

Example of a Specific Procedure

1. Receipt: The security team confirms vulnerability enquiries received at security@example.com and assigns a case number.
2. Classification: The security team analyzes the type of vulnerability and the affected systems, and assesses its severity.
3. Analysis: The development team analyzes the cause of the vulnerability and explores resolution options.
4. Resolution: The development team modifies the code to resolve the vulnerability and performs testing.
5. Verification: The QA team confirms that the modified code contains no new vulnerabilities and verifies that the existing vulnerability has been resolved.
6. Reporting: The security team reports the vulnerability resolution results and updates the related documentation.
7. Notification: The security team notifies the person who reported the vulnerability of the resolution results.

Documentation Approach

Add a section on responding to security vulnerabilities to the external enquiry response procedure within the open source process. (Reference: Open Source Process Template)

3.2.2 Effectively Resourced

To successfully operate an open source security assurance program, simply establishing policies and procedures is not enough. For these policies and procedures to be truly effective, the personnel, budget, and technical expertise needed for the program must be properly secured and allocated. This is critical for ensuring the program’s sustainability and enabling it to respond effectively to a changing threat landscape.

3.2.2.1 Program Role Identification Document

ISO/IEC 18974

• 4.2.2.1: Document with name of persons, group or function in program role(s) identified;
• 4.2.2.1 Document with name of persons, group or function in program role(s) identified.

Self-Certification Checklist

• We have documented the people, group or functions related to the Program.
• We have documented the people, group or functions related to the program.

The program role identification document is a cornerstone for the successful operation of an open source security assurance program. This document helps all stakeholders participating in the program clearly understand their respective roles and responsibilities, and enables efficient collaboration and communication. It also clarifies accountability, preventing confusion and the avoidance of responsibility that can otherwise occur during program operation.

Implementation Methods and Considerations

1. Comprehensive Role Definition:
   • Identify all roles needed to operate the program, and clearly define the objectives, responsibilities, and authority of each role.
   • Consider various roles, such as program manager, security expert, legal personnel, developer, and operations personnel.
2. Responsibility Assignment:
   • Designate a person in charge or team suited to each role, and clearly assign responsibility and authority.
   • The person in charge shall have the expertise and experience required for that role.
3. Using a RACI Matrix (Optional):
   • A RACI (Responsible, Accountable, Consulted, Informed) matrix can be used to define the responsibilities of each role more clearly.
   • A RACI matrix clearly shows who is responsible, who is accountable, who is consulted, and who is informed for each task.
4. Documentation:
   • Document the role definitions, responsibility assignments, and the RACI matrix (optional) so that program participants can easily access them.
   • The document can be posted on the organization’s internal wiki, a shared document repository, or other collaboration tools.
5. Regular Review and Update:
   • The program’s role definitions may change with the organization’s structure, operating methods, and technical environment.
   • Therefore, the role definition document shall be regularly reviewed and updated to keep it current.

Example

Implementation Considerations

• The document shall be written concisely and clearly, so that all program participants can easily understand it.
• The document’s access permissions shall be properly managed to protect confidential information.
• The document shall be regularly reviewed and updated to keep it current.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.2.2.2 Proper Staffing and Funding of Program Roles

ISO/IEC 18974

• 4.2.2.2: The identified program roles have been properly staffed and adequate funding provided;
• 4.2.2.2 The identified program roles have been properly staffed and adequate funding provided.

Self-Certification Checklist

• We have ensured the identified Program roles have been properly staffed and adequate funding has been provided.
• We have ensured the identified program roles have been properly staffed and adequate funding has been provided.

No matter how well the program roles are defined, the program cannot operate properly if there is insufficient personnel to fill those roles or if the necessary funding is not properly provided. Therefore, the organization shall properly staff each role and provide sufficient funding for program operations. This is an essential condition for the successful operation of the program.

Implementation Methods and Considerations

1. Developing a Staffing Plan:
   • Accurately estimate the number of personnel needed for each role.
   • When estimating staffing needs, consider the scope of responsibility, workload, and required skill level for the role.
   • Forecast personnel needs from a long-term perspective, and develop a plan for hiring or reassigning internal personnel.
2. Developing a Budget Plan:
   • Identify all cost items needed to operate the program (personnel costs, training costs, tool purchase costs, consulting costs, etc.) and estimate the budget for each item.
   • The budget shall be estimated on a well-founded basis so that it can realistically be executed.
   • Develop a plan for securing the budget and obtain management approval.
3. Securing and Allocating Resources:
   • Secure the necessary personnel through hiring or the reassignment of internal personnel.
   • Appropriately allocate the secured budget across each item.
   • When allocating resources, consider the program’s priorities and objectives.
4. Regular Review and Adjustment:
   • Regularly review the adequacy of the staffing and budget plan, and adjust it as needed.
   • Update the plan considering program operation status, budget execution status, and changes in the external environment.

Example

• Personnel:
  • Hire two open source security experts for the security team to handle vulnerability analysis and response for open source components.
  • Designate one open source license expert on the legal team to support legal review when using open source.
• Budget:
  • Allocate an annual budget of KRW 50 million for purchasing open source security tools (SCA, SAST, etc.).
  • Allocate an annual budget of KRW 10 million for running the open source security training program.
  • Allocate an annual budget of KRW 20 million for external security consulting costs.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.2.2.3 Identifying Expertise to Resolve Known Vulnerabilities

ISO/IEC 18974

• 4.2.2.3: Identification of expertise available to address identified known vulnerabilities;
• 4.2.2.3 Identification of expertise available to address identified known vulnerabilities.

Self-Certification Checklist

• We have ensured expertise available is to address identified Known Vulnerabilities;
• We have ensured expertise available is to address identified known vulnerabilities.

When a known vulnerability is discovered in an open source component, personnel with expertise in that vulnerability are needed to resolve it quickly and effectively. This expertise can be secured from internal personnel or obtained with the help of external experts. What matters is building a system that can secure and apply the necessary expertise in a timely manner.

Implementation Methods and Considerations

1. Identifying the Required Areas of Expertise:
   • Identify the technical areas of expertise needed to operate the program.
   • Examples: web security, cryptography, network security, systems administration, and open source licensing.
   • Clearly define the level of knowledge and experience required for each area of expertise.
2. Compiling a List of Internal Experts:
   • Compile a list of personnel within the organization who have knowledge and experience in the relevant areas of expertise.
   • Record each expert’s area of expertise, career background, and contact information.
   • The expert list shall be kept up to date.
3. Planning for External Resources:
   • Develop a plan to use external experts or consulting firms in preparation for issues that are difficult to resolve internally.
   • Secure trustworthy external resources and clearly define the contract terms.
4. Establishing an Access Procedure:
   • Establish a procedure so that program participants can easily access the expertise they need.
   • Examples: how to consult an internal expert, how to use an external consulting firm.
   • Document the access procedure so that all program participants are familiar with it.

Specific Examples

• Vulnerability Analysis:
  • If a SQL injection vulnerability is found in a specific open source component, a web security expert is asked to analyze it and identify the attack path and scope of impact.
• Licensing:
  • If interpretation of the obligations of a specific open source license is needed, an open source license expert is asked to conduct a legal review.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.2.2.4 Procedure for Assigning Internal Responsibility for Security Assurance

ISO/IEC 18974

• 4.2.2.4: A documented procedure that assigns internal responsibilities for security assurance.
• 4.2.2.4 A documented procedure that assigns internal responsibilities for security assurance.

Self-Certification Checklist

• We have a documented procedure that assigns internal responsibilities for Security Assurance.
• We have a documented procedure that assigns internal responsibilities for security assurance.

A procedure is established to clearly assign internal responsibility for the effective operation of the open source security assurance program. This procedure is as follows:

1. Party Responsible for Assignment:
   • The Open Source Program Manager (OSPM) leads the internal responsibility assignment procedure.
2. Assignment Procedure:
   • The OSPM convenes an annual responsibility assignment meeting.
   • The OSPM consults with each department head (legal, IT, security, development, quality, etc.) to select a person responsible for each security assurance activity.
   • The list of selected persons in charge is submitted to the OSRB (Open Source Review Board) for final approval.
3. Documentation:
   • The approved responsibility assignment results are drawn up as an official document.
   • The document specifies each security assurance activity, the person responsible, their role, and the required competence.
   • The completed document is registered in the company’s document management system and version-controlled.
4. Assignment Criteria:
   • Define the skills and experience required for each role, and select suitable personnel accordingly.
   • Link responsibility performance to performance evaluations to provide motivation.
5. Regular Review and Renewal:
   • Review the status of responsibility assignments at least once a year and adjust as needed.
   • Update immediately whenever there is a major change, such as an organizational restructuring or personnel transfer.
6. Training and Awareness:
   • Provide the necessary training to newly assigned persons in charge.
   • Share the responsibility assignment results with the entire organization to raise awareness.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.3.3 - 3.3 Open Source Software Content Review and Approval

Open source software has become an essential element in modern software development, but it also carries security and legal risks. Therefore, an organization must build a process to systematically review and approve the open source components included in the supplied software, in order to effectively manage these risks.

3.3.1 Software Bill of Materials

An SBOM (Software Bill of Materials) is a list of all the components, libraries, and dependencies that make up a piece of software. It is akin to a software “parts list,” and it plays a crucial role in ensuring transparency in the software supply chain and identifying potential security vulnerabilities and license-related issues.

3.3.1.1 SBOM Generation and Maintenance Procedure

ISO/IEC 18974

• 4.3.1.1: A documented procedure ensuring all open source software used in the supplied software is continuously recorded across the lifecycle of the supplied software. This includes an archive of all open source software used in the supplied software;
• 4.3.1.1: A documented procedure ensuring all open source software used in the supplied software is continuously recorded across the lifecycle of the supplied software. This includes an archive of all open source software used in the supplied software.

Self-Certification Checklist

• We have a documented procedure ensuring all Open Source Software used in the Supplied Software is continuously recorded across the lifecycle of the Supplied Software. This includes an archive of all Open Source Software used in the Supplied Software.
• We have a documented procedure ensuring all Open Source Software used in the Supplied Software is continuously recorded throughout the lifecycle of the Supplied Software. This procedure includes an archive of all Open Source Software used in the Supplied Software.

An SBOM is not something generated just once; it must be continuously updated and maintained throughout the software lifecycle. This is because, as the software changes, new components may be added or existing components may be updated. Therefore, an organization must clearly define the procedure for generating and maintaining an SBOM and document it.

Implementation Approach and Considerations

1. Select an SBOM generation tool:
   • Select a tool that can automatically generate and manage an SBOM.
   • It is advisable to choose a tool that supports standardized SBOM formats such as SPDX, CycloneDX, and SWID Tag. See the “Comparison of Major SBOM Generation Tools” table below.
   • Integrate the tool into the CI/CD pipeline and configure it to automatically generate an SBOM during the build process.
2. Define the SBOM generation and update cycle:
   • Define the cycle for when to generate and update the SBOM.
   • Generally, an SBOM is generated and updated whenever a new version of the software is released.
   • The SBOM must also be updated whenever there is a change to an open source component.
3. Establish an SBOM verification process:
   • Establish a process for verifying the accuracy and completeness of the generated SBOM.
   • The verification process includes confirming that all components included in the SBOM are accurately identified and checking that no components are missing.
   • An automated tool can also be used to verify the SBOM.
4. Store and version-control the SBOM:
   • Securely store the generated SBOM and perform version control.
   • The SBOM can be stored in the organization’s internal repository or a cloud-based repository.
   • Version control makes it possible to accurately identify the components that made up the software at a specific point in time.
5. Establish an SBOM access and sharing policy:
   • Establish a policy on who can access the SBOM and how the SBOM will be shared.
   • The SBOM must be shared with relevant departments within the organization (for example, the development team, security team, and legal team).
   • The SBOM may also need to be provided upon request from a customer or a regulatory body.

Specific Examples

• Integrate OWASP Dependency-Track into the CI/CD pipeline to automatically generate the SBOM and analyze vulnerabilities during the build process.
• Generate an SBOM whenever a new version of the software is released, and store it in the organization’s internal repository.
• Share the SBOM with the security team, development team, and legal team, and provide it to customers as needed.

Considerations for Implementation

• The SBOM generation and maintenance procedure should be tailored by considering the organization’s size, software development process, and regulatory requirements.
• The SBOM generation process should be automated as much as possible to increase efficiency.
• Efforts should be made to ensure the accuracy and completeness of the information included in the SBOM.

Using Automation Tools

Among the automation tools for SBOM generation and management, open source tools include FOSSLight, SW360, and OSV-SCALIBR. See the guides below for how to install and use these tools.

• FOSSLight
• SW360
• OSV-SCALIBR

Table: Comparison of Major SBOM Generation Tools

Documentation Approach

Include the SBOM generation procedure in the open source process as shown below. (Reference: Open Source Process Template)

3.3.1.2 Evidence of SBOM Management Procedure Compliance

ISO/IEC 18974

• 4.3.1.2: open source software component records for the supplied software that demonstrates the documented procedure was properly followed.
• 4.3.1.2: open source software component records for the supplied software that demonstrate the documented procedure was properly followed.

Self-Certification Checklist

• We have open source component records for the Supplied Software which demonstrate the documented procedure was properly followed.
• Our open source component records for the Supplied Software demonstrate that the documented procedure was properly followed.

Effective SBOM management means more than simply generating an SBOM; it means having a system in place to continuously manage it, keep it up to date, and use it when needed. Evidence of compliance with the SBOM management procedure is used to demonstrate that the organization is properly operating such a system.

Implementation Approach and Considerations

1. Automated SBOM generation process:
   • Integrate an SBOM generation tool into the CI/CD pipeline so that an SBOM is automatically generated during the software build.
   • An automated process increases the consistency and efficiency of SBOM generation and helps reduce human error.
   • The automation tool must record SBOM generation logs and store the resulting files in a designated location.
2. SBOM verification process:
   • Confirm the accuracy and completeness of the SBOM through an automated or manual verification process.
   • The verification process includes comparing the list of components in the SBOM with the list of components actually used in the software and checking for missing or incorrect information.
   • Document the verification results and take corrective action if necessary.
3. SBOM storage and access management:
   • Securely store the SBOM and appropriately manage access permissions.
   • The SBOM can be stored in an internal repository, a version control system, or an SBOM management platform.
   • Manage access permissions on a role basis, and grant access only to those who need it.
4. SBOM update and version control:
   • Update the SBOM and perform version control whenever the software changes.
   • Maintain an SBOM for each version so that the components that made up the software at a specific point in time can be accurately identified.
5. Regular audit and review:
   • Regularly audit and review the effectiveness of the SBOM management process.
   • Use the audit results to improve the process, and update policies and procedures as needed.

Examples of Supporting Evidence

• SBOM generation logs:
  • Record the execution log of the SBOM generation tool, the date and time of generation, and the generation results.
• SBOM files:
  • Securely retain the generated SBOM files and perform version control.
• SBOM verification reports:
  • Record the verification method, verification results, and any issues found along with their resolutions.
• SBOM change history:
  • Record the reason for the change, the details of the change, and the date and time of the change.

Considerations for Implementation

• The SBOM management procedure should be tailored by considering the organization’s size, software development process, and regulatory requirements.
• Tools and systems for SBOM management should be used effectively.
• The SBOM management process should be continuously improved to reflect the latest technology and threat trends.

Documentation Approach

Include the SBOM generation and maintenance procedure in the open source process as shown below. (Reference: Open Source Process Template)

Through this approach, an organization can effectively comply with the SBOM management procedure, ensure transparency in the software supply chain, and effectively respond to potential security threats and legal risks.

3.3.1 Security Assurance

As the use of open source software increases, security assurance has become a core part of the software development and management process. Security assurance refers to the process of identifying and managing vulnerabilities in open source components to strengthen the security of the overall system. It goes beyond simply finding vulnerabilities, aiming to ensure security throughout the entire software lifecycle through continuous monitoring, rapid response, and systematic management.

An effective security assurance program should include the following elements:

1. Vulnerability detection and resolution procedures
2. A continuous monitoring system
3. Security update and patch management
4. Security risk assessment and management
5. Security awareness raising and training

By managing these elements in an integrated manner, an organization can minimize the security risks arising from the use of open source and build a secure software development environment.

3.3.2.1 Vulnerability Detection and Resolution Procedure

ISO/IEC 18974

• 4.3.2.1: A documented procedure for handling detection and resolution of known vulnerabilities for the open source software components of the supplied software;
• 4.3.2.1: A documented procedure for handling the detection and resolution of known vulnerabilities in the open source software components of the supplied software.

Self-Certification Checklist

• We have a documented procedure for handling detection and resolution of Known Vulnerabilities for the Open Source Software components of the Supplied Software.
• We have a documented procedure for handling the detection and resolution of Known Vulnerabilities in the Open Source Software components of the Supplied Software.

Effective security assurance requires a clear, documented procedure for systematically detecting and resolving vulnerabilities found in open source components. This procedure should include the stages of vulnerability detection, severity assessment, response planning, remediation, and result verification, and must clearly define the owner and deadline for each stage.

Implementation Approach and Considerations

1. Documented procedure:
   • Clearly document the vulnerability detection and resolution procedure.
   • The document should specify each stage of the procedure, the owner, the deadline, and the necessary tools and systems.
   • Publish the document on a shared document repository, wiki, or other collaboration tool so that program participants can easily access it.
2. Vulnerability detection:
   • Use an SCA (Software Composition Analysis) tool to detect known vulnerabilities in each open source component included in the SBOM.
     • Examples: OWASP Dependency-Check, Black Duck
   • Periodically update vulnerability databases (for example, NVD and CVE) and check for new vulnerability information.
     • NVD (National Vulnerability Database): A vulnerability database maintained by NIST (National Institute of Standards and Technology) in the United States. It provides vulnerability information indexed by CVE (Common Vulnerabilities and Exposures) ID.
     • CVE (Common Vulnerabilities and Exposures): A list of publicly known information security vulnerabilities maintained by the MITRE Corporation. Each vulnerability is assigned a unique ID (CVE ID).
   • Perform automated vulnerability scans regularly, and conduct manual review when necessary.
   • Recommended open source vulnerability scanning tools are as follows. Detailed guides on installing, configuring, and using these tools are provided in the appendix.
     • OWASP Dependency-Check: Checks open source dependencies for vulnerabilities
     • Trivy: A vulnerability scanner for container images and file systems
3. Severity assessment:
   • Assess the severity of each detected vulnerability.
   • The CVSS (Common Vulnerability Scoring System) score can be used to objectively assess the severity of a vulnerability.
   • Adjust the severity by considering the vulnerability’s exploitability, scope of impact, and potential impact on the system.
4. Response planning:
   • Develop an appropriate response plan according to the vulnerability’s severity.
   • The response plan may include applying a patch, upgrading, mitigation measures, or replacing the component.
   • The response plan should be determined by considering not only technical aspects but also business impact, cost, and time constraints.
5. Executing the remediation:
   • Immediately carry out the necessary action according to the established response plan.
   • When applying a patch or upgrading a component, sufficient testing must be conducted to minimize the impact on the system.
   • When taking a mitigation measure, a long-term resolution must also be prepared.
6. Result verification:
   • After the remediation is complete, verify that the vulnerability has actually been resolved.
   • Rerun the vulnerability scanner to confirm that the vulnerability is no longer detected.
   • Perform a manual review to additionally check for vulnerabilities that the automated tool did not find.
7. Documentation and reporting:
   • Document the activities carried out at each stage, including vulnerability detection, severity assessment, response planning, remediation, and result verification.
   • The documentation should record the vulnerability information, the person responsible, the date and time of execution, and the results.
   • Regularly report the status of vulnerability management, and report to management when necessary.

Considerations for Implementation

• The vulnerability detection and resolution procedure should be tailored by considering the organization’s size, software development process, and security policy.
• Automated tools should be actively used to increase efficiency.
• Close cooperation among security experts, developers, and operators is required.

Documentation Approach

Include the security vulnerability management process in the open source process as shown below. (Reference: Open Source Process Template)

3.3.2.2 Maintaining Vulnerability Records

ISO/IEC 18974

• 4.3.2.2: For each open source software component a record is maintained of the identified known vulnerabilities and action(s) taken (including even if no action was required).
• 4.3.2.2: For each open source software component, a record is maintained of the identified known vulnerabilities and the action(s) taken (including cases where no action was required).

Self-Certification Checklist

• We have open source component records for the Supplied Software which track identified Known Vulnerabilities and action(s) taken (including even if no action was required).
• We have open source component records for the Supplied Software that track identified Known Vulnerabilities and the action(s) taken (including cases where no action was required).

Recording the known vulnerabilities identified for each open source component, along with the actions taken in response, is a core element of effective vulnerability management. These records help track the history of past vulnerabilities and enable a rapid response when similar issues arise. They can also be used for audit and reporting purposes.

Implementation Approach and Considerations

1. Build a vulnerability database:
   • Build a database that can systematically manage all identified vulnerabilities.
   • The database should include the following information:
     • Component name and version
     • Vulnerability ID (for example, CVE)
     • Vulnerability description
     • Severity (for example, CVSS score)
     • Date discovered
     • Response status (for example, resolved, pending, ignored)
     • Details of the response action
     • Person responsible
2. Use automated tools:
   • Integrate with an SCA (Software Composition Analysis) tool to automatically collect vulnerability information and store it in the database.
   • Periodically update the vulnerability database and reflect new vulnerability information.
3. Manual review and update:
   • Manually review vulnerabilities not detected by the automated tool and add them to the database.
   • When the response action for a vulnerability is complete, update the database and record the related information.
4. Generate regular reports:
   • Generate regular reports based on the vulnerability database.
   • Reports may include the following information:
     • The total number of vulnerabilities
     • The distribution of vulnerabilities by severity
     • The list of unresolved vulnerabilities
     • Trends in vulnerability resolution
5. Data security and access control:
   • Since the vulnerability database contains sensitive information, particular attention must be paid to data security.
   • Manage access permissions appropriately, and grant access only to those who need it.

Specific Examples

• Vulnerability tracking system: Manage vulnerability information using an issue tracking system such as Jira, Bugzilla, or YouTrack.
• Spreadsheets: For simple projects, vulnerability information can be managed using a spreadsheet such as Excel or Google Sheets.
• Security dashboard: Build a security dashboard linked to the vulnerability database to monitor the vulnerability status in real time.

Considerations for Implementation

• The vulnerability database must be kept up to date.
• The vulnerability database must be securely stored.
• The vulnerability database must have its access permissions appropriately managed.
• The vulnerability database must be backed up regularly.

Documentation Approach

Include the security vulnerability management process in the open source process as shown below. (Reference: Open Source Process Template)

Through this approach, an organization can systematically manage vulnerabilities in open source components and improve the security level of its software.

3.3.4 - 3.4 Adherence to the specification requirements

For an organization to claim that it operates an open source security assurance program, that program must comply with all the requirements of the ISO/IEC 18974 standard. This chapter provides guidance on how an organization can confirm and maintain compliance with the standard.

4.4.1 Completeness

To declare that a program complies with the ISO/IEC 18974 standard, the organization must formally confirm that the program satisfies all the requirements set out in the standard. Satisfying only some of the requirements is not sufficient.

4.4.1.1 Evidence of Requirement Satisfaction

ISO/IEC 18974

• 4.4.1.1: Documented evidence affirming the program specified in 4.1.4 satisfies all the requirements of this document.
• 4.4.1.1: Documented evidence confirming that the program specified in 4.1.4 satisfies all requirements of this document.

Self-Certification Checklist

• We have documentation confirming that the Program meets all the requirements of this specification.
• We have documented confirmation that the Program satisfies all requirements of this standard.

The organization must present documented evidence demonstrating that the program satisfies all the requirements of the ISO/IEC 18974 standard. This evidence must cover every aspect of the program’s operation and must be objective and reliable.

Implementation Methods and Considerations

1. Requirement mapping:
   • Map each requirement of the ISO/IEC 18974 standard to a specific policy, procedure, or activity of the organization’s program.
   • Document the mapping results and make them easily accessible to program participants.
2. Collecting compliance evidence:
   • Collect evidence demonstrating compliance with each requirement.
   • Evidence can take various forms, such as documents, records, logs, and test results.
   • Evidence must be objective and reliable, and must reflect up-to-date information.
3. Internal audit:
   • An independent audit team assesses the actual state of the program’s operation and confirms compliance with the ISO/IEC 18974 standard.
   • Audit results are documented and reported to management.
   • Necessary corrective actions are taken based on the audit results.
4. Management review:
   • Management reviews the operational status of the program and the audit results, and gives final confirmation of compliance with the ISO/IEC 18974 standard.
   • Management provides guidance for the program’s continuous improvement.

Example Evidence Materials

• Policy documents:
  • Open source policy, security policy, license management policy, etc.
• Procedure documents:
  • Vulnerability management procedure, incident response procedure, SBOM management procedure, etc.
• Records:
  • Vulnerability scan results, code review results, security test results, etc.
• Logs:
  • System access logs, change logs, audit logs, etc.
• Test results:
  • Functional test results, security test results, performance test results, etc.

Implementation Considerations

• Evidence must be objective and reliable.
• Evidence must reflect up-to-date information.
• Evidence must be managed systematically, with access rights appropriately controlled.

Documentation Approach

Include the following content within the open source policy. (Reference: Open Source Policy Template)

Through this approach, the organization can demonstrate that the program satisfies all the requirements of the ISO/IEC 18974 standard and build external trust.

4.4.2 Duration

ISO/IEC 18974

• 4.4.2.1: A document affirming the program meets all the requirements of this specification, within the past 18 months of obtaining conformance validation.
• 4.4.2.1: A document confirming that, within the past 18 months since the program obtained conformance validation, it satisfies all requirements of this specification.

Self-Certification Checklist

• We have documentation confirming that Program conformance was reviewed within the last 18 months.
• We have a record confirming that the Program’s compliance was reviewed within the past 18 months.

Compliance with the ISO/IEC 18974 standard is not a one-time event but an ongoing process. Therefore, even after obtaining compliance with the standard, an organization must make continuous efforts to maintain that status. This section explains the requirements related to the compliance period.

4.4.2.1 Documentation Confirming the Compliance Period

A program that complies with the ISO/IEC 18974 standard is valid for 18 months from the date it received compliance validation. Therefore, within 18 months after the program receives compliance validation, the organization must present a document confirming that the program still satisfies all the requirements of the standard. This is important for demonstrating that the program has not drifted from the standard over time and is being continuously improved.

Implementation Methods and Considerations

1. Recording the compliance validation date:
   • Accurately record the date on which the program received ISO/IEC 18974 compliance validation.
   • Keep the compliance validation certificate or related documents as evidence.
2. Establishing a compliance renewal plan:
   • Before the compliance period expires, establish a plan to revalidate compliance status and renew it if necessary.
   • The plan may include activities such as a self-assessment of compliance status, internal audits, and external reviews.
3. Periodic review of compliance status:
   • During the compliance period, periodically review whether the program still satisfies all the requirements of the ISO/IEC 18974 standard.
   • Perform the review at least once every 6 months, and document the review results.
   • If the review finds a part that does not comply with the standard, take corrective action immediately.
4. Reviewing all requirements again before renewal:
   • Before the compliance period expires, conduct a full review of whether the program once again satisfies all the requirements of the ISO/IEC 18974 standard.
   • This review may be performed by an independent audit team or external experts.
   • Document the review results and report them to management.

Example Evidence Materials

• Compliance validation certificate: An official document certifying that ISO/IEC 18974 compliance validation was obtained.
• Compliance renewal plan: A document describing the concrete plan for maintaining and renewing compliance status.
• Periodic review report: A report recording the results of periodically reviewing compliance status.
• Full requirement re-review report: A report recording the results of re-reviewing, before compliance renewal, whether the program satisfies all requirements of the standard.

Implementation Considerations

• Maintaining compliance status requires continuous effort and investment of resources.
• The organization must monitor changes to the ISO/IEC 18974 standard and make the adjustments the program needs.
• The importance of standard compliance must be emphasized to program participants, and responsibility must be assigned to them.

Documentation Approach

Include the following content within the open source policy. (Reference: Open Source Policy Template)

Through this approach, the organization can continuously maintain compliance with the ISO/IEC 18974 standard and provide customers with safe and trustworthy open source software.

3.4 - 4. Comparison and Integration with ISO/IEC 5230

This chapter compares and analyzes ISO/IEC 5230 for open source compliance management and ISO/IEC 18974 for open source security assurance, and presents a way to integrate the two standards to build a more effective open source management system.

4.1 Similarities and Differences

ISO/IEC 5230 and ISO/IEC 18974 are both international standards for open source management, but they differ in their main objectives, scope of application, and core requirements. It is important to understand both standards and apply them appropriately to the organization’s circumstances.

Table 4.1: Main Similarities Between ISO/IEC 5230 and ISO/IEC 18974

Table 4.2: Main Differences Between ISO/IEC 5230 and ISO/IEC 18974

How does ISO/IEC 5230 ensure license compliance?

To ensure open source license compliance, ISO/IEC 5230 requires the following.

• License identification process: The organization must accurately identify the licenses of all open source components it uses. This can be done using license identification tools or by manually reviewing the code.
• Compliance with license obligations: The organization must comply with all obligations of the identified licenses. For example, if the organization uses a component under the GPL (GNU General Public License), it may be required to disclose its source code.
• Fulfillment of notice obligations: The organization must notify users of the license information for open source components. This can be done by including notice text within the software product or by providing a separate license file.

How does ISO/IEC 18974 manage security vulnerabilities?

To manage open source security vulnerabilities, ISO/IEC 18974 requires the following.

• Using vulnerability scanning tools: The organization must periodically scan open source components for known vulnerabilities using automated vulnerability scanning tools.
• Assessing vulnerabilities and prioritizing them: For each vulnerability found, the organization must assess its severity, impact, and exploitability, and determine a response priority.
• Applying patches or mitigation measures: According to priority, the organization must apply patches to vulnerabilities or implement mitigation measures (e.g., changing firewall settings, modifying code).
• Periodically reviewing the vulnerability management process: The organization must periodically review the effectiveness of the vulnerability management process and improve it as needed.

4.2 The Complementary Relationship Between the Two Standards

ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance) are independent standards, but when an organization implements them together, it can create a synergistic effect in open source management. Understanding the areas each standard covers and leveraging their complementary relationship makes it possible to build a stronger open source management system.

1. Building an integrated open source management system
   • Legal risk management (ISO/IEC 5230): Compliance with open source licenses reduces the likelihood of legal disputes such as copyright and patent infringement.
   • Security risk management (ISO/IEC 18974): Managing the risk of vulnerabilities and malicious code infection in open source components reduces the likelihood of security incidents.
   • Integrated management: Rather than managing legal risk and security risk separately, building an integrated system improves efficiency.
2. Process synergy
   • Using an SBOM (Software Bill of Materials): An SBOM can be used to manage license information and security vulnerability information together. Recording both license information and vulnerability information in the SBOM makes it possible to grasp the legal and security risks of each component at the same time.
   • Integrating documentation and training programs: Efficiency can be improved by integrating open source policies, license compliance procedures, and security guidelines into a single document and jointly operating training programs.
3. Optimizing organizational structure
   • Using an OSPO (Open Source Program Office): An OSPO can be used to manage the requirements of both standards in an integrated way. The OSPO oversees open source policy development, process management, and tool adoption, and facilitates cooperation between the legal and security teams.
   • Strengthening cooperation between the legal and security teams: The legal team assesses the legal risks related to open source licenses, and the security team analyzes the security vulnerabilities of open source components. The two teams work together to conduct a comprehensive risk assessment of open source use and develop appropriate response measures.
4. Strengthening supply chain management
   • Considering both standards together when evaluating suppliers: When receiving software from a supplier, both ISO/IEC 5230 and ISO/IEC 18974 are used as criteria for evaluating the supplier’s open source management system. This helps raise the level of open source management across the entire supply chain.
   • Specifying contract terms: Supply contracts specify requirements related to open source license compliance and security, and require suppliers to comply with them.

Table 4.3: The Complementary Relationship Between ISO/IEC 5230 and ISO/IEC 18974

4.3 Integrated Implementation Strategy

ISO/IEC 5230 (open source license compliance) and ISO/IEC 18974 (open source security assurance) each address a different aspect, but an organization can implement both standards in an integrated way to create a synergistic effect. This section presents concrete strategies and action plans for effectively integrating the two standards.

1. Adopting a phased approach
   • Implementing ISO/IEC 5230 first: Implement ISO/IEC 5230 first to build a basic license compliance system. This helps reduce the legal risk associated with open source use and establish a compliance culture within the organization.
   • Adding ISO/IEC 18974: After implementing ISO/IEC 5230, introduce ISO/IEC 18974 to strengthen the security management system. This helps effectively manage vulnerabilities in open source components and strengthens the security of the software supply chain.
   • Establishing an integrated roadmap: An integrated roadmap can also be established to consider both standards at once and implement them in parallel. In this case, both legal and security aspects can be considered from the initial stage to build a balanced open source management system.
2. Leveraging common elements
   • Integrating policies and processes: Elements commonly required by both standards, such as the open source usage policy, the SBOM (Software Bill of Materials) management process, and training programs, are integrated and managed together. This helps reduce duplicated work and improve management efficiency.
   • Integrating tools: License scanning tools and vulnerability scanning tools are integrated, or tools that allow SBOM data to be shared are used to facilitate information sharing.
3. Integrating organizational structure and roles
   • Using an OSPO (Open Source Program Office): Open source-related activities are managed in an integrated way centered on the OSPO. The OSPO is composed of experts from various departments, including legal, security, and development, and supports comprehensive decision-making about open source use.
   • Clarifying responsibilities and authority: The responsibilities and authority of each role (e.g., legal team, security team, development team) are clearly defined, and a collaborative framework is established.
4. Continuous cooperation and information sharing
   • Regular meetings: Regular meetings between the legal, security, and development teams share the latest open source information, threat trends, and issues.
   • Information sharing platform: An information sharing platform (e.g., an internal wiki, a collaboration tool) is built where open source-related information can be shared and discussed.
   • Education and training: Training programs on open source licensing and security are jointly developed and delivered to all employees.

Table 4.4: Integrated Implementation Strategy for ISO/IEC 5230 and ISO/IEC 18974

3.5 - 5. Implementation Considerations by Organizational Characteristics

To effectively implement the ISO/IEC 18974 standard, a tailored approach that considers the organization’s characteristics is necessary. This section describes in detail the approaches for large enterprises, small and medium-sized enterprises (SMEs), and startups, integration with existing security processes, and education and awareness programs.

5.1 Approaches by Large Enterprises, SMEs, and Startups

5.1.1 Large Enterprises

Large enterprises must manage complex organizational structures, diverse projects, and a wide range of technology stacks, so a systematic and comprehensive approach is essential. In addition, they must pay closer attention to compliance with legal and regulatory requirements, supply chain management, and protection of brand reputation.

• Establishing a dedicated Open Source Program Office (OSPO): The OSPO functions as a central organization that establishes and manages the organization-wide open source strategy. The OSPO performs the following roles, which are important for ensuring consistent policies and processes.

  • Establishing and managing open source policy: Establishes and manages policies for open source use and contribution across the organization. Policies must reflect legal requirements, security guidelines, and the organization’s business goals.
  • Managing open source compliance: Verifies compliance with open source licenses and resolves related issues.
  • Managing security vulnerabilities: Manages the process of identifying, assessing, and patching vulnerabilities in open source components.
  • Participating in open source communities: Contributes to open source projects and builds relationships with the community.

  Success cases: Large technology companies such as Google, Microsoft, and Facebook systematically manage their open source strategies through an OSPO. Through their OSPOs, these companies encourage open source use, contribute to communities, and manage legal and security risks at the same time.

• Designating open source coordinators by department: Designates an open source coordinator for each department or project team to ensure smooth communication with the OSPO. The coordinator complies with the guidelines provided by the OSPO and reports on the status of open source use within the department.

• Adopting advanced tools and processes: Adopts advanced Software Bill of Materials (SBOM) generation tools and vulnerability scanning solutions to manage large codebases and complex dependencies.

  • Example: Implements automated open source management using commercial tools such as WhiteSource, Black Duck, and Snyk. These tools quickly scan large codebases, generate accurate SBOMs, and provide diverse vulnerability information.

• Managing a complex supply chain: Builds a systematic process to track and manage open source use by various suppliers and partners.

  • Specifies open source security requirements in supplier contracts and verifies compliance through regular audits. Contract terms may include an obligation to provide an SBOM, sharing of vulnerability information, and allocation of responsibility in the event of a security incident.

Table 5.1: Key Elements for ISO/IEC 18974 Implementation in Large Enterprises

5.1.2 Small and Medium-Sized Enterprises

SMEs have more limited resources than large enterprises, so an efficient implementation strategy is needed. The key is to choose cost-effective solutions, leverage the capabilities of existing teams, and, where necessary, seek help from outside experts.

• Designating an open source lead within an existing team: Instead of a dedicated OSPO, designates an open source security lead within the existing development or security team. The lead performs roles such as complying with open source policy, managing SBOMs, and checking vulnerabilities.
• Using cloud-based open source management tools: Considers cloud-based solutions to reduce initial investment costs and secure flexibility.
  • Example: Uses the open source management features provided by cloud-based collaboration platforms such as GitHub and GitLab. These platforms provide source code management, collaboration, build automation, and basic security scanning features.
• Considering advice from outside experts: Seeks advice from outside consultants or experts as needed to pursue efficient implementation.
  • Uses an open source security consulting firm to receive short-term technical support and training. Outside experts can provide specialized knowledge on SBOM generation, vulnerability scanning, and license compliance.
• Choosing cost-effective solutions: Optimizes costs by using open source tools or low-cost commercial solutions.
  • Example: Uses free or inexpensive tools such as OWASP Dependency-Check and Snyk Open Source. These tools provide basic SBOM generation and vulnerability scanning features and can be fully utilized even within an SME’s budget.

Table 5.2: Key Elements for ISO/IEC 18974 Implementation in SMEs

5.1.3 Startups

Startups need a flexible approach that can respond to rapid growth and change. The key is to integrate security into the development process, actively use automation tools, and increase efficiency through fast decision-making.

• Applying a simplified agile process: Adopts a simplified approach that focuses on core requirements instead of a complex process.
  • Simplifies the open source use approval procedure and allows developers to choose open source components autonomously. However, important security or license-related matters must always be reviewed.
• Integrating open source security management into the development process: Integrates security checks into the existing development workflow rather than as a separate process (DevSecOps).
  • Adds SBOM generation and vulnerability scanning steps to the CI/CD pipeline. This allows security vulnerabilities to be automatically checked during the development process and resolved before code deployment.
• Actively using automation tools: Makes maximum use of automation tools for efficient management with limited personnel.
  • Example: Uses automation tools such as GitHub Actions and GitLab CI to automate SBOM generation and vulnerability scanning. These tools are relatively simple to configure and can be easily integrated into the development workflow.
• Fast decision-making and execution: Uses a flexible organizational structure to drive rapid decision-making and policy implementation.
  • Open source-related decisions are made quickly by the development team lead or the Chief Technology Officer (CTO). Advice from the legal or security team can be sought during the decision-making process, but decision-making speed should not be slowed down.

Table 5.2: Key Elements for ISO/IEC 18974 Implementation in Startups

Success cases:

• Netflix: Netflix developed an open source tool called “Security Monkey” to automate security in cloud environments. This encouraged developers to consider security more easily and contributed to reducing the burden on the security team.
• Spotify: Spotify succeeded in strengthening security while maintaining development speed by integrating security checks into its continuous deployment pipeline.

Key considerations:

• Risk-based approach: Rather than applying the same level of security management to all open source components, it is better to prioritize components with a higher level of risk.
• Continuous learning: Open source security threats are constantly changing, so it is necessary to continuously learn the latest trends and update security practices.
• Community participation: Participating in open source communities and collaborating with other organizations to help strengthen open source security is also a good approach.

5.2 Integration with Existing Security Processes

To successfully implement ISO/IEC 18974, smooth integration with existing security processes is essential. Integrating open source security management into the existing security system reduces redundant investment, increases efficiency, and achieves consistent security management.

1. Analyzing current security policy

   • Reviewing existing policy: Reviews the organization’s existing security policies, such as information security policy, privacy policy, and risk management policy, to identify parts related to ISO/IEC 18974 requirements.
   • Performing gap analysis: Analyzes the differences between existing policy and ISO/IEC 18974 requirements and identifies parts that need to be supplemented.
   • Integrating policy: Adds open source security-related provisions to existing policy, or establishes a separate open source security policy and integrates it with existing policy.

   Example:

   • Adds a provision to the existing information security policy stating that “security review procedures must be followed when using open source software.”
   • Adds a provision to the privacy policy stating that “encryption and access control measures must be strengthened when using open source components that process personal information.”

2. Using the DevSecOps framework

   • Integrating the CI/CD pipeline: Integrates open source security management into the Continuous Integration/Continuous Delivery (CI/CD) pipeline to build a DevSecOps environment that considers security from the early stages of development.
   • Automated security checks: Automates steps such as Software Bill of Materials (SBOM) generation, license checking, and vulnerability scanning in the CI/CD pipeline.
   • Feedback loop: Provides rapid feedback of security check results to the development team so that fixes can be made.

   Example:

   • Uses CI/CD tools such as Jenkins, GitLab CI, and CircleCI to automate SBOM generation and vulnerability scanning steps.
   • Integrates Static Application Security Testing (SAST) tools such as SonarQube and Veracode into the CI/CD pipeline to check code quality and security vulnerabilities.

3. Linking with the risk management process

   • Identifying risk: Identifies risks arising from open source use (e.g., exploitation of vulnerabilities, license violations) and records them in the risk management register.
   • Assessing risk: Assesses the severity, likelihood of occurrence, and business impact of identified risks.
   • Responding to risk: Prepares and executes appropriate response measures (e.g., applying patches, mitigation measures, discontinuing use) according to the assessed risk.
   • Monitoring risk: Continuously monitors the effectiveness of the risk management plan and revises the plan as needed.

   Example:

   • Adds a risk item to the risk management register stating “use of open source components with severe vulnerabilities such as Log4Shell.”
   • Assesses the likelihood of occurrence of the corresponding risk as “medium” and severity as “high,” and establishes a response plan of “applying a patch within 24 hours of vulnerability discovery.”

4. Updating the incident response plan

   • Adding open source-related scenarios: Adds open source-related scenarios (e.g., exploitation of vulnerabilities, license violations) to the existing incident response plan.
   • Defining response procedures and responsible parties: Clearly defines the response procedure and responsible party for each scenario.
   • Training and simulation: Conducts regular training and simulations to improve response capability in the event of an open source-related security incident.
   • Reviewing insurance enrollment: Considers enrolling in cyberattack insurance to prepare for open source-related legal liability (e.g., copyright infringement lawsuits).

   Example:

   • Adds a scenario to the incident response plan stating “a zero-day vulnerability is discovered in an open source component,” and clearly defines the response procedure and responsible party.
   • Includes a scenario exploiting an open source vulnerability during penetration testing exercises to check response capability.

Table 5.3: Methods for Integration with Existing Security Processes

5.3 Education and Awareness Programs

Understanding and participation across the entire organization is essential for effective ISO/IEC 18974 implementation. Education and awareness programs should support organization members in recognizing the importance of open source security and fulfilling their own roles and responsibilities.

1. Developing tailored education programs by audience
   • Developers: Provides education on secure coding practices, major open source licenses, and vulnerability response methods.
     • Example: Provides security training courses such as OWASP Top 10 and SANS Top 25, and trains developers on how to find security vulnerabilities during code review.
   • Security team: Provides education on open source security audits, incident response procedures, and the latest security threat trends.
     • Example: Strengthens practical capability through penetration testing exercises and breach incident analysis workshops.
   • Legal team: Provides education on types of open source licenses, legal liabilities and obligations, and related laws.
     • Example: Provides legal lectures on major open source licenses such as the GNU General Public License (GPL), Apache License, and MIT License.
   • Executive management: Provides education on the need for open source security investment, Return on Investment (ROI), and risk management.
     • Example: Supports participation in open source security-related workshops or seminars and provides investment effectiveness analysis reports.
2. Using various education methods
   • Building an online learning platform: Provides a learning environment not restricted by time or place.
     • Example: Uses online education platforms such as Coursera and Udemy, or builds an in-house Learning Management System (LMS).
   • Running workshops and hands-on sessions: Provides practice-centered learning opportunities through real cases.
     • Example: Conducts web application security vulnerability diagnosis workshops using tools such as OWASP ZAP and Burp Suite.
   • Seminars inviting outside experts: Provides opportunities to share the latest trends and best practices and to acquire specialized knowledge.
3. Continuous awareness-raising activities
   • Running an internal newsletter or blog: Regularly shares the latest open source security news, vulnerability information, and success cases.
   • Conducting in-house security campaigns: Conducts campaigns that emphasize the importance of open source security and encourage member participation.
   • Running a “Security Champions” program: Trains personnel in each team to lead the security culture and encourages security-related activities.
4. Building an evaluation and feedback system
   • Measuring education effectiveness: Sets Key Performance Indicators (KPIs) to measure the effectiveness of education programs and evaluates them regularly. (e.g., education completion rate, evaluation of security knowledge improvement)
   • Collecting feedback: Collects and analyzes feedback on education programs and uses it to improve programs.
   • Reflecting improvements: Continuously improves the content, methods, and frequency of education programs based on evaluation results and feedback.

Table 5.4: Elements of Education and Awareness Programs