Templates

• 1: Open Source Policy
• 1.1: Appendix
• 2: Open Source Process

1 - Open Source Policy

1. Purpose and Scope

1.1 Purpose

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

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

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

1.2 Impact of Non-Compliance

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

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

1.3 How Program Participants Can Contribute

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

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

1.4 Scope

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

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

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

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

2. Definitions

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

2.1 Key Terms

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

3. Roles and Responsibilities

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

3.1 Role Descriptions

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

3.2 Staffing and Funding

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

3.3 Internal Responsibility Assignment Procedure

1. Responsibility assignment procedure:

   a. The OSPM convenes an annual responsibility assignment meeting.

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

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

2. Balance of responsibility and authority:

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

3. Periodic review and updates:

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

4. Documentation:

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

5. Education and awareness:

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

3.4 Current Assignees

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

4. Open Source License Compliance

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

4.1 Open Source Identification and License Obligation Review

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

4.2 Design Considering Open Source Licenses

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

4.3 Creating and Managing Compliance Artifacts

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

4.4 Creating and Managing the SBOM

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

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

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

     b. License information and obligations

     c. Purpose and manner of use

     d. Whether modified and details of modifications

     e. Vulnerability analysis results and response measures

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

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

4.5 Compliance Issue Response Procedure

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

5. Open Source Security Assurance

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

5.1 Known Vulnerability Detection and Response Procedure

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

5.2 Newly Discovered Vulnerability Response Procedure

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

5.3 Continuous Monitoring and Response

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

5.4 Alignment with Internal Best Practices

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

6. Education and Awareness

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

6.1 Open Source Education

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

6.2 Competency Assessment

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

6.3 Awareness-Raising Activities

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

6.4 Record Retention

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

6.5 Identifying and Utilizing Expertise

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

7. Contribution to External Open Source Projects

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

7.1 Contribution Procedure

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

7.2 Caution Regarding CLA Signing

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

7.3 Copyright Notice

1. Copyright Notation:

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

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

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

2. Use of Company Email:

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

7.4 Maintaining Contribution Records

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

8. Releasing Internal Projects as Open Source

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

8.1 Approval Procedure

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

8.2 Release Preparation

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

8.3 Post-Release Management

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

8.4 Record Retention

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

9. Responding to External Inquiries

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

9.1 Responsibility for Responding to External Inquiries

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

9.2 Publishing Contact Information

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

9.3 External Inquiry Response Procedure

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

10. Measuring and Improving Program Effectiveness

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

10.1 Defining Performance Indicators

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

10.2 Periodic Program Assessment

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

10.3 Continuous Improvement Plan

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

10.4 Integrating and Improving Internal Best Practices

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

10.5 Assessing Personnel and Resources

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

11. ISO Standard Compliance Declaration and Maintenance

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

11.1 ISO Standard Compliance Declaration

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

11.2 Maintaining Compliance Status

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

1.1 - Appendix

Appendix 1. Personnel Assignments

2 - Open Source Process

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

1. Open Source Process

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

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

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

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

(1) Open Source Identification

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

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

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

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

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

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

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

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

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

(2) Source Code Inspection

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

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

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

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

(3) Issue Resolution

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

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

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

(4) Review

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

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

(5) Approval

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

(6) Registration

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

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

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

The registered information is periodically reviewed and updated.

(7) Notice

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

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

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

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

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

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

(8) Pre-Distribution Confirmation

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

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

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

(9) Distribution

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

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

(10) Final Confirmation

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

(11) Monitoring

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

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

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

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

2. Security Vulnerability Management Process

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

(1) Continuous Security Testing Before Release

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

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

(2) Monitoring Known Vulnerabilities and Newly Discovered Vulnerabilities

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

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

(3) Vulnerability Assessment and Response

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

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

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

(4) Vulnerability Resolution and Verification

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

(5) Post-Release Vulnerability Analysis and Response

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

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

(6) Vulnerability Record Management

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

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

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

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

(7) Reporting and Communication

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

(8) Customer and Third-Party Notification

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

1. Customer notification:

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

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

2. Third-party disclosure:

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

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

3. Notification content:

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

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

3. External Inquiry Response Process

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

(1) Acknowledgment of Receipt

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

Main types of inquiries and requests:

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

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

(2) Notification of Investigation

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

(3) Internal Investigation

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

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

(4) Report to the Requester

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

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

(5) Issue Remediation / Notification

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

(6) Notification of Issue Resolution

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

(7) Process Improvement

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

4. Open Source Contribution Process

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

(1) Establishing and Disseminating a Contribution Policy

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

The Open Source Program Manager must do the following:

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

(2) Contribution Review and Approval Procedure

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

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

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

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