Guide

• 1: [2026] ISO Standard-Based Enterprise Open Source Management Guide
• 1.1: 0. Exploring OpenChain
• 1.2: 1. Organization
• 1.3: 2. Policy
• 1.4: 3. Process
• 1.5: 4. Tools
• 1.6: 5. Education
• 1.7: 6. Conformance
• 2: ISO/IEC 5230 Conformance Guide
• 2.1: §3.1 Program Foundation
• 2.1.1: §3.1.1 Policy
• 2.1.2: §3.1.2 Competence
• 2.1.3: §3.1.3 Awareness
• 2.1.4: §3.1.4 Program Scope
• 2.1.5: §3.1.5 License Obligations
• 2.2: §3.2 Relevant Tasks
• 2.2.1: §3.2.1 External Inquiry Response
• 2.2.2: §3.2.2 Effective Resources
• 2.3: §3.3 Content Review and Approval
• 2.3.1: §3.3.1 SBOM
• 2.3.2: §3.3.2 License Compliance
• 2.4: §3.4 Compliance Artifacts
• 2.4.1: §3.4.1 Artifacts
• 2.5: §3.5 Community Engagement
• 2.5.1: §3.5.1 Contributions
• 2.6: §3.6 Adherence to the Specification
• 2.6.1: §3.6.1 Conformance
• 2.6.2: §3.6.2 Duration
• 3: ISO/IEC 18974 Conformance Guide
• 3.1: §4.1 Program Foundation
• 3.1.1: §4.1.1 Policy
• 3.1.2: §4.1.2 Competence
• 3.1.3: §4.1.3 Awareness
• 3.1.4: §4.1.4 Program Scope
• 3.1.5: §4.1.5 Standard Practice Implementation
• 3.2: §4.2 Relevant Tasks
• 3.2.1: §4.2.1 Access
• 3.2.2: §4.2.2 Effectively Resourced
• 3.3: §4.3 Content Review and Approval
• 3.3.1: §4.3.1 SBOM
• 3.3.2: §4.3.2 Security Assurance
• 3.4: §4.4 Conformance
• 3.4.1: §4.4.1 Completeness
• 3.4.2: §4.4.2 Duration
• 3.5: ISO/IEC 5230 vs 18974 Comparison
• 4: Templates
• 4.1: Open Source Policy
• 4.2: Open Source Process
• 5: Tools
• 5.1: FOSSology
• 5.2: SW360
• 5.3: FOSSLight
• 5.4: OSV-SCALIBR
• 5.5: cdxgen
• 5.6: Syft
• 5.7: Dependency-Track
• 6: Archive
• 6.1: NIPA OpenChain Guide
• 6.1.1: I. OpenChain Project란?
• 6.1.1.1: 1. OpenChain Specification
• 6.1.1.2: 2. OpenChain Conformance
• 6.1.1.3: 3. OpenChain Curriculum
• 6.1.2: II. OpenChain Specification 준수 방법
• 6.1.2.1: 1. 프로그램 성립
• 6.1.2.2: 2. 관련 업무 정의 및 지원
• 6.1.2.3: 3. 오픈소스 콘텐츠 검토 및 승인
• 6.1.2.4: 4. 컴플라이언스 결과물 생성 및 전달
• 6.1.2.5: 5. 오픈소스 커뮤니티 참여에 대한 이해
• 6.1.2.6: 6. 설명서 요건 준수
• 6.1.3: 부록
• 6.1.3.1: 1. 샘플 오픈소스 정책 for OpenChain 2.1
• 6.1.3.2: 2. 오픈소스 컴플라이언스 프로세스 (template)
• 6.1.3.3: 3. 오픈소스도구 (FOSSology, SW360)
• 6.1.3.3.1: FOSSology
• 6.1.3.3.2: SW360
• 6.2: [out of date] Open Source Governance for Enterprises
• 6.2.1: 1. What is ISO/IEC 5230
• 6.2.2: 2. Essential elements
• 6.2.3: 3. Team
• 6.2.4: 4. Policy
• 6.2.5: 5. Process
• 6.2.6: 6. Tool
• 6.2.7: 7. Training
• 6.2.8: 8. Conformance
• 6.2.9: Appendix
• 6.2.9.1: 1. Open Source Policy (Sample)
• 6.2.9.2: 2. Open Source Compliance Process (Sample)

1 - [2026] ISO Standard-Based Enterprise Open Source Management Guide

International Standards for Open Source Management

There are two global standards for open source management:

1. ISO/IEC 5230: OpenChain Specification - International standard for open source compliance.
2. ISO/IEC 18974: OpenChain Security Assurance Specification - International standard for Open Source Security

OpenChain and ISO/IEC 5230

ISO/IEC 5230 is the only international standard for open source compliance, defining the core requirements for organizations to build an effective open source program. For details, see the OpenChain Overview page.

How Should Companies Manage Open Source?

By complying with the requirements of ISO/IEC 5230 and ISO/IEC 18974, companies can establish an effective open source management system. To do this, companies need the following six core elements:

1. Organization: Dedicated team for open source management
2. Policy: Clear open source policy established and documented
3. Process: Systematic processes for open source use, contribution, and distribution
4. Tools: Automated tools for open source inspection, tracking, and management
5. Education: Awareness and capability-building training for employees
6. Conformance: Maintaining standards compliance through continuous monitoring and improvement

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

References

1.1 - 0. Exploring OpenChain

1. What is the OpenChain Project?

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

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

In December 2009, there was a lawsuit involving an open source project called Busybox. Busybox is an open source project licensed under GPL-2.0 that is widely used in embedded systems, and 14 companies — including two Korean companies — were named in the lawsuit. A notable aspect of this case is that some of the companies sued were those that had only distributed the product without developing it themselves.

In this complex software supply chain environment, even if one company has excellent processes in place, it is extremely difficult to achieve complete open source compliance on its own. Ultimately, for a company to properly fulfill its open source compliance obligations, all members of the software supply chain must comply with license obligations and provide accurate open source information. This trust must be built across the entire supply chain.

The Linux Foundation’s OpenChain project was founded on the belief that by concisely and consistently defining the key requirements companies must follow for open source compliance, and ensuring universal adherence, trust in the open source license dimension can be built across the entire software supply chain.

At an open source conference in Europe in 2016, Dave Marr, an open source lawyer at Qualcomm, emphasized exactly this point. To raise the level of open source compliance at one company, the level of compliance across all members of the software supply chain must be raised. He also suggested that leading companies with a deep understanding of open source and already established policies and processes open up their assets and know-how so that anyone can reference them. Conference participants resonated with the idea that “open source compliance is not an area where companies can differentiate their business advantages. Companies want to manage risk at an appropriate level with minimal resources. Therefore, the more companies share their assets with each other, the more all can achieve compliance together with fewer resources.” And so the OpenChain project (then a Work Group) was born, with global companies such as Qualcomm, Siemens, Wind River, ARM, and Adobe joining.

The OpenChain project provides companies with three major things to help them achieve open source compliance more easily:

1. OpenChain Specification
2. OpenChain Conformance Certification
3. Documentation and Resources

Let’s explore how companies can leverage each of these.

2. OpenChain Specification and ISO/IEC Standards

The OpenChain Specification is a 10-page document defining the core requirements for open source compliance. OpenChain Specification Version 1.0 was released in 2016. The OpenChain Specification is designed to be suitable for all companies regardless of their size or industry.

In 2020, Version 2.1 of the specification was released, defining six core requirements that companies must fulfill to achieve open source compliance, along with a list of materials needed to demonstrate compliance.

1. Program Foundation
2. Relevant Tasks Defined and Supported
3. Open Source Content Review and Approval
4. Compliance Artifact Creation and Delivery
5. Understanding Open Source Community Engagements
6. Adherence to the Specification Requirements

For companies just starting with open source compliance, a good strategy is to work through each of the OpenChain Specification’s requirements one by one to improve their level.

This OpenChain Specification was formally registered as ISO/IEC 5230:2020, the international standard for open source compliance, in December 2020.

The OpenChain Specification, which had been a de facto standard for the past four years, was converted into the formal international standard ISO/IEC 5230:2020 — the first international standard defining open source compliance and process management. This has heightened interest among global IT companies in complying with ISO/IEC 5230, and it is expected that more companies in the software supply chain will begin requiring suppliers to comply with ISO/IEC 5230.

In 2023, a new standard for open source security assurance, ISO/IEC 18974, was announced. 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 key areas where security processes are needed
2. How to assign roles and responsibilities
3. How to ensure the sustainability of processes

Like ISO/IEC 5230, ISO/IEC 18974 is concise and easy to understand, and is supported by the global community to provide free reference materials and conformance resources.

These two standards work together to help organizations effectively manage license compliance and security assurance for open source software. While ISO/IEC 5230 focuses on license compliance, ISO/IEC 18974 focuses on security vulnerability management, making them complementary to each other.

3. How to Obtain ISO/IEC Standard Certification

If a company complies with all the requirements of both ISO/IEC 5230 and ISO/IEC 18974, it can be certified as having an open source program conformant with these standards. An open source program refers to the set of management systems — including policies, processes, and personnel — that a company uses to carry out open source compliance and security assurance activities.

The image below lists the item numbers required by ISO/IEC 5230. Companies that satisfy all of these items can be recognized as having established a transparent and trustworthy open source governance system in the software supply chain.

The OpenChain Project proposes three methods of certification:

• Self-certification
• Independent evaluation
• Third-party certification

Let’s look at each method.

(1) Self-certification

Self-certification is the most recommended method by the OpenChain project, with the advantage of being free of charge. The OpenChain Project provides an ISO/IEC 5230 self-certification website so that companies can verify for themselves whether they comply with the OpenChain Specification. The open source officers of a company can register on this website and begin the online self-certification process. Self-certification proceeds by answering Yes/No questions as shown below.

If a company has established its open source compliance system well enough to answer Yes to all the questions in the OpenChain self-certification, it can submit those results on the website (Conforming Submission). After a simple confirmation procedure by the Linux Foundation, the company can then declare ISO/IEC 5230 conformance.

By making this conformance declaration, the company is recognized in the Global Software Supply Chain as having an open source program that complies with ISO/IEC 5230.

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

In addition, companies can use the self-certification process to identify what is lacking and what additional activities are needed. This guide explains how to comply with ISO/IEC 5230 and ISO/IEC 18974 requirements for each major component such as organization, policy, and process.

Companies that lack the capacity to make improvements on their own through this guide alone may consider the independent evaluation method.

(2) Independent Evaluation

In an independent evaluation, an independent external organization assesses and evaluates a company’s open source compliance and security assurance status from a fair perspective. The distinguishing feature of an independent evaluation is that it not only generates an assessment report but also provides consulting to address the identified deficiencies. (However, it does not issue an accredited certification.)

Companies can improve their compliance and security assurance levels through fair assessment and consulting from an independent organization, and then go through a repeating process of independent evaluation again to refine policies and build processes.

Ultimately, the company reaches the level where it can obtain ISO/IEC 5230 and ISO/IEC 18974 certification, at which point it can enter the process of obtaining self-certification or third-party certification. Independent evaluation thus supports companies in raising their level of open source compliance and security assurance through assessment and consulting, helping them obtain conformant programs and achieve certification.

Companies offering independent evaluation include AlektoMetis, Source Code Control, and others.

In Korea, the Conformance Group, a subgroup of the OpenChain Korea Work Group, operates as a community where companies discuss and share methods for complying with ISO/IEC 5230 and ISO/IEC 18974 independently. Any OpenChain Korea Work Group member is welcome to participate and receive assistance.

(3) Third-party Certification

If a company wants to demonstrate a more credible and transparent level of open source compliance and security assurance to buyers in the software supply chain, it can obtain a certificate from a third-party certification body and use it for promotional purposes. Additionally, some buyers who require a more robust level of trust in open source compliance and security assurance may mandate third-party certification from their suppliers.

As of 2024, the officially recognized OpenChain third-party certification bodies are ORCRO, PWC, TÜV SÜD, Synopsys, and Bureau Veritas.

These bodies provide assessments to verify conformant programs under ISO/IEC 5230 and ISO/IEC 18974 and issue certificates to companies that pass.

As of 2024, there are still few buyers or organizations that mandatorily require third-party certification. However, in the European automotive industry, some experts predict that it will not be long before ISO/IEC 5230 and ISO/IEC 18974 are mandated for automotive software suppliers, similar to ASPICE (Automotive SPICE, the international standard process model for automotive software development).

For detailed information on the self-certification process, you can refer to the following slides:

• OpenChain Korea 9th Meeting - How to Self Certify

4. OpenChain Resources

The OpenChain Project provides a variety of documentation such as policy document templates and educational materials needed by companies to build their compliance programs. These materials are designed to help comply with the OpenChain Specification and support general open source compliance activities, and are provided under a CC-0 license so anyone can use them freely.

Much of the content in this guide is also based on materials published by OpenChain. Open source officers at each company are encouraged to look to OpenChain Resources first when they need policies, processes, or educational materials. These materials are also being translated into Korean. The OpenChain Korea Work Group is leading these translation efforts. Anyone interested can participate in the Korean translation.

The OpenChain Project also runs various webinars and study groups to provide additional resources:

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, with recordings also available.

2. Educational Materials: The OpenChain Project provides a comprehensive educational curriculum to help companies develop internal training programs. These materials cover a wide range of topics from the basics of open source software to license compliance and security assurance.

By utilizing these diverse resources, companies can build and maintain a robust open source program that complies with the ISO/IEC 5230 and ISO/IEC 18974 standards.

5. Trends in ISO/IEC Standard Adoption

The adoption of ISO/IEC 5230 and ISO/IEC 18974 standards is showing an increasingly expanding trend in the global software supply chain.

In early 2021, news emerged that German automotive manufacturers began requiring parts suppliers to have plans to comply with ISO/IEC 5230. In response, a European open source professor stated, “It is obvious that software supply chain buyers will require suppliers to comply with ISO/IEC 5230 in the future,” predicting that “it will take a position similar to ASPICE in the automotive industry.”

Reflecting this forecast, in May 2021, Volkswagen Group’s Scania included a requirement to comply with ISO/IEC 5230 in its own corporate standard (STD 4589) that suppliers must follow.

Also, in July 2021, automotive and industrial technology company Bosch declared that all group companies would have programs complying with ISO/IEC 5230 by year’s end. The industry predicts that it is only a matter of time before all automakers and other industries begin requiring ISO/IEC 5230 within the software supply chain.

In 2023, a new standard for open source security assurance, ISO/IEC 18974, was announced. This standard defines the core requirements for managing known security vulnerabilities in open source software. Together with ISO/IEC 5230, ISO/IEC 18974 helps organizations effectively manage 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 demonstrates that domestic companies are also actively adopting international standards for open source security management.

The activities of the OpenChain Korea Work Group are also becoming more vibrant. At the 22nd regular meeting held in June 2024, discussions were held on the current state of preparations for the ISO/IEC 18974 open source security standard and guidelines for SBOM-based SW supply chain management. This shows that domestic companies are actively embracing the ISO/IEC 5230 and ISO/IEC 18974 standards.

This trend is expected to continue in the future. As the complexity of software supply chains increases and security threats grow, the importance of international standards such as ISO/IEC 5230 and ISO/IEC 18974 will only become greater. By complying with these standards, companies will be able to enhance the transparency of open source use and effectively manage security risks.

1.2 - 1. Organization

First, companies need to establish an organization responsible for managing open source.

The following should be considered when organizing:

• Roles and responsibilities of the organization
• Required competencies for each role
• The organization/person in charge of each role

1. Defining the roles and responsibilities of the organization

ISO standards commonly require a document describing the roles and responsibilities of various participants in the program.

Open Source Program Manager

To build an open source management system, you first need a person responsible for it. This person is called the Open Source Program Manager or Open Source Compliance Officer, and here we use the term Open Source Program Manager.

The Open Source Program Manager is in charge of the company’s Open Source Program Office. The Open Source Program Office refers to the organization responsible for managing the company’s open source, and is also referred to as the Open Source Office.

A person with the following competencies may be suitable for the role of open source program manager.

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

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

Global ICT companies are striving to hire excellent Open Source Program Managers. You can check various job postings on the following site: https://github.com/todogroup/job-descriptions

Documenting roles and responsibilities

Companies need to define the roles needed for the Open Source Program Office and determine what responsibilities to assign.

In the case of small companies, it is possible for the Open Source Program Manager to perform all roles alone. Depending on the size of the company, there may also be a need for an IT officer to operate open source tools, and the role of a legal officer may be required to provide professional legal advice.

Generally, the following roles are needed to build a company’s open source management system.

• Legal officer
• IT officer
• Security officer
• Development culture officer

For this, companies should document the roles and responsibilities of the Open Source Program Office as follows.

2. Definition of Required Competencies

Once you have defined each role and its responsibilities, you need to identify what essential competencies are required for the personnel to perform that role.

The ISO standard commonly requires a document that describes the competencies needed for each role.

This is to evaluate whether the person in charge of each role has the ability to perform that role, and to provide education if necessary.

For this, companies should document the competencies needed for each role as follows:

3. Appointment of Responsible Person

The Open Source Program Manager consults with the relevant departments to appoint a person in charge for each role and documents it. Of course, to do this, you need to report the goals and directions for establishing an open source compliance system to the CEO or other top decision-makers and receive the necessary support.

The organization and person in charge of open source do not necessarily have to participate in open source work full-time. It is also possible to form a virtual organization in the form of an OSRB (Open Source Review Board) to perform the necessary roles.

For this, the ISO standard commonly requires a document that lists the names of the persons, groups, or functions in the program roles.

For this, companies should document the names of the persons, groups, or functions in the program roles as follows:

You can refer to the sample that documented the roles, responsibilities, required competencies, and appointment of responsible persons in the next page. [Appendix 1] Open Source Policy template - Appendix 1. Status of Responsible Persons

SK Telecom has formed an OSRB to create open source policies and processes within the company, and collaborates to develop countermeasures when issues arise.

Summary

You can check the sample that documented the roles, responsibilities, required competencies, and appointment of responsible persons in the Open Source Policy template: Appendix 1. Status of Responsible Persons

Companies can refer to this to form an open source management organization suitable for their situation.

By designating and documenting the open source program office organization in this way, you will meet the requirements marked in red in the ISO standard specification.

In fact, it is more important to appoint a person who will faithfully perform the actual work and support the person in charge to secure the competency than to document it.

1.3 - 2. Policy

1. Open Source Policy Documentation

Enterprises should establish and document an open source policy, which consists of principles for organizations involved in software development, service, and distribution to properly utilize open source. This policy should be disseminated within the organization.

For this, the ISO standard commonly requires the following documented open source (security assurance) policies:

A typical open source policy includes the following. Enterprises should create and document an open source policy that includes these principles:

• Principles to minimize license and security vulnerability risks when distributing software products and services
• Principles for contributing to external open source communities
• Principles for releasing the company’s software as open source

2. Contents to be Covered in Open Source Policy

Let’s take a closer look at what an open source policy should include.

Open Source Risk Response

When developing products/services using open source, the policy should include the following principles to minimize license and security vulnerability risks:

1. Identification of open source and review of license obligations
2. Design considering open source licenses
3. Creation of open source compliance deliverables
4. Creation of SBOM (Software Bill of Materials)
5. Response to open source license compliance issues
6. Response to open source security vulnerabilities

You can refer to the principles documented in 6. Open Source Use of [Appendix 1] Open Source Policy template.

1. Open Source Use

When developing and distributing products and services using open source, you must comply with the obligations required by each open source license. This activity is called open source compliance.

For proper open source compliance activities, software development/distribution organizations comply with the following matters and record all processes in the Jira Tracker for preservation.

(1) Identification of open source and review of license obligations

When introducing open source to product/service development, first identify what the open source license is, and review and confirm the obligations required by the license.

The company's [Open Source License Guide] includes a list of major open source licenses, and distinguishes the obligations required by each license according to the following types of distribution:

- Binary form
- Source form
- Strong/weak Copyleft
- SaaS-based provision
- Whether modification is made
- Requirement to indicate the author's open source, etc.

Software development/distribution organizations can refer to this guide when reviewing open source license obligations. If a review of an open source license not mentioned in this guide is required, contact the open source program manager.

(2) Design considering open source licenses

Understand the combination relationship of open source and design the software architecture so that the company's code is not affected by the open source license.

The company's [Open Source License Guide] explains the range of source code disclosure for each open source license and the design method to prevent the disclosure of the company's code.

(3) Creation of open source compliance deliverables

The most basic of open source compliance activities is to understand the status of open source included in the distribution software. This is to properly meet the core of open source compliance, which is the requirements of the open source license. In other words, you need to create a set of compliance deliverables for the open source included in the distribution software.

Open source compliance deliverables are largely divided into two.

1. Open source notice: A document for providing open source license text and copyright information
2. Package of source code to be disclosed: A package that collects source code to be disclosed to fulfill the obligations of open source licenses that require source code disclosure

To collect, distribute, and store these compliance deliverables, comply with the following matters.

- The open source notice or package of source code to be disclosed is collected according to the conditions required by each license. For example, if the license requires the entire text of the license to be enclosed, you should not just provide a link.
- The collected deliverables are stored in a separate repository.
- If the source code to be disclosed is provided by a written agreement, the download link is disclosed so that the repository of the collected deliverables can be accessed from the outside.

You can issue an open source notice and collect a package of source code to be disclosed through the company's open source process.

(4) Creation of SBOM (Bill of Materials)

You need to create and manage the status of open source included in the distribution software (BOM: Bill of Materials).

You can create and preserve SBOM using open source tools through the company's open source process.

(5) Compliance issue response procedure

If a compliance issue is raised, the open source program manager performs the following procedures to respond quickly.

1. Confirm the receipt of the inquiry and specify the appropriate resolution time.
2. Confirm whether the content of the issue points out a real problem. (If not, notify the issue raiser that it is not a problem.)
3. If it is a real problem, prioritize and decide on an appropriate response.
4. Perform the response, and if necessary, appropriately supplement the open source process.
5. The above contents are preserved using the Jira Tracker.

(6) Response to open source security vulnerabilities

- Identify open source vulnerabilities and evaluate their severity.
- Modify vulnerabilities or apply security patches according to the results of open source vulnerability analysis. The decision to take action on vulnerabilities considers the severity of the vulnerability, the importance of the system, the availability of vulnerability modifications or security patches, etc.
- Monitor the announcement of new open source security vulnerabilities and respond quickly when vulnerabilities occur. Open source vulnerability monitoring can be performed through vulnerability databases such as CVE, websites of security professional organizations, etc.

Internal Responsibility Assignment Procedure

The open source policy should cover the procedure for assigning responsibility internally to resolve open source management issues.

The ISO standard commonly requires the following documented procedures that assign internal responsibilities:

Firstly, the open source program manager must identify compliance issues and appropriately assign responsibilities to the role holders to resolve them. Similarly, for open source security vulnerability issues, the security manager identifies the issues and assigns responsibilities to the appropriate personnel to resolve them.

To do this, you can reflect a documented procedure for assigning internal responsibilities in the open source policy, as shown in the example below:

1. Roles, Responsibilities, and Competencies

To ensure the effectiveness of the policy, we define the roles, responsibilities, and competencies that each role holder should possess.

(2) Open Source Program Manager

- Defines the roles necessary for open source compliance, and designates the responsible organization and person for each role. Consults with the OSRB as necessary. The security manager assigns internal responsibilities for open source security assurance.

(6) Security Manager

- Assigns responsibilities for each task to ensure the success of open source security assurance.

Response to Non-compliance Cases

Companies should document procedures to quickly review and respond when non-compliance cases occur.

ISO/IEC 5230 requires a documented procedure for reviewing and remedying non-compliant cases, as follows:

For this, companies can reflect a documented procedure for reviewing and remedying non-compliance cases in the open source policy, as shown in the example below:

6. Open Source Use

(5) Compliance Issue Response Procedure

When a compliance issue is raised, the open source program manager quickly responds by following the procedure below:

1. Confirm the inquiry and specify an appropriate resolution time.
2. Verify whether the issue content points to an actual problem. (If not, inform the issue raiser that it is not a problem.)
3. If it is an actual problem, prioritize and decide on an appropriate response.
4. Perform the response and, if necessary, appropriately supplement the open source process.
5. Preserve the above content using the Jira Tracker.

Support for Personnel and Budget

Companies should provide sufficient resources to ensure the smooth operation of the open source program. They should properly allocate personnel to handle each role within the program, and guarantee sufficient budget and working hours. If not, procedures should be in place to supplement this.

The ISO standard commonly requires that personnel handling each role within the program be properly allocated and that the budget be adequately supported, as follows:

For this, companies can reflect content on personnel and budget support in the open source policy, as shown 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 appropriate time and budget for the person in charge to faithfully perform the role.

- If the person in charge of each role finds that they are not receiving appropriate support while performing their role, they should raise the issue with the open source program manager.
- The open source program manager discusses problem-solving with the head of the organization. If it is not resolved appropriately, the open source program manager can request problem-solving from the OSRB.
- The OSRB shares the problem with the head of the upper organization and requests a solution.

Provision of Expert Advice

Companies should provide a way for role holders to request advice when professional review is needed to resolve open source issues.

The ISO standard commonly requires a method to use internal or external expert advice to solve problems, as follows:

For open source license compliance issues, the company’s legal team is primarily responsible, and if the issue is acute, an external law firm with an open source specialist lawyer can be used.

For open source security vulnerability issues, the company’s security team is primarily responsible, and if the issue is complex and acute, advice can be requested from an external security technology company.

For this, companies can reflect content on providing advice in the open source policy, as shown in the example below:

4. Roles, Responsibilities, and Competencies

(4) Legal Manager

The legal manager provides advice on legal risks and mitigation measures that may arise during the process of using open source, such as interpreting open source licenses and obligations.

- Provides a reasonable way for members to inquire about open source compliance issues.
- Provides advice on license and intellectual property issues, including conflicts due to incompatible open source licenses.
- Reviews necessary legal matters such as open source licenses, CLA (Contributor License Agreement), etc. when contributing to external open source projects.
- If the issue is acute, requests advice from an external law firm with an open source specialist lawyer.

(6) Security Manager

The security manager operates an open source vulnerability analysis tool to build a system that allows security vulnerability analysis to be performed smoothly for all distribution software.

- Provides a reasonable way for members to inquire about security vulnerabilities, and uses external technical advice as needed to resolve vulnerabilities.

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

Law firms registered as OpenChain partners have met the requirements of the OpenChain Project.

Specifying the Scope of Application

A single open source policy (program) does not necessarily have to be applied to the entire organization. Depending on the characteristics of each organization and product within the company, the scope of application can be specified differently. For example, an organization that does not distribute software at all can be excluded from the scope of the open source program.

The ISO standard commonly requires a documented statement that clearly defines the scope and limits of the program, as follows:

Companies should clearly define the scope and limits of the open source program considering the characteristics of the organization and products, and specify this in the open source policy.

Also, as changes occur in accordance with changes in the business environment, situations may arise where the organizational structure, products, and services determine or modify the scope of the program. Companies should establish metrics for evaluating the scope of application and improve deficiencies by performing reviews and inspections for continuous improvement.

For this, companies should have a system that clearly defines the scope of application in the open source policy and documents the activity history, as shown below:

1. Scope of Application

This policy applies to the following three parts:

1. It applies to all products provided or distributed externally by the company. However, the use of open source for internal use only is not included in the scope of this policy.
2. It applies when members contribute to external open source projects.
3. It applies when internal code is disclosed as open source.

The scope of application can be changed to suit the company's business environment. In particular, the open source program manager investigates at least once a month whether there are products that are not subject to this policy and are distributed or serviced externally to ensure continuous effectiveness. This is measured and used as a criterion for changing the scope of application when even one case is found.

The procedure for changing the scope of application is as follows:

1. If the open source program manager determines that it is necessary to change the scope of application of the policy due to changes in the company's business environment such as new business and organizational restructuring, it submits a proposal for this to the OSRB.
2. The OSRB approves an appropriate level of change in the scope of application.
3. The OSRB modifies the open source policy to change the scope of application.

The open source program manager continuously documents the review, update, and inspection history for improving the scope of application at least once a month using the Jira Issue Tracker.

Therefore, companies should have a system that clearly defines the scope of application in the open source policy and documents the activity history.

Responding to External Inquiries

There are cases where customers and open source copyright holders contact the company to make inquiries, requests, and claims about products or services developed using open source.

The main contents of external inquiries and requests are as follows:

• Inquiry about whether open source has been used in a specific product or service
• Request for source code provision under the GPL, LGPL license mentioned in the written agreement (Written Offer)
• Explanation and source code disclosure request for open source that was not specified in the open source notice but was found in the product
• Request for missing files and build methods in the source code disclosed due to obligations such as GPL, LGPL
• Request for copyright notice
• Inquiries and requests related to open source security vulnerabilities

Companies should designate a person in charge of handling these external inquiries. Typically, the open source program manager is in charge.

There are cases where an external open source developer wants to contact a company’s person in charge to discuss an open source related issue of a specific company, but cannot find a way to contact and eventually files a legal claim directly. To prevent this, companies should always publicly disclose a way for third parties to contact the company about open source.

The ISO standard commonly requires a publicly visible method that allows any third party to make an open source license compliance inquiry, as follows:

Companies can provide a way to contact the company about open source, as shown below:

Sure, here’s the translation of the guide in professional style:

1. The representative email address of the open source responsible organization is made public.
2. The Open Compliance Directory of the Linux Foundation is used.
3. If the company has an open source website, the email address is made public through it.

Including the representative email address of the open source responsible organization in the open source notice that comes with the product and service and making it public is also a good method.

Companies can reflect the following content on external inquiries in their open source policies:

9. Response 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 from outside.

- The open source program manager can assign the handling of all or part of the inquiry to appropriate personnel within the company. If necessary, the legal representative is consulted for handling.
- Anyone who receives an inquiry about open source from outside informs the open source program manager so that a quick response can be made.

(2) Disclosure of Contact Information

The open source program manager provides the contact information of the person in charge publicly so that inquiries and requests related to open source can be made from outside.

- Provides email address information that can be contacted in the open source notice.
- Provides email address information on the open source website.
- Registers the contact information in the Open Compliance Directory of the Linux Foundation.

(3) Procedure for Responding to External Inquiries

If you respond quickly and accurately to open source inquiries from outside, you can greatly reduce the risk of claims or legal litigation. To this end, the company complies with the procedure for responding to external inquiries defined in the company's open source process.

SK Telecom includes an open source notice in all products. The open source notice provides the address of the SK Telecom open source website and the email address that can contact the open source program office.

Also, the SK Telecom Open Source Website provides an email address that can contact the open source program office.

Open Source Contribution

Global software companies not only use open source to create products and provide services, but also value the strategic value that can contribute to and create open source projects. However, if you approach without sufficient understanding of the open source project ecosystem and community operation methods and strategies, the company’s reputation may be unexpectedly damaged and legal risks may occur. Therefore, it is important for companies to establish strategies and policies for participating in and contributing to open source projects.

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

You can check the open source contribution policy in [Appendix 1] Open Source Policy template 7. Open Source Contribution.

7. Open Source Contribution

The company encourages participation and contribution to external open source projects to create business value from open source. However, care must be taken to avoid unintentional exposure of the company’s intellectual property or infringement of third-party rights during this process. To this end, members of the company must comply with the following when contributing to external open source projects:

(1) Request for Review and Approval

Contributing to open source is granting the open source project the right to modify, use, and distribute the work from a copyright perspective. Sometimes, you may need to transfer your copyright to the open source project. However, the copyright of works created during the employment period is generally owned by the employer. In other words, the works created by company members are owned by the company. The act of arbitrarily contributing works to open source can trigger unnecessary copyright infringement issues.

Therefore, if there is an open source project you want to contribute to, you must comply with the review request and approval process before making the initial contribution according to the open source contribution process.

However, in the case of simple content such as the following, you can contribute according to the judgment of the member without the review process because the risk of copyright infringement is not high:

- Small code snippets of 10 lines or less
- Questions / Answers on Stack Overflow
- Management activities on GitHub: Creating Issues, Reviewing / Approving Pull Requests, etc.

...

Companies should refer to this and include principles for open source contributions that suit the company’s situation in the open source policy.

Summary

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

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

It is necessary to establish appropriate principles for each requirement according to the company’s situation and to consider executable procedures, not just documents. A policy that is only spoken is useless.

By establishing and documenting an open source policy like this, you can meet the requirements marked in orange in the ISO standard specifications.

1.4 - 3. Process

The open source process is an executable procedure that allows companies to comply with open source policies during the software development and distribution process.

From the perspective of open source license compliance, activities are carried out to comply with the conditions required by each license for the open source used in developing and distributing software, resulting in the creation of deliverables such as open source notices and source code to be disclosed.

For open source security assurance, activities must be carried out to detect the presence of security vulnerabilities in the software to be distributed, identify structural/technical threats, and resolve issues before release.

In order for a company to effectively achieve open source license compliance and security assurance, the following processes must be established:

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

Let’s take a look at how each process should be structured.

1. Open Source Process

Companies should establish an open source process for open source license compliance and security vulnerability management according to the software development process.

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

The procedures to be taken at each stage according to the open source process are as follows:

(1) Identification and Inspection of Open Source

In the identification and inspection stage of open source, it is necessary to identify what license the open source you want to use is, what obligations the license requires, and whether there are known vulnerabilities.

Review and record which open source you want to use, what its license is, what obligations each license imposes, and what known vulnerabilities are.

The ISO/IEC 5230 standard requires a documented procedure to handle common open source license use cases and to review and record the obligations, restrictions, and rights granted by each identified license.

An example of a procedure for this is as follows:

1. The open source program manager provides a guide on the obligations, restrictions, and rights of major open source licenses. This guide should include the following use cases to handle common open source license 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

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 with the open source program manager and security officer on any questions. If necessary, advice is sought from external experts.

4. All decisions and related grounds are documented and kept.

For this, companies should establish a documented procedure to review and record the obligations, restrictions, and known vulnerabilities granted by each identified license before product release through the open source identification and inspection stage.

(1) Open Source Identification

The business unit complies with the following matters at the software design stage.

- Identify the anticipated open source usage status and check the license while designing the software.
- Check the obligations of each open source license. The obligations of each license can be checked in the company's open source license guide. : https://sktelecom.github.io/guide/use/obligation/
- Design the software considering the source code disclosure range of 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 the business units of the company can refer to it. This guide should include the following use cases to handle common open source license 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

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

When the business unit considers introducing new open source, it first identifies the license. According to the company's open source license guide, check the obligations, restrictions, and rights of the license. If the license is not explained in the company's open source license guide, ask the open source program manager about the possibility of introduction and precautions. Create a Jira Ticket for inquiries.

The open source program manager analyzes the obligations of the open source license and guides the software development organization.

- If there is any doubt, consult with the legal officer and provide clear guidance.
- The 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 check according to the guidance of the IT manager and provides the source code.

The IT manager uses the open source analysis tool to check the open source and create an SBOM (Software Bill of Materials).

The open source program manager reviews the possibility of complying with the open source license obligations, checks for conflicts between open source licenses, and if there are issues, requests the business unit to resolve them. Issues are created as Jira Tickets and assigned to the business unit.

The security officer reviews the detected known vulnerabilities and provides a response guide to the business unit according to the pre-defined Risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) Score, and Critical Risk is guided to establish a plan that can be addressed within 1 week.

In the open source identification and inspection stage, source code scanning tools can be used. More details on this can be found in “1. Source Code Scanning Tools”.

(2) Problem Solving

After identifying open source through open source identification and inspection, and confirming the risks of licenses and security vulnerabilities, a procedure is needed to solve the problem. All detected problems should be solved in the following ways:

• Remove the open source that is causing the issue.
• Replace with open source under a different license to resolve open source license issues.
• Replace with a version of open source where known vulnerabilities have been resolved.

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

(3) Problem Solving

The business department solves all problems found in the source code inspection stage.

Remove the open source that is causing the issue, or replace it with open source under a different license. In the case of security vulnerability issues, measures such as replacing with a version where known vulnerabilities have been fixed are taken.

Once the business department has resolved all discovered issues, they resolve the Jira Ticket issue and request a re-review.

(3) SBOM Identification, Review, and Storage

The most basic of open source license compliance activities is to understand the status of open source included in the distributed software. You need to build a process to create and manage an SBOM (Software Bill of Materials) that contains information identifying the open source and its licenses included in the distributed software. Knowing which open source is included in each version of the distributed software is essential for complying with the obligations required by each open source license when distributing 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 distributed software. Not only the functionality and quality of the open source, but also whether the origin, license requirements can be met, and whether known vulnerabilities have been resolved, etc., must be reviewed in advance. A review request → review → approval process is required for this.

ISO standards commonly require a documented procedure that ensures that all open source software used in the supplied software is continuously recorded during the lifecycle of the supplied software.

For this, companies can reflect the following content about SBOM in the open source process:

(4) Review

The open source program manager reviews whether all issues have been properly supplemented. If necessary, the source code inspection is re-performed using the open source analysis tool.

The security officer reviews whether all serious vulnerabilities have been resolved. If there are vulnerabilities that are difficult to resolve, they review whether they can be approved considering the business form and service exposure status.

(5) Approval

The open source program manager finally approves or rejects whether the open source compliance procedure has been properly performed. If rejected, they propose a reason and a modification method to the business department.

(6) Registration

The open source program manager finalizes the BOM to track the list of open source used in each version of the software.

The IT officer registers the finalized BOM in the system. The BOM includes a list of open source included in the distributed software and the following information:

- Product (or service) name and version of the distributed software
- Open source list
  - Open source name / version
  - Open source license

The open source program manager finalizes the BOM to track the list of open source used in each version of the software.

For more details on tools for managing SBOM, see “SBOM Management Tools”.

Also, all processes and results of such open source processes must be documented. It is more efficient to use an issue tracking system such as Jira, Bugzilla than using email.

(4) Creation of License Compliance Artifacts

As mentioned above, the most basic of open source license compliance activities is to understand the status of open source included in the distributed software. This is precisely because it is the core of open source license compliance to properly meet the requirements of open source licenses. In other words, a process must be established to create a set of compliance artifacts for the open source included in the distributed software.

The ISO/IEC 5230 standard requires a documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses.

Compliance artifacts are divided into two main categories:

1. Open Source Notice: A document for providing open source license text and copyright information

   

   • For how to create an open source notice that aggregates the SBOM using tools, see “Open Source Compliance Artifact Generation Tools”.

Sure, here is the English translation of the Korean guide you provided, written in a professional style suitable for user manuals, help documents, and technical documents:

2. Source Code Package to be Disclosed: A package that consolidates source code to be disclosed in order to comply with the obligations of open source licenses that require source code disclosure, such as GPL, LGPL.

Compliance deliverables must be provided along with the distribution of the software for distribution.

For this, companies can reflect the content on the creation of compliance deliverables from the notification stage to the distribution stage in the open source process as follows:

(7) Notification

The open source program manager creates an open source notice to comply with the notification obligation. The open source notice includes the following:

- Open source contact point where open source related inquiries can be made
- Notice content for each open source
  - Copyright
  - Open source license name
  - Copy of open source license
  - (If applicable) Written agreement to obtain a copy of the source code (Written Offer)

The open source program manager creates an open source notice and delivers it to the business department. At this time, if source code disclosure is necessary, the method of collecting the source code to be disclosed is guided to the business department.

The business department includes the open source notice when distributing the product. If the product has a screen, measures are taken so that the user can check it through the menu. (Example: App > Menu > Settings > Copyright Information > Open Source License)

The business department, when using open source under a license that requires source code disclosure such as GPL, LGPL, checks the scope of source code disclosure for this and collects the source code to be disclosed.

- The source code collected to comply with the obligations of licenses such as GPL, LGPL must match the source code that constitutes the binary loaded on the product. In other words, if you build the collected source code, it must be the same as the binary loaded on the product.

(8) Confirmation before distribution

The business department submits the following deliverables to prove that the open source compliance activities have been properly performed.

1. Final open source notice included in the product
2. Materials confirming that the open source notice is included in the product (Example: Screen capture image showing the open source notice)
3. (If applicable) Source code to be disclosed (Submit as a single file compressed)

The open source program manager reviews the materials submitted by the business department and checks for any abnormalities.

(9) Distribution

The open source program manager submits the compliance deliverables submitted by the business department to the IT manager.

The IT manager registers the compliance deliverables on the company's open source distribution site.

When distributing software for distribution, it may be difficult to include a package of source code to be disclosed. In this case, you can substitute it by providing a written agreement (Written Offer) that you will provide the source code for at least 3 years. Typically, the written agreement is provided through the product’s user manual, and the 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 deliverables must be kept for more than 3 years, and a process for this must be established.

For this, companies can consider building an open source website. You can check the details in “Open Source Compliance Artifact Storage”.

2. Open Source Security Vulnerability Process

Companies must perform activities for security assurance, such as detecting and resolving open source security vulnerabilities, while developing products/services.

The ISO/IEC 18974 standard requires documented procedures and records of actions taken for security assurance methods as follows:

In order to address vulnerabilities in the deployed software, enterprises must detect the presence of known vulnerabilities in the distribution-ready software and resolve identified risks before release. Furthermore, they need to establish methods and procedures to respond to newly discovered vulnerabilities post-release.

Initially, enterprises should detect known vulnerabilities in the distribution-ready software and resolve identified risks before release. The procedure for detecting and addressing these known vulnerabilities can be carried out through the open-source identification phase, source code inspection phase, and issue resolution phase of the open-source process, as outlined in Open Source Process.

Additionally, when newly identified vulnerabilities are disclosed after the release of the deployed software, it is imperative to establish a process for confirming their existence in the already distributed software and taking necessary measures to address them.

Below is a sample process for responding to the discovery of new security vulnerabilities:

1. New Security Vulnerability Process

After a product/service is launched in the market, we adhere to the following process to take appropriate measures according to the risk level when a new security vulnerability is reported.

(1) Monitoring

The IT department operates a system that monitors new security vulnerabilities. This system performs the following functions:

- Regularly collects information about newly disclosed security vulnerabilities.
- If an open source with a new known vulnerability is used in a product/service that has already been released, it sends a notification to the business department in charge of the product/service. From notification to review, action, and resolution, everything is documented and recorded using the Jira Issue Tracker.

(2) Initial Response

The security officer provides a response guide to the business department according to the pre-defined risk classification criteria. Risks are classified by CVSS (Common Vulnerability Scoring System) scores, and Critical Risk is guided to establish a plan that can be implemented within 1 week.

If a new security vulnerability is found in a product/service that has already been released, the business department establishes a response plan according to the response guide provided by the security officer.

If there are customers who need assurance, the business department notifies the confirmed known vulnerabilities by email or other means as needed, depending on the risk level.

(3) Problem Solving

The business department solves the security vulnerability problem by deleting the problematic open source or replacing it with a patched version, etc., according to the established response plan. Once all issues are resolved, a re-review is requested.

(4) Review

The IT department uses an open source analysis tool to check whether the problem has been properly resolved.

(5) Approval

The security officer reviews whether all serious vulnerabilities have been resolved. If there are vulnerabilities that are difficult to resolve, the approval is reviewed considering the business form and service exposure status.

(6) Registration

The IT department registers the SBOM, which has resolved the open source security vulnerability, in the system.

(7) Notification

The open source program manager creates an open source notice based on the SBOM that has resolved the open source security vulnerability and delivers it to the business department.

The business department replaces the open source notice included in the product distribution.

The IT department registers the modified open source notice on the company's open source distribution site.

(8) Distribution

The business department redistributes the software version that has resolved the open source security vulnerability.

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 department.

The IT department registers the identified risk information on the open source website so that third parties can check it.

3. External Inquiry Response Process

In order for a company not to lead to legal litigation due to external claims, it is important to respond as quickly and accurately as possible to external inquiries and requests. To this end, companies should establish a process that can respond quickly and effectively to external open source inquiries.

ISO standards commonly require the following internal documented procedures to respond to third-party inquiries.

The following figure is a sample process that a company should have in order to respond to external inquiries.

If you respond quickly and accurately to open source compliance inquiries from outside, you can greatly reduce the risk of proceeding to litigation. To this end, the company adheres to the following process to respond to external open source compliance inquiries.

(1) Receipt Notification

As soon as the open source program manager receives an inquiry, they notify the requester that the inquiry has been received. At this time, they also notify the expected date of action. If the inquiry is unclear, they request additional explanation.

The main contents of the inquiries and requests that require response are as follows:

- Inquiry whether open source has been used in a specific product or service
- Request for source code provision under GPL, LGPL license mentioned in written agreement (Written Offer)
- Explanation and source code disclosure request for open source found in the product but not specified in the open source notice
- Request for missing files and build methods in the source code disclosed due to obligations such as GPL, LGPL
- Copyright notice request

The open source program manager creates a Jira Issue for the received request and records all the response situations in detail.

(2) Investigation Notification

The open source program manager notifies the requester that they are investigating the open source compliance. It is good to notify whenever the internal investigation progress is updated.

(3) Internal Investigation

The open source program manager conducts an internal investigation on the request. They check whether the compliance process has been properly performed for the version of the product in question through the BOM and documented review history. If necessary, they request advice from the legal department.

If it is a matter that needs to be confirmed by a specific business department, the open source program manager requests an investigation from the business department. The business department immediately checks whether there is a problem with the compliance deliverables upon receiving the investigation request and reports the results to the open source program manager.

(4) Report to Requester

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

- If the requester's inquiry was a misdirected point due to misunderstanding, they notify the requester and end the process without any additional action.
- If there is a problem, they notify the requester of the exact method and timing to fulfill the obligations of the open source license in question.

(5) Problem Supplement / Notification

If a compliance problem is actually found in the internal investigation, the relevant business department performs all procedures necessary to solve the compliance problem.

(6) Problem Resolution Notification

After solving the problem, they immediately notify the requester and provide the best way to confirm that the problem has been resolved.

(7) Process Improvement

If there was a compliance problem, the OSRB meeting reviews the case, identifies the circumstances of the problem, and improves the process so that the problem does not recur.

Sure, here is the translation of the text you provided:

4. Open Source Contribution Process

If a company has a policy that allows contributions to external open source projects, there should be a documented procedure for how in-house developers can contribute to external projects.

The ISO/IEC 5230 standard requires a documented procedure for managing open source contributions.

The Open Source Contribution Process published by SK Telecom is a good example.

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

5. Process Modernization

It is not desirable for the process to be documented but not actually operated. Also, it is a problem if it does not fit the business situation or organizational composition. Companies should always keep the process up-to-date to match the internal organization and situation of the company.

The ISO/IEC 18974 standard requires periodic review and improvement of the process.

Companies can define in the open source policy document that they improve the open source policy and open source process every year and document and record all processes.

1. Roles, Responsibilities, and Competencies

To ensure the effectiveness of the policy, we define the roles and responsibilities and the competencies that each role holder should have as follows.

(1) OSRB

The OSRB (Open Source Review Board) is a consultative 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 improves policies and processes on a regular basis every year. All improvement processes are documented and recorded.
  - The OSRB always modernizes the company's process performance results, shortcomings, best practices, and reflects the business environment.
  - The policy and process for open source compliance are managed by the open source program manager.
  - The policy and process for open source security assurance are managed by the security officer.

6. Summary

By building the process up to this point, you can meet the requirements marked in yellow in the ISO standard specifications.

1.5 - 4. Tools

1. Source Code Scanning Tools

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

Many companies use these automated source code scanning tools in conjunction with manual reviews. The Linux Foundation’s FOSSology project is an open source source code scanning tool that companies can easily use for free.

For information on how to install and use FOSSology, please refer to Get Started with FOSSology.

2. Dependency Analysis Tools

In recent software development, build environments that support package managers such as Gradle and Maven are used. In these build environments, even without source code, the necessary Dependency libraries are fetched from a remote space at build time to compose the distribution software. However, these Dependency libraries are included in the distribution software but are not detected by the source code scanning tools. Therefore, it is also important to use tools for Dependency analysis.

The OSS Review Toolkit, which is open source, provides a Dependency analysis tool called Analyzer.

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

cdxgen, managed by OWASP, is an open source SBOM generation tool that supports 20+ languages and ecosystems (Java, Node.js, Python, Go, Rust, etc.) and outputs CycloneDX format SBOMs. It integrates easily with CI/CD pipelines. For installation and usage, refer to the cdxgen guide.

Syft, developed by Anchore, is an open source SBOM generation CLI tool that scans container images, filesystems, and archives to generate SBOMs in SPDX or CycloneDX format. It pairs naturally with Anchore’s Grype vulnerability scanner for SBOM-based vulnerability analysis. For installation and usage, refer to the Syft guide.

These dependency analysis tools help accurately identify open source components in distributed software and generate SBOMs, satisfying the requirements of ISO/IEC 5230 and ISO/IEC 18974.

3. SBOM Management Tools

ISO/IEC 5230 standard 3.3.1.2 requires that the SBOM list included in the distribution software be documented and stored.

SBOM can be managed with spreadsheet programs like Excel, but it is not easy to manage manually when the number and version of distribution software exceed hundreds. Therefore, it is recommended to introduce open source automation tools for this purpose.

The SW360 project, sponsored by the Eclipse Foundation, provides the ability to track the list of open sources included in each distribution software.

The installation and usage of SW360 can be referred to in the SW360 Docker.

And the aforementioned FOSSLight also provides features for SBOM management.

LG Electronics has been managing the SBOM for all business units’ distribution software for the past several years using FOSSLight, which it developed in-house. In June 2021, it announced that it had released it as open source so that anyone can use it.

Dependency-Track, managed by OWASP, is an open source SBOM management and vulnerability analysis platform. It continuously monitors component-level vulnerabilities based on uploaded SBOMs and automatically evaluates policy violations. It integrates with NVD, OSV, and other vulnerability databases for automatic detection, and supports REST API for CI/CD pipeline integration. For installation and usage, refer to the Dependency-Track guide.

4. Open Source Vulnerability Management Tools

Companies need to track products/services that contain known vulnerabilities and resolve them. To do this, companies need to build a tool environment that automates this.

SW360 can automatically check if there are any security vulnerabilities in the registered Release. For this, SW360 provides a feature to schedule the collection of CVE information every 24 hours. If you set up this scheduling, SW360 will collect CVE information from the CVE Search site (https://cve.circl.lu/) at the set time. After the Vulnerabilities information is collected, you can check if there are any security vulnerabilities in the created Project, so you can also track whether newly disclosed vulnerabilities exist in products that have already been released.

The method of managing security vulnerabilities with SW360 can be referred to in the SW360 guide.

FOSSLight also automatically acquires security vulnerability information and automatically checks project information where security vulnerabilities have been detected, providing notifications such as emails as needed.

OSV-SCALIBR, developed by Google, is an open source software composition analysis (SCA) library that extracts open source components from filesystems and container images and detects vulnerabilities by integrating with the OSV (Open Source Vulnerabilities) database. It supports Python, Go, Java, npm, and other major package ecosystems, and is suitable for integration into CI/CD pipelines to automatically detect vulnerabilities at build and deployment stages. For installation and usage, refer to the OSV-SCALIBR guide.

These tools help companies effectively manage open source security vulnerabilities while satisfying the requirements of ISO/IEC 18974.

5. Open Source Compliance Artifact Generation Tool

The main open source compliance artifact, the open source notice, is a document that provides copyright and license information for the open source included in the distributed software. Open source notices can be created using a document editor tool, but it is recommended to use a tool that generates them automatically.

SK Telecom has released an open source notice automatic generation tool (onot: https://github.com/sktelecom/onot) used internally as open source, and Kakao has participated in joint development by contributing major features.

onot is a tool that automatically converts SBOMs written in SPDX document format into open source notice format. It is a Python program that is lightweight and easy to use.

FOSSLight also provides a feature to automatically generate open source notices based on the acquired SBOM.

6. Open Source Compliance Artifact Storage

It is recommended that companies build an open source website and register open source compliance artifacts so that external customers can conveniently download open source notices and source code packages to be disclosed for distributed software at any time.

For this, the ISO/IEC 5230 standard requires a documented procedure for archiving copies of the compliance artifacts of the supplied software.

You can refer to this tool environment on SK Telecom’s open source website.

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

7. Summary

If you build up to the tool environment, you can meet the requirements marked in green in the ISO standard specification.

1.6 - 5. Education

1. Education

No matter how excellent the policies and processes are, they will be useless if no one in the organization pays attention to them. For open source policies and processes to work effectively in a company, member education is crucial.

Companies should provide practical means such as education and internal wikis so that all program participants are aware of the existence of open source policies within the organization and can perform necessary activities. Program participants here refer to all employees involved in the development, distribution, and contribution of software, including software developers, distribution engineers, and quality engineers.

For this, the ISO standard commonly requires the following documented procedures to inform about the open source policy:

Many companies make their open source policy documents available through internal wiki sites so that any employee can check the necessary items. In addition, they mandate education on open source policies during the orientation of new hires and provide regular education once a year or every two years to all program participants, ensuring that all program participants are aware of the existence of the open source policy.

Companies should include these methods in the open source policy document as follows:

5. Education and Evaluation

All members in charge of each role defined in Chapter 4 must take the advanced open source education course provided by [Learning Portal]. Through this, they will familiarize themselves with the open source policy, related education policy, and inquiry methods. The education history and evaluation results are kept in [Learning Portal] for at least 3 years.

Companies should ensure that program participants are aware of the company’s open source policy, open source-related goals, participant’s contribution methods for an effective open source program, and the impact of non-compliance with program requirements. To do this, companies should provide education, perform evaluations to confirm correct understanding by program participants, and document and keep the evaluation results.

The ISO standard commonly requires the following documented evidence indicating the assessed awareness of program participants:

Therefore, companies can include the following content in the company’s 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 Co., Ltd. (hereinafter referred to as "the company") to properly utilize open source software (hereinafter referred to as "open source").

1. Open source compliance / security assurance principles
2. Principles for contributing to external open source projects
3. Principles for disclosing in-house 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.

All members of the company can check the open source policy at the following link on the internal wiki: [internal_link]

(2) Impact of non-compliance

If this policy is not complied with, the following situations may occur:

- You may receive a request for open source license compliance from the outside.
- You may have to disclose the source code developed by the company against your will.
- You may be sued by the open source copyright holder.
- You may be fined for copyright infringement and contract violation, or receive a product sales suspension order.
- The company's reputation may be damaged.
- You may be claimed for damages due to a contract violation with the supplier.
- You may be exposed to serious security incidents, causing significant damage to the company.

For these reasons, the company takes violations of the open source policy seriously, and members or organizations that violate this may be subject to disciplinary procedures.

(3) Contribution method of members

All members of the company 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 performing the necessary activities.

The evaluation will be explained in more detail below.

The open source education includes content on the open source contribution policy. Even if an open source contribution policy is created, if no one in the company is aware of its existence, there is a risk of damage to individuals and companies due to indiscriminate contribution activities.

For this, the ISO/IEC 5230 standard requires the following documented procedure to make all program participants aware of the existence of the open source contribution policy.

Therefore, companies should provide open source education so that all in-house developers are aware of the existence of an open source contribution policy.

Creating new educational materials may not be easy for those who are just starting out. To help with these difficulties, NCSoft has made its in-house open source educational materials available to everyone by publishing the lecture (PPT) and lecture script on GitHub.

In addition, Kakao, a leading platform company in Korea, has also made its open source educational materials available for anyone to view.

If you haven’t created educational materials yet, it’s a good idea to use the open source educational materials from these excellent open source management companies.

2. Evaluation

Once a company has assigned roles, it must ensure that the assigned individuals are qualified to perform their roles based on education, training, and experience. Adequate education should be provided to program participants who lack competence. And the company must evaluate whether each participant is competent and keep the results.

For this, the ISO standard commonly requires documented evidence of assessed competence for each program participant.

Therefore, companies should perform education and evaluation as follows:

1. The company provides education so that each participant can have the necessary competence.
2. Perform an evaluation based on the content of the education.
3. The evaluation results are kept in the company’s education system or HR department.

If there are hundreds of program participants and it is not easy to provide education, it is a good idea to use the company’s online education and evaluation system.

This content can be included in the company’s open source policy as follows:

4. Roles, Responsibilities, and Competencies

To ensure the effectiveness of the policy, we define the roles and responsibilities and the competencies that each role's manager should have.

The organization/manager in charge of each role and the required competency level are defined in [Appendix 1. Manager Status].

5. Education and Evaluation

All members who are in charge of each role defined in Chapter 4 must take the advanced open source education course provided by [Learning Portal]. Through this, you will be familiar with the open source policy, related education policy, and how to inquire.

The education history and evaluation results are kept in [Learning Portal] for at least 3 years.

3. Open Source License Guide

To properly comply with open source licenses, you need to know exactly what each open source license requires. However, it is difficult for individual software developers to identify this on a daily basis, so the open source program manager should summarize the requirements/precautions for common use cases for frequently used open source licenses and share them internally.

The open source license guide should enable development departments to perform correct license compliance activities when using open source, including general requirements for common open source license use cases.

For this, the ISO/IEC 5230 standard requires a documented procedure for handling common open source license use cases for the open source components of the supplied software.

To handle open source license use cases, you need a license guide classified by open source license. General guides and license obligation summary materials for open source licenses can be referred to the License Guide provided by the Korea Copyright Commission.

The License Obligation document in the open source guide of SK Telecom is also a good resource.

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

Companies should provide an open source license guide in a space where members can easily access and refer to.

4. Summary

If you have built up to the education, evaluation, and guide provision environment, you can meet the requirements of the ISO standard specifications indicated in sky blue.

1.7 - 6. Conformance

Companies that have built an open source program (open source policy / process / tools / organization) that complies with all requirements except ISO/IEC 5230 3.6, ISO/IEC 18974 3.4 can document and specify the following two things.

For this, ISO standards commonly require the following documented procedures to announce open source policies.

Therefore, you can document the following:

1. The company’s open source program complies with all the requirements of ISO/IEC 5230, ISO/IEC 18974
2. Guarantee to maintain a state that meets all the requirements of ISO/IEC 5230, ISO/IEC 18974 for more than 18 months after obtaining conformance validation

The company can include the above in its open source policy, or it can be posted through a publicly available website.

You can refer to the content posted on the open source portal site of SK Telecom as shown in the image below. https://sktelecom.github.io/compliance/iso5230/

By doing so, you can meet the requirements marked in blue in the ISO standard specifications.

Once you have completed this, your company will finally meet all the requirements of ISO/IEC 5230, ISO/IEC 18974.

2 - ISO/IEC 5230 Conformance Guide

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

Author : OpenChain Korea Work Group / CC BY 4.0

Target Audience

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

How to Use This Guide

Full Clause Checklist

ISO/IEC 5230 consists of 13 clauses and 24 verification material items.

§3.1 Program Foundation

§3.2 Relevant Tasks

§3.3 Content Review and Approval

§3.4 Compliance Artifacts

§3.5 Community Engagement

§3.6 Adherence to the Specification

Total: 13 clauses / 24 verification material items

ISO/IEC 5230 Certification Process

There are three ways to officially recognize conformance with ISO/IEC 5230.

2.1 - §3.1 Program Foundation

2.1.1 - §3.1.1 Policy

1. Clause Overview

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

2. What to Do

• Write and formalize a policy document governing open source license compliance.
• Clearly define the scope of the policy (supplied software, contribution activities, internal releases, etc.).
• Include principles for open source use, contribution, distribution, SBOM management, and security vulnerability response in the policy.
• Establish and document a procedure for communicating the policy to Program Participants (developers, legal, IT, security, etc.).
• Retain records (training completion records, notification history, etc.) that demonstrate the communication took place.
• Include a procedure in the policy for periodically reviewing it and re-communicating it upon changes.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.1.1 Documented Open Source Policy

How to Comply

An Open Source Policy is an official document containing the principles and procedures for a company to use open source software safely and effectively. The policy document must include key items such as purpose, scope, roles and responsibilities, principles for open source use, contribution, and distribution, SBOM management, security vulnerability response, and training and review cycles. Since this document itself constitutes Verification Material 3.1.1.1, it must be managed as an official document with version and approval history recorded.

When establishing the policy, the company’s business environment and software supply chain characteristics must be reflected. For example, product companies and service companies that distribute software externally may differ in the scope of their obligation to generate Compliance Artifacts, so the scope must be clearly defined. The policy should go through a review by the legal team or OSRB (Open Source Review Board) and be approved by senior management or an authorized department head.

A policy is not a document that is established once and left alone. It should be reviewed at least once a year to reflect changes in ISO/IEC 5230 requirements, the emergence of new license types, and legal environment changes, with the change history recorded in the document.

Considerations

• Items to include: Include all of the following in the policy: open source use, external contributions, internal project releases, SBOM management, and security vulnerability response principles.
• Scope definition: Clearly distinguish the scope to which the policy applies, such as externally distributed software, internally used software, and contribution activities.
• Approval process: Final approval by OSRB or the head of the legal team or above, with the approval date and approver recorded in the document.
• Version control: Maintain document version numbers and change history so that previous versions can be compared during audits.
• Periodic review: Review the policy at least once a year, recording the completion date and reviewer.

Sample

The following is a sample of the Purpose and Scope section of an Open Source Policy document. This text itself becomes a key component of Verification Material 3.1.1.1 (documented open source policy).

## 1. Purpose and Scope

### 1.1 Purpose

This policy provides the principles and procedures for the company to use open source software
safely and effectively. The main purposes of the policy are as follows:

1. Open Source License Compliance:
   Comply with the license obligations of open source components included in supplied software
   and meet related legal requirements.
2. Open Source Security Assurance:
   Identify security vulnerabilities in open source components included in supplied software and
   minimize security risks through appropriate response measures.

These principles are designed to meet the requirements of ISO/IEC 5230 (Open Source License Compliance)
and ISO/IEC 18974 (Open Source Security Assurance).

### 1.4 Scope

This policy applies to all software projects developed, distributed, or used by the company.

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

However, open source used solely for internal purposes may have the applicability of this policy
determined through a separate review procedure.

The scope of the policy is periodically reviewed and updated in accordance with changes in the
company's business environment.

3.1.1.2 Documented Procedure for Policy Awareness

How to Comply

Writing a policy document alone is not sufficient. A procedure for communicating the policy must be established and documented so that Program Participants (all employees involved in developing, distributing, or contributing to software) can actually become aware of the policy’s existence. The communication procedure document must specifically state through which channels, when, and to whom the policy is communicated. This communication procedure document itself is Verification Material 3.1.1.2.

It is effective to combine multiple channels for communication. For new employees, include an open source policy briefing in the onboarding process. For existing employees, use internal wiki posts and email announcements. The procedure should also include a step for immediately notifying changes when the policy is updated. To prove that communication took place, retain evidence such as notification sending history, training completion records, and policy acknowledgment signatures for at least 3 years.

Considerations

• Use multiple channels: Use two or more channels such as internal wiki, email announcements, and onboarding training to increase the effectiveness of communication.
• New hires: Include an open source policy briefing as a mandatory item in the onboarding process.
• Policy updates: Establish a separate procedure for immediately notifying Program Participants of changes when the policy is updated.
• Evidence retention: Retain notification history, training completion certificates, and policy acknowledgment signatures for at least 3 years.
• Accessibility: Post the policy document on the internal portal or wiki at all times so that participants can check it at any time.

Sample

The following is a sample policy communication notification email. Retaining the sending history can serve as evidence for Verification Material 3.1.1.2.

Subject: [Open Source] Open Source Policy Notice and Acknowledgment Request

To: All development/distribution-related employees
From: Open Source Program Manager

Hello,

The company's open source policy has been established (or revised).
All employees involved in using, contributing to, or distributing open source software are
requested to review and familiarize themselves with the policy document at the link below.

- Policy document: [Internal portal link]
- Key contents: Open source use principles, license compliance procedures,
               SBOM management, security vulnerability response principles
- Policy version: v1.0 (Effective date: YYYY-MM-DD)

For inquiries about the policy content, please contact the Open Source Program Manager
(oss@company.com).

Thank you.
Open Source Program Manager

5. References

• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template

2.1.2 - §3.1.2 Competence

1. Clause Overview

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

2. What to Do

• Create a list of roles that affect the performance of the open source program and the responsibilities of each role.
• Specifically define and document the competence (knowledge, skills, experience) required to perform each role.
• Evaluate whether each Program Participant has the competence required for their role.
• Where competence is insufficient, take measures such as training, mentoring, etc. to acquire the necessary competence.
• Document and retain competence assessment results and subsequent action history.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.2.1 Documented List of Roles and Responsibilities

How to Comply

A document listing all roles involved in the program and clearly defining the responsibilities of each role must be created. Generally, the Open Source Program Manager, legal counsel, IT staff, security staff, developer culture staff, and business units are the key roles. Depending on the company size or organizational structure, it is also possible to have people hold multiple roles concurrently or operate as a virtual organization in the form of an OSRB (Open Source Review Board).

When defining roles, listing specific responsibility items rather than abstract descriptions is more advantageous for proving during audits. For example, instead of “open source management,” describe it clearly as “oversight of license review and SBOM generation for open source components used in supplied software.” This document can be included in the Open Source Policy document (§3.1.1.1) under the roles and responsibilities section, or managed as a separate appendix.

Considerations

• Role identification scope: Include roles from all organizations involved in the software supply chain, such as development, legal, IT, security, and procurement, and also review outsourced development and vendor management roles.
• Responsibility specificity: Describe responsibilities for each role in terms of specific activities, not abstract descriptions.
• Concurrent roles: When one person holds multiple roles concurrently, clearly note this in the document.
• Update cycle: Immediately update the document and version when organizational changes or personnel transfers occur.

Sample

The following is a sample roles and responsibilities list from an Open Source Policy Appendix. The full form can be found in Open Source Policy Template Appendix 1.

| Role | Responsibilities |
|------|-----------------|
| Open Source Program Manager | Overall management of the company's open source program / SBOM generation oversight /
                                External inquiry response / Internal best practice management |
| Legal Counsel | Interpretation and review of open source license obligations /
                 License compatibility review / Legal risk assessment and advisory |
| IT Staff | Operation of open source analysis tools and CI/CD pipeline integration /
             Support for SBOM generation automation |
| Security Staff | Response to known and newly discovered vulnerabilities /
                  DevSecOps environment integration and security measures |
| Developer Culture Staff | Encouraging open source community participation / Training program operation |
| Business Unit | Compliance with open source policy and processes / Open source identification and reporting |

3.1.2.2 Document Identifying Competencies for Each Role

How to Comply

The knowledge, skills, and experience required to perform each role must be specifically defined and documented. The competence definition should be written to a level where a person newly assigned to that role can clearly understand “what I need to know.” Instead of writing vaguely like “open source knowledge required,” describe it specifically, such as “understanding of the obligations and compatibility of major open source licenses (MIT, Apache-2.0, GPL-2.0, etc.).”

Breaking down competence levels into categories like “basic understanding,” “practical application,” and “expert” makes the evaluation criteria clearer and makes it easier to establish training plans. This document can be included in the Open Source Policy document or managed as a separate competence definition document, and should be reviewed periodically to reflect changes in the technical environment.

Considerations

• Specificity: Describe competence items at a measurable level so they can be used as evaluation criteria.
• Competence level distinction: Defining levels such as “Basic Understanding / Practical Application / Expert” facilitates evaluation and training design.
• Update cycle: Update competence items when new tools, licenses, or security technologies emerge.
• Training linkage: Design role-specific training curricula based on the defined competencies.

Sample

The following is a sample competence definition table by role.

| Role | Required Competence |
|------|---------------------|
| Open Source Program Manager | Understanding of major open source license obligations and compatibility /
                                Understanding of software development processes /
                                SBOM generation and management knowledge / Communication skills |
| Legal Counsel | Specialized knowledge of software copyright law /
                 Ability to interpret open source licenses / Legal risk assessment ability |
| IT Staff | Operation of open source analysis tools (FOSSology, ORT, Syft, etc.) /
             Understanding of CI/CD pipelines / IT infrastructure expertise |
| Security Staff | Understanding of DevSecOps / Operation of vulnerability analysis tools /
                  CVSS score interpretation and risk assessment ability |
| Developer Culture Staff | Understanding of open source policy / Training design ability /
                           Open source community participation experience |
| Business Unit | Basic knowledge of open source compliance /
                 Basic understanding of open source licenses / Understanding of open source policy |

3.1.2.3 Documented Evidence of Assessed Competence

How to Comply

Each Program Participant must be evaluated to confirm they actually possess the defined competencies, and the results must be documented and retained. Evaluation methods can combine a variety of approaches such as online training completion confirmation, verification of certification possession, written or practical exams, review of job performance records, and interviews. The important thing is that the evaluation results must remain as records. These records themselves are Verification Material 3.1.2.3.

If insufficient competence is found from evaluation results, take remedial measures such as training, external consulting, or mentoring, and retain completion records as well. Evaluations should be conducted regularly at least once a year, and new assignees should be immediately evaluated upon role assignment. Evaluation records should be stored in the internal Learning Management System (LMS) or document system and maintained in a state where they can be submitted immediately during audits.

Considerations

• Diverse evaluation methods: Comprehensively evaluate competence by combining multiple methods such as online training completion, exams, and on-the-job performance.
• Regular evaluation cycle: Conduct at least once a year, and immediately perform a new evaluation when an assignee changes.
• Remediation of insufficient competence: Establish a training plan for items found insufficient in evaluation results, and conduct re-evaluation after completion.
• Record retention period: Retain evaluation records at least for the duration of the assignee’s tenure, and maintain them for a certain period after departure for audit purposes.

Sample

The following is a sample competence evaluation record form. It is written by role and stored in the LMS or document system.

| Name | Role | Evaluation Item | Evaluation Method | Result | Evaluation Date | Notes |
|------|------|-----------------|-------------------|--------|-----------------|-------|
| Gil-dong Hong | Open Source Program Manager | Understanding of license obligations | Online training completion | Completed (95 points) | 2026-01-15 | - |
| Gil-dong Hong | Open Source Program Manager | SBOM management knowledge | Practical evaluation | Completed | 2026-01-15 | - |
| Chul-su Kim | Security Staff | Understanding of DevSecOps | External training completion | Completed | 2026-02-03 | Certificate retained |
| Young-hee Lee | Legal Counsel | Open source license interpretation | Interview evaluation | Completed | 2026-01-20 | - |

5. References

• Related guide: Enterprise Open Source Management Guide — 1. Organization
• Related template: Open Source Policy Template — Appendix 1. Personnel Status

2.1.3 - §3.1.3 Awareness

1. Clause Overview

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

2. What to Do

• Verify that Program Participants understand the objectives of the open source program (license compliance, Security Assurance, etc.).
• Evaluate whether each participant is aware of how their role contributes to the overall program operation.
• Verify that participants are aware of the legal and business impacts that may arise from failing to comply with the program’s requirements.
• Conduct awareness assessments periodically and document and retain the results.
• For participants with insufficient awareness, provide additional training and retain re-evaluation results.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.3.1 Documented Evidence of Assessed Awareness

How to Comply

Program Participants must be evaluated on three key areas of awareness, and the results must be recorded. The three key areas are: (1) the program’s objectives (open source license compliance and Security Assurance), (2) how one’s role contributes to the program, and (3) the legal and business impacts of not following the program.

Evaluation methods can be combined in various ways such as online quizzes, offline surveys, training completion confirmation, and interviews. The important thing is that the evaluation results must remain as documents. These records are Verification Material 3.1.3.1. Evaluations should be conducted regularly at least once a year, and new participants should be immediately evaluated when they join the program. For participants with insufficient awareness, provide additional training and retain re-evaluation results together.

Considerations

• Evaluation scope: Design evaluation questions that cover all three key areas of awareness (objectives, contributions, implications).
• Evaluation cycle: Conduct a regular evaluation at least once a year, and new participants should be evaluated immediately upon joining.
• Evidence format: Retain in a format that can be submitted during audits, such as quiz results, signed policy acknowledgment forms, and training completion certificates.
• Measures for insufficient participants: Provide additional training for participants with insufficient evaluation results and retain re-evaluation records.
• Accessibility: Keep policy documents and training materials used for evaluation always accessible on the internal portal.

Sample

The following is a sample participant awareness assessment record form. It is written at the time of training completion and stored in the LMS or document system.

| Name | Role | Evaluation Item | Evaluation Method | Result | Evaluation Date | Notes |
|------|------|-----------------|-------------------|--------|-----------------|-------|
| Gil-dong Hong | Open Source Program Manager | Understanding of program objectives | Online quiz | Completed (90 points) | 2026-01-15 | - |
| Gil-dong Hong | Open Source Program Manager | Awareness of non-compliance implications | Online quiz | Completed (90 points) | 2026-01-15 | - |
| Chul-su Kim | Developer | Understanding of program objectives | Online quiz | Completed (85 points) | 2026-01-20 | - |
| Young-hee Lee | Security Staff | Awareness of contribution method | Interview | Completed | 2026-01-22 | Interview record retained |

The following is a sample policy acknowledgment form. Obtaining a signature after training completion can serve as Verification Material.

[Open Source Policy Acknowledgment Form]

I confirm that I have reviewed and understood the following:

1. The existence of the company's open source policy and the location of the document
2. The objectives of the open source license compliance and Security Assurance program
3. How my role contributes to the operation of the open source program
4. The legal and business risks that may arise from failing to comply with open source
   policies and processes

Name: ________________  Role: ________________
Signature: ____________  Date: ________________

5. References

• Related guide: Enterprise Open Source Management Guide — 5. Training
• Related template: Open Source Policy Template — §6 Training and Awareness

2.1.4 - §3.1.4 Program Scope

1. Clause Overview

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

2. What to Do

• Determine the types of software the open source program applies to (externally distributed products, services, internal systems, etc.).
• Define the organizational scope the program applies to (company-wide, specific business unit, specific product line, etc.).
• If there are items explicitly excluded from the scope, record them together with the rationale.
• Document the scope statement and officially manage it as an open source policy or separate document.
• Re-examine and update the scope when the business environment changes (entry into new businesses, mergers and acquisitions, etc.).

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.4.1 Written Statement of Program Scope

How to Comply

A document must be written that clearly describes where the program applies and where it does not. This statement can be included in the scope section of the Open Source Policy document (§3.1.1.1) or managed as a separate document. The key point is that the boundaries must be clear. For example, it can be stated clearly as “all software products distributed externally,” or the scope can be specifically limited such as “limited to embedded software developed by business unit A.”

When determining the scope, comprehensively consider the software distribution format (binary products, SaaS, internal tools), how open source is used (direct use, indirect dependencies), and external contribution activities. It is also advisable to clearly state the handling policy for software used only internally. The scope statement must be periodically reviewed and versioned in response to business environment changes.

Considerations

• Distribution format distinction: Specify the applicability for each software distribution type such as externally distributed products, SaaS services, and internal systems.
• Organizational scope: Clearly state whether it applies company-wide or only to specific business units or product lines.
• Exception recording: If there are items excluded from the scope, record them in the document together with the reason for exclusion.
• Update cycle: Immediately re-examine and update the version when entering new businesses, undergoing mergers and acquisitions, or changing the product portfolio.
• Policy alignment: The scope statement should be consistent with the open source policy §1.4 scope section.

Sample

The following is a sample scope statement within an open source policy. This text itself constitutes Verification Material 3.1.4.1.

## Program Scope

This open source program applies to the following scope:

**Applicable**
- All software products externally distributed or sold by the company (including embedded software)
- Activities contributing to external open source projects
- Activities releasing internal projects as open source

**Excluded**
- Software used internally only and not distributed externally (however, a separate review procedure
  may be applied)
- Commercial software procured from third parties (however, review for open source inclusion is required)

**Organizational Scope**
This program applies to all business units of [Company Name], and subsidiaries and affiliates
determine applicability through separate consultation.

This scope is reviewed at least once a year in accordance with business environment changes,
and the Open Source Program Manager publishes the revised version when changes occur.

5. References

• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template — §1.4 Scope

2.1.5 - §3.1.5 License Obligations

1. Clause Overview

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

2. What to Do

• Identify and list the licenses of open source components used in the software.
• Review the obligations (notice obligations, source code disclosure obligations, etc.), restrictions (commercial use restrictions, patent use restrictions, etc.), and rights (use, modification, and redistribution rights, etc.) imposed by each license.
• Document review results by license and maintain records.
• Establish a procedure for requesting legal review when there is uncertainty in license interpretation.
• Update the procedure when new licenses emerge or existing license interpretations change.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.1.5.1 License Obligation Review Procedure

How to Comply

A procedure for reviewing and recording the obligations, restrictions, and rights of each open source license must be documented. The procedure must include the following steps: (1) license identification, (2) obligation, restriction, and rights analysis, (3) recording review results, (4) requesting legal review for uncertain items, and (5) record retention. This procedure document itself is Verification Material 3.1.5.1.

License obligations by license can be efficiently managed by utilizing pre-compiled license databases (SPDX License List, etc.). It is practically effective to prepare an obligation summary table in advance for major licenses (MIT, Apache-2.0, GPL-2.0, GPL-3.0, LGPL-2.1, AGPL-3.0, etc.) and to immediately conduct additional review when new licenses are discovered. The criteria for escalating to the legal team in the case of complex license combinations or situations requiring legal judgment should also be specified in the procedure.

Considerations

• SPDX utilization: Using the SPDX License List as a reference license list standardizes identification and classification.
• Obligation type distinction: Record obligations by type, such as notice obligations, source code disclosure obligations, patent clauses, and trademark restrictions.
• Review by distribution format: Review by distribution format, as license obligations may differ depending on the distribution format such as binary distribution, SaaS, and internal use.
• Escalation criteria: Specify in the procedure the situations requiring legal review (license conflicts, non-standard licenses, commercial restriction clauses, etc.).
• Update cycle: Immediately update the procedure and records when new licenses are adopted or existing license interpretations change.

Sample

The following is a sample obligation summary table for major open source licenses. Writing and retaining it as part of the license review procedure can serve as Verification Material.

| License | Notice Obligation | Source Code Disclosure | Same License for Modifications | Patent Clause | Commercial Use |
|---------|-------------------|----------------------|-------------------------------|---------------|----------------|
| MIT | Yes | No | No | No | Yes |
| Apache-2.0 | Yes | No | No | Yes (patent grant) | Yes |
| GPL-2.0 | Yes | Yes (upon distribution) | Yes | No | Yes |
| GPL-3.0 | Yes | Yes (upon distribution) | Yes | Yes (patent grant) | Yes |
| LGPL-2.1 | Yes | Yes (library) | Yes (library) | No | Yes |
| AGPL-3.0 | Yes | Yes (including network) | Yes | Yes (patent grant) | Yes |
| MPL-2.0 | Yes | Yes (file-level) | Yes (file-level) | Yes (patent grant) | Yes |
| BSD-2-Clause | Yes | No | No | No | Yes |
| BSD-3-Clause | Yes | No | No | No | Yes |

The following is a sample outline of a license obligation review procedure.

[License Obligation Review Procedure]

1. License Identification
   - Identify open source components and licenses through SBOM generation tools
     (FOSSology, ORT, etc.).

2. Obligation, Restriction, and Rights Analysis
   - Refer to the pre-compiled license obligation summary table to confirm the
     obligations, restrictions, and rights of the applicable license.
   - For licenses not in the summary table, review the SPDX License List and
     license text to add new entries.

3. Legal Review Request (if applicable)
   - When license conflicts, non-standard licenses, or commercial restriction
     clauses are present, request legal review from the legal team.

4. Recording Review Results
   - Record review results in the SBOM or license review record and store in
     the open source management system.

5. Obligation Fulfillment Confirmation
   - Before distribution, confirm that license obligations (notice inclusion,
     source code disclosure, etc.) have been completed.

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template

2.2 - §3.2 Relevant Tasks

2.2.1 - §3.2.1 External Inquiry Response

1. Clause Overview

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

2. What to Do

• Specify a publicly available contact (email address, web form, etc.) on the product or website where third parties can send open source license compliance inquiries.
• Document the internal response procedure from receiving an external inquiry through review, response, and closure.
• Include the person responsible for each type of inquiry (Open Source Program Manager, legal team, etc.) and the escalation path in the procedure.
• Record and retain the history of inquiries received and responses given.
• Periodically verify the validity of the public contact and the currency of the internal procedure.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.2.1.1 Publicly Available External Inquiry Channel

How to Comply

A means by which third parties can send open source license compliance inquiries must be publicly specified. The most common method is to publish a dedicated email address (e.g., oss@company.com) in product documentation, software open source notices, or the company website. This public contact itself is Verification Material 3.2.1.1.

It is better to use a role-based address rather than an individual’s personal email. This way the address is maintained even when the person in charge changes, and it is advisable to manage it as a team mailbox to prevent inquiries from being missed. Registering the contact on the OpenChain Conformance website is also an option.

Considerations

• Use role-based address: Use a role-based address such as oss@company.com instead of a personal email to prepare for changes in the person in charge.
• Publication location: Publish in locations that third parties can easily find, such as product manuals, open source notices (NOTICES file), and the company website.
• Verify responsiveness: Periodically check that the published contact is actually being received and monitored.
• Multilingual consideration: For global products, also provide English contact information.

Sample

The following is a sample public contact notice to be posted on the product open source notice or website.

Open Source License Compliance Inquiry

For inquiries regarding open source license compliance of the software components
included in this software, please contact us at the email below.

- Email: oss@company.com
- Response time: Within 14 business days

Open Source License Compliance Inquiry

For inquiries regarding open source license compliance of this software,
please contact: oss@company.com

3.2.1.2 Internal External Inquiry Response Procedure

How to Comply

An internal procedure defining how to handle an external inquiry when it is received must be documented. The procedure must include the following steps: (1) receiving and classifying the inquiry, (2) assigning a person responsible, (3) reviewing and drafting a response, (4) legal review (if necessary), (5) sending the response, and (6) record retention. This procedure document is Verification Material 3.2.1.2.

Response deadlines should be set within a reasonable range and specified in the procedure. In general, an initial response within 14 days and a final response within 60 days are common standards. The history of inquiry receipt, handling, and closure should be recorded in the internal system and retained for submission during audits.

Considerations

• Person responsible and escalation: Specify the primary person responsible (Open Source Program Manager) and the escalation path for legal review in the procedure.
• Response deadline: Specify the deadlines for initial and final responses in the procedure and adhere to them.
• Record retention: Record the inquiry content, review process, and final response, and retain for at least 3 years.
• Response by type: Include in the procedure methods for responding to different types of inquiries such as license notice requests, source code provision requests, and copyright infringement claims.

Sample

The following is a sample outline of an external inquiry response procedure.

[External Open Source Inquiry Response Procedure]

1. Receipt and Classification (within 1 business day)
   - Check the oss@company.com inbox daily.
   - Classify inquiries by type:
     A. Request for open source notice or source code provision
     B. Request for confirmation of license obligation compliance
     C. Copyright infringement claim or legal warning

2. Person Assignment and Initial Response (within 3 business days)
   - The Open Source Program Manager reviews the inquiry and sends a receipt confirmation.
   - Type C (legal warning) is immediately escalated to the legal team.

3. Review and Response Drafting (within 14 business days)
   - Review the relevant SBOM, license records, and Compliance Artifacts.
   - Type A: Confirm and provide the notice or source code.
   - Type B: Review compliance evidence and respond.
   - If necessary, request legal review of the draft response.

4. Response Sending and Closure
   - Send the final response and close the inquiry.

5. Record Retention
   - Document the inquiry content, review process, and final response and retain
     for at least 3 years.

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Policy Template — §9 External Inquiry Response

2.2.2 - §3.2.2 Effective Resources

1. Clause Overview

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

2. What to Do

• Record the names or job titles of the persons responsible for each role in the program (Open Source Program Manager, legal counsel, IT staff, etc.) in a document.
• Confirm and record that sufficient time and budget have been allocated for each role assignee to perform their duties.
• Identify and document internal or external legal expertise available when legal issues related to open source license compliance arise.
• Document a procedure for assigning internal open source compliance responsibilities to each role.
• Document a procedure for reviewing and remedying non-compliance cases when discovered.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.2.2.1 Document with Names of Persons in Program Roles

How to Comply

A document must be created listing the names, group names, or job titles of the actual persons responsible for each role in the program. This document can be managed by adding assignee information to the roles and responsibilities list document from §3.1.2.1, or can be included as an assignee status table in the Open Source Policy Appendix. It is acceptable to use job titles (Open Source Program Manager, Head of Legal, etc.) instead of specific individual names, and the document must be updated immediately when organizational changes occur.

Considerations

• Individual name or job title: Using job titles instead of names reduces the frequency of document updates when personnel changes occur.
• Concurrent roles: When one person handles multiple roles, note this fact for all relevant roles.
• Update management: Immediately update the document and record the version when organizational changes or personnel transfers occur.

Sample

The following is a sample assignee status table for program roles. The full form can be found in Open Source Policy Template Appendix 1.

| Role | Assignee | Contact |
|------|----------|---------|
| Open Source Program Manager | Gil-dong Hong (Dev Team Lead) | oss@company.com |
| Legal Counsel | Legal Kim (Head of Legal) | legal@company.com |
| IT Staff | Infra Lee (Infrastructure Team) | it-oss@company.com |
| Security Staff | Security Park (Security Team) | security@company.com |
| Developer Culture Staff | Culture Choi (HR Team) | culture@company.com |

3.2.2.2 Staffing and Funding Confirmation

How to Comply

It must be confirmed and the basis recorded that sufficient time and budget have been allocated for each role assignee to perform open source program duties. Even if there is no dedicated organization, there must be internal records confirming that the time available for concurrent assignees to invest in the work is secured, and that necessary budgets such as tool purchases or training costs have been allocated. Budget plans or work assignment documents that include management approval may constitute this Verification Material.

Considerations

• Specify dedicated vs. concurrent: Record whether it is a dedicated position or concurrent, and if concurrent, specify the input ratio (e.g., 20% of working hours).
• Retain budget evidence: Retain records proving budget support such as tool purchase contracts, training cost expenditure records, and external consulting contracts.
• Management confirmation: Maintain records of management approval or confirmation of staffing and budget support.

Sample

[Open Source Program Resource Allocation Confirmation]

Program year: 2026
Approver: [Executive name] / Approval date: 2026-01-10

| Role | Assignee | Input Ratio | Annual Budget |
|------|----------|-------------|---------------|
| Open Source Program Manager | Gil-dong Hong | 50% | - |
| Legal Counsel | Legal Kim | 20% | - |
| IT Staff (tool operation) | Infra Lee | 10% | Including tool license costs |
| Training budget | - | - | Annual OOO amount |
| External legal advisory budget | - | - | Executed as needed |

3.2.2.3 Legal Expertise Access Method

How to Comply

The method for accessing professional legal advice when legal issues related to open source license compliance arise must be identified and documented. If there is an internal legal team, record the team’s contact information and escalation procedure. If there is no internal legal team or if expertise is insufficient, specify in the document the method for utilizing external law firms or open source consulting specialists.

Considerations

• Internal vs. external: Specify both the method for utilizing the internal legal team and the criteria for requesting external consultation.
• Escalation criteria: Include in the procedure the criteria for when legal advice is needed (copyright infringement claims, non-standard licenses, patent clauses, etc.).
• Maintain external advisory list: Keep information on open source specialist external law firms or consultants up to date.

Sample

[Legal Expertise Access Method]

Internal Legal Team:
- Contact: Legal Team (legal@company.com)
- Escalation criteria: When copyright infringement claims are received, when
  interpretation of GPL-family license obligations is uncertain, when review
  of non-standard licenses is required

External Legal Advisory:
- Utilization criteria: When complex legal disputes arise that are difficult for
  the internal legal team to adjudicate
- Contract status: [External law firm name] (annual advisory contract in place)
- Open source specialist consulting: Refer to the OpenChain partner list

3.2.2.4 Internal Responsibility Assignment Procedure

How to Comply

A procedure for clearly assigning internal responsibilities related to open source compliance to each role must be documented. This procedure defines who is responsible for what, and specifies the responsible person for each work stage such as open source use approval, SBOM generation, license review, and Compliance Artifacts distribution. This procedure document can be included in the open source policy or process document.

Considerations

• Responsibility by work stage: Designate a responsible person for each stage of open source introduction, review, approval, and distribution.
• RACI utilization: Defining responsibilities by role (Responsible, Accountable, Consulted, Informed) as a RACI matrix increases clarity.
• Update cycle: Immediately update the procedure when organizational or process changes occur.

Sample

| Task | Open Source PM | Legal | IT | Security | Developer |
|------|----------------|-------|----|----------|-----------|
| Open source use approval | A | C | - | C | R |
| License obligation review | R | A | - | - | I |
| SBOM generation | A | - | R | - | C |
| Vulnerability monitoring | I | - | C | A/R | I |
| Compliance Artifacts distribution | A | C | R | - | I |
| External inquiry response | A/R | C | - | - | - |

R: Responsible / A: Accountable / C: Consulted / I: Informed

3.2.2.5 Non-Compliance Case Review and Remediation Procedure

How to Comply

A procedure for reviewing and remediating non-compliance cases (license obligation failures, SBOM omissions, unauthorized open source use, etc.) when discovered must be documented. The procedure must include: (1) identification and reporting of non-compliance cases, (2) severity assessment, (3) root cause analysis, (4) corrective action, (5) preventive measures, and (6) record retention.

Non-compliance cases can be discovered through various channels such as internal audits, external inquiries, and automated tool alerts. It is effective to distinguish between urgent measures (distribution suspension, immediate source code disclosure, etc.) and general measures depending on severity, and to set different deadlines for processing.

Considerations

• Severity classification: Classify the severity (high/medium/low) of non-compliance cases based on legal risk and set different processing deadlines.
• Escalation: Make management reporting and legal review mandatory for high-severity cases.
• Recurrence prevention: After completing corrective action, derive and record process improvement measures to prevent recurrence of the same type of non-compliance.
• Record retention: Retain non-compliance case history and corrective completion records for at least 3 years.

Sample

[Non-Compliance Case Handling Procedure]

1. Identification and Reporting
   - Identify non-compliance cases through internal audits, external inquiries,
     CI/CD tool alerts, etc.
   - Report immediately to the Open Source Program Manager.

2. Severity Assessment
   - High: GPL source code not disclosed for distributed software, copyright infringement claim received
     → Emergency review initiated within 48 hours
   - Medium: SBOM omission, incomplete license notice
     → Corrective action completed within 7 business days
   - Low: Internal process non-compliance (approval procedure skipped, etc.)
     → Corrective action completed within 30 days

3. Root Cause Analysis and Corrective Action
   - Identify the cause of non-compliance and establish a corrective plan.
   - For high and medium cases, take action after consulting with the legal team.

4. Recurrence Prevention
   - Derive and implement process or training improvement measures.

5. Record Retention
   - Record the case content, action progress, and completion date, and retain for at
     least 3 years.

5. References

• Related guide: Enterprise Open Source Management Guide — 1. Organization
• Related template: Open Source Policy Template — Appendix 1. Personnel Status

2.3 - §3.3 Content Review and Approval

2.3.1 - §3.3.1 SBOM

1. Clause Overview

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

2. What to Do

• Identify and list the open source components included in supplied software using automated tools (FOSSology, ORT, Syft, cdxgen, etc.).
• Document a procedure for tracking, reviewing, approving, and archiving open source component information (component name, version, license, source, etc.).
• Generate and manage an SBOM for each supplied software release.
• Write SBOM data in SPDX or CycloneDX standard formats to ensure interoperability.
• Immediately update the SBOM when software changes (new component addition, version upgrade, component removal) occur.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.3.1.1 Open Source Component Management Procedure

How to Comply

A series of procedures for identifying, tracking, reviewing, approving, and archiving open source components included in supplied software must be documented. The procedure covers how open source is managed throughout the software development lifecycle and must include the following steps: (1) component identification, (2) license confirmation, (3) obligation review, (4) use approval, (5) SBOM generation and registration, (6) providing SBOM upon distribution, (7) SBOM update upon changes, and (8) SBOM archiving. This procedure document itself is Verification Material 3.3.1.1.

It is recommended to adopt SPDX (ISO/IEC 5962) or CycloneDX format for standardizing the SBOM. Integrating automated tools into the CI/CD pipeline makes it easier to keep the SBOM up to date as it is automatically updated when components change.

Considerations

• Automated tool integration: Automate SBOM generation by integrating tools such as FOSSology, ORT, Syft, and cdxgen into CI/CD.
• Standard format adoption: Write SBOMs in SPDX or CycloneDX format to ensure interoperability with supply chain partners.
• Define update triggers: Mandate SBOM updates when new components are added, versions are upgraded, components are removed, or licenses change.
• Approval procedure specification: Include in the procedure the approval procedure by the Open Source Program Manager or OSRB when introducing new open source components.
• Retention period: Retain the SBOM for at least [N] years after the relevant software is distributed.

Sample

The following is a sample outline of an open source component management procedure. The full process form can be found in the Open Source Process Template.

[Open Source Component Management Procedure Outline]

(1) Identification
    - Developers report open source components to the open source management system
      when introducing them.
    - SCA tools in the CI/CD pipeline (Syft, ORT, etc.) automatically detect components.

(2) License Confirmation and Obligation Review
    - Confirm the license of identified components based on the SPDX License List.
    - Refer to the license obligation summary table to review obligations based on
      the distribution format.
    - Request legal review if uncertain.

(3) Use Approval
    - The Open Source Program Manager approves use based on review results.
    - Components that conflict with license policy are rejected after reviewing alternatives.

(4) SBOM Generation and Registration
    - Register approved components in the SBOM (format: SPDX or CycloneDX).
    - The SBOM includes component name, version, license, source (URL), and copyright notice.

(5) Distribution and SBOM Provision
    - Provide the SBOM with the software upon distribution or upon request.

(6) Update Upon Changes
    - Immediately update the SBOM when components are added, upgraded, removed, or when
      licenses change.

(7) Archiving
    - Retain the SBOM by version for at least [N] years after software distribution.

3.3.1.2 Open Source Component Records (SBOM)

How to Comply

Component records that demonstrate the procedure defined in 3.3.1.1 has actually been followed must be maintained for each supplied software. These records are the SBOM (Software Bill of Materials) and constitute Verification Material 3.3.1.2. The SBOM must include at minimum the name, version, license, and source of each open source component. Writing it in SPDX or CycloneDX format makes it immediately submittable during audits.

The SBOM should be managed by software release version, and past version SBOMs should also be retained so that the component configuration at a specific point in time can always be verified. The output from SBOM generation tools can be used directly, or it can be stored and managed in an open source management system (SW360, Dependency-Track, etc.).

Considerations

• Required items: Include component name, version, license identifier (SPDX ID), source (package registry URL or source repository), and copyright notice.
• Version-by-version management: Manage SBOMs separately for each software release version and retain past versions.
• Utilize management tools: Using open source management systems such as SW360 and Dependency-Track allows for systematic management of SBOM generation, tracking, and distribution.
• Customer provision: Retain in an accessible format so that the SBOM can be provided immediately when requested by customers or supply chain partners.

Sample

The following is a sample of key items in an SPDX format SBOM.

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: MyProduct-v1.2.0-sbom
DocumentNamespace: https://company.com/sbom/myproduct-1.2.0

PackageName: openssl
SPDXID: SPDXRef-openssl
PackageVersion: 3.0.8
PackageDownloadLocation: https://www.openssl.org/source/openssl-3.0.8.tar.gz
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: Copyright (c) 1998-2023 The OpenSSL Project

PackageName: zlib
SPDXID: SPDXRef-zlib
PackageVersion: 1.2.13
PackageDownloadLocation: https://zlib.net/zlib-1.2.13.tar.gz
PackageLicenseConcluded: Zlib
PackageLicenseDeclared: Zlib
PackageCopyrightText: Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template
• Related tools: FOSSology, ORT, Syft, cdxgen, Dependency-Track

2.3.2 - §3.3.2 License Compliance

1. Clause Overview

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

2. What to Do

• Identify major license use cases such as binary distribution, source code distribution, and distribution of modified open source, and establish handling procedures for each case.
• Include in the procedure how to handle license conflicts (combination of incompatible license components).
• Define the handling method for licenses requiring notice obligations (including copyright notices and full license text).
• Establish a distribution procedure for software containing licenses with source code disclosure obligations such as GPL.
• Document the procedure and periodically review it to address new license types.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.3.2.1 Procedure for Handling License Use Cases

How to Comply

A procedure defining how to fulfill license obligations for the various scenarios in which open source is included in supplied software must be documented. This procedure document is Verification Material 3.3.2.1. ISO/IEC 5230 presents the following 6 major use cases as examples, and the organization selects the applicable cases based on its business environment to establish handling procedures.

Each use case procedure must include: (1) criteria for determining whether the case applies, (2) license obligation items, (3) method for fulfilling the obligation, (4) person responsible, and (5) artifacts (notices, source code packages, etc.). The path for escalating to the legal team in the case of license conflicts must also be specified.

Considerations

• Determine use case scope: Select the use cases matching the organization’s software distribution method to establish procedures (not all cases may apply to every organization).
• License conflict response: Pre-define the handling method for incompatible license combinations such as GPL and Apache-2.0.
• Notice management: Establish a procedure for writing notices in a NOTICES file or product documentation for licenses with copyright notice obligations.
• Source code disclosure procedure: Separately define the procedure for responding to source code disclosure requests under GPL-family licenses.
• Update cycle: Update the procedure when new license types are adopted or distribution formats change.

Sample

The following is a sample summary table of procedures for handling license use cases.

| Use Case | License Examples | Key Obligations | Handling Method |
|----------|-----------------|-----------------|-----------------|
| Binary distribution | MIT, Apache-2.0 | Include copyright notice | Include notice in NOTICES file or in-app notice screen |
| Binary distribution | GPL-2.0, GPL-3.0 | Disclose source code or include written offer | Distribute source code package or enclose written offer |
| Source code distribution | All licenses | Preserve original license file and copyright notice | Keep license file and copyright notice as is |
| Contains modified open source | GPL-2.0, LGPL-2.1 | Note modifications, apply same license to modifications | Record modification details, disclose modified source code |
| Incompatible license combination | GPL-2.0 + Apache-2.0 | Resolve license conflict | Replace component or change structure after legal review |
| Attribution requirement | BSD-3-Clause, Apache-2.0 | Include copyright notice in product documentation or UI | Add notice to product manual or About screen |

The following is a sample outline of a license obligation handling procedure by distribution format.

[License Obligation Handling Procedure for Binary Distribution]

1. SBOM Review
   - Review the list of included open source based on the latest SBOM of the
     distributed software.

2. License Obligation Classification
   - Notice obligation: MIT, Apache-2.0, BSD, etc. → Create NOTICES file
   - Source code disclosure obligation: GPL-2.0, GPL-3.0 → Prepare source code package
   - LGPL: Determine scope of obligation based on dynamic linking status
     (legal review if necessary)

3. Compliance Artifacts Preparation
   - NOTICES file: Include copyright notices and full license text for all open source
   - Source code package: Include modified source code and build scripts for GPL components

4. Review and Approval
   - The Open Source Program Manager conducts a final review of the completeness of
     the artifacts.
   - License conflicts or uncertain items are escalated to the legal team.

5. Distribution
   - Provide Compliance Artifacts together with the software.
   - Retain a copy of the artifacts (see §3.4.1).

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template

2.4 - §3.4 Compliance Artifacts

2.4.1 - §3.4.1 Artifacts

1. Clause Overview

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

2. What to Do

• Define the types of Compliance Artifacts (NOTICES file, source code package, written offer, etc.) required for each license.
• Document a procedure for preparing artifacts and providing them with the supplied software.
• Establish and document a procedure for retaining copies of distributed artifacts for a certain period.
• Specify the artifact retention period in the policy (industry practice: at least 3 years after the last distribution).
• Maintain records that prove the archiving procedure was carried out correctly.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.4.1.1 Compliance Artifacts Preparation and Distribution Procedure

How to Comply

A procedure for preparing Compliance Artifacts required by license obligations and providing them with the supplied software must be documented. This procedure document is Verification Material 3.4.1.1. The procedure must include the following steps: (1) determining artifact types, (2) creating artifacts, (3) reviewing and approving, (4) providing with the software, and (5) record retention.

The types of Compliance Artifacts vary depending on the licenses being distributed. Generally, licenses with notice obligations (MIT, Apache-2.0, etc.) require a NOTICES file, and GPL-family licenses require a source code package or written offer. Artifacts can be provided in various ways such as enclosed in the product, included in the package, posted on a website, or provided upon request.

Considerations

• Define artifact types: Define in advance what artifacts are required for each license so that distribution preparation can proceed quickly.
• NOTICES file quality: Review that copyright notices and full license text for all open source components are included without omission.
• Source code package: For GPL components, prepare a complete source code package that includes modified source code and build scripts.
• Provision method: Determine whether to enclose artifacts with the software, post them on a website, or provide them upon request based on license requirements.
• Final review: The Open Source Program Manager conducts a final check of the completeness of artifacts before distribution.

Sample

The following is a sample outline of a Compliance Artifacts preparation and distribution procedure.

[Compliance Artifacts Preparation and Distribution Procedure]

1. Determine Artifact Types
   - Review the list of included licenses based on the SBOM.
   - Determine the necessary artifacts based on license obligations:
     · Notice obligation licenses → NOTICES file
     · GPL-2.0/3.0 → Source code package or written offer
     · LGPL → Dynamic link structure proof document or source code

2. Create Artifacts
   - NOTICES file: Generate using automated tools (FOSSology, ORT, etc.) or create manually.
     Include component name, version, full license text, and copyright notice.
   - Source code package: Include modified source code and build scripts for GPL components.

3. Review and Approval
   - The Open Source Program Manager reviews the completeness and accuracy of the artifacts.
   - Incomplete items are corrected and re-reviewed.

4. Provide with Software
   - Enclose in the product package or include in the screen displayed during installation.
   - If posting on a website or providing upon request, specify the relevant URL or procedure.
   - If using a written offer, include a written commitment valid for 3 years.

3.4.1.2 Compliance Artifacts Archiving Procedure

How to Comply

A procedure for retaining copies of Compliance Artifacts for distributed supplied software for a certain period must be documented, and records must be maintained that prove the procedure was actually followed. This procedure document and archiving records are Verification Material 3.4.1.2.

The retention period must be a reasonable period from the last distribution of the software, and at least 3 years is recommended as industry practice. The items to be retained include all artifacts provided upon distribution such as NOTICES files, source code packages, written offer copies, and SBOMs. Artifacts should be systematically managed by software version so that artifacts for a specific version can be immediately retrieved and submitted.

Considerations

• Specify retention period: Specify the retention period (at least 3 years) in the policy or procedure document.
• Version-by-version management: Link software release versions to artifacts and retain by version.
• Storage location: Store in an accessible and secure location such as an internal file server, document management system, or source code repository.
• Maintain archiving records: Record the history of when artifacts for which version were archived.
• Accessibility: Store in a searchable format so that artifacts can be immediately submitted when audits or external inquiries occur.

Sample

The following is a sample Compliance Artifacts archiving record form.

| Software Name | Version | Distribution Date | Artifact Type | Storage Location | Retention Deadline | Responsible |
|---------------|---------|-------------------|---------------|-----------------|-------------------|-------------|
| MyProduct | v1.0.0 | 2024-03-01 | NOTICES file, GPL source code package | /archive/myproduct/v1.0.0/ | 2027-03-01 | Gil-dong Hong |
| MyProduct | v1.1.0 | 2024-09-15 | NOTICES file | /archive/myproduct/v1.1.0/ | 2027-09-15 | Gil-dong Hong |
| FirmwareX | v2.3.0 | 2025-01-10 | NOTICES file, LGPL source code package, SBOM | /archive/firmwarex/v2.3.0/ | 2028-01-10 | Infra Lee |

5. References

• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related template: Open Source Process Template

2.5 - §3.5 Community Engagement

2.5.1 - §3.5.1 Contributions

1. Clause Overview

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

2. What to Do

• Decide whether the organization allows external open source contributions and specify this in the policy.
• If contributions are allowed, document a contribution policy including the types of contributions (code, documentation, bug reports, etc.), approval process, and copyright and patent handling policy.
• Establish and document a procedure for managing actual contributions from proposal through approval, submission, and recording.
• Establish a procedure for communicating the existence of the contribution policy to Program Participants.
• Record and retain the contribution history.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.5.1.1 Open Source Contribution Policy

How to Comply

A policy governing the act of contributing to external open source projects must be documented. This policy document is Verification Material 3.5.1.1. The contribution policy must include: (1) scope of allowed contributions (code, documentation, bug reports, etc.), (2) contribution approval process, (3) copyright handling (company-owned vs. individually-owned), (4) patent handling policy, (5) criteria for signing a CLA (Contributor License Agreement), and (6) prohibited contribution items (trade secrets, unpublished patents, etc.).

The policy can be included as a separate section in the Open Source Policy document or managed as an independent contribution policy document. Even organizations that completely prohibit contributions should explicitly document that “contributions are not permitted.”

Considerations

• Define contribution scope: Specifically list the types of contributions allowed (bug fixes, feature additions, documentation writing, etc.).
• Copyright attribution: Specify in the policy whether copyright of contributions belongs to the company or to the individual.
• Patent risk management: When contributions may include company patents, make legal review mandatory.
• CLA handling: When an external project requires CLA signing, specify the signing authority and procedure in the policy.
• Prohibited items: Prohibit contributions containing trade secrets, unregistered patents, or third-party intellectual property.

Sample

The following is a sample of key items in an open source contribution policy.

## Open Source Contribution Policy

### Scope of Allowed Contributions
The company allows employees to contribute to external open source projects for business purposes.
The types of contributions allowed are as follows:
- Bug fixes and patch submissions
- Documentation improvements
- Feature additions (prior approval required)
- Bug reports and issue submissions

### Copyright and Patents
- Copyright of contributions created during working hours using company resources belongs to the company.
- If there is a possibility that company patents are included in the contribution, prior review by
  the legal team is required.

### Prohibited Items
Code containing the following items cannot be contributed:
- Trade secrets or confidential information
- Third-party intellectual property
- The company's unpublished patent technology

### CLA (Contributor License Agreement)
If an external project requires CLA signing, prior reporting to and approval from the Open Source
Program Manager is required.

3.5.1.2 Open Source Contribution Management Procedure

How to Comply

A procedure defining step-by-step how to handle actual contribution activities must be documented. This procedure document is Verification Material 3.5.1.2. The procedure must include the following steps: (1) contribution proposal and approval request, (2) legal and patent review (if necessary), (3) approval, (4) contribution submission, and (5) contribution history recording. Depending on the scale or type of contribution, it is possible to operate a simplified procedure (small bug fixes) and a formal procedure (large-scale feature additions) separately.

Considerations

• Procedure distinction by contribution scale: Set scale-based criteria so that small bug fixes use simplified approval and large-scale feature additions go through formal legal review.
• Retain contribution records: Record and retain the contribution proposal, approval record, and submission link (PR/commit URL).
• Escalation: Include in the procedure an escalation path to the legal team when patent or copyright issues arise.

Sample

The following is a sample outline of an open source contribution management procedure.

[Open Source Contribution Management Procedure]

1. Contribution Proposal
   - The employee reports the contribution details (project name, contribution type, content
     summary) to the Open Source Program Manager.

2. Review and Approval
   - Small contributions (bug fixes, documentation improvements):
     The Open Source Program Manager confirms policy compliance and approves.
   - Large contributions (feature additions, core module contributions):
     The Open Source Program Manager gives final approval after the legal team's
     patent and copyright review.

3. CLA Handling (if applicable)
   - If the external project requires a CLA, process according to the approved CLA
     signing form.

4. Contribution Submission
   - Submit only the approved content.
   - Contribute using a company email or company-approved account.

5. Contribution Recording
   - Record and retain the contribution content, approver, submission date, and
     contribution URL (PR/commit link).

3.5.1.3 Contribution Policy Awareness Procedure

How to Comply

A procedure for communicating the open source contribution policy to all Program Participants so they are aware of its existence must be documented. This procedure document is Verification Material 3.5.1.3. It can be integrated with the §3.1.1.2 open source policy communication procedure by including the contribution policy in it.

It is effective to combine new hire onboarding briefings on the contribution policy, internal wiki posts, and email announcements for communication. Retain notification history and training completion records to prove that communication took place.

Considerations

• Include in onboarding: Include the contribution policy briefing as a mandatory item in the new hire onboarding process.
• Re-communication when policy is updated: Immediately notify Program Participants when the contribution policy is changed.
• Evidence retention: Retain notification sending history and training completion certificates for at least 3 years.
• Policy accessibility: Post the contribution policy on the internal portal or wiki at all times so it can be checked at any time.

Sample

The following is a sample contribution policy communication email.

Subject: [Open Source] Open Source Contribution Policy Notice

To: All development-related employees
From: Open Source Program Manager

Hello,

We would like to inform you about the company's open source contribution policy.
All employees involved in contributing to external open source projects are requested
to review and familiarize themselves with the policy document at the link below.

- Policy document: [Internal portal link]
- Key contents: Scope of allowed contributions, approval procedure, copyright and
               patent handling policy
- Policy version: v1.0 (Effective date: YYYY-MM-DD)

If you wish to make a contribution, you must go through the prior approval procedure.
Inquiries: Open Source Program Manager (oss@company.com)

Thank you.
Open Source Program Manager

5. References

• Related guide: Enterprise Open Source Management Guide — 6. Contributions
• Related template: Open Source Policy Template — §3 Open Source Contributions

2.6 - §3.6 Adherence to the Specification

2.6.1 - §3.6.1 Conformance

1. Clause Overview

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

2. What to Do

• Conduct a self-assessment to verify that all verification material items (24 items) for all clauses from §3.1 to §3.5 are in place.
• Write a document confirming that the program satisfies all requirements of ISO/IEC 5230 within the scope of application defined in §3.1.4.
• Record the reviewer, approver, and confirmation date in the confirmation document.
• Choose an appropriate certification method — self-certification, independent assessment, or third-party certification — and proceed.

3. Requirements and Verification Materials

4. How to Comply and Samples by Verification Material

3.6.1.1 Specification Conformance Confirmation Document

How to Comply

A document must be written confirming that all requirements of ISO/IEC 5230:2020 are satisfied within the scope of application defined in §3.1.4. This document is Verification Material 3.6.1.1. It can be written in the form of a checklist confirming compliance for each of the 24 verification material items, or as a general conformance statement.

Before writing, use this guide’s Full Clause Checklist to verify that all verification materials are in place. The document must include the scope of the program being confirmed, the specification version confirmed (ISO/IEC 5230:2020 version 2.1), the confirmation date, and the reviewer and approver.

Considerations

• Self-assessment first: Before writing the document, conduct a self-assessment of all 24 verification material items to confirm there are no missing items.
• Specify specification version: Specify the specification version confirmed in the document (ISO/IEC 5230:2020 version 2.1).
• Approval process: Formalize the document through the Open Source Program Manager’s review and management or OSRB approval.
• Update cycle: After a new version of the specification is published, re-confirm based on the latest version within 18 months (see §3.6.2).

Sample

The following is a sample ISO/IEC 5230 specification conformance confirmation document.

[ISO/IEC 5230 Specification Conformance Confirmation]

Program name: [Company name] Open Source Compliance Program
Scope of application: [Enter scope defined in §3.1.4]
Specification confirmed: ISO/IEC 5230:2020 (version 2.1)
Confirmation date: YYYY-MM-DD

This document confirms that the above program satisfies all requirements of
ISO/IEC 5230:2020 from §3.1 to §3.6.

Summary of conformance items:
- §3.1 Program Foundation (5 clauses, 8 verification materials): Satisfied ✓
- §3.2 Relevant Tasks (2 clauses, 7 verification materials): Satisfied ✓
- §3.3 Content Review and Approval (2 clauses, 3 verification materials): Satisfied ✓
- §3.4 Compliance Artifacts (1 clause, 2 verification materials): Satisfied ✓
- §3.5 Community Engagement (1 clause, 3 verification materials): Satisfied ✓
- §3.6 Adherence to the Specification (2 clauses, 2 verification materials): Satisfied ✓

Reviewer: [Open Source Program Manager name]
Approver: [Management or OSRB head name]
Approval date: YYYY-MM-DD

5. References

• ISO/IEC 5230 self-certification: https://certification.openchainproject.org/
• Full clause checklist: ISO/IEC 5230 Conformance Guide

2.6.2 - §3.6.2 Duration

1. Clause Overview

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

2. What to Do

• Record and manage the date on which conformance was obtained.
• Within the past 18 months of obtaining conformance, re-confirm and document that the program still meets all requirements of the specification.
• If a new version of the specification is published, update the program to meet the latest version and re-confirm within 18 months.
• Conduct periodic internal audits to verify that the program maintains continuous compliance.

3. Requirements and Verification Materials

4. How to Comply with Each Verification Material

3.6.2.1 Document Confirming All Requirements Met Within 18 Months

How to Comply

A document confirming that the program still meets all requirements of the specification must be maintained within 18 months of obtaining conformance. This document constitutes Verification Material 3.6.2.1. The simplest approach is to periodically review and update the specification conformance document from §3.6.1.1 at least once a year. Each time it is updated, record the review date and reviewer to demonstrate that a review was conducted within the past 18 months.

When a new version of ISO/IEC 5230 is published, update the program to meet the latest version within the 18-month grace period and create a re-confirmation document. Since conformance expires if the grace period is exceeded, it is important to monitor specification revision trends and respond in a timely manner.

Considerations

• Establish a periodic re-confirmation schedule: Conduct a minimum of one annual internal audit to re-confirm and document the validity of all verification material items.
• Monitor specification revisions: Regularly check OpenChain Project announcements for specification revisions and establish a response plan within 18 months when a new version is published.
• Manage conformance expiration: Register the conformance acquisition date and validity period (18 months) in a calendar or management system to receive renewal reminders before expiration.
• Reflect changes: When organizational structure, product portfolio, or process changes occur, immediately reflect them in the program and update the re-confirmation document.

Sample

Below is a sample periodic re-confirmation record for ISO/IEC 5230 specification compliance.

[ISO/IEC 5230 Specification Conformance Periodic Re-confirmation Record]

Program Name: [Company Name] Open Source Compliance Program
Initial Conformance Date: YYYY-MM-DD
Specification Version Confirmed: ISO/IEC 5230:2020 (Version 2.1)

| Re-confirmation Date | Result | Changes | Reviewer | Notes |
|----------------------|--------|---------|----------|-------|
| 2025-01-10 | Fully Met | Reflected personnel change (§3.2.2.1 updated) | John Doe | - |
| 2026-01-08 | Fully Met | None | John Doe | Next re-confirmation: 2027-01-08 |

Next re-confirmation scheduled: YYYY-MM-DD (within 12 months of last re-confirmation)
18-month validity deadline: YYYY-MM-DD (18 months from last re-confirmation)

Below is a sample response checklist for when a new version of the specification is published.

[ISO/IEC 5230 New Version Response Checklist]

New Version Publication Date: YYYY-MM-DD
Response Deadline (18 months): YYYY-MM-DD

□ Identify changes in requirements between new version and current version
□ Establish program update plan based on changed requirements
□ Complete updates and organize verification materials under new version
□ Create and approve specification conformance document under new version
□ Proceed with self-certification or certification renewal process

5. References

• Check latest OpenChain specification version: https://www.openchainproject.org/license-compliance
• Self-certification renewal: https://certification.openchainproject.org/
• §3.6.1 Conformance: Previous Clause

3 - ISO/IEC 18974 Conformance Guide

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

Author : OpenChain Korea Work Group / CC BY 4.0

Target Audience

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

Relationship with ISO/IEC 5230

How to Use This Guide

Full Clause Checklist

ISO/IEC 18974 consists of a total of 11 clauses and 25 Verification Material items. Items marked with ★ are added or changed from a security perspective compared to ISO/IEC 5230.

§4.1 Program Foundation

§4.2 Relevant Tasks

§4.3 Content Review and Approval

§4.4 Conformance

Total: 11 clauses / 25 Verification Material items

ISO/IEC 18974 Certification Process

There are three ways to officially have ISO/IEC 18974 conformance recognized.

3.1 - §4.1 Program Foundation

3.1.1 - §4.1.1 Policy

1. Clause Overview

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

2. What to Do

• Document and formalize a policy for managing security vulnerabilities in open source components included in the supplied software.
• Include vulnerability detection, assessment, response, and notification principles, as well as a Coordinated Vulnerability Disclosure (CVD) policy.
• Establish and document a procedure for communicating the policy to Program Participants (developers, security personnel, legal, IT, etc.).
• Specify in the policy a review process that periodically reviews the policy and its communication method to keep them current and valid.
• Record the review completion date, reviewer, and change history in the document.

3. Requirements and Verification Materials

§4.1.1 Policy A written open source software security assurance policy shall exist that governs open source software security assurance of the supplied software. The policy shall be internally communicated. The policy and its method of communication shall have a review process to ensure they remain current and valid.

Verification Material(s): 4.1.1.1 A documented open source software security assurance policy. 4.1.1.2 A documented procedure that makes program participants aware of the security assurance policy.

4. How to Comply and Samples per Verification Material

4.1.1.1 Documented Security Assurance Policy

How to Comply

If an Open Source Policy for ISO/IEC 5230 is already in place, you can either add a security assurance section to that policy or create a separate security assurance policy document. Both approaches satisfy Verification Material 4.1.1.1.

The policy should include: ① principles for identifying, tracking, and responding to security vulnerabilities; ② risk assessment criteria based on CVSS and remediation timelines; ③ Coordinated Vulnerability Disclosure (CVD) policy; ④ post-deployment monitoring principles; and ⑤ periodic review cycle and reviewer. The key difference from ISO/IEC 5230 §3.1.1.1 is that the periodic review process must be explicitly stated within the policy document.

Considerations

• Integration with 5230 Policy: It can be managed in an integrated manner by expanding the §5 Security Vulnerability Response section of the existing ISO/IEC 5230 policy.
• Specify Review Cycle: Include a clause stating that a minimum of one annual periodic review is conducted, with an immediate review triggered by changes in the threat environment or legal requirements.
• Adopt CVSS Criteria: Use CVSS (Common Vulnerability Scoring System) for vulnerability severity assessment and specify remediation timelines in the policy (e.g., Critical: 7 days, High: 30 days).
• Include CVD Policy: Include a CVD procedure in the policy for collaborating confidentially to resolve externally reported vulnerabilities before public disclosure.
• Version Control: Record the policy version number, change history, and review completion date.

Sample

The following is a sample of the security assurance section of an open source policy.

## §5 Open Source Security Assurance

### 5.1 Purpose
The company systematically identifies and responds to security vulnerabilities
in open source components included in the supplied software to minimize security risks.

### 5.2 Vulnerability Response Principles
Remediation timeline criteria for known vulnerabilities (CVEs) are as follows:
- Critical (CVSS 9.0–10.0): Patch or mitigation within 7 days
- High (CVSS 7.0–8.9): Patch or mitigation within 30 days
- Medium (CVSS 4.0–6.9): Establish patch plan within 90 days
- Low (CVSS 0.1–3.9): Address in next scheduled update

### 5.3 Coordinated Vulnerability Disclosure (CVD) Policy
When a vulnerability is reported externally, it will be resolved in cooperation
with the reporter before public disclosure.
Vulnerability reporting channel: security@company.com

### 5.4 Policy Review
This policy and its communication method shall be reviewed at least annually
to remain current and valid.
The review completion date and reviewer shall be recorded in the document.

4.1.1.2 Documented Procedure for Security Assurance Policy Awareness

How to Comply

A procedure for communicating the security assurance policy to Program Participants must be documented, in the same manner as the policy communication procedure for ISO/IEC 5230 (§3.1.1.2). The additional requirement of §4.1.1 is that the communication procedure itself must also be periodically reviewed to maintain its validity. You can either add security assurance policy content to the existing 5230 policy communication procedure, or establish a separate security policy communication procedure.

Considerations

• Reuse 5230 Procedure: Respond efficiently by adding the security assurance policy to existing open source policy communication channels (onboarding, internal wiki, email).
• Review the Communication Procedure: Specify the review cycle (annually) and the reviewer in the communication procedure document to manage the validity of the procedure itself.
• Retain Evidence: Keep notification history and training completion records for a minimum of 3 years.

Sample

Subject: [Security] Open Source Security Assurance Policy Notice and Acknowledgment Request

To: All employees in development/deployment/security-related roles
From: Open Source Program Manager

Dear all,

The company's open source security assurance policy has been established (or revised).
Please review and familiarize yourself with the policy document at the link below.

- Policy document: [Internal portal link]
- Key content: Vulnerability response principles, CVSS-based remediation timelines, CVD policy
- Policy version: v1.0 (Effective date: YYYY-MM-DD) / Next review scheduled: YYYY-MM-DD

Inquiries: Open Source Program Manager (oss@company.com)

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.1 Policy
• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template

3.1.2 - §4.1.2 Competence

1. Clause Overview

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

2. What to Do

• Create a list of responsibilities per program role (same as 5230).
• Define and document the competencies required for each role (same as 5230).
• Create a separate list mapping participant names to their respective roles (added in 18974).
• Assess and record the competencies of each participant (same as 5230).
• Periodically review the competence framework and record process changes (added in 18974).
• Confirm that the competence framework aligns with the company’s internal best practices and assign a person responsible (added in 18974).

3. Requirements and Verification Materials

★ = Additional items compared to ISO/IEC 5230 §3.1.2

§4.1.2 Competence The organization shall:

• Identify the roles and responsibilities that impact the performance and effectiveness of the program;
• Determine the necessary competence of program participants fulfilling each role;
• Ensure that program participants are competent on the basis of appropriate education, training, and/or experience;
• Where applicable, take actions to acquire the necessary competence;
• Retain appropriate documented information as evidence of competence.

Verification Material(s): 4.1.2.1 A documented list of roles with corresponding responsibilities for the different participants in the program. 4.1.2.2 A document that identifies the competencies for each role. 4.1.2.3 List of participants and their roles. 4.1.2.4 Documented evidence of assessed competence for each program participant. 4.1.2.5 Documented evidence of periodic reviews and changes to the process. 4.1.2.6 Documented evidence that these processes align with and are up-to-date with company internal best practices, and that a person has been assigned to make sure they remain so.

4. How to Comply and Samples per Verification Material

4.1.2.1 Documented List of Roles and Responsibilities

This is the same as ISO/IEC 5230 §3.1.2.1. From a security assurance perspective, the roles of security personnel (DevSecOps, vulnerability analysis) must be clearly included. Refer to §3.1.2.1 Documented List of Roles and Responsibilities for how to prepare this.

4.1.2.2 Document Identifying Competencies per Role

This is the same as ISO/IEC 5230 §3.1.2.2. The security personnel role should include competencies in CVSS score interpretation, operation of vulnerability analysis tools (OSV-SCALIBR, Dependency-Track, etc.), and DevSecOps understanding. Refer to §3.1.2.2 Document Identifying Competencies per Role for how to prepare this.

4.1.2.3 List of Participants and Their Roles ★

How to Comply

Unlike the list of roles in 4.1.2.1, this item requires a list mapping actual individuals by name to the roles they are assigned. The purpose is to clearly identify who the actual personnel participating in the program are, not just the organizational roles. This list must be updated immediately when personnel changes occur.

Considerations

• Name or job title: Using a job title instead of a personal name is acceptable, but it must be specific enough to identify a particular individual.
• Multiple roles: If someone holds multiple roles, list all of them.
• Timely updates: Update the document and increment the version immediately when an assignee changes.

Sample

| Name | Role | Contact | Assigned Date |
|------|------|---------|---------------|
| Gil-dong Hong | Open Source Program Manager | oss@company.com | 2025-01-01 |
| Chul-su Kim | Security (DevSecOps) | security@company.com | 2025-01-01 |
| Young-hee Lee | Legal | legal@company.com | 2025-01-01 |
| Infra Park | IT | it@company.com | 2025-03-15 |

4.1.2.4 Evidence of Assessed Competence

This is the same as ISO/IEC 5230 §3.1.2.3. Refer to §3.1.2.3 Evidence of Assessed Competence for how to prepare this.

4.1.2.5 Evidence of Periodic Reviews and Process Changes ★

How to Comply

The competence framework (role definitions, competency criteria, assessment methods) must be periodically reviewed, and any changes resulting from the review process must be recorded. The key is to verify that new security tool adoption, organizational restructuring, and improvements to vulnerability response processes have been reflected in the competence framework. The review record itself serves as Verification Material 4.1.2.5.

Considerations

• Review cycle: Conduct a minimum annual periodic review and an immediate review when the organization or processes change.
• Record changes: Record the content of changes, reasons for changes, change dates, and who made the changes.
• Evidence format: Review meeting minutes, review completion confirmations, and change history logs can all serve as evidence.

Sample

[Competence Framework Periodic Review Record]

| Review Date | Review Content | Changes | Reviewer |
|-------------|---------------|---------|----------|
| 2025-01-10 | Full review of all roles and competencies | Added CVSS v4.0 interpretation item to security competency | Gil-dong Hong |
| 2026-01-08 | Full review of all roles and competencies | Added Dependency-Track operation competency to IT role | Gil-dong Hong |

4.1.2.6 Verification of Alignment with Internal Best Practices ★

How to Comply

It must be confirmed that the competency definitions and assessment processes are aligned with the company’s internal best practices (HR policy, technical training standards, etc.), and a person responsible for continuously managing this must be assigned. The purpose is to ensure that the competence framework does not deviate from industry standards or internal guidelines.

Considerations

• Assign a responsible person: Explicitly assign and record a person responsible for managing the currency of the competence framework and its alignment with internal best practices.
• Best practice criteria: Industry standards (NIST SSDF, ISO 27001, etc.), internal security policies, and DevSecOps guidelines can be used as best practice criteria.

Sample

[Internal Best Practice Alignment Confirmation]

Competence Framework Manager: Gil-dong Hong (Open Source Program Manager)
Last alignment review date: 2026-01-08
Reference best practice criteria: Internal Security Training Standard v3.0, NIST SSDF 1.1

Review results:
- Security competency criteria align with the internal security training curriculum ✓
- Vulnerability analysis tool competency reflects the latest tools (Dependency-Track v4.x) ✓
- Next alignment review scheduled: 2027-01-08

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.2 Competence
• Related guide: Enterprise Open Source Management Guide — 1. Organization
• Related template: Open Source Policy Template — Appendix 1. Personnel Status

3.1.3 - §4.1.3 Awareness

1. Clause Overview

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

2. What to Do

• Confirm that Program Participants understand the objectives of the open source security assurance program (vulnerability detection, assessment, response, and notification).
• Assess whether each participant is aware of how their role contributes to the security assurance framework.
• Assess awareness of the legal, business, and security implications of failing to comply with the vulnerability response process.
• Record and retain the results of awareness assessments as documentation.
• Provide additional training to participants with gaps and retain the results of re-assessments.

3. Requirements and Verification Materials

§4.1.3 Awareness The organization shall ensure that the program participants are aware of:

• The open source software security assurance policy and where to find it;
• Relevant open source software security assurance objectives;
• Their contribution to the effectiveness of the program; and
• The implications of not following the program’s requirements.

Verification Material(s): 4.1.3.1 Documented evidence of assessed awareness for the program participants - which shall include the program’s objectives, contributions within the program, and implications of failing to follow the program’s requirements.

4. How to Comply and Samples per Verification Material

4.1.3.1 Evidence of Assessed Awareness for Program Participants

How to Comply

The basic approach is the same as ISO/IEC 5230 §3.1.3.1, but the awareness assessment questions must focus on Security Assurance. The three core awareness items are: ① the objectives of the security assurance program (vulnerability identification, assessment, response, and CVD); ② how one’s own role contributes to the security framework; and ③ the security, legal, and business risks of non-compliance with the process.

The method for recording and retaining assessment results as documentation is the same as for 5230. Conduct a minimum annual periodic assessment, and perform an initial assessment for new participants immediately upon joining.

Considerations

• Design security-specific questions: Include content specific to security assurance in the assessment questions, such as vulnerability response procedures, CVSS criteria, and CVD policy.
• Role-specific in-depth assessment: For security personnel, assess awareness up to technical vulnerability analysis; for developers, assess awareness of secure coding practices as well.
• Assessment cycle and evidence retention: Conduct assessments at a minimum annually and immediately upon a new participant joining, and retain results for a minimum of 3 years.

Sample

The following is a sample security assurance policy awareness acknowledgment form.

[Open Source Security Assurance Policy Awareness Acknowledgment]

I confirm that I have familiarized myself with the following:

1. The existence and location of the company's open source security assurance policy
2. The objectives of the open source component vulnerability detection, assessment,
   response, and CVD program
3. How my role contributes to the operation of the security assurance program
4. The security breaches, legal liabilities, and business risks that may arise
   from failing to comply with the vulnerability response process

Name: ________________  Role: ________________
Signature: ________________  Date: ________________

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.3 Awareness
• Related guide: Enterprise Open Source Management Guide — 5. Training
• Related template: Open Source Policy Template — §6 Training and Awareness

3.1.4 - §4.1.4 Program Scope

1. Clause Overview

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

2. What to Do

• Create a documented written statement that clearly defines the program scope (target software, organizational units, exclusions) (same as 5230).
• Define the performance metrics that the program seeks to improve upon (added in 18974).
• Maintain records demonstrating that continuous improvement is achieved through periodic reviews, updates, and audits (added in 18974).
• Periodically measure actual performance against metric targets and record the results.
• Identify areas for improvement and document the history of follow-up actions.

3. Requirements and Verification Materials

★ = Additional items compared to ISO/IEC 5230 §3.1.4

§4.1.4 Program Scope Different programs may be designed to address different scopes depending on the supplier’s needs and business model. The scope needs to be clear.

Verification Material(s): 4.1.4.1 A written statement that clearly defines the scope and limits of the program. 4.1.4.2 A set of metrics the program seeks to improve upon. 4.1.4.3 Documented evidence from each review, update, or audit to demonstrate continuous improvement.

4. How to Comply and Samples per Verification Material

4.1.4.1 Written Statement of Program Scope

This is the same as ISO/IEC 5230 §3.1.4.1. Refer to §3.1.4.1 Written Statement of Program Scope for how to prepare this. From a security assurance perspective, explicitly state that “response to known and newly discovered vulnerabilities” is included within the scope.

4.1.4.2 Set of Performance Metrics ★

How to Comply

The performance metrics that the security assurance program seeks to improve must be defined and documented. Metrics must be measurable and realistic, and connected to the program’s key objectives (vulnerability detection rate, response time, SBOM completeness, etc.). The metrics set itself is Verification Material 4.1.4.2.

Considerations

• Measurability: Set quantitative indicators rather than qualitative descriptions.
• Realistic targets: Set targets at an achievable level initially and progressively raise them.
• Periodic measurement: Measure metrics at a minimum quarterly and record the results.

Sample

[Security Assurance Program Performance Metrics]

| Metric | Measurement Method | Target | Measurement Cycle |
|--------|--------------------|--------|--------------------|
| SBOM Completeness | Proportion of distributed software with an SBOM | 100% | Quarterly |
| Critical Vulnerability Average Response Time | Detection date to patch application date | 7 days or less | Quarterly |
| High Vulnerability Average Response Time | Detection date to patch application date | 30 days or less | Quarterly |
| Vulnerability Recurrence Rate | Rate of re-vulnerability in the same component | 10% or less | Semi-annually |
| New Participant Awareness Assessment Completion Rate | Rate of assessment completion within 30 days of joining | 100% | Quarterly |
| External Vulnerability Inquiry Response Compliance Rate | Rate of response completion within 14 days | 95% or more | Quarterly |

4.1.4.3 Evidence of Continuous Improvement ★

How to Comply

Records showing that the security assurance program is actually improving through periodic reviews, process updates, internal audits, etc. must be maintained. Document the issues found, improvement actions taken, and improvement results at each review or audit. These records themselves are Verification Material 4.1.4.3.

Considerations

• Regular audit schedule: Conduct a full program audit at a minimum annually and record the results.
• Track improvement history: Track and record whether issues raised in previous audits were resolved in subsequent audits.
• Link to metrics: Use the performance trend of the metrics defined in 4.1.4.2 as evidence of improvement.

Sample

[Security Assurance Program Periodic Review Record]

Review date: 2026-01-10
Reviewers: Gil-dong Hong (Open Source Program Manager), Chul-su Kim (Security)

Metrics performance:
- SBOM Completeness: 97% → 100% (target achieved)
- Critical vulnerability average response time: 9 days → 6 days (target achieved)
- High vulnerability average response time: 35 days → 28 days (target achieved)

Improvements identified:
1. External vulnerability inquiry response compliance rate 88% → target of 95% not met
   Action: Additional inquiry monitoring assignee designated (completed 2026-02-01)
2. Delays in awareness assessment for new participants identified
   Action: Awareness assessment added as mandatory item to onboarding checklist (completed 2026-01-20)

Next review scheduled: 2027-01-09

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.4 Program Scope
• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template — §1.4 Scope

3.1.5 - §4.1.5 Standard Practice Implementation

1. Clause Overview

§4.1.5 is a new clause exclusive to 18974 that does not exist in ISO/IEC 5230. It requires establishing documented procedures for each of the 8 standard handling methods for open source vulnerabilities. This clause goes beyond a simple declaration of “responding” to vulnerabilities, requiring the formalization of the entire vulnerability lifecycle into procedures — from threat identification, detection, follow-up, customer notification, post-deployment monitoring, continuous security testing, risk verification, to information export. This clause, together with §4.3.2 Security Assurance, forms the core of ISO/IEC 18974.

2. What to Do

Establish documented procedures for each of the 8 methods:

1. Identification of structural and technical threats: Define a method to identify threats affecting the supplied software.
2. Detection of known vulnerabilities: Define a method to detect the existence of known vulnerabilities (CVEs) in open source components.
3. Follow-up on vulnerabilities: Define a method to take follow-up actions such as patching, mitigation, or acceptance for identified vulnerabilities.
4. Customer notification: Define a method to communicate identified vulnerabilities to customers, where applicable.
5. Post-deployment analysis for newly disclosed vulnerabilities: Define a method to analyze already-deployed software for newly published CVEs.
6. Continuous security testing: Define a method to apply continuous and iterative security testing to all supplied software before release.
7. Verification of risk resolution: Define a method to verify that identified risks have been addressed before release.
8. Export of risk information: Define a method to export risk information to third parties, where appropriate.

3. Requirements and Verification Materials

§4.1.5 Standard Practice Implementation A program shall demonstrate defined and implemented processes for sound and robust handling of known vulnerabilities and security software development, specifically by defining and implementing the following:

• A method to identify structural and technical threats to the supplied software;
• A method to detect the existence of known vulnerabilities in the supplied software;
• A method to follow up on identified known vulnerabilities;
• A method to communicate identified known vulnerabilities to customers, where applicable;
• A method to analyze the supplied software for newly disclosed known vulnerabilities when they are published;
• A method to apply continuous and iterative security testing to all supplied software before release;
• A method to verify that identified risks have been addressed before release; and
• A method to export information about identified risks to third parties, where appropriate.

Verification Material(s): 4.1.5.1 A documented procedure exists for each of the methods identified above.

4. How to Comply and Samples per Verification Material

4.1.5.1 Documented Procedures for the 8 Vulnerability Handling Methods

How to Comply

A procedure explaining “how” each of the 8 methods is performed must be documented. These procedures together constitute Verification Material 4.1.5.1. You can create 8 separate documents, or organize all 8 as sections within a single integrated vulnerability management procedure document. The latter approach is recommended as it reduces management burden and is easier to maintain consistency.

Method 1 — Identification of Structural and Technical Threats

Define a method to identify structural (architecture design, dependency structure) and technical (known vulnerable patterns, risky components) threats that may affect the supplied software. Using threat modeling (STRIDE, PASTA, etc.) or periodically analyzing the dependency tree to identify risky components is a common approach.

[Threat Identification Procedure Overview]
- Conduct threat modeling when designing a new software architecture.
- Analyze the dependency tree quarterly to identify EOL (End-of-Life) components,
  abandoned projects, and components with high dependency concentration.
- Register identified threats in the Risk Registry and assign a responsible party.

Method 2 — Detection of Known Vulnerabilities

Define a method to detect the existence of CVEs (Common Vulnerabilities and Exposures) in open source components based on the SBOM. Integrating automated tools (OSV-SCALIBR, Dependency-Track, Grype, etc.) into the CI/CD pipeline to scan for vulnerabilities at every build is an effective approach.

[Vulnerability Detection Procedure Overview]
- Integrate SCA (Software Composition Analysis) tools into the CI/CD pipeline.
- Automatically run SBOM-based vulnerability scans on every build.
- Reference multiple vulnerability databases such as OSV (Open Source Vulnerabilities),
  NVD (National Vulnerability Database), and GitHub Advisory Database.
- Automatically notify the security team of detected vulnerabilities along with their severity.

Method 3 — Follow-up on Vulnerabilities

Define a method to take follow-up actions on identified vulnerabilities, such as applying patches, implementing mitigations, replacing components, or accepting risk. Specify priority and remediation timelines based on CVSS scores in the procedure.

[Follow-up Procedure Overview]
- Determine remediation priority and timelines based on CVSS score:
  Critical (9.0+): within 7 days / High (7.0-8.9): within 30 days
  Medium (4.0-6.9): within 90 days / Low (0.1-3.9): at next release
- If no patch is available, implement mitigation measures (network isolation, WAF rule additions, etc.)
  and risk acceptance decisions require joint approval from the security team and open source PM.
- Record the remediation outcome in the vulnerability tracking system and verify completion.

Method 4 — Customer Notification

Define a method to communicate vulnerabilities to customers when they are discovered in supplied software and may affect customers. Specify the notification criteria (severity, customer impact scope), notification channels, and notification timelines in the procedure.

[Customer Notification Procedure Overview]
- Notify customers for Critical/High vulnerabilities that affect distributed products.
- Notification channels: Product security notice (website), customer security contact email,
  security advisory publication
- Notification timeline: Within 7 days of confirming patch or mitigation measures
- Notification content: Affected components, CVE ID, severity, recommended actions, patch delivery schedule

Method 5 — Post-deployment Analysis for Newly Disclosed Vulnerabilities

Define a method to analyze whether newly published CVEs affect already-deployed software. A monitoring system is needed that retains the SBOM for deployed software and automatically cross-references newly published CVEs against those SBOMs.

[Post-deployment Newly Disclosed Vulnerability Analysis Procedure Overview]
- Retain SBOMs for deployed software by version.
- Use tools such as Dependency-Track to automatically cross-reference newly published CVEs
  against deployed SBOMs and generate a list of affected software versions.
- When affected versions are confirmed, process them according to Method 3 (follow-up)
  and Method 4 (customer notification) procedures.
- Monitoring is performed automatically at all times, with weekly summary reports
  sent to the security team.

Method 6 — Continuous Security Testing

Define a method to apply continuous and iterative security testing to all supplied software before release. Integrating SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and SCA into the CI/CD pipeline is the common approach.

[Continuous Security Testing Procedure Overview]
- Security testing by CI/CD pipeline stage:
  · On code commit: SAST (static analysis), SCA (open source vulnerability scan)
  · On PR merge: Verify passage of security gate (blocking if Critical/High unresolved)
  · On release candidate build: DAST (dynamic analysis), container image scan
- Automatically block release on security test failure and notify the security team.
- Continuously monitor test coverage and results on a dashboard.

Method 7 — Verification of Risk Resolution

Define a method to verify that identified risks have actually been resolved before release. After applying a patch, confirm via rescan that the vulnerability has been eliminated and record the result.

[Risk Resolution Verification Procedure Overview]
- Run a rescan using the same tool after patch or mitigation is complete.
- Confirm that the vulnerability has been eliminated in the rescan result and record
  it in the vulnerability tracking system.
- For Critical/High vulnerabilities, the security team approves the verification result.
- If releasing with unresolved risks, document management approval and a mitigation plan.

Method 8 — Export of Risk Information

Define a method to export identified risk information to third parties (supply chain partners, customers, vulnerability databases, etc.) where appropriate. This includes using the VEX (Vulnerability Exploitability eXchange) format, or procedures for reporting vulnerability information to upstream projects through CVD channels.

[Risk Information Export Procedure Overview]
- When a new vulnerability is independently discovered, report it to the upstream project
  or CERT following CVD procedures.
- Use VEX format when sharing vulnerability impact information with supply chain partners.
- Before sharing with third parties, conduct a legal review to ensure no trade secrets
  or undisclosed information are included.
- Record and retain a log of information exports (recipient, date, content summary).

5. References

• No corresponding ISO/IEC 5230 clause (new clause exclusive to 18974)
• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related tools: OSV-SCALIBR, Dependency-Track

3.2 - §4.2 Relevant Tasks

3.2.1 - §4.2.1 Access

1. Clause Overview

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

2. What to Do

• Specify a public contact (email address, web form, etc.) on the product or website where third parties can send vulnerability-related inquiries.
• Document the internal procedure for handling vulnerability reports received through the public channel.
• Include the processing stages — receipt, triage, assignment, response, and closure — in the procedure.
• Specify in the procedure a handling policy following CVD principles (confidential collaboration followed by public disclosure).
• Record and retain inquiry receipt and response history for a designated period.

3. Requirements and Verification Materials

§4.2.1 Access Maintain a process to effectively respond to external vulnerability inquiries. Publicly identify a means by which a third party can make an inquiry about known vulnerabilities or newly discovered vulnerabilities.

Verification Material(s): 4.2.1.1 Publicly visible method that allows any third party to make a known vulnerability or newly discovered vulnerability inquiry (e.g., via a published contact email address, or web portal that is monitored by program participants). 4.2.1.2 An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.

4. How to Comply and Samples per Verification Material

4.2.1.1 Publicly Available Vulnerability Inquiry Channel

How to Comply

A public contact for third parties to report or inquire about vulnerabilities must be established and published externally. Publishing a security-dedicated email address (e.g., security@company.com) on product documentation, the website’s security policy page, or in a SECURITY.md file (for GitHub or other open source repositories) is common practice. This public channel itself is Verification Material 4.2.1.1.

This can be operated separately from the ISO/IEC 5230 §3.2.1.1 license inquiry channel, or configured by adding a channel dedicated to security vulnerability reporting.

Considerations

• Separate security-dedicated channel: Operating a license inquiry channel (oss@company.com) and a security vulnerability reporting channel (security@company.com) separately makes it easier to manage processing priorities.
• Guarantee of response: State explicitly that the reporting channel is actively monitored (e.g., “acknowledgment response within 3 business days”).
• Use the security.txt standard: Applying the RFC 9116 security.txt standard makes it easy for security researchers to find contact information.

Sample

[Website Security Policy Page / SECURITY.md Sample]

## Security Vulnerability Reporting

To report a security vulnerability in our software, please use the channel below.
We follow Coordinated Vulnerability Disclosure (CVD) practices.

- Reporting email: security@company.com
- Acknowledgment: Within 3 business days
- Handling policy: Vulnerabilities are reviewed confidentially and disclosed after patching

4.2.1.2 Internal Vulnerability Inquiry Response Procedure

How to Comply

A procedure for internally handling vulnerability reports received from external parties must be documented. Following CVD principles, the basic framework involves collaborating confidentially with the reporter to resolve the vulnerability and then disclosing it after the patch is ready. This procedure document is Verification Material 4.2.1.2.

Considerations

• Follow CVD principles: Maintain confidentiality with the reporter until the vulnerability is resolved and agree on a disclosure schedule.
• Processing timelines: Specify timelines for each stage — acknowledgment, vulnerability verification, patch delivery, and disclosure — in the procedure.
• Record retention: Retain the report content, review process, response actions, and disclosure history for a minimum of 3 years.

Sample

[External Vulnerability Report Response Procedure]

1. Receipt and Acknowledgment (within 3 business days)
   - Check the security@company.com inbox daily.
   - Reply to the reporter with an acknowledgment and a promise of confidential handling.

2. Vulnerability Verification (within 7 business days)
   - The security team verifies the reproducibility and impact scope of the reported vulnerability.
   - Calculate the CVSS score and classify the severity.

3. Patch Development and Remediation (7–90 days depending on severity)
   - Perform patching or mitigation according to the §4.1.5 Method 3 (follow-up) procedure.
   - Share the patch schedule with the reporter and coordinate as needed.

4. Disclosure (after patch is complete)
   - Draft a Security Advisory, confirm with the reporter, and publish.
   - Request CVE ID issuance if necessary.
   - Notify affected customers according to the §4.1.5 Method 4 (customer notification) procedure.

5. Record Retention
   - Retain the report content, review process, remediation outcome, and disclosure history
     for a minimum of 3 years.

5. References

• Corresponding ISO/IEC 5230 clause: §3.2.1 External Inquiry Response
• Related guide: Enterprise Open Source Management Guide — 3. Process

3.2.2 - §4.2.2 Effectively Resourced

1. Clause Overview

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

2. What to Do

• Document the names or job titles of personnel assigned to each role in the program.
• Confirm and record that sufficient time and budget are allocated to each role assignee.
• Identify and document the internal or external security expertise available to resolve known vulnerabilities (different focus from 5230).
• Document the procedure for assigning internal responsibility for security assurance compliance to each role.

3. Requirements and Verification Materials

★ = Different from ISO/IEC 5230 §3.2.2.3 (legal expertise) — focus shifted to security expertise

§4.2.2 Effectively Resourced Identify and Resource Program Task(s):

• Assign accountability to ensure the successful execution of program tasks.
• Program tasks are sufficiently resourced.

Verification Material(s): 4.2.2.1 A document with the names of the persons, group or function in program role(s) identified. 4.2.2.2 The identified program roles have been properly staffed and adequate funding provided. 4.2.2.3 A document identifying the expertise available to address identified known vulnerabilities. 4.2.2.4 A documented procedure that assigns internal responsibilities for security assurance.

4. How to Comply and Samples per Verification Material

4.2.2.1 Document Identifying Role Assignees

This is the same as ISO/IEC 5230 §3.2.2.1. Security assurance roles (DevSecOps engineer, vulnerability analysis personnel, etc.) must be specified. Refer to §3.2.2.1 Document Identifying Role Assignees for how to prepare this.

4.2.2.2 Confirmation of Staffing and Budget Support

This is the same as ISO/IEC 5230 §3.2.2.2. Security-related budget items such as vulnerability scanning tools, security training, and external security consulting should be included. Refer to §3.2.2.2 Confirmation of Staffing and Budget Support for how to prepare this.

4.2.2.3 Document Identifying Vulnerability Resolution Expertise ★

How to Comply

The expertise available to actually analyze and resolve identified known vulnerabilities must be identified and documented. This differs in nature from the legal expertise access method in ISO/IEC 5230 §3.2.2.3. If an internal security team exists, record that team’s competencies and contact information; if internal expertise is insufficient, document how external security experts or PSIRT (Product Security Incident Response Team) services are utilized.

Considerations

• Internal expertise list: Identify internal experts or responsible teams by vulnerability type (web security, firmware security, cryptography, etc.).
• Securing external expertise: For vulnerability types that are difficult to handle internally, record contract details or contact methods with external security organizations (CERT, security consulting firms).
• Escalation criteria: Specify the criteria under which external expertise is utilized.

Sample

[Vulnerability Resolution Expertise Status]

Internal expertise:
- Security (Chul-su Kim): Web vulnerabilities, open source component CVE analysis, CVSS assessment
- DevSecOps team: CI/CD security pipeline operation, container vulnerability analysis

Criteria for utilizing external expertise:
- When zero-day vulnerabilities, firmware vulnerabilities, or cryptography-related vulnerabilities occur
- When the internal team determines that resolution within 30 days is not feasible

External organizations:
- [External Security Consulting Firm Name] (annual contract, vulnerability analysis service)
- KrCERT/CC (vulnerability coordination and reporting channel)

4.2.2.4 Internal Responsibility Assignment Procedure

This has the same structure as ISO/IEC 5230 §3.2.2.4, but must include the assignment of security assurance-specific responsibilities (vulnerability detection, CVSS assessment, customer notification, CVD management, etc.) to each role. Refer to §3.2.2.4 Internal Responsibility Assignment Procedure for preparation, and reflect security tasks as shown in the sample below.

Sample

| Task | Open Source PM | Security | IT | Developer |
|------|----------------|----------|----|-----------|
| Vulnerability scan tool operation | I | C | A/R | I |
| CVE detection and classification | I | A/R | C | I |
| CVSS score assessment | I | A/R | - | C |
| Patch application and verification | C | A | C | R |
| Customer notification decision | A | R | - | I |
| CVD external report response | C | A/R | - | I |
| Vulnerability record management | I | A/R | C | I |

R: Responsible / A: Accountable / C: Consulted / I: Informed

5. References

• Corresponding ISO/IEC 5230 clause: §3.2.2 Effectively Resourced
• Related guide: Enterprise Open Source Management Guide — 1. Organization

3.3 - §4.3 Content Review and Approval

3.3.1 - §4.3.1 SBOM

1. Clause Overview

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

2. What to Do

• Establish a procedure for identifying, tracking, reviewing, and approving open source components in the supplied software (same as 5230).
• Establish a procedure for continuously recording and retaining the SBOM throughout the software lifecycle (emphasized in 18974).
• Retain SBOMs by version for deployed software to use in post-deployment vulnerability impact analysis.
• Integrate SBOM information with vulnerability management tools (such as Dependency-Track) so that automatic impact analysis occurs whenever new CVEs are published.
• Define triggers for immediately updating the SBOM when components are added, changed, or removed.

3. Requirements and Verification Materials

§4.3.1 Software Bill of Materials A process shall exist for creating and managing a software bill of materials that includes each open source software component (and its identified licenses) from which the supplied software is comprised, in a manner that ensures the supplied software’s open source software components are continuously recorded throughout the supplied software’s life cycle, including archiving.

Verification Material(s): 4.3.1.1 A documented procedure to ensure that all open source software used in the supplied software is continuously recorded during the life cycle of the supplied software. This includes an archive of all open source software used in the supplied software. 4.3.1.2 Open source software component records for the supplied software that demonstrates the documented procedure was followed.

4. How to Comply and Samples per Verification Material

4.3.1.1 SBOM Lifecycle Continuous Recording Procedure

How to Comply

Building on the SBOM management procedure from ISO/IEC 5230 §3.3.1.1, the procedure must be strengthened to focus on continuous lifecycle recording and archiving. This procedure document is Verification Material 4.3.1.1.

From a security assurance perspective, the key to SBOM management is that the SBOM must remain valid even after deployment so it can be immediately used for impact analysis whenever new CVEs are published. To this end, the procedure must include archiving the SBOMs of all deployed software versions and integrating with vulnerability management tools.

Considerations

• Maintain SBOM at each lifecycle stage: Define procedures to keep the SBOM current at each stage — development, build, deployment, and post-deployment monitoring.
• Archive policy: Archive the SBOMs of all deployed versions by version and specify the retention period (minimum: support period of the relevant software + 3 years).
• Integration with vulnerability tools: Import SBOMs into tools such as Dependency-Track so that automatic cross-referencing occurs every time new CVEs are published.
• Update triggers: Mandate SBOM updates upon the following events: component addition, version upgrade, component removal, license change, and replacement due to newly discovered vulnerabilities.

Sample

The following is a sample overview of an SBOM management procedure enhanced from a security assurance perspective.

[SBOM Lifecycle Management Procedure Overview]

(1) Development stage
    - Register open source components in the SBOM immediately upon introduction.
    - SCA tools (Syft, cdxgen, etc.) in the CI/CD pipeline automatically detect them.

(2) Build stage
    - Automatically generate the latest SBOM on every build (SPDX or CycloneDX format).
    - Integrate with vulnerability scanning tools to record the vulnerability status at build time.

(3) Deployment stage
    - Finalize the SBOM for the release version and store it in the archive repository.
    - Import the SBOM into Dependency-Track to activate continuous monitoring.

(4) Post-deployment monitoring
    - When new CVEs are published, automatically cross-reference against all archived version SBOMs.
    - When affected versions are confirmed, process them according to the §4.1.5 Method 5 procedure.

(5) Update triggers
    - Update the SBOM immediately upon the following events:
      · Component addition, version upgrade, component removal
      · License change, replacement due to newly discovered vulnerability

(6) Archive retention
    - Retain SBOMs of all deployed versions by version.
    - Retention period: Minimum 3 years after the official support end of the relevant software

4.3.1.2 Open Source Component Records (SBOM)

This is the same as ISO/IEC 5230 §3.3.1.2. From a security assurance perspective, recording the known vulnerability status of each component or a link to the vulnerability management tool alongside license information in the SBOM makes integration with §4.3.2 easier. Refer to §3.3.1.2 Open Source Component Records for how to prepare this.

5. References

• Corresponding ISO/IEC 5230 clause: §3.3.1 SBOM
• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related tools: Syft, cdxgen, Dependency-Track

3.3.2 - §4.3.2 Security Assurance

1. Clause Overview

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

2. What to Do

• Detect the existence of known vulnerabilities in each open source component in the SBOM.
• Assign a risk/impact score (CVSS) to each detected vulnerability.
• Determine and document the necessary remediation or mitigation steps for each vulnerability.
• Obtain customer consent above a pre-determined threshold, where applicable.
• Perform appropriate actions based on the risk/impact score and record them.
• Perform appropriate actions for newly disclosed vulnerabilities in already-deployed software.
• Monitor and respond to vulnerability disclosures for the supplied software after its release.
• Maintain detection and remediation results per vulnerability as component records.

3. Requirements and Verification Materials

§4.3.2 Security Assurance There shall exist a process to apply security assurance activities to each open source software component that is to be included in the bill of materials (SBOM):

• Applying a method to detect the existence of known vulnerabilities;
• Assign a risk/impact score to each identified known vulnerability;
• Determine and document the necessary remediation or mitigation steps for each detected and scored known vulnerability;
• Obtain customer approval above a pre-determined threshold, where applicable;
• Perform appropriate action based on risk/impact score;
• Perform appropriate action for newly disclosed known vulnerabilities in previously released supplied software;
• Ability to monitor and respond to vulnerability disclosures for the supplied software after its release.

Verification Material(s): 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.2 For each open source software component, a record is maintained of the identified known vulnerabilities and action taken (including a determination that no action was required).

4. How to Comply and Samples per Verification Material

4.3.2.1 Vulnerability Detection and Resolution Procedure

How to Comply

A documented procedure covering the entire process from vulnerability detection to resolution for each open source component in the SBOM is Verification Material 4.3.2.1. This procedure is a concrete operational flow that integrates the individual methods defined in §4.1.5.

The flowchart below illustrates the entire flow from CVE detection to remediation completion.

flowchart TD
    A([SBOM Component]) --> B[Vulnerability Scan\nSCA Tool]
    B --> C{CVE Detected?}
    C -- No --> D[Record: No Detection\nAwait Periodic Rescan]
    C -- Yes --> E[Calculate CVSS Score\nRisk/Impact Assessment]
    E --> F{Severity Classification}
    F -- Critical/High --> G[Immediate Response\n7–30 day deadline]
    F -- Medium --> H[Planned Response\n90 day deadline]
    F -- Low --> I[Address at Next Release]
    G --> J{Customer Impact?}
    H --> J
    J -- Yes --> K[Customer Notification\n§4.1.5 Method 4]
    J -- No --> L[Remediation Decision]
    K --> L
    L --> M{Patch Available?}
    M -- Yes --> N[Apply Patch\nRescan Verification]
    M -- No --> O[Mitigation Measures\nor Risk Acceptance]
    N --> P[Record Remediation Result\n§4.3.2.2]
    O --> P
    P --> Q([Continuous Monitoring\n§4.1.5 Method 5])

Detailed Steps

The following is a sample describing each step of the flowchart in procedure document form.

[Vulnerability Detection and Resolution Procedure]

Step 1 — Vulnerability Detection
- At CI/CD pipeline build, SCA tools (Dependency-Track, OSV-SCALIBR, etc.)
  automatically scan for vulnerabilities based on the SBOM.
- Reference multiple vulnerability DBs such as NVD, OSV, and GitHub Advisory Database.
- Even after deployment, automatically cross-reference against archived SBOMs
  when new CVEs are published.

Step 2 — Risk/Impact Score Assessment
- Calculate the CVSS v3.1 base score for each detected CVE.
- Adjust the Environmental Score by considering the actual usage context of the
  company's product (network exposure, privilege requirements, etc.).
- Severity classification: Critical (9.0+) / High (7.0-8.9) / Medium (4.0-6.9) / Low (0.1-3.9)

Step 3 — Remediation Decision and Documentation
- Determine the remediation method based on severity and customer impact scope:
  · Patch application: Upgrade to a newer version or apply a patch
  · Mitigation: Network isolation, disabling functionality, etc. when no patch is available
  · Risk acceptance: When the actual exploitability is low and mitigation is also unnecessary
    (joint approval from security team + open source PM required)
- Record the basis for the remediation decision in the vulnerability tracking system.

Step 4 — Customer Consent (where applicable)
- For Critical/High vulnerabilities affecting customer-distributed products:
  · Proactively notify the customer's security contact of vulnerability information
    and the response plan.
  · Share the patch deployment schedule and mitigation methods.

Step 5 — Remediation
- Perform the determined remediation within the remediation deadline.
- Run a rescan after patch application to confirm the vulnerability is eliminated.
- Update the remediation completion result in the §4.3.2.2 record.

Step 6 — Continuous Monitoring
- Continuously monitor the vulnerability status of deployed software using tools
  such as Dependency-Track.
- When new CVEs are published, automatically or immediately re-execute steps 1–3.

4.3.2.2 Vulnerability and Action Records

How to Comply

For each open source component in the SBOM, records of identified vulnerabilities and actions taken (including a determination that no action was required) must be maintained. These records are Verification Material 4.3.2.2. The phrase “including a determination that no action was required” is important — components where no vulnerability was detected must also record the fact that a scan was performed and the detection result.

Records can be managed using various tools such as Dependency-Track, a Jira security issue tracker, or spreadsheets, and must be maintained in a form that can be produced immediately during an audit.

Considerations

• Record per component: Maintain individual records for each component in the SBOM.
• Record “no detection” as well: Record the scan date and result even for components where no vulnerability was detected.
• Track remediation history: Manage the history of vulnerability occurrence, remediation, and rescan for the same component in chronological order.
• Retention period: Retain for the support period of the relevant software plus a minimum of 3 years.

Sample

The following is a sample per-component vulnerability and action record.

| Software | Version | Component | Component Version | CVE ID | CVSS | Severity | Action | Action Date | Assignee | Notes |
|----------|---------|-----------|-------------------|--------|------|----------|--------|-------------|----------|-------|
| MyProduct | v1.2.0 | openssl | 3.0.7 | CVE-2023-0286 | 7.4 | High | Upgraded to 3.0.8 | 2023-02-10 | Chul-su Kim | Rescan confirmed |
| MyProduct | v1.2.0 | zlib | 1.2.11 | CVE-2022-37434 | 9.8 | Critical | Upgraded to 1.2.13 | 2022-10-15 | Chul-su Kim | Customer notified |
| MyProduct | v1.2.0 | libpng | 1.6.37 | None | - | - | No action required | 2023-03-01 | Chul-su Kim | Periodic scan result |
| FirmwareX | v2.3.0 | busybox | 1.35.0 | CVE-2022-28391 | 9.8 | Critical | Risk acceptance (network isolation mitigation) | 2022-11-20 | Chul-su Kim | No patch available, PM approval obtained |

5. References

• No corresponding ISO/IEC 5230 clause (new clause exclusive to 18974)
• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related tools: Dependency-Track, OSV-SCALIBR
• Related clauses: §4.1.5 Standard Practice Implementation, §4.3.1 SBOM

3.4 - §4.4 Conformance

3.4.1 - §4.4.1 Completeness

1. Clause Overview

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

2. What to Do

• Conduct a self-assessment to verify that all Verification Materials (25 items) of all clauses from §4.1 to §4.3 are in place.
• Prepare a document affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974 within the defined scope.
• Record the reviewer, approver, and confirmation date in the confirmation document.
• When simultaneously complying with ISO/IEC 5230 and 18974, use an integrated checklist to reduce duplicated review burden.

3. Requirements and Verification Materials

§4.4.1 Completeness In order for a program to be deemed conformant with this specification, the organization shall affirm that the program satisfies the requirements presented in this specification.

Verification Material(s): 4.4.1.1 Documented evidence affirming the program specified in §4.1.4 satisfies all the requirements of this specification.

4. How to Comply and Samples per Verification Material

4.4.1.1 Specification Conformance Confirmation Document

How to Comply

A document affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974 within the defined scope must be prepared. This document is Verification Material 4.4.1.1. Use the checklist below to review all 25 Verification Material items and record the confirmation results.

ISO/IEC 18974 Conformance Self-Assessment Checklist

§4.1 Program Foundation
[ ] 4.1.1.1 Documented security assurance policy
[ ] 4.1.1.2 Procedure for communicating policy awareness
[ ] 4.1.2.1 List of roles and responsibilities
[ ] 4.1.2.2 Document identifying competencies per role
[ ] 4.1.2.3 List of participants and role mapping ★
[ ] 4.1.2.4 Evidence of assessed competence
[ ] 4.1.2.5 Evidence of periodic reviews and changes ★
[ ] 4.1.2.6 Verification of alignment with internal best practices ★
[ ] 4.1.3.1 Evidence of assessed awareness for participants
[ ] 4.1.4.1 Written statement of program scope
[ ] 4.1.4.2 Set of performance metrics ★
[ ] 4.1.4.3 Evidence of continuous improvement ★
[ ] 4.1.5.1 Documented procedures for 8 vulnerability handling methods ★

§4.2 Relevant Tasks
[ ] 4.2.1.1 Publicly available vulnerability inquiry channel
[ ] 4.2.1.2 Internal vulnerability inquiry response procedure
[ ] 4.2.2.1 Document identifying role assignees
[ ] 4.2.2.2 Confirmation of staffing and budget
[ ] 4.2.2.3 Document identifying vulnerability resolution expertise ★
[ ] 4.2.2.4 Internal responsibility assignment procedure

§4.3 Content Review and Approval
[ ] 4.3.1.1 SBOM lifecycle continuous recording procedure
[ ] 4.3.1.2 Open source component records (SBOM)
[ ] 4.3.2.1 Vulnerability detection and resolution procedure ★
[ ] 4.3.2.2 Vulnerability and action records ★

§4.4 Conformance
[ ] 4.4.1.1 Document affirming all requirements are satisfied
[ ] 4.4.2.1 Document affirming requirements satisfied within past 18 months

★ = Additional items compared to ISO/IEC 5230 (9 items)

Considerations

• Integrated review with 5230: If ISO/IEC 5230 certification is held, reuse existing materials for the 16 common items and focus on the 9 items exclusive to 18974.
• Approval procedure: Formalize the document through review by the Open Source Program Manager and approval by management.
• Specify specification version: Specify ISO/IEC 18974:2023 (version 1.0) as the specification confirmed for conformance in the document.

Sample

[ISO/IEC 18974 Specification Conformance Confirmation]

Program name: [Company name] Open Source Security Assurance Program
Scope: [Scope as defined in §4.1.4]
Specification confirmed for conformance: ISO/IEC 18974:2023 (version 1.0)
Confirmation date: YYYY-MM-DD

This document affirms that the above program satisfies all requirements
(25 Verification Material items) of ISO/IEC 18974:2023 from §4.1 through §4.4.

Conformance confirmation summary:
- §4.1 Program Foundation (5 clauses, 13 Verification Materials): Satisfied ✓
- §4.2 Relevant Tasks (2 clauses, 6 Verification Materials): Satisfied ✓
- §4.3 Content Review and Approval (2 clauses, 4 Verification Materials): Satisfied ✓
- §4.4 Conformance (2 clauses, 2 Verification Materials): Satisfied ✓

Reviewer: [Open Source Program Manager name]
Approver: [Management or OSRB head name]
Approval date: YYYY-MM-DD

5. References

• Corresponding ISO/IEC 5230 clause: §3.6.1 Conformance
• ISO/IEC 18974 self-certification: https://certification.openchainproject.org/
• Full clause checklist: ISO/IEC 18974 Conformance Guide

3.4.2 - §4.4.2 Duration

1. Clause Overview

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

2. What to Do

• Record and manage the date on which conformance was obtained.
• Within the past 18 months of obtaining conformance, re-confirm and document that all requirements of the specification are still met.
• If a new version of ISO/IEC 18974 is published, update the program to meet the latest version and re-confirm within 18 months.
• Conduct periodic internal audits to verify that all 25 verification material items remain continuously compliant.

3. Requirements and Verification Materials

4. How to Comply with Each Verification Material

4.4.2.1 Document Confirming All Requirements Met Within 18 Months

How to Comply

In the same manner as ISO/IEC 5230 §3.6.2.1, review and update the specification conformance document from §4.4.1.1 at least once a year. Each time it is updated, record the review date and reviewer to demonstrate that a review was conducted within the past 18 months.

For organizations operating both ISO/IEC 5230 and 18974 simultaneously, consolidating the periodic re-confirmation schedules for both specifications into a single annual integrated audit improves management efficiency.

Sample

[ISO/IEC 18974 Specification Conformance Periodic Re-confirmation Record]

Initial Conformance Date: YYYY-MM-DD
Specification Version Confirmed: ISO/IEC 18974:2023 (Version 1.0)

| Re-confirmation Date | Result | Changes | Reviewer | Notes |
|----------------------|--------|---------|----------|-------|
| 2025-01-10 | Fully Met | Vulnerability resolution expertise document updated (§4.2.2.3) | John Doe | - |
| 2026-01-08 | Fully Met | Performance metric targets raised (§4.1.4.2) | John Doe | - |

Next re-confirmation scheduled: YYYY-MM-DD
18-month validity deadline: YYYY-MM-DD

5. References

• Corresponding ISO/IEC 5230 clause: §3.6.2 Duration
• Check latest OpenChain specification version: https://www.openchainproject.org/security-assurance

3.5 - ISO/IEC 5230 vs 18974 Comparison

1. Relationship Between the Two Standards

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

Complying with both standards simultaneously allows license obligation fulfillment and security vulnerability management to be operated as a single integrated open source program. Common foundational documents (policy, competence records, SBOM procedures) can be written once and used for both standards simultaneously, so the practical additional work required to prepare for 18974 after obtaining 5230 certification is approximately 30–40% of the total.

2. Clause-by-Clause Comparison Table

Summary

• Common clauses: 9 (16 Verification Materials)
• 5230-exclusive clauses: §3.3.2, §3.4.1, §3.5.1 (6 Verification Materials)
• 18974-exclusive clauses: §4.1.5, §4.3.2 (3 Verification Materials)
• Common clauses expanded in 18974: 4 — §4.1.1, §4.1.2, §4.1.4, §4.2.2 (+6 Verification Materials)

3. Verification Material Count Comparison

4. Strategy for Simultaneous Conformance with Both Standards

The most efficient path is to obtain 5230 first and then prepare for 18974 as an addition. The policy documents, competence records, and SBOM procedures built during the 5230 certification process can be directly used for 18974’s common clauses (§4.1.1–§4.1.4, §4.2.1, §4.2.2, §4.3.1, §4.4.1, §4.4.2). What needs to be separately prepared are additions to existing documents and 2 new clauses exclusive to 18974.

The items that need to be newly prepared exclusively for 18974 are as follows:

• §4.1.5 Standard Practice Implementation: Documented procedures for each of the 8 vulnerability handling methods (threat identification, detection, follow-up, customer notification, post-deployment analysis, security testing, risk verification, and information export)
• §4.3.2 Security Assurance: Full process from CVE detection → risk assessment → remediation decision → execution → monitoring, and per-component vulnerability action records
• Supplementing common clauses: Additional preparation of §4.1.2 list of participants (4.1.2.3), evidence of periodic review (4.1.2.5), alignment with best practices (4.1.2.6), §4.1.4 performance metrics (4.1.4.2), and evidence of continuous improvement (4.1.4.3)

The practical workload for an organization with a 5230 framework to additionally prepare for 18974 is estimated to be approximately 30–40% of the total 5230 preparation work.

5. Reference Links

• ISO/IEC 5230 Conformance Guide
• ISO/IEC 18974 Conformance Guide
• Enterprise Open Source Management Guide
• OpenChain Self-Certification

4 - Templates

4.1 - 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 the OOO company (hereinafter referred to as “the company”) to properly utilize open source software (hereinafter referred to as “open source”).

1. Principles of open source compliance / security assurance
2. Principles of contribution 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.

All members of the company can check the open source policy at the following link on the internal wiki: [internal_link]

(2) Impact of Non-compliance

If this policy is not complied with, the following situations may occur:

• You may receive a request for open source license compliance from outside.
• You may have to disclose the source code developed by the company against your will.
• You may be sued by the open source copyright holder.
• You may be fined for copyright infringement and breach of contract, or receive an order to stop selling products.
• The company’s reputation may be damaged.
• You may be claimed for damages due to breach of contract with the supplier.
• You may be exposed to serious security incidents, causing significant damage to the company.

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 procedures.

(3) How Members Can Contribute

All members of the company 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 performing the necessary activities.

2. Scope of Application

This policy applies to the following three parts:

1. It applies to all products provided or distributed by the company. However, the use of open source for internal use only is not included in the scope of this policy.
2. It applies when members contribute to external open source projects.
3. It applies when internal code is released as open source.

The scope of application can be changed to suit the company’s business environment. In particular, the Open Source Program Manager investigates at least once a month whether there are products that are not applied and are distributed or serviced externally to ensure continuous effectiveness. This is used as a criterion for changing the scope of application when even one case is found.

The procedure for changing the scope of application is as follows:

1. If the Open Source Program Manager determines that changes to the scope of application of the policy are necessary due to changes in the company’s business environment such as new business and organizational restructuring, he/she submits a proposal to the OSRB.
2. The OSRB approves an appropriate level of change in the scope of application.
3. The OSRB modifies the open source policy to change the scope of application.

The Open Source Program Manager continuously reviews, updates, and inspects the scope of application at least once a month to improve it, and documents the history using the Jira Issue Tracker.

3. Terminology

• SBOM (Software Bill of Materials): List of software components
• Software Distribution Participants: Refers to all employees involved in software development, distribution, and contribution in the company, including software developers, distribution engineers, quality engineers, etc.
• …

4. Roles, Responsibilities, and Competencies

The following roles, responsibilities, and competencies required for each role are defined to ensure the effectiveness of the policy.

The responsible organization/person and the level of required competencies for each role are defined in [Appendix 1. Status of Responsible Persons].

• The Open Source Program Manager regularly updates the list according to the company’s business situation.
• The head of the organization responsible for each role appoints a person in charge within the organization and allocates appropriate time and budget to ensure that the person in charge can faithfully perform the role.
  • If the person in charge of each role finds that they are not being properly supported in performing their role, they should raise the issue with the Open Source Program Manager.
  • The Open Source Program Manager discusses problem-solving with the head of the organization. If it is not resolved appropriately, the Open Source Program Manager can request problem-solving from the OSRB.
  • The OSRB shares the issue with the head of the upper organization and requests a solution.

(1) OSRB

The OSRB (Open Source Review Board) is a consultative body composed of the Open Source Program Manager and responsible persons from related organizations such as the legal team, patent team, development team, infrastructure team, etc., for managing open source in the company.

• The OSRB establishes policies and processes for managing open source in the company and defines the roles and responsibilities within the company to implement them.
• The OSRB reviews and improves policies and processes annually. All improvement processes are documented and recorded.
  • The OSRB always updates the policies and processes for open source compliance and security assurance to reflect the business environment by analyzing the company’s process performance, shortcomings, and best practices.
  • The Open Source Program Manager is responsible for managing the policies and processes for open source compliance.
  • The security officer is responsible for managing the policies and processes for open source security assurance.
• The OSRB discusses solutions and prepares countermeasures when open source issues occur within the company.
• The OSRB reports issues to the executive management when necessary and receives feedback on risk mitigation measures.

(2) Open Source Program Manager

The Open Source Program Manager is responsible for the overall responsibility of the company’s open source program. It has the following responsibilities to ensure the management activities of open source used in products and services:

• Defines the roles necessary for open source compliance and assigns the responsible organization and person for each role. Consults with the OSRB if necessary. The internal responsibility for open source security assurance is assigned by the security officer.
• Organizes and evaluates open source education.
• Serves as the chairman of the OSRB and directs activities.
• Responds to inquiries and requests related to open source use and compliance from outside.
• Reviews and approves open source use requests.
• Maintains SBOM records.
• Provides a way for members to receive open source related advice.
• Maintains a repository for open source notices and source code disclosure.

(3) OSPO

The Open Source Program Office (OSPO) supports and nurtures open source activities both inside and outside the company.

• It provides guidelines for contributing code to external open source projects.
• It provides guidelines for releasing internal projects as open source.
• It develops and operates an open source portal.
• It develops and selects open source tools.
• It sponsors open source project events.
• It manages relationships with open source communities.

(4) Legal Officer

The Legal Officer provides advice on legal risks and mitigation measures that may arise in the process of using open source, such as interpreting open source licenses and obligations.

• It provides a reasonable method for members to inquire about open source compliance issues.
• It provides advice on license and intellectual property issues, including conflicts due to incompatible open source licenses.
• It reviews necessary legal matters such as open source licenses, CLA (Contributor License Agreement), etc. when contributing to external open source projects.
• In acute cases, it requests advice from external law firms with open source specialist lawyers.

(5) IT Officer

The IT Officer operates open source analysis tools and automates them to build a system that allows open source analysis to be smoothly performed for all distributed software.

• It operates open source analysis tools.
• It integrates with the DevOps environment to automate open source analysis.
• It builds systems and processes to perform open source analysis for all distributed software.
• It secures and maintains SBOM for all distributed software.

(6) Security Officer

The Security Officer operates open source security vulnerability analysis tools to build a system that allows security vulnerability analysis to be smoothly performed for all distributed software.

• It assigns responsibilities for each task to ensure successful open source security assurance.
• It operates open source security vulnerability analysis tools.
• It integrates with the DevSecOps environment to automate open source security vulnerability analysis.
• It builds systems and processes to perform open source security vulnerability analysis for all distributed software.
• It provides a reasonable method for members to inquire about security vulnerabilities, and uses external expert technical advice if necessary to resolve vulnerabilities.

(7) Development Culture Officer

The Development Culture Officer supports in-house developers to actively use open source and participate in in-house and external communities to acquire advanced development culture.

• It encourages participation in open source communities.
• It creates a culture that recognizes active external open source project activities as in-house performance.
• It creates a development culture that can be recognized as an attractive company by open source developers.

(8) Quality Assurance Officer

The Quality Assurance Officer, such as QA, checks whether the open source license obligations have been properly performed when distributing software.

• It checks whether open source management activities are performed according to the development process stage.
• It checks whether the deliverables are created as required by the open source license.
• It checks whether the open source notice and the source code to be disclosed are provided together when distributing software.
• If there is an issue, it notifies the software development/distribution organization and guides them to correct the issue immediately.

5. Education and Evaluation

All members who are responsible for the roles defined in Chapter 4 must take the advanced open source education course provided by the [Learning Portal]. Through this, they will familiarize themselves with the open source policy, related education policy, and how to look it up.

The education history and evaluation results are kept in the [Learning Portal] for at least 3 years.

Assessment Evidence Retention Procedure

• Evidence of competency assessment shall be collected and retained in one or more of the following forms: test scores, training completion certificates, policy awareness confirmation signatures. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)
• Evidence shall be registered in the internal document management system (e.g., Learning Portal, HR system) and maintained in a state that can be immediately produced during audits.
• After the retention period expires, records shall be destroyed in accordance with the personal data protection policy.

6. Open Source Use

When developing and distributing products and services using open source, you must comply with the obligations required by each open source license. This activity is called open source compliance.

For proper open source compliance activities, the software development/distribution organization complies with the following matters and all processes are recorded and preserved in the Jira Tracker.

(1) Open Source Identification and License Obligation Review

When introducing open source to product/service development, first identify what the open source license is, and review and confirm the obligations required by the license.

The company’s [Open Source License Guide] includes a list of major open source licenses, and explains the obligations required by each license according to the following types of distribution:

• Binary form
• Source form
• Strong/Weak Copyleft
• SaaS-based provision
• Whether modified
• Including open source that requires author indication, etc.

The software development/distribution organization can refer to this guide when reviewing open source license obligations. If you need to review an open source license not mentioned in this guide, contact the open source program manager.

(2) Open Source License Consideration Design

Understand the combination relationship of open source and design the software architecture so that our code is not affected by the open source license.

The company’s [Open Source License Guide] explains the range of source code disclosure for each open source license and how to design to prevent the disclosure of our code.

(2-1) License Use Case Policy

The following guidelines apply depending on how open source components are used:

1. Internal use only: When open source is used internally without external distribution, there is no obligation to generate compliance deliverables, but SBOM records must still be maintained.
2. External distribution (binary): If licenses that require source code disclosure (e.g., GPL) are included, a source code package must be provided along with the binary, or a written offer must be included.
3. External distribution (SaaS/network service): If licenses that treat network use as distribution (e.g., AGPL) are included, a separate legal review is required.
4. Contribution to open source projects: Confirm that the license applied to contributed code is compatible with the project’s license.

For each use case, compliance deliverables are created and managed according to the procedures in §4.3.

(3) Creation of Open Source Compliance Deliverables

The most basic of open source compliance activities is to understand the status of open source included in distributed software. This is to properly meet the core of open source compliance, which is the requirements of the open source license. In other words, you need to create a set of compliance deliverables for the open source included in the distributed software.

Open source compliance deliverables are divided into two main categories.

1. Open Source Notice: A document for providing the full text of the open source license and copyright information
2. Source Code Package to be Disclosed: A package that collects the source code to be disclosed to fulfill the obligations of open source licenses that require source code disclosure, such as GPL, LGPL

To collect, distribute, and store these compliance deliverables, comply with the following matters.

• The open source notice or source code package to be disclosed is collected according to the conditions required by each license. For example, if the license requires the entire text of the license to be enclosed, you cannot just provide a link.
• The collected deliverables are stored in a separate repository.
• If the source code to be disclosed is provided by a written agreement, the download link is made public so that the repository of the collected deliverables can be accessed from the outside.
• Compliance deliverables shall be retained for a minimum of 3 years from the date of the last distribution of the supplied software. If a license requires a longer retention period, that period takes precedence. (ISO/IEC 5230 §3.4.1.2)

You can issue an open source notice and collect a source code package to be disclosed through the company’s open source process.

(4) Creation of SBOM (Bill of Materials)

You must create and manage the status of open source included in distributed software (BOM: Bill of Materials).

• SBOMs shall be generated in one of the following standard formats: SPDX or CycloneDX. (ISO/IEC 18974 §3.3.1.2)

You can create and preserve SBOM using open source tools through the company’s open source process.

(5) Compliance Issue Response Procedure

If a compliance issue is raised, the open source program manager performs the following procedures to respond quickly.

1. Confirm the inquiry receipt and specify a reasonable resolution time.
2. Check whether the issue content is pointing out a real problem. (If not, inform the issue raiser that it is not a problem.)
3. If it is a real problem, prioritize and decide on an appropriate response.
4. Perform the response and, if necessary, appropriately supplement the open source process.
5. The above contents are preserved using the Jira Tracker.

(6) Open Source Vulnerability Response

• We identify open source vulnerabilities and evaluate their severity.
• Based on the analysis of open source vulnerabilities, we either fix the vulnerability or apply a security patch. The decision to address vulnerabilities takes into account the severity of the vulnerability, the importance of the system, and the availability of vulnerability fixes or security patches.
• Remediation actions shall be completed within the following deadlines based on vulnerability severity: Critical (CVSS 9.0 or above) within 1 week, High (CVSS 7.0–8.9) within 4 weeks. (ISO/IEC 18974 §3.3.2.1)
• We monitor the announcement of new open source security vulnerabilities and respond quickly when vulnerabilities occur. Open source vulnerability monitoring can be performed through vulnerability databases such as CVE and websites of security specialist organizations.
• All vulnerability response records shall be retained for a minimum of 3 years from the date of the last distribution of the relevant supplied software. (ISO/IEC 18974 §3.3.2.2)

7. Open Source Contribution

The company encourages participation and contribution to external open source projects to create business value from open source. However, care must be taken to avoid unintentional exposure of the company’s intellectual property or infringement of third-party rights during this process. To this end, members of the company must comply with the following when contributing to external open source projects:

(1) Request for Review and Approval

Contributing to open source is granting the open source project the right to modify, use, and distribute the work from a copyright perspective. Sometimes, you may need to transfer your copyright to the open source project. However, the copyright of works created during the employment period is generally owned by the employer. In other words, the works created by company members are owned by the company. The act of arbitrarily contributing works to open source can trigger unnecessary copyright infringement issues.

Therefore, if there is an open source project you want to contribute to, you must comply with the review request and approval process before making the initial contribution according to the open source contribution process.

However, in the case of simple content such as the following, you can contribute according to the judgment of the member without the review process because the risk of copyright infringement is not high:

• Small code snippets of 10 lines or less
• Questions / Answers on Stack Overflow
• Management activities on GitHub: Creating Issues, Reviewing / Approving Pull Requests, etc.

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

You should only contribute code that you have the right to contribute. In other words, you contribute code that you have written yourself. You should not arbitrarily contribute third-party code.

(3) Be Careful About Intellectual Property Exposure

Do not contribute code or documents that may expose sensitive information or company intellectual property, such as patents.

If the code you want to contribute contains a company patent, you need to check whether this patent can be contributed to the project under an open source license. If there is any ambiguity, contact the OSPO.

(4) Be Careful About Signing the CLA

Some open source projects require all contributors to sign the CLA (Contributor License Agreement). This is an agreement that seeks consent from contributors to reduce copyright disputes that can arise while the project manages the works of multiple contributors. Typically, projects led by large corporations require you to sign the CLA.

The CLA varies from project to project, but it usually contains the following:

• I (or my affiliated company) have the right to contribute the contribution I want to contribute to the project. (In other words, I am the author of this contribution.)
• I (or my affiliated company) grant the project the right to modify, distribute, and manage my contribution.
• I (or my affiliated company) will not revoke the granted rights.
• I (or my affiliated company) grant the project the right to change the license as needed in the future.

Also, although rare, some CLAs require agreement on the following conditions:

• I (or my affiliated company) transfer my copyright to the project or project management organization at the same time as I contribute my contribution.

The company does not allow contributions to open source projects that require copyright transfer to protect its intellectual property. To make this judgment, company members must request a review from the OSPO before signing if the open source project they want to contribute to requires signing the CLA.

(5) Copyright Notice

The intellectual property of the works created by members during their employment is basically owned by the company. Therefore, when members contribute 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 open source project in question.

However, if you are modifying existing code for purposes such as bug fixes, you do not need to indicate copyright for the code modification.

(6) Use of Company Email

When contributing to an open source project, do not use personal email, use company email. Through this, (1) members have a sense of responsibility to communicate with the community on behalf of the company, and (2) the company can improve its recognition as a company that actively contributes to the open source community.

(7) Contribution Policy Awareness Procedure

1. Mandatory policy awareness: All program participants must be aware of the existence and content of the external open source contribution policy (§7) and internal project release policy (§8). The OSPO shall notify new participants of the contribution policy during onboarding and reconfirm it through annual training. (ISO/IEC 5230 §3.1.3)
2. Awareness confirmation and records: The OSPO shall confirm policy awareness and maintain the results as records. Awareness confirmation records shall be retained for a minimum of 3 years.

8. Open Source Release

The company respects the value of collaboration with the open source community and encourages the release of internal software to open source projects. However, there are a few rules to follow to protect the company’s intellectual property and prevent unintended copyright infringement.

(1) Approval

Open source release is granting anyone the right to modify, use, and distribute the work through an open source license from a copyright perspective. Generally, the copyright of works created during the employment period is owned by the employer. In other words, the works created by company members are owned by the company. The act of arbitrarily disclosing works to open source can trigger unnecessary copyright infringement issues.

Therefore, if you want to disclose software as open source, you must follow the review request and approval process according to the company’s open source release policy.

If there is anything that seems undesirable in the process of release, do not hesitate to contact the OSPO.

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

One of the worst situations that can occur in an open source project is the inclusion of legally problematic code in the project. Code that the company does not have the right to distribute, or code that infringes on the IP of another company, such as a patent, can cause legal problems. Therefore, while preparing to disclose the code, check the source of all code and remove any code that may be problematic.

(3) Be Careful About Intellectual Property Exposure

Do not disclose code or documents that may expose sensitive information or company intellectual property, such as patents.

If the code you want to disclose contains a company patent, you need to check whether this patent can be disclosed under an open source license. If there is any ambiguity, contact the OSPO.

(4) Disclose Useful Code

In order to be a successful project, 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 want to disclose should (1) provide differentiated value to the open source community, (2) solve problems that the community has not been able to solve, and (3) be expected to attract positive attention by disclosing our technology.

• Do not disclose code that could not be used in actual products or services as open source.
• Do not disclose code that deals with problems already solved in the open source community. In this case, contribute to the existing open source project.

(5) Resource Allocation

• Secure the resources that need to be invested in the project.
• Initially, you need developers at a level similar to general internal projects.
• You need developers who can quickly review contributions from outside.
• The roles of the legal and marketing teams are also needed.

Secure a budget for the infrastructure needed to maintain and manage the project. This includes project hosting tools like GitHub. If you cannot create an environment that supports sufficient resources, do not disclose it as open source.

(6) Use of Company Email

When conducting open source release activities, use company email instead of personal email. This has the following benefits:

• Members have a sense of responsibility to communicate with the community on behalf of the company.
• The company can improve its recognition as a company that actively discloses to the open source community.

9. Response 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 from outside.

• The Open Source Program Manager can assign all or part of the processing of inquiries to appropriate personnel within the company. If necessary, consult with a legal officer to handle it.
• Anyone who receives an open source inquiry from outside informs the Open Source Program Manager so that a quick response can be made.

(2) Public Contact Information

The Open Source Program Manager provides contact information publicly so that outsiders can make inquiries and requests related to open source.

• Provide an email address where you can be contacted in the open source notice.
• Provide email address information on the open source website.
• Register your contact information in the Open Compliance Directory of the Linux Foundation.

(3) External Inquiry Response Procedure

If you respond quickly and accurately to open source inquiries from outside, you can greatly reduce the risk of claims or legal litigation. To this end, the company complies with the external inquiry response procedure defined in the company’s open source process to respond to external open source inquiries.

(4) Record Retention

• External inquiry response records shall be retained for a minimum of 3 years from the date the inquiry is closed. (ISO/IEC 18974 §3.2.1.2)

10. Declaration and Maintenance of Compliance with ISO Standards

The company supports the spirit of the OpenChain project of the Linux Foundation for improving the level of open source compliance in the software supply chain and actively participates.

• The company guarantees compliance with ISO/IEC 5230:2020 as of October 1, 2021, by applying this open source policy.
• The company guarantees that it meets all the requirements of OpenChain Specification Version 2.1, ISO/IEC 5230:2020 for more than 18 months after obtaining conformity certification.
• The company reviews conformity at least every 18 months and changes and updates policies as needed.

Appendix 1. Status of Responsible Persons

4.2 - Open Source Process

The OO Company (hereinafter referred to as the “Company”) actively utilizes open source software in the development of products and services that include software. The Company must perform appropriate activities to detect open source security vulnerabilities and follow-up measures, and to comply with the obligations imposed by open source licenses when distributing software, in order to minimize open source risks. We follow the open source process to ensure these activities.

1. Open Source Process

The open source process defines the procedures that the Company must perform to comply with open source license obligations and resolve open source security vulnerabilities according to each development stage for developing and distributing software products and services. All members involved in the development/distribution of software products comply with the following 11 steps of the open source process.

The Company strives to provide safe and stable software products and services to customers by minimizing open source risks through the open source process.

The open source program manager should review the process at least once a year to spread internal best practices and improve areas that are lacking.

(1) Identification of Open Source

The business department complies with the following matters at the software design stage.

• Identify the foreseeable open source usage status and check the license when designing the software.
• Check the obligations of each open source license. The obligations of each license can be checked in the Company’s open source license guide: https://sktelecom.github.io/guide/use/obligation/
• Design the software considering the source code disclosure range of 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 the business departments of the entire company can refer to it. This guide should include the following use cases so that general open source license use cases can be managed.

• Distribution in binary form
• Distribution in source form
• Integration with other open sources that trigger additional license obligations
• Inclusion of modified open source

The business department marks copyright and licenses in the source code according to the company’s rules. The company’s rules for marking copyright and licenses in the source code can be checked on the following page. (insert_link)

When the business department reviews the introduction of new open source, it first identifies the license. Check the license obligations, restrictions, and rights according to the company’s open source license guide. If it is a license not explained in the company’s open source license guide, ask the open source program manager about the possibility of introduction and precautions. Create a Jira Ticket for inquiries.

The open source program manager analyzes the obligations of the open source license and guides the software development organization.

• If there is any doubt, request advice from the legal manager and provide clear guidance.
• The newly analyzed license information is reflected in the company-wide license guide.

The security manager provides a guide for the company’s security assurance.

(2) Auditing Source Code

The business department requests an open source inspection according to the guidance of the IT manager and provides the source code.

The IT manager uses an open source analysis tool to inspect the open source and create 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 is a conflict between the open source licenses, and if there is an issue, requests the business department to resolve it. Issue matters are created as Jira Tickets and assigned to the business department.

The security manager reviews the known vulnerabilities detected and provides a response guide to the business department according to the pre-defined Risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) Score, and Critical Risk is advised to establish a plan that can be dealt with within 1 week.

(3) Resolving Issues

The business department resolves all problems found in the source code inspection stage.

Remove the open source that has become an issue or replace it with open source under a different license. In the case of security vulnerability issues, measures such as replacing with a version in which known vulnerabilities have been fixed are taken.

When the business department resolves all discovered issues, it resolves the Jira Ticket issue and requests a re-review.

(4) Reviews

The open source program manager reviews whether all issues have been properly supplemented. If necessary, the source code inspection is re-performed using an open source analysis tool.

The security manager reviews whether all serious vulnerabilities have been resolved. If there are vulnerabilities that are difficult to resolve, the possibility of approval is reviewed considering the business form and service exposure status.

(5) Approval

The open source program manager finally approves or rejects whether the open source compliance procedure has been properly performed. If rejected, it proposes a reason and a correction method to the business department.

(6) Registration

The open source program manager finalizes the BOM to track the open source usage list for each version of the software.

The IT manager registers the finalized BOM in the system. The BOM includes a list of open sources included in the software for distribution and the following information.

SBOMs shall be written in SPDX or CycloneDX standard format, and format compliance shall be verified before registration.

• Product (or service) name and version of the software for distribution
• Open source list
  • Open source name / version
  • Open source license

The open source program manager finalizes the BOM to track the open source usage list for each version of the software.

(7) Notices

The open source program manager creates an open source notice to comply with the notice obligation. The open source notice includes the following contents.

• Open source contact that can be contacted for open source related inquiries
• Notice content for each open source
  • Copyright
  • Open source license name
  • Copy of open source license
  • (If applicable) Written agreement to obtain a copy of the source code

The open source program manager creates an open source notice and delivers it to the business department. At this time, if the source code needs to be disclosed, it guides the business department on how to collect the source code to be disclosed.

The business department includes the open source notice when distributing the product. If it is a product with a screen, it takes measures so that the user can check it through the menu. (Example: App > Menu > Settings > Copyright Information > Open Source License)

The business department collects the source code to be disclosed by checking the source code disclosure range when using open source under a license that requires source code disclosure such as GPL, LGPL, etc.

• The source code collected to comply with the obligations of licenses such as GPL, LGPL, etc. must match the source code that constitutes the binary loaded on the product. In other words, the collected source code should be the same as the binary loaded on the product when built.

(8) Pre-Distribution Verifications

The business department submits the following deliverables to demonstrate that open source compliance activities have been appropriately performed:

1. The final open source notice included in the product
2. Materials confirming the inclusion of the open source notice in the product (e.g., a screenshot showing the open source notice)
3. (If applicable) Source code to be disclosed (submitted as a single compressed file)

The open source program manager reviews the materials submitted by the business department to check for any issues.

(9) Distribution

The open source program manager submits the compliance deliverables provided by the business department to the IT manager.

The IT manager registers the compliance deliverables on the company’s open source distribution site.

If customers request it, the IT manager shall prepare to provide the SBOM for the relevant supplied software to the customer.

(10) Final Verifications

The open source program manager comprehensively verifies whether the compliance deliverables have been properly registered on the company’s open source portal and whether they can be downloaded without issues from outside.

(11) Monitoring

The open source program manager periodically checks for products with inadequate generation of open source compliance deliverables. They also operate a process to respond quickly to external inquiries. The detailed procedure for responding to external inquiries follows [2. External Inquiry Response Process].

If an open source component is added, changed, or removed; a new vulnerability is discovered; or a license change is confirmed, the SBOM for the relevant supplied software shall be updated immediately.

The security manager operates a process to monitor and respond to newly known vulnerabilities. The detailed procedure for responding to new security vulnerabilities follows [3. New Security Vulnerability Management Process].

2. New Security Vulnerability Management Process

We adhere to the following process to take appropriate action according to the risk when a new security vulnerability is reported after a product/service has been launched in the market.

(1) Monitoring

The IT manager operates a system to monitor new security vulnerabilities. This system performs the following functions:

• It periodically collects information about newly disclosed security vulnerabilities.
• If an open source with a newly known vulnerability is used in a product/service that has already been released, it sends a notification to the business department manager responsible for that product/service. From the notification to the review, action, and resolution, everything is documented using the Jira Issue Tracker.

(2) Initial Response

The security manager provides a response guide to the business department according to the predefined risk classification criteria. The risk is classified by the CVSS (Common Vulnerability Scoring System) score, and a plan that can be implemented within one week is recommended for Critical Risk.

If a product/service that has already been released has a new security vulnerability, the business department establishes an action plan according to the response guide provided by the security manager.

If there are customers who need assurance, the business department notifies them of the confirmed known vulnerabilities by email or other means as necessary, depending on the risk.

(3) Problem Resolution

The business department resolves the security vulnerability issue by deleting the problematic open source or replacing it with a patched version, according to the established action plan. Once all issues are resolved, a review is requested.

(4) Review

The IT manager uses open source analysis tools to confirm whether the problem has been appropriately resolved.

(5) Approval

The security manager reviews whether all serious vulnerabilities have been resolved. If there are vulnerabilities that are difficult to resolve, the approval is reviewed considering the business form and service exposure status.

(6) Registration

The IT manager registers the SBOM, which has resolved the open source security vulnerability, in the system.

Vulnerability response records shall be retained for a minimum of 3 years from the date of the last distribution of the relevant supplied software. (ISO/IEC 18974 §3.3.2.2)

(7) Notification

The open source program manager generates an open source notice based on the SBOM that has resolved the open source security vulnerability and delivers it to the business department.

The business department replaces the open source notice included in the product distribution.

The IT manager registers the modified open source notice on the company’s open source distribution site.

(8) Distribution

The business department redistributes the software version that has resolved the open source security vulnerability issue.

The security manager identifies whether there is risk information that needs to be disclosed to third parties, and if there is, it is delivered to the IT manager.

The IT manager registers the identified risk information on the open source website so that third parties can check it.

(9) Vulnerability Disclosure Timing Procedure (CVD)

For newly discovered vulnerabilities (discovered internally or reported by external researchers), the Coordinated Vulnerability Disclosure (CVD) procedure is followed:

1. Pre-disclosure coordination:
   • Immediately notify the maintainers of the affected open source project privately upon discovery.
   • As a principle, disclose within 90 days of the initial notification to allow sufficient time for patch development and deployment.
   • The disclosure schedule may be adjusted through negotiation with maintainers, and the agreed schedule shall be documented.
2. Immediate disclosure exceptions:
   • If the vulnerability is already publicly known and being exploited, or if there is an immediate threat, it may be disclosed immediately without a coordination period.
   • Immediate disclosure decisions shall be jointly approved by the security manager and the open source program manager.
3. Disclosure content and channels:
   • Apply for CVE ID issuance (MITRE or CNA) in parallel with disclosure.
   • Vulnerability details, scope of impact, and patch or mitigation methods shall be posted on the company’s security advisory page and relevant public databases (e.g., NVD).

3. External Inquiry Response Process

If you respond quickly and accurately to open source compliance inquiries from outside, you can greatly reduce the risk of proceeding to litigation. To this end, companies comply with the following process to respond to external open source compliance inquiries.

(1) Acknowledge

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 notified. If the inquiry is unclear, additional explanation is requested to accurately understand the requester’s intention.

The main contents of the inquiries and requests that require a response are as follows:

• Inquiry about whether open source has been used in a specific product or service
• Request for source code provision under the GPL, LGPL license mentioned in the written agreement
• Explanation and source code disclosure request for open source found in the product but not specified in the open source notice
• Request for provision of missing files and build methods in the source code disclosed due to obligations such as GPL, LGPL
• Request for copyright notice
• Inquiry about known or newly discovered vulnerabilities

The open source program manager creates a Jira Issue for the received request and records all the response situations in detail.

(2) Inform

The open source program manager informs the requester that they are conducting open source compliance faithfully and that they are investigating the requester’s inquiry. It is good to notify whenever the internal investigation progress is updated.

(3) Investigate

The open source program manager conducts an internal investigation on the request. They check whether the compliance process has been appropriately performed for the version of the product in question through the BOM and documented review history. If necessary, they request advice from the legal manager.

If it is a matter that needs to be confirmed by a specific business department, the open source program manager requests an investigation from the business department. The business department that received the investigation request immediately checks whether there is a problem with the compliance deliverables and reports the results to the open source program manager.

(4) Report

The open source compliance manager completes the internal investigation within the scheduled date of action and notifies the requester of the result.

• If the requester’s inquiry was a misdirected point due to misunderstanding, they notify the requester and end the process without any additional action.
• If there is a problem, they notify the requester of the exact method and timing to fulfill the obligations of the relevant open source license.

(5) Rectify / Notify

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

(6) Report

After resolving the issue, they immediately notify the requester and provide the best way to confirm that the issue has been resolved.

(7) Improve

In case of a compliance issue, the case is reviewed through the OSRB meeting, the circumstances of the occurrence of the problem are identified, and the process is improved so that the problem does not recur.

(8) Record Retention

The open source program manager records the entire external inquiry response process (receipt, investigation, response, resolution) in the issue tracking system. These records shall be retained for a minimum of 3 years from the date the inquiry is closed. (ISO/IEC 18974 §3.2.1.2)

Records shall include the following:

• Date and time of inquiry receipt and requester information
• Inquiry content and classification (license compliance / security vulnerability)
• Internal investigation results and response actions taken
• Final resolution and completion date

4. Open Source Contribution Process

When program participants contribute to external open source projects, they must follow the procedures below to protect the company’s intellectual property and ensure license compatibility. For detailed policy, refer to Open Source Policy §7.

(1) Intent Confirmation and Pre-Review Request

Program participants must request a contribution review from the OSPO before contributing to an external open source project.

Information to include in the request:

• Name and repository URL of the target project
• Summary of the contribution (bug fix, feature addition, etc.)
• Source of the contributed code (self-authored or company-owned)
• Whether any company patents are included

(2) OSPO Review and Approval

The OSPO reviews the contribution request and verifies the following:

1. License compatibility: Confirm whether the license of the contributed code is compatible with the target project’s license.
2. Intellectual property review: Confirm that the contributed code does not contain company patents or sensitive information. Request legal team advice if necessary.
3. CLA review: If the target project requires signing a CLA (Contributor License Agreement), review the terms and confirm there are no copyright assignment clauses.

After completing the review, the OSPO notifies the requester of the approval or rejection decision.

(3) Performing the Contribution

For approved contributions, program participants must comply with the following when contributing:

• Include the company copyright notice and SPDX license identifier at the top of each file.
• Use the company email when contributing.
• Contribute only code authored by the participant or code for which the company holds the rights.

(4) Contribution History Recording and Retention

The OSPO records all approved contributions in the internal system.

Record items:

• Target project and date of contribution
• Summary of contribution
• Approver and approval date
• Whether CLA was signed

Contribution records shall be retained for a minimum of 3 years.

5. Internal Project Release Process

When releasing internally developed projects as open source, the following procedures must be followed to protect the company’s intellectual property and ensure appropriate license selection. For detailed policy, refer to Open Source Policy §8.

(1) Release Review Request

The department wishing to release must request a release review from the OSPO.

Information to include in the request:

• Project overview and purpose of release
• Scope of release (code, documentation, etc.)
• Whether any patents are included
• List of dependent third-party libraries

(2) OSPO Review and Approval

The OSPO reviews the following:

1. Intellectual property review: Confirm that the release code does not contain company patents, trade secrets, or sensitive information. Request legal team advice if necessary.
2. License selection: Select an appropriate open source license considering the purpose of release (community building, standards contribution, etc.) and intellectual property protection.
3. Dependency license compatibility: Confirm that the licenses of included third-party components are compatible with the selected release license.

(3) Release Preparation

After approval, the responsible department performs the following:

• Remove sensitive information (API keys, internal server addresses, etc.) from the code.
• Include copyright notice and SPDX license identifier at the top of each file.
• Write README, contribution guide (CONTRIBUTING.md), and license file (LICENSE).
• Register the project on a public repository such as GitHub.

(4) Post-Release Management

The OSPO and responsible department perform the following for continuous maintenance of the released project:

• Periodically review and respond to external contributions (Pull Requests, Issues).
• When security vulnerabilities are reported, respond according to the §2 Security Vulnerability Management Process.
• Periodically review the project status (active/maintenance/archived) and state it clearly in the README.

(5) Release Record Retention

The OSPO retains release approval records and related review records for a minimum of 3 years.

Retention items:

• Request and approval date/time, approver
• Selected license and rationale for selection
• Intellectual property review results
• Public repository URL

6. Training and Evaluation Process

To ensure that open source program participants sufficiently understand the policies and processes and maintain their competencies, training and competency evaluation are conducted according to the following procedures. For detailed policy, refer to Open Source Policy §6.

(1) Determining Training Targets and Schedule

The open source program manager confirms training targets and establishes a training plan at least once a year.

• New participants: Complete mandatory training during onboarding.
• Existing participants: Complete regular training at least once a year.
• Role changes: Complete additional training suited to the new role.

(2) Conducting Training

The open source program manager provides training in the following ways:

1. Online training: Complete mandatory courses on the Learning Portal; course completion is automatically recorded in the system.
2. Offline training: Hold workshops or seminars when needed, recording the list of attendees and training materials.

Training content must include the following topics:

• Purpose and principles of the open source policy
• License obligations and compliance procedures
• SBOM creation and utilization
• Vulnerability management procedures
• External open source contribution policy and internal project release procedures

(3) Competency Evaluation

After completing training, the open source program manager evaluates participants’ competencies.

• Evaluation is conducted through online tests or practical assignments.
• Evaluation criteria (passing scores, etc.) are defined in advance when establishing the training plan.
• Participants who do not pass are given supplemental training opportunities and re-evaluated.

(4) Recording and Retaining Evaluation Results

The open source program manager records training completion and evaluation results.

Record items:

• Trainee name, role, and completion date
• Evaluation results (score or pass/fail)
• Supplemental training history (if applicable)

Records shall be registered in the internal document management system or Learning Portal and retained for a minimum of 3 years. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)

(5) Training Content Review and Improvement

The open source program manager reviews training content and evaluation methods at least once a year and updates them to reflect the following:

• Changes in open source-related laws and regulations
• New vulnerability trends and case studies
• Changes in internal policies and processes

5 - Tools

5.1 - FOSSology

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

Linux Foundation의 FOSSology 프로젝트는 이러한 스캔 도구를 개발하고 오픈소스로 공개해 누구나 자유롭게 사용할 수 있게 한 도구이다.

주요 특징

FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

설치

기업 내에서 FOSSology를 사용하기 위해서는 사내에 FOSSology 서버를 구축해야 한다. 이를 위해 리눅스 기반의 서버 시스템에 FOSSology를 설치해야 한다. FOSSology는 다음 세 가지 방법으로 설치할 수 있다.

1. Docker 사용
2. Vagrant와 VirtualBox 사용
3. Source build하여 설치

여기서는 가장 간편한 방법인 Docker를 사용하는 방법에 대해 설명한다.

FOSSology는 컨테이너화 된 Docker 이미지를 Docker Hub (https://hub.docker.com/)를 통해 공개하고 있다. : https://hub.docker.com/r/fossology/fossology

Pre-built 된 Docker 이미지는 다음 명령어를 사용하여 실행할 수 있다.

$ docker run -p 8081:80 fossology/fossology

Docker 이미지는 다음 URL과 계정 정보로 사용할 수 있다. : http://[IP_OF_DOCKER_HOST]:8081/repo

• Username : fossy
• Passwd : fossy

설치와 관련한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://github.com/fossology/fossology/blob/master/README.md

테스트 서버

FOSSology를 설치할 수 있는 시스템 구축이 곤란한 상황이라면, FOSSology Project에서 제공하는 테스트 서버를 이용할 수 있다. FOSSology 프로젝트에서는 테스트를 위한 환경을 제공한다. (테스트 서버는 예고없이 중단될 수 있다.)

사용자는 다음 계정으로 FOSSology 테스트 서버에 접속하여 FOSSology 기능을 시험해볼 수 있다.

Basic Workflow

FOSSology의 기본 사용 절차는 다음과 같다.

• 사용하고자 하는 오픈소스의 라이선스와 Copyright 정보를 확인하기 위해 오픈소스의 소스 코드를 하나의 파일로 압축하여 FOSSology에 업로드한다.
• 이를 위해 메뉴 > Upload > From File을 선택합니다.

• 업로드할 파일을 선택하고 Upload 버튼을 클릭한다.
• 업로드가 완료되면 Job Agent에 의해 자동으로 분석을 수행한다.
• 메뉴 > Jobs > My Recent Jobs에서 분석 중인 Status를 확인할 수 있다.

• 분석이 완료되면 메뉴 > Browse에서 분석 결과를 확인할 수 있다.

• 개별 파일을 선택하면 FOSSology가 검출한 라이선스 관련 텍스트가 무엇인지 확인할 수 있다.

• 메뉴 > Browser > 파일 혹은 디렉터리를 선택 > Copyright/Email/Url/Author에서는 FOSSology가 검출한 Copyright/Email/Url/Author 정보를 보여다.

사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목에 대해서는 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/get-started/basic-workflow/

위와 같은 방법으로 사용하고자 하는 오픈소스의 라이선스는 무엇인지, Copyright 정보는 어떻게 되는지를 간단히 확인할 수 있다.

5.2 - SW360

(Updated on August 29, 2023.)

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

이렇듯, 오픈소스 정보를 추적하는 활동은 꼭 필요하다. 기업들은 이를 위해 자체 시스템을 구축하거나, 상용 서비스를 구매하여 사용하기도 한다. SW360은 Eclipse 재단에서 후원하는 오픈소스로서 소프트웨어 BOM에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

• 제품에 사용된 컴포넌트 추적
• 보안 취약점 평가
• 라이선스 의무 관리
• 고지문 등 법적 문서 생성

설치

SW360은 다음과 같이 구성된다.

• Frontend : Liferay-(Tomcat-)based portal application
• Backend : Tomcat-based thrift service
• Database : CouchDB

Project 구조와 설치를 위해 요구되는 소프트웨어 등 자세한 내용은 README의 Required software 부분에서 확인할 수 있다. : https://github.com/eclipse-sw360/sw360

SW360은 다음 두 가지의 설치 방법을 제공한다. 사용자는 이 중 하나를 선택하여 설치할 수 있다.

1. Docker를 통해 Deploy 할 수 있다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md
2. SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
3. Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
   • Vagrant 기반 설치 가이드는 여기에서 확인할 수 있다. (단, 가이드 작성 시점과 현재 코드가 상이하여 정상동작하지 않을 가능성이 있습니다.)

이 가이드에서는 Docker로 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md

1. 코드 다운로드

Docker Image 빌드를 위해 코드를 다운로드 한다. 테스트가 완료된 코드는 여기서 받을 수 있다. : https://github.com/haksungjang/sw360/tree/docker_build

git clone -b docker_build https://github.com/haksungjang/sw360.git

2. 빌드

먼저 Docker를 설치한다. (기업 개발자가 사용하려면 유료 구매가 필요할 수 있음에 주의하세요.)

아래와 같이 docker_build.sh를 실행하여 빌드한다.

cd sw360
./docker_build.sh

정상적으로 빌드가 완료되면 아래와 같이 생성된 이미지를 확인할 수 있다.

docker image ls

REPOSITORY                       TAG              IMAGE ID       CREATED          SIZE
eclipse-sw360/sw360              18-development   ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/sw360              latest           ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      18-development   ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      latest           ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/binaries           18-development   aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/binaries           latest           aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   18-development   aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   latest           aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/base               18-development   e5147733fc88   37 minutes ago   1.52GB
eclipse-sw360/base               latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       18-development   e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/thrift     0.18.1           0012d7998058   4 weeks ago      152MB
ghcr.io/eclipse-sw360/thrift     latest           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             0.18.1           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             latest           0012d7998058   4 weeks ago      152MB

3. 실행

docker-compose up 명령으로 생성된 이미지를 실행한다.

docker-compose up

정상적으로 실행이 완료되면 아래와 같이 세개의 container가 실행된 것을 볼 수 있다.

docker ps 

CONTAINER ID   IMAGE                 COMMAND                  CREATED         STATUS                   PORTS                                              NAMES
4299fd39010c   eclipse-sw360/sw360   "/app/entry_point.sh"    3 minutes ago   Up 3 minutes             0.0.0.0:8080->8080/tcp, 0.0.0.0:11311->11311/tcp   sw360
13fd5696b140   postgres:14           "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes (healthy)   0.0.0.0:5438->5432/tcp                             sw360-postgresdb-1
7bb70f2daaf4   couchdb               "tini -- /docker-ent…"   3 minutes ago   Up 3 minutes (healthy)   4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp         sw360-couchdb-1

이 상태에서 http://localhost:8080/로 접근하면 다음과 같은 화면에 진입한다.

설정

SW360을 정상적으로 설치한 후에는 아래의 절차대로 초기 설정이 필요하다. 자세한 내용은 여기에서 확인할 수 있다. : SW360 Initial Setup Configuration

1. User, Login 설정

설정을 위해 다음 계정으로 로그인한다.

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

로그인을 하면 아래와 같이 Not Found라는 표시가 나타나게 된다.

화면 우상단의 아이템 아이콘(큐브 모양)을 클릭하고 Control Panel 탭을 선택한다.

SECURITY > Password Policies > Default Password Policy > PASSWORD CHANGES > Change Requried를 활성화한다.

그리고, 다시 Control Panel탭에서 CONFIGURATION > Instance Settings을 선택한다. 그러면, PLATFORM메뉴를 볼 수 있다.

거기서 Users를 선택한다. 그리고, Default User Associations 메뉴로 진입하고, Apply to Existing Users를 체크한다. 그리고 Save한다.

이번에는 Instance Settings > PLATFORM에서 User Authentication를 선택한다. General로 진입하여 모든 항목을 Uncheck한다. (관리 목적상 필요한 항목은 Check하여 활성화할 수 있다.) 그리고 Save한다.

끝으로, jquery와 font awesome을 활성화시켜야 한다. 이를 위해 Control Panel 탭에서 CONFIGURATION > System Settings으로 진입하면 PLATFORM 하위에 Third Party를 볼 수 있다.

Third Party에 진입하여 JQuery와 Font Awesome을 각각 Enable시킨다.

브라우저를 새로 실행하면 변경 사항이 적용된다.

2. LAR 파일 import

SW360 설정을 위해서는 *.lar 파일들을 import해야 한다. 이를 설정하기 위해서는 메뉴로 진입해야 하는데, 메뉴 버튼은 화면 좌측 상단에 있다.

메뉴에서 Publishing > Import에 진입한다.

우측의 + 버튼을 눌러 LAR 파일을 업로드 할 수 있는데, LAR 파일은 SW360 소스 파일 내 frontend/configuration 폴더 하위에 있다. (예: https://github.com/haksungjang/sw360/tree/docker_build/frontend/configuration)

먼저, Public_Pages_7_4_3_18_GA18.lar 파일을 업로드하고 Continue 버튼을 누른다.

File Summary 화면에서 업로드된 LAR 파일 세부 내용을 볼 수 있다.

제일 아래의 AUTHORSHIP OF THE CONTENT를 Use the Current User as Author로 변경하고 Import 버튼을 누른다.

그러면 Import가 성공적으로 완료된 걸 볼 수 있다.

이와 유사하게 Private_Pages_7_4_3_18_GA18.lar 파일을 Import한다. File Summary 화면에서 아래와 같이 PAGES > Private Pages로 변경한다.

그리고, PERMISSIONS, UPDATE DATA, AUTHORSHIP OF THE CONTENT 항목을 각각 아래 이미지와 같이 선택하고, Import버튼을 눌러 Import를 수행한다.

여기까지 수행을 마친 후 메뉴 상단의 Home 버튼을 누른다.

그럼 아래와 같이 Welcome to SW360! 화면에 진입한다.

Start 버튼을 눌러 SW360 첫 화면에 진입할 수 있다. (모든 항목이 비어있다.)

3. User Account 설정 (테스트용)

SW360 메뉴에서 Admin > User를 선택한다.

화면 하단의 UPLOAD USERS 메뉴에서 테스트를 위한 User 리스트를 업로드 한다. (테스트를 위한 User 리스트는 여기에서 다운 받을 수 있다. : test_users_with_passwords_12345.csv )

그러면 다음과 같이 9개의 User 리스트가 업로드 된 것을 볼 수 있다.

여기서 보이는 User 리스트 중 하나인 user@@sw360.org 계정으로 다시 로그인을 시도한다. Password는 12345이다.

Basic Workflow

1. License 등록

SW360을 처음 설치하면 먼저 자주 사용하는 오픈소스 라이선스 들을 등록해야 한다. 라이선스 다음과 같은 정보를 포함한다.

• Full Name
• Short Name
• License Type
• GPL-2.0 Compatibility (예: yes, no)
• License Text

메뉴 > Licenses > Add License를 선택하면 다음과 같이 Create License 화면으로 진입한다.

이와 같이 라이선스를 하나씩 수동으로 등록하는 일은 상당히 수고스러울 수 있는데, 다행히 SW360은 SPDX License List를 한 번에 Import 하는 기능을 제공한다. 메뉴 > Admin < Import SPDX Information을 클릭한다.

그러면, 곧 SPDX License List가 자동으로 등록됩니다. 메뉴 > Licenses에서 338개의 License가 등록된 것을 확인할 수 있다.

2. Component 및 Release 등록

SW360에서 Component는 하나의 소프트웨어 단위이다. 여기에는 다양한 형태의 소프트웨어가 해당할 수 있으며, 그 예는 다음과 같다.

• 오픈소스 소프트웨어
• 라이브러리
• 3rd party 소프트웨어

Component는 다음과 같은 정보를 포함한다.

• Component Name
• Main Licenses
• Categories (예: Library, Cloud, Mobile, …)
• Component Type (예: OSS, Internal, InnerSource, Service, Freeware)
• Default Vendor
• Homepage URL

Release는 Component에서 하나의 Version을 가리키는 단위이다. 따라서 하나의 Component는 여러 개의 Release를 가질 수 있다. Release는 하나의 Component 하위에 생성되어 관리된다.

Release는 다음과 같은 정보들을 포함한다.

• Component Name
• Version
• License
• Download URL
• CPE ID (예: cpe:2.3:a:apache:maven:3.0.4)

예를 들어, zlib-1.2.8을 등록해야 한다면, 먼저 Component에 zlib을 먼저 등록한 후, Release에 zlib 1.2.8을 등록한다. Menu > Components > Add Component를 선택하면 Create Component 화면으로 진입하여 zlib에 대한 정보를 등록할 수 있다.

Component를 생성하면, Components > Releases > Add Release에서 zlib-1.2.8 version에 대한 정보를 등록할 수 있다.

하나의 zlib이라는 Component에 1.2.8과 1.2.11 version을 각각의 Release로 등록하였을 때, Release Overview 화면에서 다음과 같이 2개의 Release가 존재하는 것을 볼 수 있다.

SW360은 다수의 Component 정보를 Import 시키기 위한 기능을 제공한다. 메뉴 > Admin > Import / Export에 CSV template에 등록을 원하는 Component 정보를 입력 후 Import 할 수 있다.

단, 이 기능은 2020년 2월 기준 아직 안정적으로 동작하지 않을 수 있다.

3. Project 생성

Project는 하나의 제품을 가리킨다. 사업 유형에 따라 제품일수도 있고, 서비스 혹은 소프트웨어 일수도 있다. Project에는 제품에 사용된 Component/Release를 등록하여 관리한다.

Project 생성 시에는 다음과 같은 정보를 등록한다.

• Project Name
• Version
• Project type (예: Product, Customer Project, Service, Internal Project, InnerSource)

메뉴 > Projects > Add Project를 통해 Project를 생성할 수 있다.

Project를 생성하고 나면, 포함하는 Release나 하위 Project를 등록한다. 메뉴 > Projects에서 해당 Project를 선택하면 “Linked Releases and Projects”에서 Linked Projects와 Linked Releases를 등록할 수 있다.

다음은 SuperCalc라는 Project에 OpenSSL 1.0.1과 zlib 1.2.8을 Linked Releases로 등록한 이후의 화면이다.

4. 보안 취약점 관리

SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 확인할 수 있다. 이를 위해 SW360은 CVE 정보를 주기적으로 수집하도록 스케쥴링하는 기능을 제공한다. 메뉴 > Admin > Schedule 에서 CVE SEARCH 정보를 24시간마다 수집하도록 스케쥴링을 설정할 수 있다.

이렇게 스케쥴링을 설정하면 SW360은 정해진 시간에 CVE Search 사이트(https://cve.circl.lu/)에서 CVE 정보를 수집한다. 수집한 CVE 정보는 메뉴 > Vulnerabilities에서 확인할 수 있다.

이렇게 Vulnerabilities 정보가 수집된 이후에는 생성한 Project에 보안 취약점이 있는지 조회할 수 있다. 위에서 생성한 SuperCalc Project에서는 85개의 보안 취약점이 보고된 것을 확인할 수 있다.

이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화할 수 있는 형태로 관리가 가능하다.

또한 SW360은 위와 같은 Web Interface 뿐만 아니라 대부분의 기능을 REST API로 제공하여서 FOSSology 등의 다른 도구와의 연동이 가능하다. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

즉, 소스 코드 스캐닝 도구의 분석 결과를 SW360에 Import 시키는 등의 방법으로 DevOps에 Integration 시켜서 Project, Release 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.

5.3 - FOSSLight

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

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

1. Features

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

2. Installation

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

Prerequisites: Docker and Docker Compose must be installed on your system.

# Clone the FOSSLight Hub repository
git clone https://github.com/fosslight/fosslight_hub.git
cd fosslight_hub

The repository includes a docker-compose.yml file. Run the following command to start FOSSLight:

docker-compose up -d

This starts FOSSLight Hub, FOSSLight Scanner, and the MariaDB database as Docker containers.

Access http://localhost:8080 in your browser to verify the installation.

3. Basic Usage

FOSSLight Hub

1. Navigate to http://localhost:8080 and log in.
2. Create a new project under Projects → New Project.
3. Upload scan results from FOSSLight Scanner.
4. Review SBOM information, license details, and vulnerability data in the web UI.
5. Generate reports in SPDX, CycloneDX, Excel, or Text format.

FOSSLight Scanner (CLI)

# Scan a project directory and output results as JSON
docker run --rm \
  -v $(pwd)/upload:/home/fosslight_scanner/upload \
  -v $(pwd)/result:/home/fosslight_scanner/result \
  fosslight/fosslight_scanner \
  -p /home/fosslight_scanner/upload/my_project \
  -o /home/fosslight_scanner/result/my_sbom.json \
  -f fosslight_json

Scan results are saved to the result directory and can be uploaded to FOSSLight Hub.

4. References

• FOSSLight Official Website: https://fosslight.org/
• FOSSLight GitHub: https://github.com/fosslight/fosslight_hub
• SPDX: https://spdx.dev/
• CycloneDX: https://cyclonedx.org/

5.4 - OSV-SCALIBR

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

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

1. Features

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

2. Installation

Build with Go 1.21 or later:

git clone https://github.com/google/osv-scalibr.git
cd osv-scalibr
go build -o scalibr ./binary/cli/...

Alternatively, download pre-built binaries from the Releases page.

3. Basic Usage

(1) Filesystem Scan

# Scan a directory and output vulnerability results
./scalibr scan --result=result.json /path/to/project

# Generate SBOM in SPDX format
./scalibr scan --output=sbom.spdx.json /path/to/project

(2) Container Image Scan

./scalibr scan --image=ubuntu:22.04 --result=result.json

(3) Reviewing Results

# Query vulnerability list from JSON result file
cat result.json | jq '.findings[].adv.id'

4. CI/CD Integration

OSV-SCALIBR is well-suited for integration into CI/CD pipelines to automatically detect vulnerabilities during build and deployment stages.

# GitHub Actions example
- name: Run OSV-SCALIBR
  run: |
    ./scalibr scan --result=result.json .
    # Fail build if vulnerabilities are found
    jq -e '.findings | length == 0' result.json

5. References

• OSV-SCALIBR GitHub: https://github.com/google/osv-scalibr
• OSV Database: https://osv.dev/
• SPDX: https://spdx.dev/

5.5 - cdxgen

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

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

Features

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

Installation

Install with Node.js 18 or later:

npm install -g @cyclonedx/cdxgen

Or use the Docker image:

docker pull ghcr.io/cyclonedx/cdxgen

Basic Usage

(1) Scan a Source Code Directory

# Scan current directory and generate CycloneDX JSON SBOM
cdxgen -o sbom.json .

# Specify language if auto-detection fails
cdxgen -t java -o sbom.json /path/to/project

(2) Scan a Container Image

cdxgen -t docker -o sbom.json ubuntu:22.04

(3) Scan a GitHub Repository

cdxgen -t github -o sbom.json https://github.com/org/repo

(4) Explore SBOM in REPL Mode

cdxgen --repl -o sbom.json .

CI/CD Integration Example

# GitHub Actions example
- name: Generate SBOM with cdxgen
  run: |
    npm install -g @cyclonedx/cdxgen
    cdxgen -o sbom.json .
- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.json

References

• cdxgen GitHub: https://github.com/CycloneDX/cdxgen
• CycloneDX Standard: https://cyclonedx.org/
• OWASP CycloneDX: https://owasp.org/www-project-cyclonedx/

5.6 - Syft

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

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

Features

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

Installation

Script Installation (Linux/macOS)

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

Homebrew (macOS)

brew install syft

Docker

docker pull anchore/syft

Basic Usage

(1) Scan a Container Image

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

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

(2) Scan a Local Directory

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

(3) View Results in Terminal

# Print package list to terminal
syft ubuntu:22.04

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

(4) Vulnerability Scanning with Grype

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

CI/CD Integration Example

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

References

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

5.7 - Dependency-Track

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

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

Features

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

Installation

Using Docker Compose is the simplest approach:

# Download official Docker Compose file
curl -LO https://dependencytrack.org/docker-compose.yml

# Start services
docker compose up -d

By default, the API server runs on port 8081 and the frontend on port 8080. Default admin credentials: admin / admin (change immediately after first login)

Basic Usage

(1) Create a Project and Upload SBOM via Web UI

1. Navigate to http://localhost:8080
2. Click Projects → Create Project
3. Enter project name and version, then save
4. Open the project → Components tab → Upload BOM
5. Upload your SBOM file (.cdx.json or .spdx.json)

After upload, Dependency-Track automatically starts vulnerability analysis.

(2) Upload SBOM via API (CI/CD Integration)

# API Key: Administration > Access Management > Teams
API_KEY="your-api-key"
PROJECT_UUID="your-project-uuid"

curl -X PUT \
  "http://localhost:8081/api/v1/bom" \
  -H "X-Api-Key: ${API_KEY}" \
  -H "Content-Type: multipart/form-data" \
  -F "project=${PROJECT_UUID}" \
  -F "bom=@sbom.cdx.json"

(3) GitHub Actions Integration Example

- name: Upload SBOM to Dependency-Track
  uses: DependencyTrack/gh-upload-sbom@v3
  with:
    serverhostname: dependency-track.example.com
    apikey: ${{ secrets.DT_API_KEY }}
    project: ${{ secrets.DT_PROJECT_UUID }}
    bomfilename: sbom.cdx.json

Using with cdxgen / Syft

Dependency-Track is most effective when used with SBOM generation tools like cdxgen and Syft:

cdxgen or Syft  →  Generate SBOM  →  Upload to Dependency-Track  →  Continuous monitoring

• SBOM generation: Use cdxgen or Syft to generate SBOMs at build time
• Centralized management: Upload to Dependency-Track to manage vulnerability status across all projects

References

• Dependency-Track Official Docs: https://docs.dependencytrack.org/
• Dependency-Track GitHub: https://github.com/DependencyTrack/dependency-track
• CycloneDX Standard: https://cyclonedx.org/

6 - Archive

This section contains older guide documents that are no longer actively maintained.

6.1 - NIPA OpenChain Guide

OpenUP conducted research under the supervision of the National Information and Communication Industry Promotion Agency (NIPA) and produced a guidebook explaining detailed methods for companies to comply with the OpenChain Specification. : OpenChain 2.0 Guide for Open Source Governance in the Enterprise

With the permission of NIPA, the contents of the guide are published on GitHub, and anyone can refer to the contents, modify / improve the contents.

References

Language

This page contains only Korean language materials for Korean companies.

6.1.1 - I. OpenChain Project란?

오늘날 소프트웨어는 갈수록 그 규모와 복잡도가 커지고 있다. 하나의 소프트웨어를 개발하기 위해서는 자체 개발하는 소프트웨어뿐 아니라 오픈소스, 3rd party Software, 반도체 벤더의 SDK 등 소프트웨어 공급망에 걸친 다양한 소프트웨어가 사용될 수 있기 때문이다.

이러한 복잡한 소프트웨어 공급망의 조직 중 한 곳이라도 라이선스 의무를 준수하지 않거나, 올바른 오픈소스 정보를 제공하지 못한 경우, 최종 소프트웨어를 배포하는 기업은 라이선스 준수에 실패하고 이로 인해 제품 판매가 중단되는 상황이 발생할 수 있다. 실제로 2009년 12월, Busybox라는 오픈소스 관련된 소송이 있었다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 두 곳의 국내 회사를 포함하여 총 14개 회사가 소송 대상이 되었다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당했다는 점이다.

이와 같은 복잡한 소프트웨어 공급망 환경에서는 어느 한 기업이 아무리 훌륭한 프로세스를 갖추고 있다고 해도 자체적으로 완벽한 오픈소스 컴플라이언스를 달성하는 건 매우 어렵다. 결국 소프트웨어를 최종 배포하는 기업이 오픈소스 컴플라이언스를 제대로 이행하기 위해서는 소프트웨어 공급망의 모든 구성원이 라이선스 의무를 준수하고 올바른 오픈소스 정보를 제공하여 공급망 전체에 신뢰가 구축되어야 한다.

Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 활동을 더 간단하고 일관성 있게 만들어 소프트웨어 공급망 전체에 신뢰를 구축할 수 있도록 해준다.

2016년 유럽의 한 오픈소스 콘퍼런스에서 퀄컴의 오픈소스 변호사인 데이브 머(Dave Marr)는 한 기업의 오픈소스 컴플라이언스 수준을 높이기 위해서는 소프트웨어 공급망 내의 모든 구성원이 오픈소스 컴플라이언스 수준을 높이는 것이 중요함을 강조한 바 있다. 아울러 이를 위해서는 오픈소스를 충분히 이해하고, 정책 및 프로세스를 앞서 구축하고 있는 기업들이 자신들의 자산과 노하우를 공개해 누구나 이를 참고할 수 있게 해야 한다는 의견을 제시했다. 콘퍼런스 참석자들은“오픈소스 컴플라이언스는 기업의 이익을 차별화할 수 있는 분야가 아니다. 기업은 최소한의 리소스를 투입하여 적정한 수준의 리스크 관리를 원하기 때문에 기업들이 가진 자산을 공유하면 할수록 적은 비용으로 모두 함께 컴플라이언스를 달성 할 수 있다”는 아이디어에 공감했다. OpenChain 프로젝트(당시에는 Work Group)는 그렇게 시작됐고, Qualcomm, Siemens, Wind River, ARM, Adobe 등 다수 글로벌 기업들이 참여했다.

6.1.1.1 - 1. OpenChain Specification

OpenChain 프로젝트는 곧 OpenChain Specification 1.0을 제작하여 배포했다. OpenChain Specification은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 표준 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2019년 4월에는 버전 2.0의 Specification이 배포됐으며, 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요건에 대한 설명과 이를 수행하고 있음을 입증하기 위한 검증 자료 목록을 정의하고 있다.

1. 오픈소스 컴플라이언스를 관리하기 위한 프로그램
2. 효과적인 리소스 제공을 위한 업무 정의 및 지원
3. 오픈소스 검토 및 승인을 관리하는 프로세스
4. 컴플라이언스 결과물 생성 및 제공을 위한 프로세스
5. 오픈소스 커뮤니티 참여를 이해하고 관리하기 위한 정책
6. OpenChain Specification 요건 준수

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이와 같은 OpenChain Specification의 요건을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.

6.1.1.2 - 2. OpenChain Conformance

OpenChain Project는 기업이 OpenChain Specification을 충족하는지 자체적으로 확인할 수 있도록 온라인 자체 인증 웹사이트를 제공한다.

기업의 오픈소스 담당자는 OpenChain 자체 인증 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있으며, Yes/No 질문에 답변하는 방식으로 진행된다.

자체 인증을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있다.

만약, 오픈소스 컴플라이언스 체계가 잘 구축된 기업이 OpenChain 자체 인증 질문지의 모든 항목을 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있다(Conforming Submission). 그러면 OpenChain 준수(Conformant) 기업으로 인정됨과 동시에, OpenChain 프로젝트의 웹사이트에서 OpenChain 준수 프로그램을 갖춘 기업 목록에 기업의 로고를 등록할 수 있게 된다.

OpenChain 준수 기업에게는 OpenChain 로고를 사용할 수 있는 자격이 주어진다. 이렇게 OpenChain 준수 프로그램을 갖췄다고 인정받은 기업은 소프트웨어 공급망 내에서 오픈소스 컴플라이언스를 충실하게 수행하고 있음을 보여줄 수 있다.

6.1.1.3 - 3. OpenChain Curriculum

OpenChain 프로젝트에서는 기업이 컴플라이언스 프로그램을 구축하는데 필요한 정책 문서 템플릿, 교육 자료 등 다양한 참고자료를 제공한다. 이 자료들은 OpenChain Specification 및 일반적인 오픈소스 컴플라이언스 활동을 지원하기 위해 고안됐으며, 누구나 자유롭게 사용할 수 있도록 Public Domain으로 제공된다.

6.1.2 - II. OpenChain Specification 준수 방법

OpenChain Specifiation에서는 오픈소스 컴플라이언스를 위한 핵심 요구 사항을 정의한다. OpenChain Specification을 준수한다고 인정받은 기업은 소프트웨어 솔루션을 배포하는 조직간에 신뢰를 제공할 수 있게 된다. 여기에서는 기업들이 OpenChain Specification을 준수하기 위해 충족해야 하는 여섯가지 주요 요건과 그 방법을 세부적으로 설명한다.

6.1.2.1 - 1. 프로그램 성립

1.1 정책 (Policy)

오픈소스를 이용하여 소프트웨어를 개발하고 배포하는 기업이라면 오픈소스를 관리하기 위한 정책과 프로세스를 구축하고, 이를 위한 인력과 자원을 할당해야 한다. OpenChain에서는 이러한 일련의 활동을 관리하는 체계를 오픈소스 프로그램이라고 부르고, OpenChain Specification을 준수하기 위한 첫번째 요건은 바로 이 프로그램을 설립해야 하는것이다. 여기서 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다. OpenChain Specification에서는 이를 입증하기 위한 자료로 우선 문서화된 오픈소스 정책을 요구한다. 이 안내서에서는 참고를 위해 OpenChain Specification의 요건을 충족하는 오픈소스 정책 문서 예시를 “[부록 01] 샘플 오픈소스 정책”에서 제공한다.

OpenChain Specification은 이어지는 장에서 오픈소스 프로그램이 갖춰야할 요건들을 설명하고 있다.

오픈소스 프로그램은 소프트웨어 공급담당자가 이 오픈소스 정책 문서의 존재를 알고, 필요한 활동을 할 수 있도록 교육, 내부 위키 등 실질적인 수단을 제공해야 한다. 여기서 소프트웨어 공급담당자(Software Staff)란 기업이 소프트웨어를 개발하고 배포, 기여하는데 관여하는 모든 직원을 의미하며, 소프트웨어 개발자, 배포 엔지니어, 품질 엔지니어 등을 포함한다.

많은 기업들은 오픈소스 정책 문서를 사내 위키 사이트를 통해 공개하여 직원 누구나 필요한 사항을 확인할 수 있게 한다. 또한, 신규 채용인원의 입사 연수 시 오픈소스 정책에 대한 교육을 의무화하고, 소프트웨어 공급담당자를 대상으로 매년 혹은 2년에 한번씩 주기적인 교육을 제공함으로 모든 소프트웨어 공급담당자가 오픈소스 정책의 존재를 인식하도록 할 수 있다. 이러한 방법들을 오픈소스 정책 문서에 구체화하여 포함해야 한다.

1.2 역량 (Competence)

오픈소스 프로그램이 올바르게 구축되고 운영될 수 있도록 역할과 책임(R&R)을 정의해야 한다. 각 역할을 수행할 담당자가 갖춰야 할 역량을 정의하고, 지정된 담당자가 해당 역할을 수행할 수 있는 역량을 갖추었는지 파악해야 한다. 해당 인원이 교육, 훈련 및 경험을 바탕으로 맡은 역할을 수행할 수 있는 자격을 갖추었음을 보장해야 한다. 이를 위해 각 인원이 필요한 역량을 갖출 수 있도록 교육을 제공한다.

이를 입증하기 위해 기업은 프로그램 내 여러 참여자에 대한 책임 및 역할 목록과 각 역할을 수행하는 담당자가 갖춰야할 역량을 정의하여 문서화 한다. 이 안내서에서는 참고를 위해 오픈소스 프로그램의 각 참여자의 역할과 책임 및 필요한 역량을 정의한 샘플 문서를 “[부록 01] 오픈소스 정책 for OpenChain 2.0(예)의 4. 역할, 책임 및 역량”에서 제공한다.

그리고, 기업은 각 참여자가 역량을 갖추고 있는지 평가하고, 이를 보관한다. 이를 위해 기업은 각 참여자가 필요한 역량을 보유할 수 있도록 교육을 제공한다. 교육 내용을 기반으로 평가하고, 그 결과는 기업의 교육 시스템 혹은 HR 부서에서 보관해야 한다. 소프트웨어 공급담당자가 수천명 이상이어서 교육 제공이 쉽지 않을 경우, 기업의 온라인 교육과 평가 시스템을 이용하는 것도 좋은 방법이다.

1.3 인지도 (Awareness)

프로그램 참여자가 오픈소스 정책, 기업의 오픈소스 관련 목표, 오픈소스 프로그램이 효과적일 수 있도록 참여자의 기여 방법, 그리고 프로그램 요건을 준수하지 않았을 때의 발생할 수 있는 위험에 대해 인식하도록 한다.

이를 위해 오픈소스 정책은 프로그램 참여자가 오픈소스 정책 등의 주요 내용을 인식할 수 있도록 다음의 내용을 포함해야 한다.

• 먼저, 오픈소스를 사용, 배포, 기여하는 일련의 활동을 수행하는 목표를 포함한다. 예를 들어,“오픈소스를 이용하여 제품을 만들때 오픈소스 컴플라이언스 리스크를 최소화하고, 오픈소스 커뮤니티에 참여하고 기여함으로 최고의 가치를 창출한다”와 같은 형태로 목표를 수립할 수 있다.
• 그리고, 프로그램 참여자가 자신의 역할에 대한 책임을 완수함으로써 오픈소스 프로그램의 효과가 증대될 수 있음을 알린다.
• 또한, 오픈소스 프로그램의 요건들을 준수하지 않았을 때 어떠한 위험이 발생하는지에 대해서도 알린다.

대표적인 위험 요소는 다음과 같다.

• 사용한 코드의 저작권자로부터 법적 클레임
• 의도하지 않은 기업 독점 코드의 공개
• 라이선스 의무 위반으로 인한 벌금
• 평판 손실
• 수익 손실
• 공급업체 및 고객과의 계약 위반

각 프로그램 담당자가 프로그램의 목표, 프로그램에 기여 방법, 프로그램 미준수의 의미에 대해 올바르게 인식할 수 있도록 교육을 제공하고, 이를 평가한다. 평가한 결과는 문서화하여 보관한다. 1.2장에서 언급한 교육 및 평가 시 이에 대한 내용을 포함하면 될 것이다.

1.4 프로그램 적용 범위 (Program Scope)

오픈소스 프로그램은 반드시 기업 전체에 적용해야 하는 것은 아니다. 기업 내 각 조직의 특성에 따라 프로그램의 적용 범위를 달리 할 수 있다. 예를 들어, 소프트웨어를 전혀 배포하지 않는 조직이라면 오픈소스 프로그램의 적용 범위에 해당하지 않을 수 있다. 따라서, 기업의 오픈소스 정책은 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의해야 한다.

예를 들어, “이 오픈소스 정책은 회사가 외부에 배포하는 모든 제품에 적용한다. 향후 배포하는 제품의 형태에 따라 프로그램의 구성과 적용 범위가 달라질 수 있으며, 이에 대해서는 오픈소스 팀이 OSRB와의 협의를 통해 결정한다.”와 같은 형태로 프로그램 적용 범위를 정의할 수 있다.

1.5 라이선스 의무 (License Obligations)

오픈소스의 사용 가능 여부를 판단하기 위해서는 먼저 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항을 검토하고 확인해야 한다. 오픈소스 프로그램은 소프트웨어 개발팀에서 오픈소스 라이선스가 부여하는 의무, 제한 및 권리를 검토할 수 있도록 오픈소스 라이선스 의무 요약 자료를 제공하는 것이 좋다. 공개SW 라이선스(https://www.oss.kr/oss_license )에서는 주요 오픈소스 라이선스의 의무, 제한 및 권리를 자세히 설명한다.

오픈소스를 사용하기에 앞서 라이선스 검토하고 이를 문서화하는 절차는“[부록 02] 오픈소스 컴플라이언스 프로세스 (예시)”절차의 오픈소스 식별 단계에 해당한다.

6.1.2.2 - 2. 관련 업무 정의 및 지원

2.1 접근성 (Access)

배포한 제품에 사용된 오픈소스에 대해 고객 및 오픈소스 저작권자가 기업에게 오픈소스 관련 문의, 요청 및 클레임을 제기하는 경우가 있다. 소송까지 당하지 않기 위해서는 이러한 외부 문의에 가능한 빠르고 정확하게 대응하는 것이 중요하다. 따라서 기업은 외부에서 기업에게 오픈소스 관련 문의를 할 수 있는 연락 방법을 공개적으로 밝히고, 외부 오픈소스 문의를 접수하였을 때 빠르고 효과적으로 대응 할 수 있는 프로세스를 갖추고 있어야 한다.

외부에서 기업에게 오픈소스 관련 문의를 할 수 있는 연락 방법은 회사의 오픈소스 담당자의 이메일 주소를 공개하거나, Linux Foundation의 Open Compliance Directory를 이용하는 것이다.

오픈소스 개발자들이 기업의 오픈소스 컴플라이언스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 법적 클레임까지 제기하는 경우가 있다. Linux Foundation은 이러한 경우를 최소화 하기 위해 기업들에게 오픈소스 관련 문의를 받을 수 있는 연락처를 공개할 수 있도록 Open Compliance Directory라는 공간을 마련하였다.

이를 통해 오픈소스 개발자들은 원하는 기업의 컨택 포인트 정보를 쉽게 확인할 수 있고, 법적 클레임까지 제기하기 이전에 기업의 오픈소스 담당자와 오픈소스 컴플라이언스 이슈를 논의하여 문제를 해결할 수 있다. 기업의 오픈소스 담당자는 Open Compliance Directory에 기업 정보 및 연락 방법을 등록하는 것이 소송 리스크를 줄일 수 있는 방법 중 하나이다.

외부 문의 및 요청의 주된 내용은 다음과 같다.

• 특정 오픈소스가 제품 및 서비스에 사용되었는지 확인 요청
• Written Offer에서 언급된 GPL, LGPL 등의 라이선스 하의 소스 코드 제공 요청
• 오픈소스 고지문에 명시되지 않았지만 제품에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
• GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 제공 요청
• Copyright 표시 요청

외부로부터의 이러한 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지 진행되는 위험을 크게 줄일 수 있다. 따라서, 기업은 외부의 오픈소스 컴플라이언스 문의에 대응하기 위한 절차를 갖고 있어야 한다. 컴플라이언스 문의를 대응하기 위한 일반적인 절차는 다음과 같다.

1. 접수 확인 (Acknowledge) 문의를 받으면 즉시 응답하여, 문의가 제대로 접수되었음을 알린다. 이때 조치 예정일을 함께 알린다. 요청자의 의도가 무엇인지 정확히 파악하는 것이 중요하기 때문에 문의가 불명확한 경우 추가 설명을 요청한다.
2. 요청자에게 알림 (Inform) 요청자에게 오픈소스 컴플라이언스를 충실히 수행하고 있음과 요청자의 문의에 대해 조사하고 있음을 알린다. 내부 조사 진행사항이 업데이트되면 알리는 것이 좋다.
3. 내부 조사 (Investigate) 문의에 대해 내부 조사를 진행한다. 문제가 된 제품의 버전에 대하여 컴플라이언스 프로세스가 적절하게 수행되었는지 BOM 및 문서화 된 검토 이력을 통해 확인한다.
4. 요청자에게 보고 (Report) 요청자에게 통보했던 조치 예정일 내에 내부 조사를 마치고, 이에 대한 내부 기록을 남긴 후 요청자에게 결과를 알린다.
5. 처리 종료 (Close Inquiry) 요청자의 문의가 오해로 인한 잘못된 지적이나 요청이었다면 추가 조치 없이 요청자에게 이를 알리고 처리를 종료한다.
6. 문제 보완 (Rectify) 내부조사에서 실제 컴플라이언스 문제가 발견되면 해당 조직은 제품 또는 서비스의 컴플라이언스 문제를 해결하기 위해 필요한 모든 절차를 수행한다. 예상되는 완료 일자를 요청자에게 다시 한번 알린다. 즉, 해당 오픈소스 라이선스의 의무를 이행하기 위한 정확한 방법과 시기를 알려야 한다. 문제를 해결한 후에는 즉시 요청자에게 알리고 문제가 해결되었음을 확인할 수 있는 최선의 방법을 제공한다.
7. 프로세스 개선 (Improve) 컴플라이언스 문제가 있었던 경우, OSRB 미팅을 통해 사례를 검토하고, 문제가 발생한 경위를 파악하여, 문제가 재발하지 않을 수 있도록 프로세스를 개선한다.

2.2 효과적인 리소스 제공 (Effectively Resourced)

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 리소스를 충분하게 제공해야 한다.

• 프로그램 참여자들이 업무를 수행할 수 있는 시간과 자금을 할당하고, 주기적으로 오픈소스 정책을 검토하여 기업의 소프트웨어 전략에 맞추어 업데이트해야 한다.
• 프로그램 참여자들이 컴플라이언스 이슈 해결을 위한 프로세스가 구축되어야 하고, 이슈 해결을 위해 법적인 검토가 필요할 경우 법무 자문을 요청할 수 있는 방법이 제공되어야 한다.

오픈소스 프로그램이 기능을 수행하기 위해서는 각 역할 별 담당자가 지정되어야 한다.

• 각 역할 별 담당자 혹은 담당 조직을 지정하고, 누구나 이를 참고할 수 있도록 문서화하여 공유한다.
• 각 조직의 책임자는 프로그램 내의 각 역할별 담당자가 적절히 충원되었는지, 업무를 수행하는데 필요한 자금이 적절하게 제공되었는지를 확인한다.

만약, 프로그램 참여자가 자신의 역할을 수행하는데 리소스나 자금 지원이 부족하다고 판단한다면, 반드시 기업의 오픈소스 책임자에게 문제를 제기하여 해결해야 한다. 문제가 효과적으로 해결되지 않을 경우, 오픈소스 이사회에 보고하고, 이사회는 필요한 의사결정을 수행하여 적절한 자원이 할당 될 수 있도록 해야 한다.

기업은 프로그램 참여자가 이슈 해결을 위해 법률적인 검토가 필요할 경우, 이에 대해 법률 자문을 요청할 수 있는 방법을 제공해야 한다. 회사 내의 법무팀을 통해 우선 제공하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있다. OpenChain Project에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다.

OpenChain 파트너로 등록된 법무법인은 OpenChain Project에서 요구하는 요건을 충족한 곳들이며, 대한민국에서는 법무법인 태평양이 등록되어 있다.

오픈소스 책임자는 기업의 오픈소스 컴플라이언스 활동을 위한 기업 내부의 역할과 책임을 할당해야 한다. 오픈소스 정책 문서에는 오픈소스 책임자가 오픈소스 컴플라이언스 이슈 해결을 위해 담당해야 할 역할에 대해 기술한다.

컴플라이언스 미준수 이슈가 제기된 경우, 기업은 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 한다. 이에 대한 자세한 내용은 2.1장에서 외부 문의 대응에 대한 프로세스 설명 부분을 참고할 수 있다.

6.1.2.3 - 3. 오픈소스 콘텐츠 검토 및 승인

3.1 BOM (Bill of Materials)

오픈소스 컴플라이언스 활동의 가장 기본은 바로 공급 대상 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이다. 공급 대상 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고있는 BOM을 작성하고 관리하는 프로세스를 구축해야 한다. 공급 대상 소프트웨어마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문이다. 모든 오픈소스는 배포 대상 소프트웨어에 통합하기 전에 검토 및 승인되어야 한다. 오픈소스의 기능, 품질 뿐만 아니라 출처, 라이선스 요건을 충족하는지 검토가 되야 한다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요하다. [부록 02]에서는 기업의 오픈소스 컴플라이언스를 위한 프로세스 전과정에 대해 설명하고 있다. 식별부터 등록까지의 과정을 통해 BOM을 작성하고 관리하게 된다.

{% page-ref page="../../appendix/process.md" %}

공급 대상 소프트웨어에 포함된 오픈소스 목록은 문서화하여 보관해야 한다. Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW360(https://projects.eclipse.org/proposals/ sw360)은 공급 대상 소프트웨어별로 포함하고 있는 오픈소스 목록을 트래킹할 수 있는 기능을 제공한다. SW360 사용 방법은 [부록 03]을 참고할 수 있다.

오픈소스 컴플라이언스 프로세스의 모든 과정과 결과는 문서화가 되어야 한다. 이메일을 사용하는 것 보다는 Jira, Bugzilla 등의 이슈 트래킹 시스템을 이용하는 것이 이러한 과정을 효율적으로 문서화 할 수 있다.

3.2 라이선스 컴플라이언스

오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스 별로 요구하는 사항에 대해 정확히 알고 있어야 한다. 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어렵기 때문에 오픈소스 책임자는 자주 사용되는 오픈소스 라이선스 들에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋다. 오픈소스 책임자는 자주 사용되는 오픈소스 라이선스별로 일반적인 사용 사례에 대한 의무 요약 자료를 제공한다. 오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 NIPA에서 제공하는“공개SW 라이선스 가이드”를 참고할 수 있다. (https://www.oss.kr/oss_license)

[부록 2] 오픈소스 컴플라이언스 프로세스 (예시)의 오픈소스 컴플라이언스 프로세스의 식별, 검사, 문제해결, 리뷰, 승인 단계를 통해 공급 대상 소프트웨어의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리할 수 있다.

식별 및 검사 단계에서는 소스코드 스캔 도구를 사용할 수 있다. 소스코드 스캔 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양하게 있다. 각 도구들은 특장점 들이 있지만 어떤 하나도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않는다. 따라서 기업은 제품의 특성과 요구사항에 맞는 적합한 도구를 선택해야 한다. 많은 기업들이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용한다. Linux Foundation의 FOSSology Project는 오픈소스로 공개된 소스 코드 스캔 도구로서 기업들이 손쉽게 무료로 사용할 수 있다. 사용 방법은 [부록 03] 오픈소스도구 (FOSSology, SW360)을 참고할 수 있다.

6.1.2.4 - 4. 컴플라이언스 결과물 생성 및 전달

3.1장에서 오픈소스 컴플라이언스 활동의 가장 기본은 공급 대상 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이라고 하였다. 이는 바로 오픈소스 컴플라이언스의 핵심인 오픈소스 라이선스의 의무를 파악하여 요건들을 충족하기 위해서이다. 즉, 공급 대상 소프트웨어에 포함된 것으로 식별한 오픈소스에 대한 컴플라이언스 결과물 세트를 생성하는 프로세스가 구축되어야 한다.

컴플라이언스 결과물은 크게 두가지로 구분된다.

1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 Copyright 정보 제공을 위한 문서
2. 공개할 소스코드 패키지 : GPL, LGPL 등 소스 코드 제공을 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스코드를 취합한 패키지

컴플라이언스 결과물은 공급 대상 소프트웨어를 배포할 때 함께 제공해야 한다.“[부록 02] 오픈소스 컴플라이언스 프로세스(예시)”의 고지, 확인, 배포 단계를 통해 컴플라이언스 결과물을 생성하여 배포한다.

공급 대상 소프트웨어를 배포 시, 공개할 소스코드 패키지를 동봉하는 것이 곤란할 경우, 최소 3년간 소스코드를 제공하겠다는 서면 약정서(Written Offer)를 제공하는 것으로 대신할 수 있다. 일반적으로 서면 약정서는 제품의 사용자 매뉴얼을 통해 제공하며, 예시는 다음과 같다.

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.

따라서, 컴플라이언스 결과물은 3년 이상 보관해야 하며 이를 위한 프로세스가 구축되어야 한다. 기업들은 자체적인 웹사이트(예: http://opensource.lge.com/) 구축하여 외부 고객들이 공급 대상 소프트웨어에 대한 오픈소스 고지문과 공개할 소스코드 패키지를 언제든지 다운받을 수 있도록 편의를 제공한다.

6.1.2.5 - 5. 오픈소스 커뮤니티 참여에 대한 이해

5.1 기여 (Contributions)

글로벌 소프트웨어 기업들은 오픈소스를 사용하여 제품을 만들고 서비스를 하는 것 뿐만 아니라 오픈소스 프로젝트에 기여하며 얻을 수 있는 전략적 가치도 중요하게 여긴다. 그러나 오픈소스 프로젝트 생태계와 커뮤니티 운영방식에 대한 충분한 이해와 전략 없이 접근한다면 예기치 않게 회사의 명성이 손상되고 법적 위험이 발생할 수 있다. 따라서 기업은 오픈소스 프로젝트로의 참여 및 기여를 위한 전략과 정책을 만드는 것이 중요하다.

[부록 01] 오픈소스 정책 for OpenChain 2.0(예시)의 8장 오픈소스 기여 정책을 참고할 수 있다.

6.1.2.6 - 6. 설명서 요건 준수

6.1 준수 (Conformance)

기업이 OpenChain을 준수하는 오픈소스 프로그램을 가지고 있다고 선언한다는 것은 OpenChain Specification의 모든 요건을 충족한다는 것이다. 어느 하나의 요건이라도 충족하지 못한다면 OpenChain을 준수한다고 할 수 없다.

OpenChain Specification의 모든 요건을 충족한다면, [부록 01] 오픈소스 정책 for OpenChain 2.0(예시)의 9장에서와 같이 OpenChain을 충족하고 있음을 문서상에 명시할 수 있다.

6.2 기간 (Duration)

오픈소스 프로그램이 OpenChain을 준수한다고 선언한 이후에도 계속해서 준수하는 활동을 유지하는 것이 중요하다. OpenChain Specification 2.0의 6.2.1조에서는 OpenChain을 준수한다고 선언한 이후에도 최소 18개월 이상은 변함없이 OpenChain Specification 2.0의 모든 요건을 준수하고 있어야 함을 요구한다.

기업은 오픈소스 프로그램이 OpenChain을 준수함을 선언한 이후 적어도 18개월 이상 계속해서 준수하는 상태를 유지하여야 하며, 그렇게 하고 있다면, [부록 01] 오픈소스 정책 for OpenChain 2.0 (예시)의 9장에서와 같이 OpenChain을 18개월 이상 계속하여 충족하고 있음을 문서상에 명시할 수 있다.

6.1.3 - 부록

6.1.3.1 - 1. 샘플 오픈소스 정책 for OpenChain 2.1

OO회사 오픈소스 정책

1. 목적

이 정책은 오픈소스를 사용하는 조직 전체가 오픈소스 컴플라이언스 활동을 수행하도록 수립되었다. 또한 이 정책은 직원들이 오픈소스의 가치를 이해하게 하고, 오픈소스 커뮤니티에 기여하기 위한 방법을 제공한다.

<OO회사>의 직원은 이 정책의 근거와 내용을 이해하고 필요한 활동을 충실히 수행함으로써 정책의 효과 및 회사의 컴플라이언스 수준 향상에 기여한다.

이 정책을 준수하는 것은 중요하다. 준수하지 않을 경우 다음과 같은 상황을 초래할 수 있다.

• 사용 중인 코드에 대한 저작권 또는 기타 지식재산권 보유자의 법적 클레임
• 고객으로부터의 클레임
• 회사 독점 코드의 의도치 않은 공개
• 라이선스 의무 위반으로 인한 벌금 부과
• 평판 손실
• 수익 손실
• 공급업체 및 고객과의 계약 위반

이러한 이유로 회사는 코드 침해를 심각하게 간주하며, 코드를 침해하는 개인은 회사의 징계 절차에 처해질 수 있다.

2. 적용

이 오픈소스 정책은 [회사가 외부로 제공하거나 배포하는 모든 제품]에 적용된다. 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않는다.

또한 이 정책은 <OO회사>의 직원이 오픈소스 프로젝트에 기여하거나 <OO회사>의 코드를 오픈소스로 공개할때 적용한다.

<OO회사>의 오픈소스 정책은 [LINK]에서 확인할 수 있다.

3. 용어

“오픈소스” - Open Source Initiative(OpenSource.org)에서 발표한 Open Source Definition 혹은 Free Software Foundation에서 발표한 Free Software Definition을 충족하는 라이선스, 혹은 유사한 라이선스가 하나 이상 적용된 소프트웨어.

“공급 대상 소프트웨어” - 회사가 제3자 (다른 조직 또는 개인)에게 배포하는 소프트웨어

4. 역할, 책임 및 역량

이 정책의 효과적인 수행을 보장하기 위해 다음과 같이 필요한 역할 및 책임과 각 역할의 담당자가 갖추어야 할 역량을 정의한다.

<OO회사>의 소프트웨어 개발 및 배포를 담당하는 최고 임원은 각 역할 및 책임을 위한 담당자가 지정되고, 역할을 수행할 적절한 자금과 시간이 할당되도록 보장해야 한다.

각 역할의 담당자는 자신의 역할에 대해 적절하게 지원이 되지 않는다면 반드시 오픈소스 책임자를 통해 문제를 해결해야 한다. 적절하게 해결되지 않는다면, 오픈소스 운영위원회를 통해 문제를 제기할 수 있다.

가) 오픈소스 책임자

오픈소스 책임자는 오픈소스가 사용된 <OO회사> 제품의 컴플라이언스를 보장할 책임과 함께 다음 사항에 대한 책임이 있다.

• 오픈소스 정책을 검토, 개선 및 전파한다.
• 효율적인 오픈소스 정책 수행을 위해 회사 내부의 역할 및 책임을 검토하고 할당한다.
• 오픈소스 컴플라이언스 관련 이슈에 대한 교육과 평가를 검토하고 구현한다.
• 오픈소스 운영위원회의 의장을 맡아서 활동을 지휘한다.
• 소프트웨어 개발팀이 오픈소스 정책과 프로세스를 이해하고 준수하도록 안내하는 역할을 하고, 필요할 경우 경영진에게 문제를 제기한다.
• 외부로부터의 오픈소스 사용 및 컴플라이언스에 대한 문의에 답변한다.

오픈소스 책임자는 업무 수행을 위해 오픈소스 관련 IP 리스크, 개발 프로세스를 이해하고, 커뮤니케이션 스킬에 대한 역량을 갖춰야 한다.

2020년 1월 현재 OOO팀의 OOO가 오픈소스 책임자 역할을 담당한다.

나) 오픈소스 센터

오픈소스 센터는 오픈소스 컴플라이언스를 위한 전문 센터이며, 컴플라이언스를 효과적으로달성하기위한프로세스를정의한다. 오픈소스책임자가리더역할을수행 하고, 센터의 구성원들은 오픈소스 책임자가 원활하게 책임을 수행할 수 있도록 돕는 역할을 맡는다. 오픈소스 센터는 다음과 같은 역할을 수행한다.

• 컴플라이언스 실무 교육을 개발 및 제공한다.
• 컴플라이언스 도구를 선택 / 개발 및 배포한다.
• 코드 검사 및 자동 스캔을 수행하여 <OO회사> 제품 내 오픈소스 포함 여부를 식별한다.
• 오픈소스 사용 요청을 검토하고 승인한다.
• 오픈소스 사용 목록에 관한 기록을 유지한다.
• 오픈소스 고지 및 소스코드 공개를 위한 웹 사이트를 개발하고 유지 관리한다.

다) 소프트웨어 개발팀

소프트웨어 개발팀은 소프트웨어 개발에 사용할 오픈소스를 식별하고 오픈소스 센터에 오픈소스 사용 승인 요청을 제출한다.

소프트웨어 개발팀은 소프트웨어 개발에 사용한 오픈소스에 적용되는 오픈소스 라이선스의 의무를 이행할 책임이 있다.

소프트웨어 개발팀은 오픈소스 정책 및 프로세스와 소프트웨어 아키텍쳐를 이해한다.

라) 법무팀

법무팀은 오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 이행하기 위한 가이드를 소프트웨어 개발팀에 제공한다. 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공한다. 필요할 경우 오픈소스 사용 검토 및 승인 결정에 참여한다.

오픈소스 프로젝트로의 기여를 위한 검토 요청에 의견을 제공한다.

5. 교육 및 평가

소프트웨어 배포에 관여하는 <OO회사>의 모든 직원은 교육 및 평가를 통해 오픈소스 정책을 숙지한다.

이 정책을 수행하는 모든 대상자는 자신의 역할에 필요한 역량을 다루는 최소한의 기본 교육을 수강하고 평가를 받는다.

교육 및 평가 프로그램은 <OO회사> 오픈소스정책의 목표, 컴플라이언스 수준 향상에 기여 하기 위한 참여자의 역할 및 컴플라이언스 미준수 시 회사 및 개인에 미치는 영향 등에 대해 다룬다.

평가 기록은 최소 3년동안 유지한다.

6. 오픈소스 사용 정책

오픈소스를 사용하기 위해서는 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인한다. 그렇게 공급 대상 소프트웨어에 포함된 오픈소스와 라이선스 의무사항을 식별하고, 소프트웨어를 배포 시 라이선스 의무사항을 준수하기 위한 활동을 한다.

이를 효과적으로 수행하기 위해 <OO회사> 오픈소스 컴플라이언스 프로세스를 준수한다.

오픈소스 라이선스 준수를 위한 과정에서 의문사항이 있는 경우 [오픈소스 책임자]는 법무팀에게 문의 할 수 있다.

오픈소스 사용 결정 결과 및 관련 근거는 오픈소스 이슈 추적 시스템에 기록한다.

7. 외부 문의 대응 정책

<OO회사>에서 배포한 소프트웨어에 대해 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 공개된 연락처를 제공한다. 이를 위해 소프트웨어 배포 시 오픈소스 센터의 이메일 주소를 제공하고,
Linux Foundation의 Open Compliance Directory (https://compliance. linuxfoundation.org/ references/open-compliance-directory/)에 <OO회사>의 연락처를 등록한다.

외부로부터 오픈소스 관련 문의를 받은 사람은 누구나 오픈소스 책임자에게 문의한다. 오픈소스 책임자는 문의를 처리하고 회사 내 적절한 개인 또는 조직에 할당한다. 오픈소스 책임자는 문의를 할당하고 처리하는 것에 대한 전반적인 책임이 있다.

<OO회사>에서 배포한 소프트웨어에 대해 외부로부터 컴플라이언스 미준수 이슈가 제기될 경우, 오픈소스 책임자는 다음과 같이 처리한다.

1. 질의 접수 승인 및 적절한 해결 시간을 명시한다.
2. 질의가 진짜 문제인 것인지를 확인한다. (아니라면 영업일 기준 3일 이내에 질의자에게 응답한다.)
3. 이슈가 진짜 문제라면, 3일 이내에 적절한 대응 방법을 결정하고, 질의자에게 대응 계획에 대해 응답한다.
4. 결정한 방법에 따라 30일 이내에 대응하고, 질의자에게 문제가 해결되었음을 알린다.
5. 이상의 사항을 오픈소스 이슈 추적시스템에 기록한다.

8. 오픈소스 기여 정책

<OO회사>는 오픈소스에서의 비즈니스 가치 창출을 위해 외부 오픈소스 프로젝로의 참여와 기여를 권장한다. 그러나 의도하지 않은 지식 재산의 노출 혹은 침해를 주의해야 한다.

회사의 업무와 관련이 있는 오픈소스 프로젝트에 기여하기 위해서는 먼저 SW개발팀 리더에게 승인을 받아야 한다.

그리고 오픈소스 프로젝트의 오픈소스 라이선스와 특허 조건을 검토한다. 또한 기여 하고자 하는 오픈소스 프로젝트가 요구하는 DCO (Developer Certificate of Origin), CLA (Contributor License Agreement)등의 문서 서명에 대해 검토해야 한다. 필요할 경우 법무팀에 검토를 요청할 수 있다.

9. OpenChain 준수

<OO회사>는 소프트웨어 공급망에서의 오픈소스 컴플라이언스 수준 향상을 위해 Linux Foundation의 OpenChain 프로젝트의 정신을 지지하며 적극적으로 참여한다. <OO회사>의 오픈소스 정책은 OpenChain Specification 2.0을 준수하도록 설계되었다.

<OO회사>는 <OO회사>의 오픈소스 정책을 포함하는 오픈소스 프로그램이 OpenChain Specification 2.0의 모든 요건을 준수하고 있음을 확약한다.

<OO회사>는 <OO회사>의 오픈소스 정책을 포함하는 오픈소스 프로그램이 OpenChain Specification 2.0의 모든 요건을 준수하고 있음을 확약한 이후 18개월 동안 여전히 모든 요건을 준수하기 위한 활동을 수행하고 있음을 확약한다.

6.1.3.2 - 2. 오픈소스 컴플라이언스 프로세스 (template)

오픈소스 컴플라이언스의 주요 두가지 목적은 다음과 같다.

1. 의무 파악 : 공급 대상 소프트웨어가 포함하고 있는 오픈소스를 식별하고 각 오픈소스 라이선스가 요구하는 의무를 파악한다.
2. 의무 사항 이행 : 식별한 의무 사항을 이행한다.

이를 위해 기업은 공급 대상 소프트웨어를 배포하는 시점에 오픈소스 라이선스 의무사항을 준수할 수 있도록 오픈소스 컴플라이언스 프로세스를 구축해야 한다. 여기서는 일반적인 오픈소스 컴플라이언스 프로세스의 구성요소와 각각의 기능 및 역할을 포함하는 프로세스(예시)를 제안한다.

<OO 회사> 오픈소스 컴플라이언스 프로세스 (예시)

<OO 회사>의 오픈소스 정책에 근거하여 오픈소스를 사용하기 위해서는 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인해야 한다. 그렇게 공급 대상 소프트웨어에 포함된 오픈소스와 라이선스 의무사항을 식별하고, 소프트웨어를 배포 시 라이선스 의무사항을 준수하기 위한 오픈소스 컴플라이언스 활동을 해야 한다.

<OO회사>의 오픈소스 컴플라이언스 프로세서는 공급 대상 소프트웨어에 사용되는 오픈소스를 관리하는 일련의 과정을 정의한다. 이 과정에는 다음 사항이 포함된다.

1. 공급 대상 소프트웨어에 사용된 모든 오픈소스 식별
2. 식별한 오픈소스에 의해 발생하는 모든 의무를 식별하고 추적
3. 모든 의무를 충족하기 위한 활동

이를 효과적으로 수행하기 위해 <OO회사>의 모드 소프트웨어 공급관리자는 다음 10단계를 수행한다.

Step 1. 오픈소스 식별 (Identification of Open Source)

오픈소스 식별 단계는 오픈소스 컴포넌트를 식별하기 위한 검토 단계이다. 자체 독점 소프트웨어인지, 제3자 소프트웨어인지 여부에 관계 없이 공급 대상 소프트웨어에 포함된 오픈소스를 모니터링한다. 오픈소스 식별 방법은 다음과 같다.

• 오픈소스 사용 요청 접수 : SW개발자는 특정 제품에 오픈소스를 사용하고자 함을 오픈소스 책임자 또는 오픈소스 센터에 알리고, 검토 및 승인을 위한 오픈소스 패키지의 용도에 관한 정보를 제공한다.
• 회사 개발 소프트웨어 검사 (Auditing) : 개발자가 오픈소스의 소스코드를 복사해서 가져와 소프트웨어를 개발할 수 있기 때문에 회사가 개발한 소프트웨어에 대해서도 검사를 수행한다.
• 제3자 소프트웨어 실사 (Due diligence)

Step 2. 소스 코드 검사 (Auditing Source Code)

소스 코드 검사 단계에서는 소스 코드 분석 도구를 사용하여 소스 코드를 스캔하여 오픈소스를 발견한다. 소스 코드 스캔도구는 FOSSology를 이용한다. GPL-3.0 등 정책적으로 사용할 수 없는 오픈소스 라이선스가 적용된 오픈소스 혹은 라이선스 충돌로 양립할 수 없는 오픈소스가 발견될 경우 문제로 식별하여 개발팀에 보완을 요청한다.

Step 3. 문제 해결 (Resolving Issues)

소스 코드 검사 단계에서 식별된 모든 문제를 해결한다. 문제 사항은 Jira Ticket으로 생성하여 개발팀에 할당되고, 오픈소스 책임자는 모든 문제가 적절하게 해결되었는지 확인한다.

Step 4. 검토 (Reviews)

식별된 모든 문제가 해결되면 검토 단계로 이동한다. 검토 단계의 절차는 다음과 같다.

1. 소프트웨어 PL : 소프트웨어에 포함된 오픈소스에 대한 사용 승인 요청서를 제출한다.
2. 오픈소스 책임자 : 사용 승인 요청서를 접수하면 모든 정보가 누락없이 포함 되었는지를 확인하고, Jira ticket을 생성하여 검토 절차를 진행한다.
3. 소스코드 검사 담당자: Jira ticket이 생성되면 소스코드 검사를 수행하여 문제가 모두 해결되었는지 확인한다.
4. 법무팀 : 라이선스 이슈를 검토한다.

Step 5. 승인 (Approval)

검토가 완료되면 Jira ticket은 승인 단계로 이동한다. OSRB는 오픈소스의 사용을 승인하거나 거절한다. 거절시에는 이유에 대한 설명과 수정 방법을 제안한다. OSRB가 오픈소스 구성요소의 사용을 승인하면 개발팀은 라이선스 의무를 이행하기 위한 준비를 시작한다.

Step 6. 등록 (Registration)

사용이 승인된 오픈소스 구성요소는 오픈소스 사용을 추적하는 BOM (소프트웨어 인벤토리)에 추가한다. BOM에는 오픈소스 구성요소 이름, 버전, 관리 담당자 이름, 이를 사용하는 제품 이름, 제품 버전, 제품 릴리즈 번호 등의 정보를 포함한다. BOM을 관리하는 도구는 SW360을 사용한다.

Step 7. 고지 (Notices)

오픈소스를 사용할 때 주요 의무 중 하나는 고지 의무이다. 이를 위해 다음 사항을 수행 한다.

• 저작권, 라이선스 고지를 제공한다.
• 라이선스 사본을 제공한다.
• (해당되는 경우) 소스 코드 사본을 얻을 수 있는 방법을 최종 사용자에게 알린다.

이와 같은 사항을 제품 배포 시 포함시킬 수 있도록 관련 부서에 전달한다. 화면이 있는 제품이면 사용자가 메뉴 > 오픈소스 고지 정보에서 오픈 소스 고지 내용을 확인할 수 있게 한다. 제품에 화면이 없을 경우, 사용자 매뉴얼에 오픈소스 고지 내용을 포함시킨다.

Step 8. 배포 전 확인 (Pre-Distribution Verifications)

이 단계에서는 다음 사항을 보장하기 위한 확인을 수행한다.

• 오픈소스 라이선스가 요구하는 공개할 소스 코드를 취합한다.
• 취합한 소스 코드는 제품에 탑재된 바이너리와 매치되어야 한다.
• 소스 코드 내 부적절한 주석을 제거한다.
• 적절한 고지문이 제품에 포함되었다. 여기에는 최종 사용자가 소스 코드를 받을 수 있는 방법 (Written Offer)도 함께 제공한다.

Step 9. 배포 (Distribution)

배포 전 확인이 완료되면 공개할 소스 코드 패키지를 오픈소스 배포사이트에 업로드한다. 오픈소스 배포사이트에는 제품 및 버전별로 등록할 수 있다. 최종 사용자는 자신이 원하는 제품의 버전에 해당하는 소스 코드 패키지를 오픈소스 배포사이트에서 검색하여 다운로드 받을 수 있다.

Step 10. 최종 확인 (Final Verifications)

공개할 소스 코드 패키지를 오픈소스 배포사이트에 업로드 후 패키지가 올바르게 업로드 되었고, 외부에서 오류 없이 다운로드 및 압축 해제가 되는지 확인한다. 라이선스에 따라 빌드하여 바이너리 생성까지 보장을 요구하는 경우, 외부에서 다운받은 소스 코드가 README의 안내대로 오류 없이 빌드하여 바이너리가 생성되는지, 생성된 바이너리가 제품에 탑재된 바이너리와 동일한지 확인한다.

6.1.3.3 - 3. 오픈소스도구 (FOSSology, SW360)

오픈소스 컴플라이언스 활동을 위해서는 정책, 프로세스나 교육자료뿐만 아니라 소스코드 스캔, Dependency 분석, 오픈소스 BOM 관리 등을 위한 다양한 도구와 시스템도 요구된다. 때문에 다수의 기업이 이러한 도구와 시스템을 도입하고 활용하는데 많은 리소스를 투입하고 있다. 특히 오픈소스 컴플라이언스를 처음 시작하는 기업은 프로세스뿐 아니라 비용 측면에서도 어려움을 겪고 있다.

이런 어려움을 해결하기 위해, 2019년 6월, OpenChain 프로젝트에 참여하고 있는 지멘스, 보쉬, 도시바, 후지쓰, 히타치 등의 오픈소스 컴플라이언스 도구 전문가들을 주축으로 OpenChain Tooling Work Group이 시작되었다.

OpenChain Tooling Work Group은 여러 기업의 오픈소스 전문가들이 이슈를 함께 해결하고 결과물을 공유해 오픈소스 컴플라이언스 비용을 절감하고 양질의 컴플라이언스 결과물을 만들어 내기 위해 구성되었다.

구체적으로는 FOSSology, SW360, Software Heritage, ClearlyDefined, SPDX 등의 기존 오픈소스 프로젝트를 활용하여 통합(turn-key) 오픈소스 툴 체인을 만들고, 모든 기업이 이를 자유롭게 사용할 수 있도록 하는 것을 목표로 삼고 있다. (https://groups.io/g/oss-based-compliance-tooling)

여기서는 FOSSology와 SW360에 대해 소개 및 간단한 사용 방법에 대해 알아본다.

6.1.3.3.1 - FOSSology

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

Linux Foundation의 FOSSology 프로젝트는 이러한 스캔 도구를 개발하고 오픈소스로 공개해 누구나 자유롭게 사용할 수 있게 한 도구이다.

주요 특징

FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

설치

기업 내에서 FOSSology를 사용하기 위해서는 사내에 FOSSology 서버를 구축해야 한다. 이를 위해 리눅스 기반의 서버 시스템에 FOSSology를 설치해야 한다. FOSSology는 다음 세 가지 방법으로 설치할 수 있다.

1. Docker 사용
2. Vagrant와 VirtualBox 사용
3. Source build하여 설치

여기서는 가장 간편한 방법인 Docker를 사용하는 방법에 대해 설명한다.

FOSSology는 컨테이너화 된 Docker 이미지를 Docker Hub (https://hub.docker.com/)를 통해 공개하고 있다. : https://hub.docker.com/r/fossology/fossology

Pre-built 된 Docker 이미지는 다음 명령어를 사용하여 실행할 수 있다.

$ docker run -p 8081:80 fossology/fossology

Docker 이미지는 다음 URL과 계정 정보로 사용할 수 있다. : http://[IP_OF_DOCKER_HOST]:8081/repo

• Username : fossy
• Passwd : fossy

설치와 관련한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://github.com/fossology/fossology/blob/master/README.md

테스트 서버

FOSSology를 설치할 수 있는 시스템 구축이 곤란한 상황이라면, FOSSology Project에서 제공하는 테스트 서버를 이용할 수 있다. FOSSology 프로젝트에서는 테스트를 위한 환경을 제공한다. (테스트 서버는 예고없이 중단될 수 있다.)

사용자는 다음 계정으로 FOSSology 테스트 서버에 접속하여 FOSSology 기능을 시험해볼 수 있다.

Basic Workflow

FOSSology의 기본 사용 절차는 다음과 같다.

• 사용하고자 하는 오픈소스의 라이선스와 Copyright 정보를 확인하기 위해 오픈소스의 소스 코드를 하나의 파일로 압축하여 FOSSology에 업로드한다.
• 이를 위해 메뉴 > Upload > From File을 선택합니다.

• 업로드할 파일을 선택하고 Upload 버튼을 클릭한다.
• 업로드가 완료되면 Job Agent에 의해 자동으로 분석을 수행한다.
• 메뉴 > Jobs > My Recent Jobs에서 분석 중인 Status를 확인할 수 있다.

• 분석이 완료되면 메뉴 > Browse에서 분석 결과를 확인할 수 있다.

• 개별 파일을 선택하면 FOSSology가 검출한 라이선스 관련 텍스트가 무엇인지 확인할 수 있다.

• 메뉴 > Browser > 파일 혹은 디렉터리를 선택 > Copyright/Email/Url/Author에서는 FOSSology가 검출한 Copyright/Email/Url/Author 정보를 보여다.

사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목에 대해서는 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/get-started/basic-workflow/

위와 같은 방법으로 사용하고자 하는 오픈소스의 라이선스는 무엇인지, Copyright 정보는 어떻게 되는지를 간단히 확인할 수 있다.

6.1.3.3.2 - SW360

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

이렇듯, 오픈소스 정보를 추적하는 활동은 꼭 필요하다. 기업들은 이를 위해 자체 시스템을 구축하거나, 상용 서비스를 구매하여 사용하기도 한다. SW360은 Eclipse 재단에서 후원하는 오픈소스로서 소프트웨어 BOM에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

• 제품에 사용된 컴포넌트 추적
• 보안 취약점 평가
• 라이선스 의무 관리
• 고지문 등 법적 문서 생성

설치

SW360은 다음과 같이 구성된다.

• Frontend : Liferay-(Tomcat-)based portal application
• Backend : Tomcat-based thrift service
• Database : CouchDB

Project 구조와 설치를 위해 요구되는 소프트웨어 등 자세한 내용은 README의 Required software 부분에서 확인할 수 있다. : https://github.com/eclipse/sw360/blob/master/README.md

SW360은 다음 세 가지의 설치 방법을 제공한다. 사용자는 이 중 하나를 선택하여 설치할 수 있다.

1. Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
2. SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
3. Docker를 통해 Deploy 할 수 있다. : https://github.com/sw360/sw360chores

여기서는 CentOS 7.6 시스템에 Vagrant 기반으로 설치하여 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/sw360/sw360vagrant/blob/master/README.md

1) 사전 설치

vagrant box에 SW360을 설치하기 위해서는 openjdk, VirtualBox 및 Vagrant를 설치해야 다. 먼저 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)

VirtualBox를 설치한다.

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

CentOS 7에서 VirtualBox 설치 시, “kernel module is not loaded’ 에러가 발생할 경우, kernel-devel을 설치하여 해결한 후 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

Vagrant와 vagrant-aws plugin을 설치한다.

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

그리고, sw360vagrant 코드를 Clone 한다.

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

2) Dependency 다운로드

Vagrant box를 빌드하는 시간을 줄이기 위해 Dependency Package들을 미리 다운로드 받는다.

$ cd sw360vagrant
$ ./download-packages.sh

그러면 다음의 package들이 ./shared/package 폴더 안에 다운로드 된다.

• Liferay 7.2.1 CE GA2 with Tomcat (9.0.17)
• Postgresql-42.2.9 ODBC client for Java as *.jar file
• SW 360에서 필요한 11개의 *.jar 파일
• Thrift 0.11
• A box images from the Ubuntu 16.04 LTS (xenial-server-cloudimg-amd64-vagrant.box)

3) Base box 생성

이제 다음 명령어로 Base box를 생성한다.

$ cd generate-box
$ ./generate_box.sh

이 작업은 수십 분 소요될 수 있다.

4) Box 실행

다음 명령어로 Box를 실행한다.

# 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

Box를 실행하면 liferay, postgresql 및 couchdb가 구성된다. 이상없이 실행이 될 경우, https://localhost:8443/ 로 Liferay 화면에 접근할 수 있다.

5) SW360 Layout Deploy

마지막 단계는 Liferay에서 SW360의 Layout을 Deploy하는 것이다. 이 작업은 아직 자동화가 되지 않아 관리자가 수동으로 수행해야 다. https://localhost:8443/에 접근하여 다음 계정으로 로그인한다.

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

이후에는 다음 사이트의 안내에 따라 Layout deploy를 수행한다. https://github.com/eclipse/sw360/wiki/Deploy-Liferay7

Deploy가 완료되면 다음과 같은 화면을 볼 수 있다.

Basic Workflow

1) License 등록

SW360을 처음 설치하면 먼저 자주 사용하는 오픈소스 라이선스 들을 등록해야 한다. 라이선스 다음과 같은 정보를 포함한다.

• Full Name
• Short Name
• License Type
• GPL-2.0 Compatibility (예: yes, no)
• License Text

메뉴 > Licenses > Add License를 선택하면 다음과 같이 Create License 화면으로 진입한다.

이와 같이 라이선스를 하나씩 수동으로 등록하는 일은 상당히 수고스러울 수 있는데, 다행히 SW360은 SPDX License List를 한 번에 Import 하는 기능을 제공한다. 메뉴 > Admin < Import SPDX Information을 클릭한다.

그러면, 곧 SPDX License List가 자동으로 등록됩니다. 메뉴 > Licenses에서 338개의 License가 등록된 것을 확인할 수 있다.

2) Component 및 Release 등록

SW360에서 Component는 하나의 소프트웨어 단위이다. 여기에는 다양한 형태의 소프트웨어가 해당할 수 있으며, 그 예는 다음과 같다.

• 오픈소스 소프트웨어
• 라이브러리
• 3rd party 소프트웨어

Component는 다음과 같은 정보를 포함한다.

• Component Name
• Main Licenses
• Categories (예: Library, Cloud, Mobile, …)
• Component Type (예: OSS, Internal, InnerSource, Service, Freeware)
• Default Vendor
• Homepage URL

Release는 Component에서 하나의 Version을 가리키는 단위이다. 따라서 하나의 Component는 여러 개의 Release를 가질 수 있다. Release는 하나의 Component 하위에 생성되어 관리된다.

Release는 다음과 같은 정보들을 포함한다.

• Component Name
• Version
• License
• Download URL
• CPE ID (예: cpe:2.3:a:apache:maven:3.0.4)

예를 들어, zlib-1.2.8을 등록해야 한다면, 먼저 Component에 zlib을 먼저 등록한 후, Release에 zlib 1.2.8을 등록한다. Menu > Components > Add Component를 선택하면 Create Component 화면으로 진입하여 zlib에 대한 정보를 등록할 수 있다.

Component를 생성하면, Components > Releases > Add Release에서 zlib-1.2.8 version에 대한 정보를 등록할 수 있다.

하나의 zlib이라는 Component에 1.2.8과 1.2.11 version을 각각의 Release로 등록하였을 때, Release Overview 화면에서 다음과 같이 2개의 Release가 존재하는 것을 볼 수 있다.

SW360은 다수의 Component 정보를 Import 시키기 위한 기능을 제공한다. 메뉴 > Admin > Import / Export에 CSV template에 등록을 원하는 Component 정보를 입력 후 Import 할 수 있다.

단, 이 기능은 2020년 2월 기준 아직 안정적으로 동작하지 않을 수 있다.

3) Project 생성

Project는 하나의 제품을 가리킨다. 사업 유형에 따라 제품일수도 있고, 서비스 혹은 소프트웨어 일수도 있다. Project에는 제품에 사용된 Component/Release를 등록하여 관리한다.

Project 생성 시에는 다음과 같은 정보를 등록한다.

• Project Name
• Version
• Project type (예: Product, Customer Project, Service, Internal Project, InnerSource)

메뉴 > Projects > Add Project를 통해 Project를 생성할 수 있다.

Project를 생성하고 나면, 포함하는 Release나 하위 Project를 등록한다. 메뉴 > Projects에서 해당 Project를 선택하면 “Linked Releases and Projects”에서 Linked Projects와 Linked Releases를 등록할 수 있다.

다음은 SuperCalc라는 Project에 OpenSSL 1.0.1과 zlib 1.2.8을 Linked Releases로 등록한 이후의 화면이다.

4. 보안 취약점 관리

SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 확인할 수 있다. 이를 위해 SW360은 CVE 정보를 주기적으로 수집하도록 스케쥴링하는 기능을 제공한다. 메뉴 > Admin > Schedule 에서 CVE SEARCH 정보를 24시간마다 수집하도록 스케쥴링을 설정할 수 있다.

이렇게 스케쥴링을 설정하면 SW360은 정해진 시간에 CVE Search 사이트(https://cve.circl.lu/)에서 CVE 정보를 수집한다. 수집한 CVE 정보는 메뉴 > Vulnerabilities에서 확인할 수 있다.

이렇게 Vulnerabilities 정보가 수집된 이후에는 생성한 Project에 보안 취약점이 있는지 조회할 수 있다. 위에서 생성한 SuperCalc Project에서는 85개의 보안 취약점이 보고된 것을 확인할 수 있다.

이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화할 수 있는 형태로 관리가 가능하다.

또한 SW360은 위와 같은 Web Interface 뿐만 아니라 대부분의 기능을 REST API로 제공하여서 FOSSology 등의 다른 도구와의 연동이 가능하다. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

즉, 소스 코드 스캐닝 도구의 분석 결과를 SW360에 Import 시키는 등의 방법으로 DevOps에 Integration 시켜서 Project, Release 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.

6.2 - [out of date] Open Source Governance for Enterprises

References

This guide has referenced the following resources:

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

6.2.1 - 1. What is ISO/IEC 5230

You can find everything about ISO/IEC 5230 on the OpenChain project website. : https://www.openchainproject.org/

6.2.2 - 2. Essential elements

Essential elements of an open source program

You need the following components to build an effective open source governance for your comapny.

Among the above elements, in order to establish an open source governance suitable for all items required by ISO/IEC 5230, a company must have the following five core elements.

1. Team
2. Policy
3. Process
4. Tool
5. Education

6.2.3 - 3. Team

Identify the roles and the corresponding responsibilities

In order to establish a company’s open source governance, it is necessary to appoint a person in charge of it. It may be called an open source program manager, an open source compliance officer, etc., and this person in charge is responsible for the overall open source compliance of the company.

A person with the following competencies is suitable for this role.

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

An open source program manager should be guaranteed to be able to perform the role as full-time as possible.

Global ICT companies are working hard to hire such excellent open source program managers, and you can check various job postings at the following site. : https://github.com/todogroup/job-descriptions

To establish open source governance, you need to define the needs of each role and determine what responsibilities should be assigned. For small businesses, it is possible for an open source program manager to perform all the roles alone. Depending on the size of the enterprise, an infrastructure person who operates open source tools may be required, and the role of a legal person may be required to provide professional legal advice.

In general, the following roles are required to establish a corporate open source governance system.

• Legal
• Infrastructure
• Development culture
• Security

If you do the above, you can prepare the following evidence required by ISO/IEC 5230.

Define competencies

Once you have defined each role and its responsibilities, you need to figure out what competencies the person performing that role should have. This is because, through this, it is necessary to evaluate whether the person in charge of each role has the capability to perform the role, and if there is not enough, the company must provide the necessary training to him.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Identify person or group

The open source program manager, in consultation with the relevant department, designates and documents the person in charge for each role. Of course, for this, it will be necessary to report the goals and directions for establishing an open source compliance system to the top decision makers such as the CEO to receive the necessary support.

Open source-related person and group in charge do not necessarily have to participate in open source work full-time. You can organize a virtual group in the form of an OSRB (Open Source Review Board) and perform the necessary roles.

SK Telecom has formed the OSRB to create open source policies and processes, and prepare countermeasures when issues arise.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

The table below is a sample representative that specifies the roles of open source-related organizations and people in charge, and the required competencies. You can refer to this and form an open source organization and document it.

This can also be found on this page. : appendix-1-list-of-persons-in-charge

If you organize in this way, you will now meet the following three requirements among the requirements of ISO/IEC 5230.

6.2.4 - 4. Policy

Document open source policy

A company should establish, document, and disseminate an open source policy composed of principles for a company to properly use open source in software development, service, and distribution.

Common open source policies include:

• Principles for creating and distributing software products and services using open source
• Principles for contributing to the external open source community
• Principles for releasing open source

The following pages provide sample open source policy documents that meet the requirements of ISO/IEC 5230. : “Appendix 1. Open Source Poicy (Sample)”

Each company can use this sample policy by modifying it according to the company’s business strategy and environment.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Define scope

An open source program does not necessarily apply to the entire organization. The scope can be specified differently depending on the characteristics of each organization and product within the company. Different open source programs can be applied to different organizations and products. Similarly, organizations that do not distribute software at all may be excluded from the scope of the open source program. A company can clearly define the scope and limits of the application of an open source program in consideration of the characteristics of the organization and product, and specify it in the open source policy.

As a company’s organization and its products and services change with the business environment, it may be necessary to determine or modify the scope of the program. A company should prepare a procedure to manage it as in 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’s coverage.
2. If it is determined that the project is not included, a proposal to include the project in the scope of application is submitted to the OSRB.
3. If accepted by OSRB, the scope of the open source program will be modified accordingly.
4. Other than that, if the open source program manager determines that it is necessary to review the program scope, it may start the program scope review according to the same process.

The following examples can be included in the open source policy.

2. Scope
This policy applies to the following three parts:

1. Applies to [all products provided or distributed by the company externally]. 
   However, the open source only for internal use is not included in the scope of 
   this policy.
2. Applied when contributing to external open source projects.
3. Applied when releasing internal code as open source.

The scope can be changed according to the business environment of the company, 
and the procedure for this is as follows.

1. If the open source program manager determines that it is necessary to change 
   the scope of policy according to changes in the company's business environment, 
   such as a new business or reorganization, submit a proposal for this to the OSRB.
2. OSRB approves proposals for scope changes at the appropriate level.
3. OSRB modifies the open source policy to change the scope of the policy.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Respond to external inquiries

For products or services developed using open source, customers and open source copyright holders may raise open source related inquiries, requests and claims to companies. The main contents of external inquiries and requests are as follows.

• Ask if open source is used for certain products and services
• Request to provide source code under the GPL, LGPL license mentioned in the Written Offer
• A request for a description of the open source found in the product and disclosure of the source code, although not specified in the open source notice
• Request to provide missing files and build methods in the source code published under GPL, LGPL, etc.
• Request for copyright notice

You should designate a contact person to handle these external inquiries. This is usually done by an open source program manager.

In addition, even if an external open source developer wants to contact a company representative to discuss an issue related to a specific company’s open source compliance, they cannot find a way to contact them and eventually file a legal claim. In order to prevent this, you must always disclose publicly how to contact the company from outside to make inquiries and requests related to open source.

To disclose your contact information so that external open source related inquiries can be received, (1) publicly disclosed the email address of the company’s open source program manager, or (2) the Linux Foundation’s [Open Compliance Directory] (https://compliance.linuxfoundation. org/references/open-compliance-directory/).

It is also a good idea to disclose the representative email address of the company open source program office in the open source notice that accompanies the product and service.

These contents can be included in the open source policy as in the example below.

Respond to external inquiries

(1) Responsibility for responding to external inquiries
The open source program manager is responsible for responding 
to inquiries and requests for open source compliance from 
outside.<sub>(3.2.1.2)</sub>

* The open source program manager may assign all or part of 
  the handling of inquiries to appropriate personnel within the 
  company. If necessary, contact the legal team to deal with it.
* Anyone who receives an inquiry about open source compliance 
  from outside will notify the open source program manager so 
  that a prompt response can be made.

(2) Disclosure of contact information
The open source program manager publicly provides the contact 
information of the person in charge so that external inquiries 
and requests related to open source can be submitted to the 
company.<sub>(3.2.1.1)</sub>

* Include the email address of the person in charge in the open 
  source notice.
* Register your contact in the Linux Foundation's Open Compliance 
  Directory.

(3) External Inquiry Response Procedure
If you respond quickly and accurately to open source compliance 
inquiries from outside, you can significantly reduce the risk of 
going to a lawsuit. To this end, in order to respond to external 
open source compliance inquiries, you should follow the external 
inquiry response process defined in the company's open source 
compliance process.<sub>(3.2.1.2)</sub>

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Provide staff and funding

You must provide sufficient resources for open source programs to function properly. Staff for each role in the program should be appropriately assigned, and sufficient funding and working hours should be ensured. If there is a shortage, there should be a procedure to make up for it. The following example sentences 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 for the person in charge to fulfill the role.
 * The person in charge of each role should raise an issue with 
   the open source program manager if appropriate support is not 
   provided while performing his/her role.
 * The open source program manager discusses problem solving with 
   the head of the organization. If not properly resolved, the open 
   source program manager may request the OSRB to resolve the issue.
 * OSRB shares the problem with the head of the higher level organization 
   and asks for a solution.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Identify Legal Expertise

You should provide a way for the person in charge of each role to seek legal advice when a legal review is needed to resolve an open source compliance issue.

The legal team within the company provides legal advice first, and if the issue is complex, you can seek advice from an external law firm with an open source lawyer. An example of an open source policy for this is as follows.

4. Roles, Responsibilities and Competencies

(2) Open Source Program Manager
* Provides a way to request legal advice on open source.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

For reference, the OpenChain project provides a list of global law firms that provide open source-related advice through partner programs. : https://www.openchainproject.org/partners

Assigns internal responsibilities

There should be a process for assigning internal responsibilities for open source compliance. This is the role of an open source program manager. The open source program manager must identify the issues and assign them appropriately to the person in charge of each role. To do this, you should include this in your open source policy document as follows:

4. Roles, Responsibilities and Competencies

(2) Open Source Program Manager

The open source program manager is responsible for the overall 
responsibility for the company's open source programs. 
To ensure open source compliance of products and services using 
open source, open source program manager is responsible for:

- Define the roles required for open source compliance, and 
  designate a responsible person and group in charge of each 
  role. Consult with OSRB if necessary.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Handle non-compliant cases

Businesses should document procedures for promptly reviewing and responding to non-compliance cases. Refer to the following examples and include them in your open source policy.

6. Use open source

(5) Compliance Issue Remediation Procedure

Should a non-compliance issue be raised, the Open Source Program Manager 
responds promptly by performing the following procedures.

1. Acknowledge receipt of the query and state a reasonable time for resolution;
2. Determine whether the query discloses a genuine issue or not 
   (and if not, respond to the querier accordingly);
3. If the issue is genuine, apply to prioritise, and determine the appropriate response.
4. Carry out response and, where necessary, improve open source compliance processes.
5. Document the above using Jira Tracker.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Open Source Contribution Policy

Global IT companies value not only the use of open source to make products and services, but also the strategic value that can be created by contributing to open source projects. However, if you contribute without a sufficient understanding and strategy for the open source project ecosystem and how the community operates, unexpected legal risks may arise and the company’s reputation may be damaged. Therefore, it is important for companies to create strategies and policies for participation and contribution to open source projects.

The following pages provide sample open source contribution policy documents. : 7. Open Source Contribution

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

If you even establish an open source policy that includes the above, the following green items among the ISO/IEC 5230 requirements will be satisfied.

6.2.5 - 5. Process

A process is an actionable procedure that enables a company to comply with open source policies during software development/distribution. Simply put, the open source compliance process is an activity to comply with the obligations required by each license for the open source used while developing and distributing software, and it generates artifacts such as open source notices and source code to be disclosed.

If the open source compliance process is subdivided and schematized, it is shown in the figure below.

The image below is a sample open source compliance process that companies can commonly use.

You can refer to the next page for more details on this. : 2. Open Source Compliance Process (Sample)

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

Identify and audit

In order to determine whether an open source can be used, it is necessary to first identify the license of the open source to be used and check the obligations required by the license. You should review and record whether you used open source, what the licenses are, and what obligations each license gives you. An example of the procedure for this is as follows.

1. The development team makes a preliminary assessment of the license based on the open source policy.
2. In case of any doubt, contact the open source program manager, and if necessary, the open source program manager refers the question to external legal experts.
3. The outcome of any determination, and associated rationale (whether internal or external) is recorded.

The Identification of Open Source, Auditing Source Code, Resolving Issues, Reviews, and Approval steps are an example of a documented process for reviewing and documenting the obligations, restrictions and rights imposed by each identified license.

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

In the open source identification and audit phase, you use a code scan tool to inspect the source code. For details on this, refer to “6. Tool”.

Create Bill of Materials

The most basic of open source compliance activities is to determine open source included in the supplied software. It is necessary to establish a process for creating and managing a Bill of Materials (BOM) containing the information by identifying the open source included in the supplied software and identified license. This is because it is necessary to know which open source is included in each version of the supplied software so that when distributing the software, you can comply with the obligations required by the identified license of each open source.

All open source must be reviewed and approved prior to integration into the supplied software. It should be reviewed in advance whether it can meet license requirements as well as the function and quality of open source. For this, a review request → review → approval process is required.

Appendix 2. Open Source Compliance Process (Sample) explains all the processes for open source compliance. BOM is created and managed through the process from 1. Identification of Open Source to 6. Registration.

The tool for managing the open source BOM is described in detail in “6. Tool”.

In addition, all processes and results of such an open source compliance process should be documented. Rather than using e-mail, it is better to use an issue tracking system such as [Jira] (https://www.atlassian.com/software/jira) and [Bugzilla] (https://www.bugzilla.org/) to effectively document this process.

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

Create Artifacts

As mentioned above, the most basic of open source compliance activities is to determine the open source included in the supplied software. This is to properly meet the open source license requirements, which are the core of open source compliance. In other words, a process for generating a set of compliance artifacts for open source included in the supplied software should be established.

Compliance artifacts are divided into two main categories.

1. Open Source Notice: A document to provide full open source license and copyright information

   

   • The method of automatically generating an open source notice corresponding to an open source BOM is further described in “6. Tool”.

2. Source code package to be disclosed: A package that collects source codes to be disclosed to fulfill open source license obligations that require source code disclosure such as GPL, LGPL, etc.

Compliance artifacts must be provided when distributing supplied software.

In “Appendix 2. Open Source Compliance Process (Sample)”, the compliance artifacts are created and distributed through 7. Notices to 9. Distribution.

When distributing supplied software, if it is difficult to enclose the source code package to be disclosed, it can be replaced by providing a written offer to provide the source code for at least 3 years. Typically, a written offer is provided through the product’s user manual, examples of which are 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.

<SFLC Guide to GPL Compliance>

Therefore, a process must be established to store compliance artifacts for at least 3 years. To this end, a company needs to build an open source website, which is described in detail in “6. Tool”.

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

Respond to third party inquiries

It is important for a company to respond to third party inquiries as quickly and accurately as possible in order to avoid legal litigation. For this, a company must have a process that can respond quickly and effectively to third party open source inquiries.

The figure below shows the process a company must have to respond to third party inquiries.

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

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

Open Source Contribution Process

If you have a policy to allow contributions to external open source projects, there should be a documented procedure to manage how in-house developers can contribute to external projects.

The Open Source Contribution Procedure released by SK telecom is a good example.

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

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

If you build the process up to this point, you will comply with the ISO/IEC 5230 requirements as follows.

6.2.6 - 6. Tool

Source code scanning tool

You should use a source code scanning tool during the identification of open source and audit phase of the open source compliance process. Source code scanning tools range from freely available, open source-based tools to commercial tools, each with their own strengths and weaknesses, but none of them seem to provide complete functionality to solve all problems. Therefore, companies can choose the appropriate tool for the characteristics and requirements of the product.

Many companies use a combination of these automated source code scanning tools and manual reviews. Linux Foundation’s FOSSology project is an open source source code scanning tool that companies can use for free.

For instructions on how to install and use FOSSology, refer to Get Started.

Dependency analysis tool

In recent software development, build environments that support Package Manager such as Gradle and Maven are used. In such a build environment, even if there is no source code, the required dependency library at build time is received from the remote to compose the supplied software. At this time, the dependency library is included in the supplied software, but it is not detected by the source code scanning tool. Therefore, it is also important to utilize a tool for dependency analysis.

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

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

Open Source BOM Management Tool

3.3.1.2 of the ISO/IEC 5230 standard requires that the open source BOM list included in the supplied software be documented and kept. The open source BOM can also be managed with a spreadsheet program such as Excel. However, if the number and version of supplied software exceed hundreds, it is not easy to manage them manually. Therefore, it is better to use an automated tool to manage it.

SW360, an open source project hosted by the Eclipse Foundation, provides a function to track the list of open source BOM included in the supplied software.

How to install and use SW360 is SW360 wiki

And FOSSLight, an open source released by LG Electronics mentioned above, also provides a function for open source BOM management.

LG Electronics developed FOSSLight on its own and has been managing the open source BOM for supplied software for all business divisions for the past several years, and in June 2021, it announced that it had been released as an open source for anyone to use.

For detailed installation and usage instructions, refer to the following English guide. : https://fosslight.org/fosslight-guide-en/

If you have the above tools, you can prepare the following evidence required by ISO/IEC 5230.

Create artifacts

It is better to use a tool that automatically generates an open source notice, which is an open source compliance product, rather than writing it manually.

You can automatically generate an open source notice by registering an open source BOM using the FOSSLight tool. The open source disclaimer generated by FOSSLight also includes a Written Offer to provide source code.

In addition, SK Telecom is planning to release the open source automatic notice generation tool used in-house.

Archive open source artifacts

It is recommended that companies create an open source website and register open source compliance artifacts to provide convenience so that external customers can download open source notices and source code packages to be disclosed at any time.

You can refer to SK Telecom’s open source website.

In particular, this website was developed as an open source, and since the source code is open, you can easily build a website by referring to it.

If you build a tool environment like this, you can prepare the following evidence required by ISO/IEC 5230.

If you build the tool environment in this way, you will comply with the ISO/IEC 5230 requirements as follows.

6.2.7 - 7. Training

Training

No matter how good policies and processes are in place, they will be useless if no one in the company understands and follows them. In order for the open source policy and open source compliance process to work effectively in the company, it is important to educate employees.

You should provide practical methods, such as training and internal wikis, to ensure that all program participants are aware that there is an open source policy within the company and can take necessary actions. Program participants here mean all employees involved in the development, distribution, and contribution of software by a company, including software developers, distribution engineers, and quality engineers.

Many companies publish open source policy documents through their in-house wiki site, so that any employee can see what they need. In addition, training on open source policy is mandatory for new hires during training, and regular training is provided annually or every two years to program participants so that all program participants are aware of the existence of open source policies. . In other words, you should write these methods as the following example and include the open source policy document.

5. Training and Assessment
All program participants should take the open source mandatory 
training provided by [Learning Portal] every year. Through training, 
all participants should be familiar with open source policies and 
processes. Training history is stored in [Learning Portal].

If you build an educational environment like this, you can prepare the following evidence required by ISO/IEC 5230.

In addition, you should ensure that program participants are aware of the company’s open source policies, the relevant open source objectives, the contributions expected to ensure the effectiveness of the Program, and the implications of failing to follow the Program requirements. To this end, you should provide training and conduct assessments to ensure that program participants are properly aware. The assessment results are documented and stored.

To do this, you can include the example below in your company’s open source policy.

1. Purpose

(1) Purpose of the policy<sub>(3.1.3.1)</sub>

This policy provides the following principles for all organizations 
involved in software development, service, and distribution in OOO 
Company (hereinafter referred to as the "Company") to properly utilize 
open source software (hereinafter referred to as "Open Source"). 

1. Principles for open source license compliance
2. Principles for contribution to external open source projects
3. Principles for releasing open source

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

(2) Impact of non-compliance
It is important that [COMPANY] adheres to this policy. Failure to do 
so may lead to:
- legal claims from the holders of copyright or other intellectual 
  property rights in code we use
- claims from our customers;
- the inadvertent release of [COMPANY] proprietary code;
- breach of regulatory obligations by [COMPANY] potentially leading to fines;
- loss of reputation;
- loss of revenue;
- breach of contract with suppliers and customers.
For this reason, we take breaches of this policy seriously, and any 
individual breaching the policy may find themselves subject to [COMPANY]'s 
disciplinary procedure.

(3) How to contribute to the effectiveness of the Program

All members of the company can contribute to the effectiveness of the 
program and improvement of the company's compliance level by understanding 
the rationale and content of this policy and faithfully performing the 

Assessment will be described in more detail later.

If you include the content of such education in your policy, you can prepare the following evidence required by ISO/IEC 5230.

Open source training also includes content on the open source contribution policy. Even if an open source contribution policy has been created, if program participants are not aware of its existence, there is a risk of harm to individuals and companies due to unexpected copyright infringement. You should provide open source training so that all program participants are aware of the existence of the open source contribution policy.

If you provide training on the contribution policy in this way, you can prepare the following evidences required by ISO/IEC 5230.

If you want to create a new educational material, it may not be easy for the person in charge who is starting the job for the first time. The OpenChain Project has released the reference training slides for anyone to refer to.

NCSOFT, a Korean game company, has published teaching plans (PPT) and lecture scripts on GitHub so that anyone can use in-house open source educational materials (Korean only).

In addition, Kakao, a representative platform company in Korea, has also released open source training materials for in-house developers so that anyone can refer to it (Korean only).

If you have not yet created training materials, it is also a good way to use open source training materials from these excellent open source management companies.

Assessment

Once you have designated a person in charge for each role, you should ensure that the person assigned is qualified to perform the role based on education, training and experience. Training should also be provided to program participants with insufficient competencies so that they can acquire sufficient competencies. And the company should assess each participant’s competencies and archive the results.

1. Provide training so that each participant has the necessary competencies.
2. Assess based on education content.
3. Keep the assessment results in the company’s training system or HR team.

If it is difficult to provide training because there are more than hundreds of participants in the program, it is also a good idea to use the company’s online training and assessment system.

You can include this in your company’s open source policy as follows.

4. Roles, Responsibilities and Competencies
In order to ensure the effectiveness of the policy, the roles and 
responsibilities and the competencies that the person in charge of 
each role should have are defined as follows.
The person/group in charge of each role and the required competency 
level are defined in [Appendix 1. Status of Person in Charge].

5. Training and Assessment
All members in charge of each role defined in Chapter 4 should take 
the advanced open source training course provided by [Learning Portal]. 
Training history and evaluation results are stored in [Learning Portal] 
for at least 3 years.

If you have this training and evaluation system, you can prepare the following evidence required by ISO/IEC 5230.

Open Source License Guide

To properly comply with open source licenses, you must know exactly what each open source license requires. However, since it is difficult for a software developer to figure it out on their own, it is recommended that an open source program manager identify requirements / conditions for common use cases for frequently used open source licenses and share them within the company.

The Open Source License Guide should include requirements specific to common open source licensing use cases to ensure that software developers use open source and comply with its license obligations properly.

For general guides on open source licenses and summary of license obligations, refer to the Open Source License Checklists provided by the OSADL.

The document Obligations by license in SK Telecom’s open source guide is also a good resource (Korean only).

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

If you provide this open source licensing guide, you can prepare the following evidence required by ISO/IEC 5230.

If you build an environment for providing training, assessment and guide in this way, you will comply with ISO/IEC 5230 requirements as follows.

6.2.8 - 8. Conformance

If you build an open source program (open source policy / process / tool / organization) that complies with all requirements except Article 6 of the ISO/IEC 5230 standard, you can write and publish a document specifying the following two.

1. A document affirming the program specified in requirement §3.1.4 satisfies all the requirements of this specification.
2. A document affirming the program meets all the requirements of this version of the specification (version 2.1), within the past 18 months of obtaining conformance validation

You may include the above document in the open source policy, or you may publish it through an externally public website.

As shown in the image below, you can refer to the content that SK Telecom posted on the open source portal site. https://sktelecom.github.io/en/compliance/iso5230/

If you document that you meet all the requirements of ISO/IEC 5230 in this way, you can prepare the following evidence required by ISO/IEC 5230.

If you’ve made it this far, your company will finally meet all the requirements of ISO/IEC 5230.

6.2.9 - Appendix

6.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 all organizations involved in software development, service, and distribution in [COMPANY] (hereinafter referred to as the “Company”) to properly utilize open source software (hereinafter referred to as “Open Source”).

1. Principles for open source license compliance
2. Principles for contribution to external open source projects
3. Principles for releasing open source

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

All members of the company can view the open source policy at the following link on the in-house wiki: [internal_link]_(3.1.1.1)

(2) Impact of non-compliance

It is important that [COMPANY] adheres to this policy. Failure to do so may lead to:

• legal claims from the holders of copyright or other intellectual property rights in code we use
• claims from our customers;
• the inadvertent release of [COMPANY] proprietary code;
• breach of regulatory obligations by [COMPANY] potentially leading to fines;
• loss of reputation;
• loss of revenue;
• breach of contract with suppliers and customers. For this reason, we take breaches of this policy seriously, and any individual breaching the policy may find themselves subject to [COMPANY]’s disciplinary procedure.

(3) How to contribute to the effectiveness of the Program

All members of the company can contribute to the effectiveness of the program and improvement of the company’s compliance level by understanding the rationale and content of this policy and faithfully performing the necessary activities.

2. Scope_(3.1.4.1)

This policy applies to the following three parts:

1. Applies to [all products provided or distributed by the company externally]. However, the open source only for internal use is not included in the scope of this policy.
2. Applied when contributing to external open source projects.
3. Applied when releasing internal code as open source.

The scope can be changed according to the business environment of the company, and the procedure for this is as follows.

1. If the open source program manager determines that it is necessary to change the scope of policy according to changes in the company’s business environment, such as a new business or reorganization, submit a proposal for this to the OSRB.
2. OSRB approves proposals for scope changes at the appropriate level.
3. OSRB modifies the open source policy to change the scope of the policy.

3. Terms

• “compliance artifacts” - a collection of artifacts that represent the output of a compliance program and accompany the supplied software. The collection may include (but is not limited to) one or more of the following: attribution notices, source code, build and install scripts, copy of licenses, copyright notices, modification notifications, written offers, open source component bill of materials, and SPDX documents.
• “open source” - software subject to one or more licenses that meet the Open Source Definition published by the Open Source Initiative (see opensource.org/osd) or the Free Software Definition published by the Free Software Foundation (see gnu.org/philosophy/free-sw.html) or similar license.
• “program” - the set of policies, processes and personnel that comprise an organization’s open source license compliance activities.
• “program participants” - any organization employee or contractor that defines, contributes to or has responsibility for preparing supplied software. Depending on the organization, that may include (but is not limited to) software developers, release engineers, quality engineers, product marketing and product management.
• “SPDX” - the format standard created by the Linux Foundation’s SPDX (Software Package Data Exchange) Working Group for exchanging bill of materials for a given software package, including associated license and copyright information (see spdx.org).
• “supplied software” - software that an organization distributes to third parties (e.g., other organizations or individuals).

4. Roles, Responsibilities and Competencies_(3.1.2.1)

In order to ensure the effectiveness of the policy, the roles and responsibilities and the competencies that the person in charge of each role should have are defined as follows.

The person/group in charge of each role and the required competency level are defined in [Appendix 1. Status of Person in Charge]._(3.1.2.2)

• The open source program manager periodically updates the list according to 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 for the person in charge to fulfill the role._(3.2.2.2)
  • The person in charge of each role should raise an issue with the open source program manager if appropriate support is not provided while performing his/her role.
  • The open source program manager discusses problem solving with the head of the organization. If not properly resolved, the open source program manager may request the OSRB to resolve the issue.
  • OSRB shares the problem with the head of the higher level organization and asks for a solution.

(1) OSRB

OSRB_{Open Source Review Board} is a consultative body composed of an open source program manager, legal team, patent team, development team, and infrastructure team for the company’s open source compliance.

• Create policies and processes for open source compliance, and define roles and responsibilities within the company to implement them.
• When an open source compliance issue occurs within the company, discuss solutions and prepare countermeasures.
• If necessary, report issues to the executive team to receive feedback on risk mitigation measures.

(2) Open Source Program Manager

The open source program manager is responsible for the overall responsibility for the company’s open source programs. To ensure open source compliance of products and services using open source, open source program manager is responsible for:_(3.2.2.4)

• Define the roles required for open source compliance, and designate a responsible person and group in charge of each role. Consult with OSRB if necessary.
• Supervise and assess open source compliance training.
• Serves as the chair of the OSRB and directs its activities.
• Respond to inquiries and requests related to open source use and compliance from outside.
• Review and approve requests for use of open source.
• Maintain open source BOM records.
• Provides a way to request legal advice on open source._(3.2.2.3)
• Maintain a repository for open source notices and source code disclosure.

(3) OSPO

OSPO_{Open Source Program Office} is responsible for supporting and nurturing the growth of open source activities inside and outside the company.

• Establish, improve and disseminate open source policies.
• Provides a guide for contributing code to external open source projects.
• Provides a guide for releasing an in-house project as an open source.
• Develop and operate an open source portal.
• Develop and select open source tools.
• Sponsor open source project events.
• Manage relationships with the open source community.

(4) Legal team

The legal team provides advice on legal risks and mitigation measures that may arise in the process of using open source, such as interpreting open source licenses and obligations.

• Advise on licensing and intellectual property issues, including conflicts due to incompatible open source licenses.
• When contributing to external open source projects, review necessary legal matters such as open source licenses and CLA_{Contributor License Agreement}.

(5) IT infrastructure team

The IT infrastructure team operates and automates open source analysis tools to build a system so that license analysis is performed automatically for supplied software.

• Operate an open source license analysis tool.
• Automate license analysis by integrating with DevOps.
• Establish systems and processes so that license analysis is performed for supplied software.
• Obtain and maintain an open source BOM for supplied software.

(6) Security Officer

The security officer operates an open source security vulnerability analysis tool to build a system so that security vulnerability analysis is performed smoothly for supplied software.

• Operate an open source security vulnerability analysis tool.
• Automate open source security vulnerability analysis by integrating with DevSecOps.
• Establish systems and processes so that open source security vulnerability analysis is performed for supplied software.

(7) Development Culture

The development culture manager supports developers to actively utilize open source and participate in the open source community to learn a good development culture.

• Encourage developers to participate in the open source community.
• Create a culture where activities in open source projects can be recognized as achievements.
• Create a development culture that can be perceived as an attractive company to open source developers.

(8) Quality Responsible

The organization responsible for quality, such as QA, checks whether the open source license obligations have been properly performed when distributing software.

• Check whether open source compliance activities are performed in accordance with the development process.
• Check that the artifacts are generated as required by the open source license.
• When distributing software, make sure that the open source notice and the source code to be released are provided together.
• If an issue is found, notify the software development/deployment team and guide them to fix the issue immediately.

5. Training and Assessment

All program participants should take the open source mandatory training provided by [Learning Portal] every year. Through training, all participants should be familiar with open source policies and processes. Training history is stored in [Learning Portal]._(3.1.1.2)

All members in charge of each role defined in Chapter 4 should take the advanced open source training course provided by [Learning Portal]. Training history and assessment results are stored in [Learning Portal] for at least 3 years._(3.1.2.3)

6. Use open source

If you use open source to develop and distribute products and services, you should comply with the obligations required by each open source license. The activities that companies perform for this purpose are called open source compliance.

For proper open source compliance activities, software development/distribution organizations should comply with the following:_(3.3.1.1)

• All processes of the open source compliance process are recorded and preserved in Jira Issue Tracker.

(1) Identify open source and review license obligations.

When using open source to develop products / services, first identify what an open source license is, and review and investigate the obligations that the license requires.

The company’s [Open Source License Guide] provides a guide for frequently used open source licenses, and explains the obligations for each type of distribution as follows for each license._(3.3.2.1)

• Distributed in binary form;
• Distributed in source form;
• Integrated with other open source such that it triggers additional licensing obligations;
• Contains modified open source;
• Contains open source or other software under an incompatible license interacting with other components within the supplied software; and/or
• Contains open source with attribution requirements.

Software development/distribution teams can refer to this guide when reviewing their open source license obligations. If you need to review an open source license not mentioned in this guide, contact your open source program manager.

(2) Design software considering open source licenses.

Identify open source dependencies and design your software architecture so that your code is not subject to open source licenses. .

The company’s [Open Source Licensing Guide] describes the source code disclosure scope for each open source license and design methods to prevent disclosure of own code.

(3) Create an open source compliance artifact.

The most basic of open source compliance activities is to identify open sources included in supplied software. This is to properly meet the open source license requirements, which are the core of open source compliance. That is, a set of compliance artifacts for open source included in the supplied software should be generated._(3.4.1.1)

Open source compliance artifacts are divided into two main categories.

1. Open source notice: A document to provide full open source license and copyright notice
2. Source code package to be disclosed: A package that collects source code to be disclosed to fulfill open source license obligations that require source code disclosure such as GPL, LGPL, etc.

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

• Open source notices or source code packages to be disclosed are collected according to the conditions required by each license. For example, a license requires the accompanying full text of the license, but not just a link.
• Collected artifacts are stored in a separate storage.
• When providing source code to be made public by a written agreement, provide a download link so that the external general public can access the repository of the collected artifacts.

Follow the company’s open source compliance process to create and provide open source compliance artifacts as above.

(4) Create open source Bill of Materials (BOM)

Create and manage the Bill of Materials (BOM) included in the supplied software._(3.3.1.2)

Follow the company’s open source compliance process to create and preserve open source BOMs using open source tools.

(5) Compliance Issue Remediation Procedure

Should a non-compliance issue be raised, the Open Source Program Manager responds promptly by performing the following procedures._(3.2.2.5)

1. Acknowledge receipt of the query and state a reasonable time for resolution;
2. Determine whether the query discloses a genuine issue or not (and if not, respond to the querier accordingly);
3. If the issue is genuine, apply to prioritise, and determine the appropriate response.
4. Carry out response and, where necessary, improve open source compliance processes.
5. Document the above using Jira Tracker.

7. Open Source Contributions

The company encourages participation and contribution to external open source projects to create business value in open source. However, in this process, you should be careful about unintentional exposure of the company’s intellectual property or infringement of the rights of third parties. Therefore, members of the company should comply with the following when contributing to external open source projects._(3.5.1.1)

(1) Request a review and get approval.

An open source contribution is to grant an open source project the right of an author to modify/use/distribute a work from a copyright point of view. In some cases, you may need to transfer your copyright to an open source project. In general, however, the copyright of a work created during employment is owned by the employer. In other words, works created by company members are owned by the company. Contributing to open source works created while you were employed may raise unnecessary copyright infringement issues.

Therefore, if there is an open source project that you would like to contribute to, follow the review request and approval procedures before making the initial contribution according to the open source contribution process.

However, in the case of a small contribution as follows, since the risk of copyright infringement is not large, you can contribute at your own discretion without the review process.

• Small code snippets of 10 lines or less
• Inquiries and answers on Stack Overflow
• Activities on GitHub: Issue creation, Pull Request Review / Approve, etc.

(2) Contribute only code that you have the right to contribute

Only contribute code for which you have the right to contribute. In other words, contribute your own code, not third-party code.

(3) Be careful not to expose the company’s intellectual property

Do not contribute code or documents that may expose the company’s intellectual property such as sensitive information or patents.

• If the code you want to contribute includes [Company]’s patent, you should check whether you can contribute to the project under the open source license. If there is any ambiguity, contact OSPO.

(4) Be careful about signing the CLA.

Some open source projects require all contributors to sign a CLA_{Contributor License Agreement}. This is an agreement to seek consent from contributors to reduce copyright disputes that may arise when a project manages the works of multiple contributors. Typically, a company-led project requires a CLA to be signed.

The CLA varies from project to project, but primarily includes agreement to the following:

• I (or my company) have the right to contribute to the project the contribution I intend to contribute. (i.e. I am the author of this contribution.)
• I (or my company) grant the project the right to modify, distribute, and manage my contributions to the project.
• I (or my company) will not revoke the authority granted to me.
• I (or my company) grant the project the right to change the license according to future needs of the project.

In addition, in rare cases, some CLAs also require consent to the following terms and conditions:

• I (or my company) transfer my copyright to the project or project management organization at the same time as I contribute my contribution.

[Company] does not allow contributions to open source projects that require transfer of copyright to protect the company’s intellectual property. Therefore, if the open source project you want to contribute to requires the CLA to be signed, be sure to ask OSPO for a review before signing.

(5) Add company copyright notice

The intellectual property of the work you create during your employment is basically owned by the company. Therefore, you should add your company’s copyright notice when contributing code to external open source projects.

When contributing more than one file, add the copyright and license notices at the top of the files, like this:

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

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

However, if your contribution is only to modify existing code for the purpose of fixing a bug, you do not need to add a copyright notice for that code modification.

(6) Use your company email

When contributing to an open source project, use your company email, not your personal email. This will (1) give you a sense of responsibility to communicate with the community on behalf of the company, and (2) improve the awareness of the company that actively contributes to the open source community.

8. Open Source Release

[Company] respects the value of collaboration with the open source community and encourages the release of internal software as an open source project. However, there are several rules that should be followed to protect the company’s intellectual property and prevent unintentional copyright infringement.

(1) Get approval

From a copyright point of view, releasing as open source means that the author grants the right to modify/use/distribute the work by anyone through an open source license. In general, the copyright of a work created during employment is owned by the employer. In other words, the work you create is owned by the company. The act of arbitrarily releasing a work as open source may cause unnecessary copyright infringement issues.

Therefore, if you want to release the software as open source, follow the review request and approval procedure according to the company’s open source release policy.

Do not hesitate to contact OSPO if anything in your open source process appears to be undesirable.

(2) Release only the code you have the right to publish.

One of the worst things that can happen to an open source project is that the project contains legally problematic code. Code that the company does not have the right to release, or code that infringes IP, such as another company’s patent, can cause legal problems. Therefore, while preparing the code to be released, check the source of all code and delete problematic code.‌

(3) Be careful about the exposure of the company’s intellectual property.

Do not release code or documents that may expose sensitive information or patents to the company’s intellectual property.

If the code you want to release contains [Company] patent, see if you can release it under the open source license. If there are any ambiguities, please contact OSPO.

(4) Publish useful code

To be a successful project, it should also be useful to others. If a similar project already exists, join the existing project rather than create a new one.

An open source that intends to release should be able to expect: (1) provide differentiated value to the open source community; (2) to solve problems that the community has not been able to solve; (3) We receive positive attention by releasing our technology.

• If the code we haven’t used in our products or services, don’t even release it as open source.
• Do not publish code that addresses a problem that has already been addressed by the open source community. If this is the case, contribute to an existing open source project.

(5) Prepare the resource

Prepare in advance the resources that will be put into the open source project, including developers.

• In the beginning, the number of developers similar to that of a general in-house project is required.
• Get developers who can quickly review external contributions.
• The role of the legal team and marketing team is also required.
• Secure a budget for the infrastructure required to maintain and manage the project. This includes tools for hosting projects like Github.

If you can’t create an environment with enough resources to support it, don’t release it as open source.

(6) Use your company email

For open source release activities, do not use personal emails, but use company emails. This will (1) give you a sense of responsibility to communicate with the community on behalf of the company, and (2) improve the awareness of the company that actively contributes to the open source community.

9. Respond to external inquiries

(1) Responsibility for responding to external inquiries

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

• The open source program manager may assign all or part of the handling of inquiries to appropriate personnel within the company. If necessary, contact the legal team to deal with it.
• Anyone who receives an inquiry about open source compliance from outside will notify the open source program manager so that a prompt response can be made.

(2) Disclosure of contact information

The open source program manager publicly provides the contact information of the person in charge so that external inquiries and requests related to open source can be submitted to the company._(3.2.1.1)

• Include the email address of the person in charge in the open source notice.
• Register your contact in the Linux Foundation’s Open Compliance Directory.

(3) External Inquiry Response Procedure

If you respond quickly and accurately to open source compliance inquiries from outside, you can significantly reduce the risk of going to a lawsuit. To this end, in order to respond to external open source compliance inquiries, you should follow the external inquiry response process defined in the company’s open source compliance process._(3.2.1.2)

10. OpenChain

[COMPANY] supports the Linux Foundation’s OpenChain project. This policy has been carefully designed to be compliant with the OpenChain Specification v2.1, ISO/IEC 5230:2020.

• [COMPANY] affirms that as of [insert date] it is in compliance with the OpenChain Specification v 2.1, ISO/IEC 5230:2020._(3.6.1.1)
• [COMPANY] affirms that within the past 18 months of obtaining conformance validation, the program meets all the requirements of the OpenChain Specification v2.1, ISO/IEC 5230:2020._(3.6.2.1)
• [COMPANY]’s affirmation of conformance will be reviewed and renewed if appropriate at intervals of at least [12|18 months].

Appendix 1. List of persons in charge

6.2.9.2 - 2. Open Source Compliance Process (Sample)

OOO Corporation (hereinafter referred to as the “Company”) actively uses open source software (hereinafter referred to as “Open Source”) while developing products and services including the software. When a company distributes its software, it should perform activities to comply with the obligations imposed by the open source license, which is called open source compliance.

1. Process for software development/distribution

This open source compliance process defines the procedures a [company] should follow to comply with its open source license obligations for each stage of development for developing and distributing software products and services. All employees involved in developing/distributing software products should follow these 10 steps of the Open Source Compliance Process.

1. Identification of Open Source

The development team should adhere to the following during the software design phase.

• Identify predictable open source usage and check licenses while designing software.
• Check the obligations for each open source license. You can check the obligations for each license in the company’s Open Source Licensing Guide.
• Design software considering the source code disclosure scope of each open source license.

Open source program managers should write a guide on the obligations, restrictions, and rights of frequently used open source licenses, and make them available for reference to the development team.

The development team should display the copyright and license in the source code according to the company’s policy. The copyright and license notation rules in the company’s source code can be found on the following page. : (insert_link)

When a development team needs to use a new open source, first identify the license. Check your license obligations, restrictions, and rights according to your company’s Open Source Licensing Guide. If the license is not described in the company’s open source license guide, ask the open source program manager whether it can be introduced or not. Create a Jira Ticket and inquire.

Open source program managers guide the software development team by analyzing their open source license obligations.

• If in doubt, seek advice from the Legal Department to provide clear guidance.
• Add newly analyzed open source licenses to the guide.

2. Auditing Source Code

The development team requests open source audit by providing the source code according to the guidance of the infrastructure team.

The development team uses the open source analysis tool provided by the infrastructure team to audit the open source and generate the open source BOM.

The open source program manager reviews whether the obligations of the open source license can be complied with and whether there is an open source license conflict, and if there is an issue, ask the development team to resolve it. Create issues with Jira Tickets and assign them to the development team.

3. Resolving Issues

The development team should resolve any issues found during the source code inspection phase. Take action, such as removing the open source that has become an issue, or replacing it with an open source under a different license.

When the development team resolves all issues found, Resolve the Jira Ticket issue and request a review.

4. Reviews

Open source program managers review that all issues have been properly addressed. If necessary, re-audit the source code using an open source analysis tool.

5. Approval

The open source program manager should finally approve or reject whether the open source compliance process has been properly performed. In case of rejection, explain the reason and suggest to the development team how to fix it.

6. Registration

The open source program manager confirms the BOM for tracking the list of open source usage by version of the software.

The person in charge of infrastructure registers the confirmed BOM in the system. Include in the BOM a list of the open sources included with the supplied software and information such as:

• Product (or service) name and version of the supplied software
• Open Source List
  • Open source name / version
  • Open source license

7. Notices

Open Source Program Managers create Open Source Notices to comply with notice obligations. Include the following in the Open Source Notice.

• Open source contact information for external inquiries related to open source
• Notice by open source
  • Copyright notice
  • Open source license name
  • A copy of the open source license
  • Written Offer to receive a copy of the source code (if applicable)

The open source program manager creates an Open Source Notice and delivers it to the development team. In this case, if it is necessary to disclose the source code, guide the development team on how to collect the source code to be disclosed.

The development team should enclose the Open Source Notice when distributing the product. In the case of a product with a screen, take measures so that the user can check it through the menu. (Example: Apps > Menu > Settings > Copyright Information > Open Source License)

If the development team uses open source under a license that requires source code disclosure, such as GPL or LGPL, check the source code disclosure scope for this and collect the source code to be disclosed.

• The source code collected to comply with license obligations such as GPL and LGPL should match the source code that creates the binaries loaded in the product. In other words, when the compiled source code is built, it should be the same as the binary loaded on the product.

8. Pre-Distribution Verifications

The development team should submit the following artifacts demonstrating that the open source compliance activities were properly conducted.

1. Final Open Source Notice included in the product
2. Materials confirming that the product includes Open Source Notice (eg, screen capture image showing Open Source Notice)
3. (if applicable) source code to be disclosed (compressed and submitted in one file)

The open source program manager should review the data submitted by the development team and check for any abnormalities.

9. Distribution

Open source program managers should submit compliance artifacts submitted by the development team to the infrastructure team.

The infrastructure team registers the compliance artifacts on the company’s open source distribution site.

10. Final Verifications

The open source program manager should comprehensively check whether the compliance product is registered on the company’s open source portal without any abnormality or whether it is downloaded from outside the company.

2. External Inquiry Response Process

If you respond quickly and accurately to open source compliance inquiries from outside, you can greatly reduce the risk of going to a lawsuit. Therefore, you should follow the following process to respond to external open source compliance inquiries.

1. Acknowledge

The open source program manager immediately informs the requester that the inquiry has been received. In this case, inform the requester of the expected date of action. Since it’s important to know exactly what the requester’s intent is, ask for further clarification if the inquiry is unclear.

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

• Inquiries about whether open source has been used for certain products and services
• Request to provide source code under the GPL, LGPL license mentioned in the Written Offer
• Request for clarification of open source found in the product and disclosure of source code even though it is not specified in the Open Source Notice
• Request to provide missing files and build methods in the source code published due to GPL, LGPL, etc.
• Request for copyright notice

The open source program manager creates a Jira Issue for the received request and records all responses in detail.

2. Inform

The open source program manager informs the requester that it is faithfully performing open source compliance and is investigating the requester’s inquiry. Notify the requestor whenever possible internal investigation progress is updated.

3. Investigate

The open source program manager conducts an internal investigation of the request. Check the BOM and documented review history to ensure that the compliance process has been properly implemented for the version of the product in question. Seek advice from the Legal Department if necessary.

If a specific development team needs confirmation, the open source program manager should ask the development team to investigate. The development team requested to be investigated immediately identifies any issues with the compliance artifacts and reports the findings to the open source program manager.

4. Report

The open source program manager should complete the internal investigation within the due date for action and inform the requester of the results.

• If the requester’s complaint was a misunderstanding rather than a compliance issue, notify the requester without further action and terminate the procedure.
• If any compliance issues are discovered, inform the requester of the exact method and timing to fulfill the obligations of the applicable open source license.

5. Rectify

If an internal investigation reveals an actual compliance issue, the development team should take all necessary steps to resolve the compliance issue.

6. Report

After resolving the issue, notify the requester immediately and provide the best way to confirm that the issue has been resolved.

7. Improve

If there are compliance issues, conduct an OSRB meeting to review the case, find out how the issue arose, and improve the process so that the issue does not recur.