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

• 1: 0. Exploring OpenChain
• 2: 1. Organization
• 3: 2. Policy
• 4: 3. Process
• 5: 4. Tools
• 6: 5. Education
• 7: 6. Conformance
• 8: 7. AI Compliance

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

The three certification methods differ in cost, duration, deliverables, and market trust as follows.

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 review by the Linux Foundation, the company can then declare ISO/IEC 5230 conformance. The typical processing flow is (1) checklist completion → (2) Conforming Submission → (3) Linux Foundation Review (5-10 business days) → (4) Listing, with the entire process usually taking 1-2 weeks.

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 May 2026, the OpenChain accredited third-party certification bodies include ORCRO, PWC, TÜV SÜD, Black Duck (spun off from Synopsys SIG in 2024), and Bureau Veritas, among others. For the latest list, see the OpenChain official partner page.

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.

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.

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. To minimize gaps, query multiple vulnerability databases in parallel: NVD (NIST, the standard CVE database), OSV.dev (Google, covering package ecosystems such as npm, PyPI, Go, and Maven), GitHub Security Advisories (GHSA), and KISA KNVD (Korea Internet & Security Agency).
- Evaluate severity using the CVSS (Common Vulnerability Scoring System) v3.1 or v4.0 score. Use the EPSS (Exploit Prediction Scoring System) score and inclusion in the CISA KEV (Known Exploited Vulnerabilities) catalog as supplementary indicators to reflect real-world exploitability.
- 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.
- When notifying supply chain partners and customers of whether they are affected, use the VEX (Vulnerability Exploitability eXchange) standard format (CSAF 2.0 or CycloneDX VEX). VEX expresses the impact status with the following four status values: `not_affected` (justification required), `affected`, `fixed`, and `under_investigation`.
- Monitor the announcement of new open source security vulnerabilities and respond quickly when vulnerabilities occur. Open source vulnerability monitoring can be performed through the vulnerability databases mentioned above, 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.

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 marking rules refer to the company's internal guide, and the [SPDX-License-Identifier](https://spdx.dev/) or [REUSE-3.0](https://reuse.software/) specification is generally recommended.

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 the CVSS (Common Vulnerability Scoring System) v3.1 or v4.0 Score, and Critical Risk is guided to establish a plan that can be addressed within 1 week.

When detecting and evaluating known vulnerabilities, query multiple public vulnerability databases in parallel to minimize gaps: NVD (NIST, the standard CVE database), OSV.dev (Google, covering package ecosystems such as npm, PyPI, Go, and Maven), GitHub Security Advisories (GHSA), and KISA KNVD (Korea Internet & Security Agency). When assessing severity, use the CVSS v3.1 or v4.0 score, and reflect real-world exploitability by also considering the EPSS (Exploit Prediction Scoring System) score and inclusion in the CISA KEV (Known Exploited Vulnerabilities) catalog as supplementary indicators.

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

(5) Vulnerability Inspection and Assessment

The security officer must establish a process for inspecting and assessing known vulnerabilities and newly discovered vulnerabilities in the open source software components of the supplied software. This process should include the following steps:

1. Search vulnerability databases: Query the following public vulnerability databases in parallel to minimize gaps.

   • National Vulnerability Database (NVD) — the standard CVE database
   • OSV.dev — operated by Google, integrating package ecosystems such as npm, PyPI, Go, and Maven
   • GitHub Security Advisories (GHSA) — package-ecosystem-first disclosures
   • KISA KNVD — Korea Internet & Security Agency, Korean-language advisories

2. Use automated vulnerability scanning tools: Use tools such as OWASP Dependency-Check to scan the dependencies of the supplied software and identify known vulnerabilities.

3. Assess vulnerability severity: Use CVSS (Common Vulnerability Scoring System) v3.1 or v4.0 to assess the severity of the discovered vulnerabilities.

   • As supplementary indicators, also consider the EPSS (Exploit Prediction Scoring System) score and inclusion in the CISA KEV catalog to reflect real-world exploitability.

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

5. Establish a response plan: Establish a response plan for each vulnerability based on the severity and the results of the risk analysis.

(2) Source Code Inspection

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

| Risk | CVSS 2.0 | CVSS 3.1 / 4.0 | Recommended Remediation Timeline |
|---|:---:|:---:|:---:|
| Low | 0.0 - 3.9 | 0.0 - 3.9 | - |
| Medium | 4.0 - 6.9 | 4.0 - 6.9 | - |
| High | 7.0 - 10.0 | 7.0 - 8.9 | Within 4 weeks |
| Critical | - | 9.0 - 10.0 | Within 1 week |

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

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

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

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 from multiple public vulnerability databases (NVD, OSV.dev, GitHub Security Advisories, and KISA KNVD), and reinforces prioritization using the EPSS (Exploit Prediction Scoring System) score and inclusion in the CISA KEV (Known Exploited Vulnerabilities) catalog.
- 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 the CVSS (Common Vulnerability Scoring System) v3.1 or v4.0 score, 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. When notifying supply chain partners and customers of whether they are affected, use the VEX (Vulnerability Exploitability eXchange) standard format (CSAF 2.0 or CycloneDX VEX), which expresses the impact status with four status values: `not_affected` (justification required), `affected`, `fixed`, and `under_investigation`.

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

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

Many companies use these automated source code scanning tools in conjunction with manual reviews. Here, we introduce two major open source source code scanning tools.

(1) FOSSology

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

Key features:

• Source code scanning and license identification
• Extraction of license and copyright information
• Web-based user interface
• Support for large-scale codebase analysis

FOSSology can be used by companies free of charge and benefits from continuous improvement and support from the open source community.

For information on how to install and use FOSSology, please refer to the FOSSology guide.

(2) SCANOSS

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

Key features:

• Fast source code scanning and open source component identification
• License and vulnerability information
• Integration support through APIs
• SBOM (Software Bill of Materials) generation

SCANOSS provides both free and paid versions, and supports both cloud-based services and on-premises solutions.

For information on how to install and use SCANOSS, please refer to the SCANOSS guide.

By using these source code scanning tools, you can effectively identify and manage the open source components of the supplied software. However, rather than relying entirely on the results of the tools, professional review and judgment by program participants should be conducted together.

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 repository at build time to compose the supplied software. These dependency libraries are included in the supplied software but are not detected by source code scanning tools. Therefore, it is important to use tools for dependency analysis.

(1) OSS Review Toolkit

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

Key features of Analyzer:

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

(2) FOSSLight Dependency Scanner

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

Key features:

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

(3) cdxgen

cdxgen is an open source SBOM generation tool developed as part of the OWASP CycloneDX project. It supports various languages and package managers and can be easily integrated into CI/CD pipelines.

Key features:

• Support for 20+ languages and package ecosystems such as Java, JavaScript, Python, Go, and Rust
• Generation of SBOMs in CycloneDX and SPDX formats
• Support for container image and binary analysis
• CI/CD integration with GitHub Actions, Jenkins, etc.

For information on how to install and use cdxgen, please refer to the cdxgen guide.

(4) Syft

Syft is an open source SBOM generation tool developed by Anchore that analyzes container images and filesystems to generate SBOMs.

Key features:

• Analysis of various sources such as container images, filesystems, and archives
• Output in various SBOM formats such as SPDX, CycloneDX, and Syft JSON
• Vulnerability analysis through integration with Grype (vulnerability scanner)
• Support for Kubernetes and CI/CD pipeline integration

For information on how to install and use Syft, please refer to the Syft guide.

By using these dependency analysis tools, you can accurately identify the open source components included in the supplied software and generate SBOMs. This helps satisfy the requirements of ISO/IEC 5230 and ISO/IEC 18974.

3. Open Source Governance / SBOM Management Tools

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

SBOM can be managed with spreadsheet programs, but manual management becomes difficult when the number and versions of supplied software increase. Therefore, it is efficient to introduce automated open source tools.

(1) SW360

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

Key features:

• Project, component, and license management
• SBOM generation and management
• Vulnerability management
• License obligation tracking

For information on how to install and use SW360, see the SW360 guide.

(2) FOSSLight

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

Key features:

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

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

For information on how to install and use FOSSLight, please refer to the FOSSLight guide.

(3) Dependency-Track

Dependency-Track is an open source SBOM management and vulnerability analysis platform managed by OWASP. It collects and manages SBOMs and continuously monitors the vulnerabilities of each component.

Key features:

• Collection and management of SBOMs in CycloneDX and SPDX formats
• Automatic vulnerability detection through integration with vulnerability databases such as NVD and OSV
• Per-project component and license status dashboard
• REST API and CI/CD pipeline integration

For information on how to install and use Dependency-Track, please refer to the Dependency-Track guide.

Quick start: To build a license policy and vulnerability monitoring environment from scratch by generating an SBOM with cdxgen and uploading it to Dependency-Track, please refer to Building an Open Source Management Automation Environment: cdxgen + Dependency-Track.

By using these tools, companies can effectively perform open source governance and manage SBOMs, satisfying the requirements of ISO/IEC 5230 and ISO/IEC 18974.

4. Open Source Vulnerability Management Tools

To effectively manage known vulnerabilities or newly discovered vulnerabilities included in the supplied software, companies need to build an automated tool environment. Here, we introduce four major open source vulnerability management tools.

(1) OWASP Dependency-Check

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

Key features:

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

(2) SW360

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

Key features:

• Automatic vulnerability checking for registered Releases
• Periodic collection of CVE information (scheduled every 24 hours)
• Per-project security vulnerability lookup
• Tracking the impact of newly disclosed vulnerabilities on existing products

For information on how to manage security vulnerabilities with SW360, please refer to the SW360 guide.

(3) FOSSLight

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

(4) OSV-SCALIBR

OSV-SCALIBR is an open source software composition analysis (SCA) library developed by Google. It extracts open source components from filesystems and container images and detects vulnerabilities by integrating with the OSV (Open Source Vulnerabilities) database.

Key features:

• Package extraction from filesystems, container images, and archives
• OSV database-based vulnerability detection
• Support for major package ecosystems such as Python, Go, Java, and npm
• Can be integrated into existing tools as a library

For information on how to install and use OSV-SCALIBR, please refer to the OSV-SCALIBR guide.

By using these tools, companies can effectively manage open source security vulnerabilities while satisfying the requirements of ISO/IEC 18974.

5. Open Source Compliance Artifact Generation Tools

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 supplied software. Open source notices can be created manually, but it is efficient to use a tool that generates them automatically.

(1) onot

SK Telecom has released an open source notice automatic generation tool used internally as open source under the name onot. Kakao also 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.

For information on how to install and use onot, please refer to the onot guide.

(2) FOSSLight

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

By using these tools, you can automate and standardize the open source notice generation process, improving the efficiency and accuracy of the open source license compliance process. It also helps satisfy the requirements of ISO/IEC 5230 and ISO/IEC 18974.

6. Open Source Compliance Artifact Storage

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

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

To this end, companies should build a system that can safely store open source compliance artifacts and disclose them externally when necessary.

(1) GitHub Pages

GitHub Pages is a service that allows you to host a website directly from a GitHub repository. You can use it to store and disclose open source compliance artifacts.

The method for storing open source compliance artifacts using GitHub Pages is as follows:

1. Create a dedicated repository on GitHub
2. Upload open source notices and source code to the repository
3. Enable the website through GitHub Pages settings
4. Configure it to be accessible externally via a public URL

Using GitHub Pages provides the following benefits:

• Free to use
• Version control features
• High availability and stability
• Easy updates and management

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.

By storing and disclosing open source compliance artifacts using GitHub Pages, companies can effectively fulfill open source license obligations and improve transparency.

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

Integrating open source compliance and security assurance activities into the continuous integration/deployment (CI/CD) pipeline enables automated checking and management throughout the development process. This allows open source-related issues to be discovered and resolved early.

(1) Jenkins Plugins

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

Major Jenkins plugins:

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

Example Jenkins pipeline (conceptual diagram — when applying in practice, replace with verified step names and parameters by referring to each plugin’s official documentation):

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Dependency Scan') {
            steps {
                dependencyCheck additionalArguments: '', odcInstallation: 'Default'
            }
        }
        stage('License Scan') {
            steps {
                fossology()
            }
        }
        stage('SBOM Update') {
            steps {
                sw360UpdateProject()
            }
        }
    }
    post {
        always {
            dependencyCheckPublisher pattern: '**/dependency-check-report.xml'
        }
    }
}

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

(2) GitLab CI/CD Pipeline

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

Example GitLab CI/CD pipeline (conceptual diagram — when applying in practice, replace with verified commands by referring to official images and CLI commands):

stages:
  - scan
  - analyze
  - report

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

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

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

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

license_report:
  stage: report
  script:
    - generate_license_report
  artifacts:
    reports:
      license_scanning: reports/license-scan-report.json

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

By integrating these processes into the CI/CD pipeline, open source compliance and security assurance activities can be automated and seamlessly integrated into the development workflow. This helps effectively satisfy the requirements of ISO/IEC 5230 and ISO/IEC 18974.

8. Summary

If you build up to this tool environment, you can meet the major requirements of the ISO/IEC 5230 and ISO/IEC 18974 standard specifications.

By using these tools, you can obtain the following benefits:

1. Through source code scanning and dependency analysis tools, you can accurately identify the open source included in the supplied software and determine its licenses.

2. Using open source governance and SBOM management tools, you can systematically manage and track the open source components of the supplied software.

3. Through open source vulnerability management tools, you can continuously monitor and respond to known vulnerabilities or newly discovered vulnerabilities.

4. Using open source compliance artifact generation and storage tools, you can efficiently generate and manage the documents needed to comply with license obligations.

5. Through integration with CI/CD tools, you can integrate and automate the open source management process within the development workflow.

By building this tool environment, companies can systematically and efficiently perform open source license compliance and security assurance activities, receiving significant help in satisfying the requirements of ISO/IEC 5230 and ISO/IEC 18974.

By effectively using open source management tools, companies can minimize the legal risks associated with open source use, respond quickly to security vulnerabilities, and build a transparent and trustworthy software supply chain. This will ultimately lead to improved competitiveness and increased customer trust.

ISO/IEC 5230 / 18974 Compliance Guide — Clauses related to this section:

• §3.4.1 Compliance Artifacts — Artifact retention period and version control procedures
• §4.1.5 Implementing Standard Practices — How to use SCA, SAST, and DAST tools
• §4.3.2 Security Assurance — SBOM-based vulnerability detection and recording

Additional considerations when using AI:

• §7. AI Compliance — AI coding tool usage policy and automatic CI/CD blocking
• AI SBOM Guide — Generating AI SBOMs with cdxgen, Syft, and Dependency-Track (Korean)
• §6.3 OpenSSF Model Signing — Model weight signing tools (Korean)

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.

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 §4.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. Confirm that the program has met all the requirements of ISO/IEC 5230 and ISO/IEC 18974 during the past 18 months since obtaining conformance validation (retrospective past-fact confirmation, not a future commitment)

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.

8 - 7. AI Compliance

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

ISO/IEC 42001 (AI management system) covers AI governance as a whole, and some of its clauses directly intersect with open source management. This section organizes those intersections from a practical perspective.

1. Three Areas Where Open Source Is Used in AI Systems

AI System
  ├── 1. AI Frameworks · Libraries
  │       (PyTorch, TensorFlow, Hugging Face Transformers, LangChain, etc.)
  │       → Apply general open source license compliance
  │
  ├── 2. Pre-trained Models
  │       (Llama, Mistral, Falcon, BERT, etc.)
  │       → Custom per-model license verification required
  │
  └── 3. Training Datasets
          (Common Crawl, Wikipedia, CC-BY datasets, etc.)
          → Fulfill open data license obligations

Each area has points that differ from existing open source compliance processes, so refer to the following.

2. Open Source Management by AI System Area

(1) Managing AI Frameworks · Libraries

Open source frameworks and libraries used in AI development are subject to the same ISO/IEC 5230 open source management process as general software.

Major AI Framework Licenses

Checkpoints

(2) Managing Pre-trained Models

Pre-trained models often use custom licenses that differ from general open source libraries. In particular, they may include commercial use restrictions or obligations to disclose derivative models, so caution is required.

Major Open Source AI Model License Types (as of 2026-05)

The following table summarizes the licenses of leading industry models as of 2026-05. Based on OSAID 1.0 (Open Source AI Definition, OSI, 2024-10), it distinguishes between “open source AI models” (disclosure of all three elements: data, code, and weights) and “Open Weight models” (weights only disclosed).

Including Model Information in the AI SBOM

Build an AI SBOM that includes pre-trained models in the SBOM (Software Bill of Materials). The two de facto industry-standard formats are SPDX 3.0 AI Profile (strong on license/copyright expression) and CycloneDX 1.6 ML-BOM (rich in security/ethics/performance metadata), and organizations may adopt either one or both.

# Example AI SBOM model entry (based on SPDX 3.0 AI Profile)
- name: "meta-llama/Llama-3.1-8B"
  version: "3.1"
  license: "Llama Community License Agreement"
  primaryPurpose: "inference"
  hyperparameter:
    contextWindow: 131072
  modelCard: "https://huggingface.co/meta-llama/Llama-3.1-8B"

For the key field specifications of each standard (12 fields in SPDX 3.0 AI Profile / 4 modelCard areas in CycloneDX 1.6 ML-BOM) as well as authoring examples and tool usage, refer to the AI SBOM Guide (Korean).

(3) Managing Training Datasets

If a dataset used to train an AI model is subject to an open data or Creative Commons license, you must fulfill the conditions of that license.

Major Open Data License Types

Checkpoints

• Record training datasets and their licenses in the AI SBOM
• When using CC-BY-family data, specify the source in the model card or system documentation
• When CC-BY-SA data is used for training, consult the legal team on the license treatment of derivative models

3. Alignment with ISO/IEC 42001

If a company operates or is preparing an ISO/IEC 42001 AI management system, the following clauses connect directly to open source management.

Full guide on the open source cross-cutting requirements of ISO/IEC 42001: ISO/IEC 42001 Guide (Korean)

4. Leveraging AI Work Group Deliverables

The AI Work Group of the OpenChain Korea Work Group developed an AI SBOM compliance guide. This guide provides detailed instructions on how to document AI system components (models, datasets, frameworks) in SPDX 3.0 AI Profile or CycloneDX 1.6 ML-BOM format.

• AI Work Group activities and guide: Resources — AI Work Group

5. Compliance When Using AI Coding Tools

AI coding tools such as GitHub Copilot, Claude Code, Cursor, and Windsurf boost development productivity, but they also bring new risks from an open source compliance perspective.

(1) Key Risks of AI Coding Tools

• License contamination risk: AI learns from open source code and generates similar code. Copyleft code such as GPL may be inadvertently introduced.
• Recommendation of vulnerable packages: AI sometimes recommends older versions based on its training data, so packages containing known CVEs may be introduced.
• Missing dependency SBOM entries: Dependency packages suggested by AI are also subject to SBOM and vulnerability management.

(2) Four-Stage Strategy by Assurance Level

Stage 1 can be started immediately, but true automated blocking (hard block) takes effect from Stage 3 onward.

(3) Internalizing the Open Source Policy in AI Rule Files

If you specify the open source policy in advance in AI tool configuration files such as CLAUDE.md · .cursorrules · .clinerules, the AI will automatically be aware of the policy when generating code.

## Open Source Policy

### License Management
Always verify and specify the license when adding a new external package.

**Allowed licenses**: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC
**Caution licenses** (legal review required): LGPL, MPL
**Prohibited licenses** (may not be used without prior approval): GPL, AGPL, SSPL

### Security Management
- Do not use package versions with known CVE vulnerabilities
- Run a vulnerability audit after adding dependencies: `npm audit` / `pip-audit` / `trivy fs .`

### SBOM Management
- The SBOM must be updated when dependencies change
- Generation tools: syft, cdxgen, trivy

(4) Automated CI/CD Pipeline Blocking

Automatically verify with SCA (Software Composition Analysis) tools before merging a PR.

For how to configure CI/CD, refer to 4. Tools in this guide.

(5) Handling Copyright Attribution of AI-Generated Code

The copyright attribution of code generated by AI coding tools varies depending on whether human authorship is recognized. From a legal and compliance perspective, decide on and document the following five items.

5-1. Copyright Attribution Criteria for AI-Generated Code

US Copyright Office 2024 AI Guidance (official page): No copyright is granted to fully AI-generated works; for AI-assisted work, “human creative contribution” must be recognized for copyright to apply.

5-2. Leveraging Vendor IP Indemnification

The following AI coding tool vendors provide IP indemnification (intellectual property assurance) in their terms of use. Verify the terms before adoption and reflect them in internal policy.

• Microsoft Copilot Copyright Commitment — Covers defense and settlement costs for copyright infringement claims for Microsoft 365 Copilot · GitHub Copilot Business/Enterprise users
• OpenAI Copyright Shield — Provides the same coverage for ChatGPT Enterprise/Team users
• Anthropic Customer Protection — Provides IP coverage for Claude commercial customers
• Google Cloud Generative AI Indemnification — Covers users of GCP generative AI services such as Vertex AI

Each form of coverage applies only when its conditions are met (e.g., enabling content filtering, complying with the terms, etc.).

5-3. AI Use Disclosure and Labeling Obligations

EU AI Act §50 and the Korea AI Basic Act impose obligations to label AI-generated content. Indicate the following when disclosing content internally or externally.

• Internal code commit messages: Specify the AI tool used (e.g., feat: implement API handler (assisted by Claude Code))
• Externally released code: State AI usage disclosure in the README or CONTRIBUTING
• AI system outputs: Labeling per EU AI Act §50 (e.g., “AI-generated”, “AI-assisted”)

5-4. Documenting the AI Coding Tool Usage Policy

Specify the following items in your internal policy or AI coding tool guidelines.

## AI Coding Tool Usage Policy

### Permitted Tools
- Use only commercial tools that provide vendor IP indemnification
  (e.g., GitHub Copilot Business, ChatGPT Enterprise, Claude for Business)
- Personal free accounts (Copilot Individual, etc.) are prohibited for internal code

### Copyright Attribution Decisions
- When AI output is used as-is, state it in the commit message
- For AI draft + human modification, record the modification ratio and the rationale in the PR description
- For fully AI-generated code, review separate license labeling when releasing externally

### Blocking License Risk
- Verify whether AI-recommended code is similar to copyleft-licensed code such as GPL/AGPL
- Use matching detection tools such as Copilot duplicate detection
- Escalate to the legal team when in doubt

5-5. External Fact References

This subsection corresponds to the obligations of the US Copyright Office AI guidance · EU AI Act §50 · Korea AI Basic Act in §1 Global AI Regulation Matrix (Korean). When regulations change, check the matrix above first.

Checkpoints

• Is the AI coding tool usage policy documented?
• Are the criteria for determining copyright attribution of AI-generated code specified?
• Have the vendor IP indemnification conditions been reviewed and satisfied?
• Are the AI usage labeling obligations fulfilled for internal commits and external releases?

6. Summary

AI compliance is a natural extension of the existing ISO/IEC 5230 · 18974 open source management system. By identifying and fulfilling license obligations for the three areas of an AI system (frameworks · models · datasets), and applying the open source cross-cutting clauses of the ISO/IEC 42001 AI management system, a company can build a comprehensive compliance framework.

Through this section, a company can gain the following benefits:

1. Clarify license obligations for each AI system component
2. Secure external supply chain transparency by operating an AI SBOM
3. Block the risk of license contamination and vulnerability introduction when using AI coding tools
4. Pre-organize the open source area when preparing for ISO/IEC 42001 certification
5. Mechanically prevent policy violations through CI/CD pipeline automation

ISO/IEC 5230 / 18974 / 42001 Compliance Guide — Clauses related to this section:

• ISO/IEC 42001 Guide Home (Korean) — Overview of the entire AI management system
• §5.2 Policy (Korean) — Including OSS principles in the AI policy
• §6.1.2 AI Risk Assessment (Korean) — OSS risk assessment
• §7.5 Documentation (Korean) — AI SBOM
• §8.5 · §8.6 AI System · Data (Korean) — OSS management during operation
• §8.8 External AI Procurement (Korean) — AI supply chain verification
• AI SBOM Guide (Korean) — SPDX 3.0 AI Profile
• ISO/IEC 5230 Guide — §3.3.1 SBOM — General SBOM criteria