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

• 1: 0. Understanding OpenChain
• 2: 1. Organization
• 3: 2. Policy
• 4: 3. Process
• 5: 4. Tools
• 6: 5. Training
• 7: 6. Conformance Declaration

1 - 0. Understanding OpenChain

1. What Is the OpenChain Project?

Today, software continues to grow in scale and complexity. Developing a single piece of software can involve not only software built in-house but also a variety of software spanning the software supply chain, including open source, third-party software, and vendor SDKs.

If even a single organization within this complex software supply chain fails to comply with open source license obligations or fails to provide accurate information about its open source use, the enterprise distributing the final software has no choice but to fail at meeting its own open source license obligations. This can result in lawsuits and even the suspension of product sales.

In December 2009, a lawsuit arose involving the open source project Busybox. Busybox is open source licensed under GPL-2.0 that is widely used in embedded systems, and 14 companies, including two South Korean companies, became subject to the lawsuit. A notable point in this case is that among the defendants were companies that were sued despite not developing the product themselves but only distributing it.

In such a complex software supply chain environment, it is very difficult for any single enterprise, no matter how excellent its processes are, to achieve perfect open source compliance on its own. Ultimately, for an enterprise to properly implement open source compliance, every member of the software supply chain must comply with license obligations and provide accurate open source information. This kind of trust must be built across the entire supply chain.

The OpenChain project, part of the Linux Foundation, was founded on the belief that concisely and consistently defining the core requirements enterprises must meet for open source compliance, and having everyone comply with them, can build trust in open source licensing across the entire software supply chain.

At an open source conference in Europe in 2016, Dave Marr, an open source attorney at Qualcomm, emphasized exactly this point. To raise one enterprise’s level of open source compliance, the compliance level of every member across the software supply chain must be raised. He further suggested that, to achieve this, leading enterprises that already have a solid understanding of open source and have established policies and processes should openly share their assets and know-how so that anyone could reference them. Conference attendees agreed with the idea that “open source compliance is not an area where enterprises can differentiate their profits. Enterprises want an appropriate level of risk management while investing minimal resources. That is why the more enterprises share their assets with one another, the more everyone can achieve compliance together with fewer resources.” This is how the OpenChain project (then called a Work Group) began, with numerous global enterprises participating, including Qualcomm, Siemens, Wind River, ARM, and Adobe.

The OpenChain project provides three main things to help enterprises more easily achieve open source compliance.

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

Let’s look at how enterprises can make use of each of these, one by one.

2. The OpenChain Specification and ISO/IEC Standards

The OpenChain Specification is a 10-page document that defines the core requirements for open source compliance. Version 1.0 of the OpenChain Specification was published in 2016. The OpenChain Specification is designed to be suitable for any enterprise, regardless of size or industry.

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

1. Program Establishment
2. Defining and Supporting Related Tasks
3. Reviewing and Approving Open Source Content
4. Creating and Delivering Compliance Artifacts
5. Understanding Open Source Community Engagement
6. Conformance to Specification Requirements

For an enterprise just starting out with open source compliance, a good strategy is to raise its maturity level by fulfilling these OpenChain Specification requirements one by one.

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

The OpenChain Specification, which had served as a de facto standard for the previous four years, was converted into the formal international standard ISO/IEC 5230:2020 — the first international standard to define open source compliance and process management. As a result, interest among global IT enterprises in complying with ISO/IEC 5230 is rising, and more enterprises are expected to require ISO/IEC 5230 compliance from their suppliers across the software supply chain.

In 2023, ISO/IEC 18974, a new standard for open source security assurance, was published. This standard is based on the OpenChain Security Assurance Specification and defines the core requirements for managing known security vulnerabilities in open source software. ISO/IEC 18974 covers the following key areas:

1. Identifying the core areas requiring security processes
2. How to assign roles and responsibilities
3. How to ensure the sustainability of the process

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

Together, these two standards support organizations in effectively managing both license compliance and security assurance for open source software. Where ISO/IEC 5230 focuses on license compliance, ISO/IEC 18974 focuses on vulnerability management, making the two mutually complementary.

3. How to Certify to the ISO/IEC Standards

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

The image below lists the item numbers required by ISO/IEC 5230. An enterprise that fulfills all these items can be recognized as having built a transparent and trustworthy open source governance system within the software supply chain.

The OpenChain project proposes three certification methods:

• Self-Certification
• Independent Assessment
• Third-Party Certification

Let’s look at each method.

(1) Self-Certification

Self-certification is the method most recommended by the OpenChain project and has the advantage of incurring no cost. The OpenChain Project provides an ISO/IEC 5230 self-certification website so that enterprises can verify on their own whether they comply with the OpenChain Specification. An enterprise’s open source manager can sign up on this website and begin the online self-certification process. Self-certification proceeds by answering Yes/No questions, as shown below.

If an enterprise has built its open source compliance system well enough to answer Yes to every question in the OpenChain self-certification, it can submit the result on the website (Conforming Submission). After a brief question-and-answer verification process with the Linux Foundation, it can then declare ISO/IEC 5230 certification.

By making this certification declaration, an enterprise is recognized within the global software supply chain as having an open source program that conforms to ISO/IEC 5230.

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

In addition, going through the self-certification process lets an enterprise determine what is lacking and what additional activities are needed. This guide explains, by major component — organization, policy, process, and so on — how to meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

For an enterprise that lacks the capability to make improvements on its own using only this guide, the independent assessment method can be considered.

(2) Independent Assessment

In an independent assessment, an independent organization outside the enterprise inspects and evaluates the enterprise’s open source compliance and security assurance status from an impartial standpoint. What distinguishes independent assessment is that it does not stop at producing an assessment report, but also provides consulting to address the gaps identified. (It does not, however, issue an official certificate.)

By receiving impartial assessment and consulting from an independent organization, an enterprise can raise its compliance and security assurance level, and through the iterative process of undergoing independent assessment again, refine its policies and build out its processes.

Eventually, the enterprise reaches a level where it can obtain ISO/IEC 5230 and ISO/IEC 18974 certification, at which point it can move into the process of obtaining self-certification or third-party certification. In this way, independent assessment provides evaluation and consulting to raise an enterprise’s open source compliance and security assurance level, supporting the enterprise in holding a conformant ISO/IEC 5230 and ISO/IEC 18974 program and obtaining certification.

Companies that provide independent assessment include AlektoMetis and Source Code Control, among others.

In South Korea, the Conformance Group, a subgroup of the OpenChain Korea Work Group, is a community where enterprises discuss and share methods for achieving ISO/IEC 5230 and ISO/IEC 18974 conformance on their own. Anyone who is a member of the OpenChain Korea Work Group can participate and get help.

(3) Third-Party Certification

An enterprise wishing to demonstrate a more reliable and transparent level of open source compliance and security assurance to buyers in the software supply chain can obtain a certificate from a third-party certification body and use it for promotional purposes. In addition, some buyers who demand stronger assurance of open source compliance and security may come to require third-party certification from their suppliers.

As of 2024, OpenChain’s authorized third-party certification bodies are ORCRO, PWC, TÜV SÜD, Synopsys, and Bureau Veritas.

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

As of 2024, buyers or organizations that mandatorily require third-party certification are not yet common. However, some experts in the European automotive industry predict that it will not be long before ISO/IEC 5230 and ISO/IEC 18974 become mandatory for automotive software suppliers, much like ASPICE (Automotive SPICE, an international standard process model for automotive software development).

In addition, detailed self-certification methods can be found in the following slides:

• OpenChain Korea 9th Meeting - How to Self Certify

4. OpenChain Resources

The OpenChain project provides a variety of documentation resources that enterprises need to build a compliance program, including policy document templates and training materials. These materials are designed to support conformance with the OpenChain Specification and general open source compliance activities, and are provided under the CC-0 license so that anyone can use them freely.

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

The OpenChain project also provides additional resources by running various webinars and study groups:

1. Webinars: The OpenChain project regularly hosts webinars to share the latest trends and best practices in open source compliance and security. These webinars can be found on the OpenChain website, where recordings are also available.

2. Training Materials: The OpenChain project provides a comprehensive training curriculum to help enterprises develop internal training programs. This material covers a range of topics, from the basic concepts of open source software to license compliance and security assurance.

By making use of these various resources, an enterprise can build and maintain a strong open source program that conforms to the ISO/IEC 5230 and ISO/IEC 18974 standards.

5. Trends in ISO/IEC Standard Adoption

Adoption of the ISO/IEC 5230 and ISO/IEC 18974 standards is showing a gradually expanding trend across the global software supply chain.

In early 2021, news emerged that a German automaker had begun requiring its parts suppliers to have an ISO/IEC 5230 compliance plan. In response, a European open source professor predicted that “it is clear that buyers in the software supply chain will increasingly require suppliers to comply with ISO/IEC 5230,” adding that “in the automotive industry, it will come to occupy the same position as ASPICE.”

Reflecting this outlook, in May 2021, Scania, part of the Volkswagen Group, incorporated a requirement for ISO/IEC 5230 compliance into its own corporate standard (STD 4589) that suppliers must follow.

Also, in July 2021, Bosch, an automotive and industrial technology company, declared that all of its group companies would have an ISO/IEC 5230-compliant program by the end of the year. The industry outlook is that it is only a matter of time before every automaker, and other industries as well, begin requiring ISO/IEC 5230 within their software supply chains.

In 2023, ISO/IEC 18974, a new standard for open source security assurance, was published. This standard defines the core requirements for managing known security vulnerabilities in open source software. Together with ISO/IEC 5230, ISO/IEC 18974 supports organizations in effectively managing both license compliance and security assurance for open source software.

As of 2024, this trend is accelerating further. For example, KT announced in October 2024 that it had obtained ISO/IEC 18974 certification. This shows that South Korean enterprises, too, are actively adopting international standards for open source security management.

The activities of the OpenChain Korea Work Group are also becoming more active. At its 22nd regular meeting held in June 2024, discussions covered the state of readiness for the ISO/IEC 18974 open source security standard and SBOM-based software supply chain management guidelines. This shows that South Korean enterprises are actively embracing the ISO/IEC 5230 and ISO/IEC 18974 standards.

This trend is expected to continue. As the complexity of the software supply chain increases and security threats grow, the importance of international standards such as ISO/IEC 5230 and ISO/IEC 18974 is likely to grow further. By complying with these standards, enterprises will be able to increase transparency in their open source use and effectively manage security risk.

2 - 1. Organization

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

The following should be considered when forming the organization:

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

1. Defining the Roles and Responsibilities of the Organization

The ISO standards commonly require a document that describes the roles and responsibilities of the various participants in the program, as follows.

Open Source Program Manager

To build an open source management system, an enterprise first needs someone responsible for leading and carrying it out. This person is called by titles such as Open Source Program Manager or Open Source Compliance Officer; this guide uses the term Open Source Program Manager.

The Open Source Program Manager is in charge of the enterprise’s Open Source Program Office (OSPO). Open Source Program Office refers to the organization responsible for an enterprise’s open source management, and is also referred to by the term Open Source Secretariat.

A person with the following competencies can be considered well-suited for the role of Open Source Program Manager.

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

It is best for the Open Source Program Manager to be guaranteed the ability to perform the role full-time whenever possible.

Global ICT enterprises are making efforts to hire capable Open Source Program Managers of this kind. Various job postings can be found at the following site: https://github.com/todogroup/job-descriptions

Documenting Roles and Responsibilities

An enterprise must define each role needed for the OSPO and determine what responsibilities to assign to it.

In a small enterprise, it is possible for the Open Source Program Manager alone to perform all the roles. Depending on the size of the enterprise, an IT staff member to operate open source tools may also be needed, and a legal role may be required to provide specialized legal counsel.

In general, the following roles are needed to build an enterprise’s open source management system.

• Legal
• IT
• Security
• Developer Relations

To this end, the roles and responsibilities that make up the OSPO must be documented as follows.

2. Defining Required Competencies

Once each role and its responsibilities have been defined, the essential competencies that the person performing that role must have need to be identified.

The ISO standards commonly require a document that describes the competencies needed for each role, as follows.

This is because it is necessary to assess whether the person assigned to each role has the competencies to perform it, and to provide training if needed.

To this end, an enterprise must document the competencies needed for each role, as follows.

3. Assigning Owners

The Open Source Program Manager consults with the relevant departments to assign an owner for each role and document this. To do so, the goals and direction for building the open source compliance system must be reported to the top decision-maker, such as the CEO, in order to obtain the necessary support.

The organization and owners related to open source do not necessarily need to work on open source full-time. It is also possible to form a virtual organization in the form of an OSRB (Open Source Review Board) to carry out the necessary roles.

The ISO standards commonly require a document naming the persons, groups, or functions responsible for each role in the program, as follows.

To this end, an enterprise must document the names of the persons, groups, or functions responsible for each role in the program, as follows.

A documented sample of roles, responsibilities, required competencies, and owner assignments can be found on the next page. [Appendix 1] Open Source Policy (Sample) - Appendix 1. Assigned Owners

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

4. Summary

A documented sample of roles, responsibilities, required competencies, and owner assignments can be found in the open source policy template document: Appendix 1. Assigned Owners

An enterprise can refer to this to organize its open source management structure to fit its own situation.

By designating and documenting the OSPO organization in this way, an enterprise satisfies the requirements marked in red below among the ISO standard specifications.

In fact, more important than the documentation itself is appointing an owner who will faithfully carry out the actual work, and supporting that owner in acquiring the necessary competencies.

Taking part in systematic training, such as the Open Source License Professional Training offered by the Korea Copyright Commission or the NIPA Open Software Management Academy, is also very helpful.

The roles of the Open Source Program Manager and the Security role are becoming increasingly important. The Open Source Program Manager must also have a basic understanding of open source security assurance, and the Security role needs an understanding of new security requirements such as SBOM (Software Bill of Materials) management.

In addition, continuous learning and staying current with the latest trends are becoming important across every role. The open source ecosystem and related technologies and regulations are changing rapidly, so each owner must continuously update their knowledge in their own field. Participating in international communities such as OpenChain or the TODO Group, or attending domestic open source conferences, is also a good approach.

3 - 2. Policy

1. Documenting an Open Source Policy

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

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

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

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

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

2. What the Open Source Policy Must Cover

An open source policy must include the following core content:

(1) Open Source License Compliance Principles

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

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

(2) Open Source Security Assurance Principles

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

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

(3) Responding to Open Source Risk

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

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

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

1. Use of Open Source

When developing and delivering supplied software, the obligations required by each open source license must be observed. The activities carried out for this purpose are called open source license compliance.

For proper open source license compliance activities and security assurance, the software development/delivery organization must comply with the following and record and retain the entire process in an issue tracking system.

(1) Identify open source and review license obligations

When introducing open source into supplied software development, first identify what the open source license is, and review and confirm the obligations the license requires.

The company's [Open Source License Guide] includes a list of major open source licenses, and for each license, it explains the obligations required by each of the following distribution forms.

- Binary form
- Source form
- Strong/weak Copyleft
- SaaS-based delivery
- Whether modified
- Inclusion of open source requiring attribution, etc.

Software development/delivery organizations can refer to this guide when reviewing open source license obligations. If a review of an open source license not covered by this guide is needed, contact the open source program manager.

(2) Design with open source licenses in mind

Identify the coupling relationships of open source and design the software architecture so that the company's own code is not affected by open source licenses.

The company's [Open Source License Guide] explains the source code disclosure scope for each open source license and design methods for preventing disclosure of the company's own code.

(3) Produce open source compliance artifacts

The most basic element of open source license compliance activity is understanding the state of open source included in supplied software. This is precisely to properly satisfy the open source license requirements that are the core of open source license compliance. In other words, a set of compliance artifacts must be produced for the open source included in supplied software.

Open source compliance artifacts fall into two broad categories.

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

To compile, distribute, and archive these compliance artifacts, the following must be observed.

- Compile the open source notice or the source code package to be disclosed according to the conditions required by each license. For example, if a license requires that the full text of the license be enclosed, providing only a link is not sufficient.
- Store the compiled artifacts in a separate repository.
- If the source code to be disclosed is provided via a written offer, publish a download link so that the repository of compiled artifacts can be accessed externally.

The company's open source process can be used to issue the open source notice and compile the source code package to be disclosed.

(4) Generate the Software Bill of Materials (SBOM)

There must be a process to generate and maintain an SBOM (Software Bill of Materials) that includes the details of each open source software component making up the supplied software.

The company's open source process can use open source tools to generate and retain the SBOM.

(5) Compliance issue response procedure

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

1. Acknowledge receipt of the inquiry and specify a reasonable resolution time.
2. Confirm whether the issue content actually points to a real problem. (If not, inform the person who raised the issue that it is not a problem.)
3. If it is a real problem, set a priority and decide on an appropriate response plan.
4. Carry out the response and, if necessary, appropriately supplement the open source process.
5. Preserve the above using the issue tracking system.

(6) Open source security assurance management

A documented procedure for detecting and resolving known vulnerabilities in the open source software components of supplied software must be established and maintained. This procedure must include the following.

- Apply methods for discovering the existence of known vulnerabilities
- Perform a risk/impact assessment for each discovered vulnerability
- Take appropriate action such as contacting customers or upgrading software components when necessary

The following processes must also be built.

- Identify structural and technical threats to supplied software
- Apply continuous and repeated security testing
- Confirm that identified risks have been resolved before the release of supplied software
- Secure monitoring and response capability after supplied software is released to the market

A record must be kept of the known vulnerabilities and newly discovered vulnerabilities identified for each open source software component, and of the actions taken.

(4) Internal Responsibility Assignment Procedure

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

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

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

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

4. Roles, Responsibilities, and Competencies

To ensure the policy is effective, the following defines the roles and responsibilities and the competencies the person in charge of each role must have.

(2) Open Source Program Manager

- Defines the roles necessary for open source license compliance and designates the responsible organization and person in charge of each role. Consults with the OSRB when necessary.

(6) Security Lead

- Assigns responsibility for each task so that open source security assurance can be carried out successfully.

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

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

(5) Responding to Non-Compliant Cases

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

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

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

6. Use of Open Source

(5) Compliance and Security Assurance Issue Response Procedure

When a license compliance or security assurance issue is raised, the open source program manager performs the following procedure to respond promptly:

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

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

(6) Staffing and Budget Support

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

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

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

4. Roles, Responsibilities, and Competencies

The head of the organization responsible for each role designates a person in charge within the organization and allocates adequate time and budget for that person to fully perform the role.

- If the person in charge of each role is not adequately supported while performing the role, they must raise the issue with the open source program manager.
- The open source program manager discusses the resolution with the relevant organization head. If not resolved adequately, the open source program manager may request the OSRB to resolve the issue.
- The OSRB shares the issue with the head of the higher organization and requests resolution.

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

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

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

(7) Providing Expert Advice

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

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

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

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

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

4. Roles, Responsibilities, and Competencies

(4) Legal Lead

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

- Provides a reasonable way for program participants to inquire about open source license compliance issues.
- Provides advice on license and intellectual property issues, including conflicts caused by incompatible open source licenses.
- Reviews necessary legal matters, such as open source licenses and the CLA (Contributor License Agreement), when contributing to external open source projects.
- If an issue is contentious, requests advice from an outside law firm with attorneys specializing in open source.

(6) Security Lead

The security lead operates open source security vulnerability analysis tools and builds a system so that security vulnerability analysis is smoothly performed for all supplied software.

- Provides a reasonable way for program participants to inquire about known vulnerabilities or newly discovered vulnerabilities, and uses outside professional technical advice when necessary to resolve vulnerabilities.

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

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

(8) Specifying Scope of Application

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

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

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

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

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

2. Scope of Application

This policy applies to the following three parts.

1. It applies to all supplied software the company provides or distributes externally. However, using open source solely for internal use is not within the scope of this policy.
2. It applies when program participants contribute to external open source projects.
3. It applies when releasing internal code as open source.

The scope of application can change to match the company's business environment. In particular, to ensure continuous effectiveness, the open source program manager investigates at least once a month whether there is any supplied software distributed or serviced externally that is not covered by this policy. If even one such case is found, this is used as the basis for determining that the scope of application must be changed.

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

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

The open source program manager continuously documents the history of reviews, updates, and inspections performed at least once a month to improve the scope of application, using the [Jira](https://www.atlassian.com/software/jira) Issue Tracker.

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

(9) Responding to External Inquiries

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

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

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

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

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

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

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

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

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

9. Responding to External Inquiries

(1) Responsibility for Responding to External Inquiries

Responding to inquiries and requests about open source from external parties is the responsibility of the open source program manager.

- The open source program manager may assign all or part of the handling of an inquiry to an appropriate program participant within the company. Legal is consulted for handling when necessary.
- Any program participant who receives an external inquiry about open source must notify the open source program manager so a prompt response can be made.

(2) Publishing Contact Information

The open source program manager publicly provides the contact information of the person in charge so that external parties can make open source-related inquiries and requests.

- Provides contact email information in the open source notice.
- Provides email information on the open source website.
- Registers contact information in the Linux Foundation's Open Compliance Directory.

(3) External Inquiry Response Procedure

Responding to external open source inquiries promptly and accurately can greatly reduce the risk of claims or legal action. To this end, the company follows the external inquiry response procedure defined in the company's open source process for responding to external open source inquiries.

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

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

(10) Open Source Contribution

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

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

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

7. Open Source Contribution

The company encourages participation and contribution to external open source projects to create business value from open source. However, this process requires care to avoid unintended exposure of the company's intellectual property or infringement of third-party rights. To this end, when a program participant of the company contributes to an external open source project, the following must be observed.

(1) Review Request and Approval

From a copyright standpoint, an open source contribution grants the open source project the right to modify, use, and distribute the work. In some cases, copyright must even be assigned to the open source project. Generally, the copyright of a work created during employment is owned by the employer. In other words, a work created by a program participant is owned by the company. A program participant contributing a work to open source on their own judgment can cause unnecessary copyright infringement issues.

Therefore, if there is an open source project you wish to contribute to, follow the review request and approval procedure before the first contribution, in accordance with the open source contribution process.

However, in the following simple cases, since the risk of copyright infringement is not significant, a program participant may contribute based on their own judgment without going through the review procedure.

- A small code snippet of 10 lines or fewer
- Questions/answers on Stack Overflow
- Administrative activity on GitHub: creating issues, reviewing/approving pull requests, etc.

...

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

(11) SBOM Generation and Management

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

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

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

6. Use of Open Source

(4) Generate the Software Bill of Materials (SBOM)

There must be a process to generate and maintain an SBOM (Software Bill of Materials) that includes the details of each open source software component making up the supplied software.

The company's open source process can use open source tools to generate and retain the SBOM.

- The SBOM is generated using a standard format such as [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/).
- An SBOM is generated and managed for all supplied software.
- The SBOM is updated and version-controlled with each release of the supplied software.
- The accuracy of SBOM information is periodically verified.
- Preparations are made to share the SBOM with customers and regulators when necessary.

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

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

3. Summary

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

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

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

An open source policy must include the following core elements:

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

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

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

4 - 3. Process

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

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

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

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

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

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

1. Open Source Process

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

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

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

(1) Open Source Identification and Inspection

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

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

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

An example procedure for this is as follows:

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

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

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

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

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

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

(1) Open Source Identification

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

- While designing the software, it identifies the open source expected to be used and confirms the identified licenses.
- It checks the obligations for each open source license. License-specific obligations can be found in the company's open source license guide: https://sktelecom.github.io/guide/use/obligation/
- It designs the software taking into account the source code disclosure scope required by each open source license.

The Open Source Program Manager creates and publishes a guide on the obligations, restrictions, and rights of major open source licenses so that business units across the company can refer to it. To manage common open source license use cases, this guide must cover the following use cases:

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

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

When reviewing the adoption of new open source, the business unit first identifies the license. It checks the license obligations, restrictions, and rights according to the company's open source license guide. If the license is not covered by the company's open source license guide, it consults the Open Source Program Manager on whether adoption is possible and what precautions apply. It creates a Jira Ticket for the inquiry. 

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

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

The security officer provides a guide for the company's security assurance.

(2) Source Code Inspection

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

The IT staff performs the open source inspection using an open source analysis tool and generates an SBOM (Software Bill of Materials).

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

The security officer reviews the detected Known Vulnerabilities and provides response guidance to the business unit according to predefined risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and for Critical Risk, the business unit is guided to establish a remediation plan within one week.

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

(2) Issue Resolution

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

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

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

(3) Issue Resolution

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

It removes the open source causing the issue or replaces it with open source under a different license. For issues involving a Known Vulnerability or a Newly Discovered Vulnerability, it takes measures such as replacing the component with a version in which the vulnerability has been fixed.

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

(3) SBOM Identification, Review, and Retention

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

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

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

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

(4) Review

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

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

(5) Approval

The Open Source Program Manager gives final approval or rejection of whether the open source license compliance procedure was performed properly. In the case of rejection, it explains the reason to the business unit and proposes a way to remediate it.

(6) Registration

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

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

- The product (or service) name and version of the supplied software
- List of open source
  - Open source name / version
  - Open source license

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

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

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

(4) Creating License Compliance Artifacts

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

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

Compliance artifacts are broadly divided into two types:

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

   

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

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

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

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

(7) Notice

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

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

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

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

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

- The source code compiled to comply with obligations under licenses such as GPL and LGPL must match the source code that makes up the binary shipped in the product. In other words, building the compiled source code must produce the same result as the binary shipped in the product.

(8) Pre-Distribution Check

The business unit submits the following compliance artifacts demonstrating that open source license compliance activities were properly performed:

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

The Open Source Program Manager reviews the materials submitted by the business unit to confirm there are no issues.

(9) Distribution

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

The IT staff registers the compliance artifacts on the company's open source distribution site.

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

The software included in this product contains copyrighted software 
that is licensed under the GPL. A copy of that license is included 
in this document on page X. You may obtain the complete Corresponding 
Source code from us for a period of three years after our last shipment 
of this product, which will be no earlier than 2011-08- 01, by sending 
a money order or check for $5 to:

GPL Compliance Division
Our Company
Any Town, US 99999

Please write"source for product Y" in the memo line of your payment.
You may also find a copy of the source at http://www.example.com/sources/Y/.
This offer is valid to anyone in receipt of this information.

<Source: SFLC Guide to GPL Compliance>

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

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

(5) Security Vulnerability Inspection and Assessment

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

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

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

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

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

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

(2) Source Code Inspection

The security officer reviews the detected Known Vulnerabilities and provides response guidance to the business unit according to predefined risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and for Critical Risk, the business unit is guided to establish a remediation plan within one week.

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

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

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

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

2. Open Source Security Vulnerability Response Process

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

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

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

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

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

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

(1) Monitoring Known Vulnerabilities and Newly Discovered Vulnerabilities

(1) Monitoring

The IT staff builds and operates a system to monitor new security vulnerabilities. This system performs the following functions.

- It periodically collects newly published security vulnerabilities.
- If open source with a newly discovered Known Vulnerability is used in an already-released product/service, it sends a notification to the business unit responsible for that product/service. From notification through review, action, and resolution, everything is documented and recorded using the Jira Issue Tracker.

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

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

(2) Vulnerability Assessment and Response

(2) Initial Response

The security officer provides response guidance to the business unit according to predefined risk classification criteria. Risk is classified by CVSS (Common Vulnerability Scoring System) score, and for Critical Risk, the business unit is guided to establish a remediation plan within one week.

If a new security vulnerability is discovered in a previously released product/service, the business unit establishes a remediation plan according to the response guidance provided by the security officer.

If there are customers under warranty, the business unit notifies them of the identified Known Vulnerability by email or other means, as necessary, according to the risk level.

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

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

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

(3) Applying Security Testing

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

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

(4) Vulnerability Resolution and Patch Management

(3) Issue Resolution

The business unit resolves the security vulnerability issue according to the established remediation plan, by methods such as removing the problematic open source or replacing it with a patched version. Once all identified issues are resolved, it requests a re-review.

(4) Review

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

(5) Approval

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

(6) Registration

The IT staff registers the SBOM, with the open source security vulnerability resolved, in the system.

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

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

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

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

(5) Customer Notification

(7) Notice

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

The business unit replaces the open source notice included with the product distribution.

The IT staff registers the revised open source notice on the company's open source distribution site.

(8) Distribution

The business unit redistributes the version of the software in which the open source security vulnerability has been resolved.

The security officer identifies whether there is risk information that needs to be disclosed to third parties, and if so, delivers it to the IT staff.

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

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

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

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

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

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

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

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

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

3. External Inquiry Response Process

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

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

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

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

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

(1) Receipt Notification

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

Major inquiries and requests include:

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

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

(2) Investigation Notification

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

(3) Internal Investigation

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

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

(4) Reporting to the Requester

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

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

(5) Remediation / Notification

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

(6) Resolution Notification

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

(7) Process Improvement

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

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

4. Open Source Contribution Process

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

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

(1) Establishing and Communicating the Contribution Policy

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

(1) Establishing and Communicating the Contribution Policy
- A documented policy governing contributions to open source projects must be established.
- This policy must be communicated within the organization.
- There must be a process for enforcing the policy.

The Open Source Program Manager must do the following:
- Draft a documented open source contribution policy.
- Establish a documented procedure to ensure that all program participants are aware of the open source contribution policy (e.g., through training, an internal wiki, or other effective means of communication).

(2) Contribution Review and Approval Procedure

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

(2) Contribution Review and Approval Procedure

A documented procedure governing open source contributions must be established. This procedure must include the following:
- Confirm the origin and license of the code to be contributed.
- Review whether there is a right to contribute the code.
- Review the license and contribution policy of the project to which the contribution is directed.
- If necessary, obtain a legal team review.
- Define an approval procedure for the contribution.
- Specify how an approved contribution is to be submitted.

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

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

The open source contribution procedure published by SK telecom is a good example:

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

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

5. Keeping the Process Current

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

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

(1) Periodic Process Review

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

The OSRB (Open Source Review Board) is a body composed of the Open Source Program Manager and the heads of related organizations, such as the legal team, patent team, development team, and infrastructure team, for the company's open source management.

The OSRB reviews the policy and process annually on a regular basis and improves them. All improvement processes are documented and recorded.

(2) Identifying and Implementing Improvements

The following activities are carried out to improve the process:

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

(3) Documenting Process Updates

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

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

These documented records can be managed using tools such as Jira or Confluence.

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

6. Summary

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

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

1. Establishing an open source license compliance framework

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

2. Strengthening open source security assurance

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

3. Effective response to external inquiries

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

4. Systematizing open source contribution activities

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

5. Continuous process improvement

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

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

5 - 4. Tools

1. Source Code Scanning Tools

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

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

(1) FOSSology

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

Key features:

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

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

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

(2) SCANOSS

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

Key features:

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

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

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

2. Dependency Analysis Tools

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

(1) OSS Review Toolkit

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

Key features of the Analyzer:

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

(2) FOSSLight Dependency Scanner

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

Key features:

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

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

3. Open Source Governance / SBOM Management Tools

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

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

(1) SW360

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

Key features:

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

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

(2) FOSSLight

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

Key features:

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

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

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

4. Open Source Security Vulnerability Management Tools

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

(1) OWASP Dependency-Check

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

Key features:

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

(2) SW360

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

Key features:

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

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

(3) FOSSLight

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

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

5. Open Source Compliance Artifact Generation Tools

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

(1) onot

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

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

(2) FOSSLight

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

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

6. Archiving Open Source Compliance Artifacts

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

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

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

(1) GitHub Pages

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

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

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

Using GitHub Pages has the following benefits:

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

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

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

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

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

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

(1) Jenkins Plugins

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

Major Jenkins plugins:

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

Example Jenkins pipeline:

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

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

(2) GitLab CI/CD Pipeline

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

Example GitLab CI/CD pipeline:

stages:
  - scan
  - analyze
  - report

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

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

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

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

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

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

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

8. Summary

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

Using these tools brings the following benefits:

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

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

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

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

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

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

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

6 - 5. Training

1. Training

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

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

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

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

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

5. Training and Assessment

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

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

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

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

1. Purpose

(1) Purpose of the Policy 

This policy provides the following principles for the entire organization involved in software development, service, and distribution at OOO Corporation (hereinafter "the Company") to properly use open source software (hereinafter "open source").

1. Principles of open source compliance / security assurance
2. Principles for contributing to external open source projects
3. Principles for releasing internal projects as open source

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

Every member of the Company can check the open source policy at the following link on the internal wiki: [internal_link]

(2) Consequences of Non-Compliance
Failure to comply with this policy may result in the following situations.

- The Company may receive external requests for open source license compliance.
- The Company may be forced to unintentionally disclose source code it developed.
- The Company may be sued by open source copyright holders.
- The Company may be fined for copyright infringement or breach of contract, or ordered to halt product sales.
- The Company's reputation may be damaged.
- The Company may breach a contract with a supplier and be subject to a claim for damages.
- The Company may be exposed to a serious security incident, causing substantial harm to the Company.

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

(3) How Members Can Contribute

Every member of the Company can contribute to the effectiveness of this policy and to improving the Company's compliance level by understanding the rationale and content of this policy and faithfully carrying out the required activities.

Assessment is explained in more detail again below.

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

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

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

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

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

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

2. Assessment

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

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

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

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

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

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

4. Roles, Responsibilities, and Competencies

To ensure the effectiveness of this policy, the roles and responsibilities and the competencies required of the owner of each role are defined as follows.

The responsible organization/owner and the required competency level for each role are defined in [Appendix 1. Assigned Owners].


5. Training and Assessment

All members holding a role defined in Chapter 4 must complete the advanced open source training course offered on the [Learning Portal]. This ensures familiarity with the open source policy, the related training policy, and how to look it up. 

Training records and assessment results are retained on the [Learning Portal] for at least 3 years.

3. Open Source License Guide

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

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

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

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

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

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

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

4. Awareness-Raising Activities

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

(1) Regular Newsletter Publication

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

(2) Workshops and Seminars

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

(3) Open Source Contribution Encouragement Program

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

5. Measuring and Improving Training Effectiveness

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

(1) Training Program Evaluation Metrics

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

(2) Feedback Collection and Analysis

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

(3) Establishing a Continuous Improvement Plan

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

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

6. Summary

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

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

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

7 - 6. Conformance Declaration

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

(1) Confirming That Standard Requirements Are Met

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

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

The open source program of [Company Name] meets all the requirements of ISO/IEC 5230:2020 (open source license compliance) and ISO/IEC 18974 (open source security assurance). 

This can be confirmed through the following documents and processes:
1. Open source policy document
2. Open source process document
3. Open source training and assessment records
4. SBOM (Software Bill of Materials) management system
5. Open source license compliance artifact generation and retention system
6. Open source security vulnerability management system
7. External inquiry response process records

[Date]
[Signature of Open Source Program Manager]

(2) Declaring Continued Conformance Assurance

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

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

[Company Name] guarantees that it will maintain a state of meeting all requirements for at least 18 months after obtaining conformance certification for ISO/IEC 5230:2020 (open source license compliance) and ISO/IEC 18974 (open source security assurance).

To this end, the following activities are carried out:
1. Conduct an internal audit at least every 6 months to verify that all requirements continue to be met
2. Obtain an external expert review at least once a year to assess the program's effectiveness
3. Provide ongoing training and competency assessment for program participants
4. Regularly review and update the open source policy and processes
5. Monitor and respond to changes in new technology trends and legal requirements

[Date]
[Signature of Open Source Program Manager]

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