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

• 1: 1. Why Does Open Source Security Matter?
• 2: 2. Key Requirements of ISO/IEC 18974
• 3: 3. How to Implement ISO/IEC 18974
• 3.1: 3.1 Program Foundation
• 3.2: 3.2 Relevant Tasks Defined and Supported
• 3.3: 3.3 Open Source Software Content Review and Approval
• 3.4: 3.4 Adherence to the specification requirements
• 4: 4. Comparison and Integration with ISO/IEC 5230
• 5: 5. Implementation Considerations by Organizational Characteristics
• 6: 6. ISO/IEC 18974 Self-Certification Process
• 7: 7. Case Studies and Success Strategies
• 8: 8. Conclusion and Future Outlook

1 - 1. Why Does Open Source Security Matter?

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

1.1 The Concepts of Open Source Software and Security Assurance

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

Characteristics of Open Source Software

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

Table 1.1: Advantages and Disadvantages of Open Source Software

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

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

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

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

1.2 Background and Objectives of the ISO/IEC 18974 Standard

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

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

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

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

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

1.3 The Purpose and Importance of ISO/IEC 18974

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

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

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

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

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

1.4 Benefits of ISO/IEC 18974 Certification

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

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

Summary

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

2 - 2. Key Requirements of ISO/IEC 18974

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

2.1 Program Foundation

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

2.1.1 Policy

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

Table 2.1: Policy Requirement and Verification Materials

Considerations for Establishing the Policy

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

2.1.2 Competence

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

Table 2.2: Competence Requirement and Verification Materials

Considerations for Building Competence

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

2.1.3 Awareness

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

Table 2.3: Awareness Requirement and Verification Materials

Activities to Raise Awareness

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

2.1.4 Resources

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

Table 2.4: Resources Requirement and Verification Materials

Considerations for Providing Resources

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

2.1.5 Measurement

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

Table 2.5: Measurement Requirement and Verification Materials

Considerations for Measurement

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

2.2 Relevant Tasks Defined and Supported

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

2.2.1 Access

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

Table 2.6: Access Requirement and Verification Materials

Considerations for Ensuring Access

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

2.2.2 Effectively Resourced

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

Table 2.7: Effectively Resourced Requirement and Verification Materials

Considerations for Resource Allocation

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

2.3 Open Source Software Content Review and Approval

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

2.3.1 SBOM (Software Bill of Materials)

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

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

Considerations for SBOM Management

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

2.3.2 Security Assurance

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

Table 2.9: Security Assurance Requirement and Verification Materials

Considerations for Security Assurance

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

2.3.3 Review and Approval

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

Table 2.10: Review and Approval Requirement and Verification Materials

Considerations for the Review and Approval Process

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

2.4 Conformance to Document Requirements

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

2.4.1 Program Conformance

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

Table 2.11: Program Conformance Requirement and Verification Materials

Considerations for Verifying Program Conformance:

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

2.4.2 Continuous Improvement

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

Table 2.12: Continuous Improvement Requirement and Verification Materials

Considerations for Continuous Improvement:

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

3 - 3. How to Implement ISO/IEC 18974

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

3.1 - 3.1 Program Foundation

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

3.1.1 Policy

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

3.1.1.1 Documented Open Source Software Security Assurance Policy

ISO/IEC 18974

• 4.1.1.1: A documented open source software security assurance policy

Self-Certification Checklist

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

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

Example Policy Content

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

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

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

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

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

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Example Procedures

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

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

Example Improvement Plan

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

Documentation Approach

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

3.1.2 Competence

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

3.1.2.1 Documented List of Roles and Responsibilities

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

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

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

3.1.2.2 Document Defining the Competencies Required for Each Role

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

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

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

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

3.1.2.3 List of Participants and Their Roles

ISO/IEC 18974

• 4.1.2.3: List of participants and their roles;

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

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

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

3.1.2.4 Documented Evidence of Assessed Competence for Each Participant

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

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

Example Improvement Plan

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

Documentation Approach

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

3.1.2.5 Recording Process Reviews and Changes

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Sample Evidence

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

Sample Table: Process Review and Change Record

Example Improvement Plan

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

Documentation Approach

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

3.1.2.6 Verifying Alignment with Company Internal Best Practices

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Sample Evidence

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

Sample Table: Verifying Alignment with Company Internal Best Practices

Example Improvement Plan

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

Documentation Approach

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

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

3.1.3 Awareness

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

3.1.3.1 Documented Evidence of Assessed Awareness of Program Participants

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Sample Evidence

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

Example (Based on Personnel Assignments)

Example Improvement Plan

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

Documentation Approach

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

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

3.1.4 Program Scope

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

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

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example (Considering Organization Size and Business Characteristics)

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

Sample Table: Program Scope Definition

Documentation Approach

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

3.1.4.2 Set of Metrics to Achieve for Program Improvement

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example Metrics

Data Collection Methods

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

Documentation Approach

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

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

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Sample Evidence

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

Sample Table: Continuous Improvement Activity Record

Example Improvement Plan

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

Documentation Approach

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

3.1.5 Standard Practice Implementation

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

3.1.5.1 Method to Identify Structural and Technical Threats to Supplied Software

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example

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

Implementation Considerations

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

Automation Tool Options

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

• FOSSLight
• SW360
• OSV-SCALIBR

Documentation Approach

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

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

3.1.5.2 Method to Detect Known Vulnerabilities in Supplied Software

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example

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

Implementation Considerations

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

Automation Tool Options

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

• FOSSLight
• SW360
• OSV-SCALIBR

Documentation Approach

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

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

3.1.5.3 Method to Follow Up on Identified Known Vulnerabilities

ISO/IEC 18974

• Method for following up on identified known vulnerabilities;

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example

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

Implementation Considerations

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

Documentation Approach

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

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

3.1.5.4 Method to Communicate Identified Known Vulnerabilities to Customers

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Communication methods:

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

Content of the communication:

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

Implementation Considerations

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

Example

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

Documentation Approach

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

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

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

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Implementation Considerations

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

Example

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

Documentation Approach

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

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

3.1.5.6 Method for Continuous and Repeated Security Testing Before Release

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Specific Examples

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

Implementation Considerations

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

Automation Tool Options

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

• FOSSLight
• SW360
• OSV-SCALIBR

Documentation Approach

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

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

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

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Specific Examples

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

Implementation Considerations

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

Documentation Approach

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

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

3.1.5.8 Method to Communicate Identified Risks to Third Parties

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Specific Examples

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

Implementation Considerations

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

Documentation Approach

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

3.2 - 3.2 Relevant Tasks Defined and Supported

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

3.2.1 Access

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

3.2.1.1 Publicly Visible Method for Vulnerability Enquiries

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Examples

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

Documentation Approach

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

3.2.1.2 Internal Procedure for Responding to Vulnerability Enquiries

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example of a Specific Procedure

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

Documentation Approach

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

3.2.2 Effectively Resourced

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

3.2.2.1 Program Role Identification Document

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example

Implementation Considerations

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

Documentation Approach

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

3.2.2.2 Proper Staffing and Funding of Program Roles

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example

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

Documentation Approach

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

3.2.2.3 Identifying Expertise to Resolve Known Vulnerabilities

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Specific Examples

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

Documentation Approach

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

3.2.2.4 Procedure for Assigning Internal Responsibility for Security Assurance

ISO/IEC 18974

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

Self-Certification Checklist

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

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

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

Documentation Approach

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

3.3 - 3.3 Open Source Software Content Review and Approval

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

3.3.1 Software Bill of Materials

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

3.3.1.1 SBOM Generation and Maintenance Procedure

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Approach and Considerations

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

Specific Examples

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

Considerations for Implementation

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

Using Automation Tools

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

• FOSSLight
• SW360
• OSV-SCALIBR

Table: Comparison of Major SBOM Generation Tools

Documentation Approach

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

3.3.1.2 Evidence of SBOM Management Procedure Compliance

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Approach and Considerations

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

Examples of Supporting Evidence

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

Considerations for Implementation

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

Documentation Approach

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

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

3.3.1 Security Assurance

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

An effective security assurance program should include the following elements:

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

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

3.3.2.1 Vulnerability Detection and Resolution Procedure

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Approach and Considerations

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

Considerations for Implementation

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

Documentation Approach

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

3.3.2.2 Maintaining Vulnerability Records

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Approach and Considerations

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

Specific Examples

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

Considerations for Implementation

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

Documentation Approach

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

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

3.4 - 3.4 Adherence to the specification requirements

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

4.4.1 Completeness

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

4.4.1.1 Evidence of Requirement Satisfaction

ISO/IEC 18974

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

Self-Certification Checklist

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

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

Implementation Methods and Considerations

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

Example Evidence Materials

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

Implementation Considerations

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

Documentation Approach

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

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

4.4.2 Duration

ISO/IEC 18974

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

Self-Certification Checklist

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

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

4.4.2.1 Documentation Confirming the Compliance Period

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

Implementation Methods and Considerations

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

Example Evidence Materials

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

Implementation Considerations

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

Documentation Approach

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

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

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

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

4.1 Similarities and Differences

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

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

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

How does ISO/IEC 5230 ensure license compliance?

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

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

How does ISO/IEC 18974 manage security vulnerabilities?

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

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

4.2 The Complementary Relationship Between the Two Standards

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

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

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

4.3 Integrated Implementation Strategy

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

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

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

5 - 5. Implementation Considerations by Organizational Characteristics

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

5.1 Approaches by Large Enterprises, SMEs, and Startups

5.1.1 Large Enterprises

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

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

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

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

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

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

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

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

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

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

5.1.2 Small and Medium-Sized Enterprises

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

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

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

5.1.3 Startups

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

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

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

Success cases:

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

Key considerations:

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

5.2 Integration with Existing Security Processes

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

1. Analyzing current security policy

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

   Example:

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

2. Using the DevSecOps framework

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

   Example:

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

3. Linking with the risk management process

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

   Example:

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

4. Updating the incident response plan

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

   Example:

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

Table 5.3: Methods for Integration with Existing Security Processes

5.3 Education and Awareness Programs

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

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

Table 5.4: Elements of Education and Awareness Programs

6 - 6. ISO/IEC 18974 Self-Certification Process

The ISO/IEC 18974 self-certification process is how an organization confirms for itself that it is effectively implementing a security assurance program for open source software. This process consists of the following stages: preparation and gap analysis, implementation and process improvement, self-assessment and certification declaration, and maintenance and renewal.

6.1 Preparation and Gap Analysis

The preparation and gap analysis stage is the process of understanding the requirements of the ISO/IEC 18974 standard and assessing the organization’s current level of open source security management to identify areas that need improvement. This stage consists of the following detailed tasks.

6.1.1 Detailed Review of the ISO/IEC 18974 Standard Document

1. Compile a list of core requirements
   • Thoroughly review the ISO/IEC 18974 standard document.
   • Extract and list the core requirements for each section.
   • Prioritize the requirements.
2. Understand terminology and concepts
   • Organize the technical terms and concepts used in the standard.
   • If necessary, prepare a glossary and share it within the organization.
3. Obtain the self-certification checklist
   • Download the latest version of the self-certification checklist from the OpenChain Project website.
   • Familiarize yourself with the structure and content of the checklist.

Table 6.1: Example ISO/IEC 18974 Core Requirements

This table shows the key requirements of ISO/IEC 18974 and their priority. Organizations can use this as a basis for developing an implementation plan.

6.1.2 Analysis of the Current Open Source Security Management Process

1. List existing policies, procedures, and tools
   • Identify the open-source-related policies, procedures, and tools currently in use.
   • Clarify the purpose, scope, and owner of each item.
2. Identify strengths and weaknesses
   • Analyze the effective parts of the current process and the parts that need improvement.
   • Conduct a SWOT analysis to identify internal strengths and weaknesses, and external opportunities and threats.
3. Create process flow diagrams
   • Create flow diagrams for key open source management processes (for example, open source use approval, vulnerability response).
   • Specify the owner and required time for each step.

Table 6.2: Example SWOT Analysis of the Current Open Source Security Management Process

• Expertise of the existing security team | | Weaknesses (W) | - Lack of systematic SBOM management
• Insufficient open source security training program | | Opportunities (O) | - Potential for collaboration with the open source community
• Advancement of cloud-based security tools | | Threats (T) | - Increasing open source vulnerabilities
• Increasingly complex license requirements |

This SWOT analysis table comprehensively shows the organization’s current open source security management status. It helps identify the areas that need improvement.

6.1.3 Performing the Gap Analysis

1. Identify the gap between the current state and the requirements
   • Compare the ISO/IEC 18974 requirements against the current process item by item.
   • Evaluate compliance with each requirement as “fully compliant,” “partially compliant,” or “non-compliant.”
2. Prioritize areas requiring improvement
   • Based on the identified gaps, determine the priority of the areas that need improvement.
   • Set priorities by considering business impact, implementation difficulty, resource requirements, and other factors.
3. Set specific improvement targets
   • Set specific, measurable targets for each area of improvement.
   • Create a timeline for achieving the targets.

Table 6.3: Example Gap Analysis and Improvement Plan

This table shows the gap analysis results and the corresponding improvement plan. Organizations can use this as a basis for developing a concrete action plan.

6.1.4 Using the OpenChain Project Checklist

The self-certification checklist provided by the OpenChain Project is a very useful tool for assessing compliance with ISO/IEC 18974. The checklist can be used as follows:

1. Download and review the checklist
   • Download the latest version of the checklist from the OpenChain Project website.
   • Review each item on the checklist and, if necessary, adjust the terminology to fit the organization’s context.
2. Perform the self-assessment
   • Answer each item on the checklist with “yes,” “no,” or “not applicable.”
   • Be sure to record the reason for any “no” or “not applicable” response.
3. Collect supporting evidence
   • For each “yes” response, collect evidence that supports it.
   • Evidence can take various forms, such as documents, screenshots, and logs.
4. Develop an improvement plan
   • Develop an improvement plan for items with a “no” response.
   • Assign an owner and a target completion date to each improvement plan.

Table 6.4: Example OpenChain Project Checklist

This table shows some items from the OpenChain Project checklist and the corresponding self-assessment results. It allows organizations to understand their current compliance status and develop an improvement plan.

Through the preparation and gap analysis stage, an organization can lay the foundation for implementing ISO/IEC 18974. The information gathered and plans developed in this stage form the basis for the next stage, “Implementation and Process Improvement.”

6.2 Implementation and Process Improvement

In this stage, based on the gap analysis results, an organization establishes or revises its open source security policy, improves related processes and procedures, and adopts and configures the necessary tools. The goal is to build an effective open source security management system that meets the ISO/IEC 18974 requirements.

6.2.1 Establishing or Revising the Open Source Security Policy

1. Reflect the ISO/IEC 18974 requirements:
   • Based on the gap analysis results, confirm that all ISO/IEC 18974 requirements are reflected in the policy.
   • In particular, core requirements such as Software Bill of Materials (SBOM) management, vulnerability management, and license compliance must all be included without exception.
2. Develop detailed guidelines suited to the organization’s characteristics:
   • Refine the policy by considering the organization’s size, industry, technology stack, and risk management policy.
   • For example, a financial company should specify additional security measures in the policy to comply with privacy protection and financial regulations.
3. Obtain top management approval:
   • Obtain approval from the CEO (Chief Executive Officer) or the CISO (Chief Information Security Officer) to secure the policy’s enforceability.
   • Manage the approved policy as an official document and share it with all relevant parties in the organization.

Table 6.5: Contents of the Open Source Security Policy

6.2.2 Improving Processes and Procedures

1. Build an SBOM generation and management process:
   • SBOM generation: Build a process that automatically generates an SBOM during the software build.
   • SBOM storage and management: Securely store the generated SBOM and manage it in conjunction with a version control system.
   • SBOM distribution: Establish a system for rapidly distributing the SBOM when needed (for example, upon customer request or when a security incident occurs).
   • Use tools: Automate the process using SBOM generation tools such as SPDX Tools, FOSSLight, and SW360.
2. Establish a vulnerability monitoring and response system:
   • Vulnerability scanning: Build a process that periodically scans open source components for vulnerabilities.
     • Use tools: Use vulnerability scanning tools such as OWASP Dependency-Check, Snyk, and Black Duck.
     • Scan interval: Set the scan interval by considering the project’s importance and rate of change.
   • Vulnerability assessment and prioritization: Assess the severity, impact, and exploitability of discovered vulnerabilities, and determine response priority.
   • Vulnerability response: Take appropriate response measures, such as patching, mitigation, or component replacement, based on the assessment results.
   • Set response deadlines: Set response deadlines according to vulnerability severity, and follow the exception handling procedure if a vulnerability is not resolved within the deadline.
3. Build an incident reporting system:
   • Reporting procedure: Clearly define the reporting procedure for when an open-source-related security incident occurs (for example, vulnerability exploitation or license violation).
   • Reporting recipients: Designate the parties who must be notified (for example, the security team, legal team, or management).
   • Reporting format: Prepare a reporting format that includes the information needed for a report (for example, when the incident occurred, the scope of impact, and the components involved).

Table 6.6: Process and Procedure Improvements

6.2.3 Adopting and Configuring the Necessary Tools

1. Select open source discovery and vulnerability scanning tools:
   • Select appropriate tools by considering the organization’s development environment, technology stack, and budget.
   • Compare free open source tools with commercial tools, and select a tool with the necessary features.
   • Free tools: OWASP Dependency-Check, Bandit, Trivy, etc.
   • Commercial tools: Snyk, Black Duck, WhiteSource, etc.
2. Integrate with the existing development environment:
   • Integrate the selected tools with the existing development environment, such as the IDE (Integrated Development Environment) and the CI/CD (Continuous Integration/Continuous Delivery) pipeline.
   • The integration helps developers easily use the tools and automate security checks.
3. Use automation features:
   • Make full use of the tools’ automation features to automate tasks such as SBOM generation, vulnerability scanning, and license checking.
   • Automation saves human resources and reduces the likelihood of human error.

Table 6.7: Criteria for Selecting Open Source Security Tools

6.2.4 Documentation Work

1. Prepare detailed documentation of policies, processes, and procedures:
   • Prepare detailed documentation of the established or revised policy, the improved processes, and the related procedures.
   • Documents should be written in clear, easy-to-understand language and be readily accessible to everyone concerned within the organization.
2. Clarify roles and responsibilities:
   • Clearly define and document the owner and person in charge of each process step.
   • A RACI (Responsible, Accountable, Consulted, Informed) matrix can be used to clearly define roles and responsibilities.
3. Manage document versions:
   • Build a document version control system to manage the change history and maintain the latest version.
   • Version control tools such as Git and Subversion, or collaboration tools such as SharePoint and Confluence, can be used.

Table 6.8: Documentation Work Items

Through this stage, an organization can establish the systematic foundation needed to implement ISO/IEC 18974 and complete its preparations for continuous improvement. Next is the self-assessment and certification declaration stage.

6.3 Self-Assessment and Certification Declaration

In this stage, based on the preparation and improvements made earlier, an organization assesses for itself whether it meets the ISO/IEC 18974 requirements and declares self-certification on the OpenChain Project website. The self-assessment must be conducted objectively and systematically, and the certification declaration must be approved by the organization’s top executive.

6.3.1 Using the OpenChain Project Self-Certification Checklist

1. Download the latest version of the checklist:
   • Download the latest version of the checklist for ISO/IEC 18974 self-certification from the OpenChain Project website (https://www.openchainproject.org/security-assurance).
   • The checklist may be provided in spreadsheet (.xlsx) or document (.pdf) format.
2. Understand and interpret the checklist items:
   • Carefully read each item on the checklist and interpret it in light of the organization’s context.
   • Checklist items generally reflect a specific requirement of the ISO/IEC 18974 standard and are used to assess how the organization meets that requirement.
3. Prepare supporting evidence:
   • For each checklist item, prepare evidence that demonstrates the organization meets the corresponding requirement.
   • Evidence can take various forms, such as policy documents, procedure manuals, audit reports, training materials, and system logs.

6.3.2 Performing a Systematic Self-Assessment

1. Check compliance with each requirement:
   • Review the prepared evidence and determine, for each item on the checklist, whether the organization complies with the corresponding requirement.
   • Answer each item with “yes,” “no,” or “not applicable.”
2. Maintain an objective perspective:
   • Exclude subjective judgment from the self-assessment process and evaluate based on objective evidence.
   • Consider seeking help from an independent audit team or an external expert to increase the reliability of the assessment results.
3. Record the assessment results:
   • Record in detail the assessment result and the basis for each checklist item.
   • In particular, for items answered “no” or “not applicable,” clearly record the reason and the improvement plan.

Table 6.9: Example OpenChain Project Self-Certification Checklist

6.3.3 Identifying Unmet Items and Developing an Improvement Plan

1. Analyze the root causes of gaps:
   • Analyze the root cause of each item answered “no” or “not applicable” in the self-assessment.
   • When analyzing root causes, consider various factors such as technical issues, budget constraints, staffing shortages, and inadequate processes.
2. Derive short-term and long-term improvement measures:
   • Derive short-term and long-term improvement measures to address the identified causes.
   • Start short-term improvement measures with those that can be implemented relatively easily, and aim long-term improvement measures at strengthening the organization’s overall capabilities.
3. Designate a schedule and owner for each improvement:
   • Clearly designate the implementation schedule and owner for each improvement measure.
   • The owner is responsible for tracking the progress of the improvement plan, securing the necessary resources, and completing the plan.

Table 6.10: Example Improvement Plan for Unmet Items

6.3.4 Declaring Certification on the OpenChain Project Website

1. Access the self-certification page:
   • Go to the ISO/IEC 18974 self-certification page on the OpenChain Project website (https://www.openchainproject.org/security-assurance).
2. Enter the required information:
   • Enter the organization’s basic information, such as its name, address, and contact information.
   • Enter certification-related information, such as the self-assessment results and improvement plan.
   • Enter the certification owner’s contact information, such as name, title, and contact details.
3. Agree to and submit the declaration:
   • Agree to the OpenChain Project’s self-certification declaration.
   • Verify the entered information, obtain approval from the organization’s top executive (for example, the CISO or head of legal), and submit it.
4. Obtain the certification badge:
   • Once the certification declaration is complete, obtain the ISO/IEC 18974 certification badge provided by the OpenChain Project.
   • The organization can use the certification badge on its website, marketing materials, and other channels to promote its open source security capabilities.

By completing this stage, an organization can formally declare its compliance with the ISO/IEC 18974 requirements and publicly announce that it has built its own open source security management system. Next is the certification maintenance and renewal stage.

6.4 Maintenance and Renewal

ISO/IEC 18974 self-certification is not a one-time event but an ongoing process. Through this stage, an organization can maintain its certification, continuously improve its open source security management system, and effectively respond to the changing threat landscape.

6.4.1 Conducting Regular Internal Audits

1. Develop an audit plan:
   • Develop a plan to conduct internal audits annually or semiannually.
   • Clearly define the audit scope, audit cycle, the departments and systems subject to audit, and the audit owner.
2. Conduct the audit:
   • Conduct the audit using various methods, such as checklists, interviews, document review, and system log analysis.
   • During the audit, assess compliance with the ISO/IEC 18974 requirements, the effectiveness of policies and procedures, and opportunities for improvement.
3. Report the audit results:
   • Document the audit results and clearly present the issues found, improvements, and recommendations.
   • The audit report must be shared with relevant stakeholders (for example, the CISO, legal team, and development team).
4. Track improvement activities:
   • Develop and implement a corrective action plan based on the audit results.
   • Regularly track the progress of the corrective action plan and confirm its completion.

Table 6.11: Example Internal Audit Checklist Items

6.4.2 Tracking New Requirements and Updates

1. Gather information:
   • Collect the latest information related to ISO/IEC 18974 through the OpenChain Project website, newsletters, community forums, and other sources.
   • Participate in open-source-security-related conferences, seminars, and workshops to learn about the latest technology trends and best practices.
   • Monitor changes to security-related laws and regulations (for example, GDPR, CCPA, DORA, and the EU Cyber Resilience Act).
2. Assess the impact:
   • Assess the impact of new requirements or updates on the organization’s open source security management system.
   • Confirm whether existing policies, procedures, and tools need to be changed.
3. Reflect changes in the process:
   • Reflect the necessary changes in policies and procedures based on the assessment results.
   • Train members of the organization on the changes and adopt new tools.

6.4.3 Formal Reassessment Every 18 Months (Recommended)

1. Conduct a full reassessment:
   • Reassess compliance with the ISO/IEC 18974 requirements using the latest checklist provided by the OpenChain Project.
   • Identify the areas that have improved since the previous assessment and the areas that need further improvement.
2. Develop an improvement plan:
   • Develop and implement an improvement plan based on the reassessment results.
   • This process is equivalent to repeating the gap analysis and implementation stages described earlier.
3. Update documentation:
   • Reflect the results of the reassessment and improvement activities to keep policies, procedures, and related documents up to date.

6.4.4 Continuous Improvement Activities

1. Collect feedback:
   • Collect feedback on the open source security management system from internal and external stakeholders.
   • Various methods can be used, such as surveys, interviews, and workshops.
2. Analyze data:
   • Along with the collected feedback, analyze various data, such as SBOM data, vulnerability analysis results, and audit results, to identify opportunities for improvement.
3. Implement improvements:
   • Develop and implement a specific action plan for each identified improvement opportunity.
   • Various activities can be carried out, such as adopting new technologies, improving processes, and developing training programs.
4. Measure performance:
   • Set KPIs (Key Performance Indicators) to measure the effectiveness of improvement activities, and measure them regularly.
   • Analyze the measurement results to evaluate the effectiveness of the improvement activities, and revise the plan if necessary.
5. Share knowledge:
   • Share success and failure cases from improvement activities within the organization to enhance learning.
   • Use internal wikis, blogs, newsletters, and other channels to share knowledge and encourage communication.

7 - 7. Case Studies and Success Strategies

This section analyzes cases of obtaining ISO/IEC 18974 certification and presents key strategies for successful implementation. Through case studies across various company sizes, it will help readers understand real-world application methods and establish the optimal strategy for their organization.

7.1 Certification Cases by Various Company Sizes

7.1.1 Global Software Company: openEuler

openEuler is a major open source operating system project in China that obtained ISO/IEC 18974 certification in June 2024. This case shows how ISO/IEC 18974 is implemented in a large-scale open source project.

• Background and goals of certification: openEuler aimed to build a secure, compliant, and sustainable operating system community.
• Key challenges during implementation: The main challenge was implementing consistent security practices across a large-scale open source project.
• Business impact and benefits after certification: openEuler’s development process, software supply chain, risk assessment, management, and developer security capabilities were recognized as meeting the highest level of standard.
• Analysis of success factors: Community-wide cooperation and commitment, and making security a core value, were the main success factors.

Key lesson: In large-scale open source projects, community participation and cooperation are the key success factors for ISO/IEC 18974 implementation.

7.1.2 Large Enterprise: KT

KT obtained ISO/IEC 18974 certification in October 2024. This case shows how a large enterprise integrates ISO/IEC 18974 into its existing security system.

• Background and goals of certification: KT pursued certification to strengthen its open source software security management system and increase trust within the supply chain.
• Key challenges during implementation: It was necessary to build a systematic management system to ensure open source compliance.
• Business impact and benefits after certification:
  • Recognized for systematic and consistent open source software security management capability.
  • Strengthened its position as a company compliant with open source security and compliance.
  • Increased trust among participants within the supply chain.
• Analysis of success factors:
  • Building a systematic license and security check system through an open source management portal
  • Rapid resolution of legal and security issues through the formation of an in-house “OSRB” (OpenSource Review Board)
  • Establishing a culture of proper open source use through continuous employee education

Key lesson: Large enterprises can achieve efficient open source management by integrating ISO/IEC 18974 with their existing security system and leveraging an in-house expert group.

7.1.3 Financial Company: KakaoBank

In November 2023, KakaoBank became the first domestic financial company to obtain ISO/IEC 18974, the international standard for open source security assurance. This case shows how ISO/IEC 18974 is implemented at a financial company that requires a high level of security.

• Background and goals of certification: The need to build a systematic management system emerged as the company actively used open source to provide world-class financial services quickly and efficiently.
• Key challenges during implementation: The company had to meet more than 30 security certification requirements, including establishing open source policy and processes, building a compliance system, securing expertise in the responsible organization and personnel, and conducting in-house employee education.
• Business impact and benefits after certification: The company’s open source use and security management capability were internationally recognized, and it was recognized as a company with systematic and consistent open source security management capability. It gave customers confidence that the company could provide safer financial services.
• Analysis of success factors: The company formed an open source expert council (OSRB) to jointly discuss open source-related issues and built a system to manage licenses and security vulnerabilities in advance.

Key lesson: Financial companies must build a systematic open source management system and secure expertise through an expert council to meet high-level security requirements.

7.1.4 SME: (Hypothetical case) IT Solution Provider “TechSolution”

TechSolution is a small and medium-sized IT solution provider developing cloud-based services. TechSolution pursued ISO/IEC 18974 certification to safely protect customer data and secure a competitive advantage.

• Background and goals of certification: TechSolution set a goal of obtaining ISO/IEC 18974 certification to strengthen the security of its cloud-based services, increase customer trust, and create new business opportunities.
• Key challenges during implementation: The main challenge was meeting ISO/IEC 18974 requirements with a limited budget and personnel.
• Business impact and benefits after certification:
  • Improved the security level of cloud-based services and was able to safely protect customer data.
  • Improved customer trust, strengthening relationships with existing customers and succeeding in attracting new customers.
  • Improved company image and secured a competitive advantage by promoting the ISO/IEC 18974 certification.
• Analysis of success factors:
  • Strengthened cooperation between the existing development team and security team, and clarified responsibilities and roles by designating an open source security lead.
  • Reduced initial investment costs and increased management efficiency by using cloud-based SBOM generation and vulnerability scanning tools.
  • Systematically implemented ISO/IEC 18974 requirements with the help of an outside consulting firm and gained know-how for obtaining certification.

Key lesson: SMEs can efficiently use limited resources and successfully obtain ISO/IEC 18974 certification with the help of outside experts.

7.1.5 Startup: (Hypothetical case) AI-based Service Development Startup “AIBrain”

AIBrain is an early-stage startup developing AI-based services. AIBrain emphasizes innovative technology and rapid development speed as its strengths, but also has concerns about security issues.

• Background and goals of certification: AIBrain expected ISO/IEC 18974 certification to strengthen security throughout the development process and have a positive impact on attracting investment and forming partnerships.
• Key challenges during implementation: As an early-stage startup, it lacked security-specialized personnel, and it was difficult to meet ISO/IEC 18974 requirements without slowing down development speed.
• Business impact and benefits after certification:
  • A security-conscious development culture took root, improving the security of the product.
  • Demonstrated security capability to investors and partners, succeeding in attracting investment and forming partnerships.
  • Improved company image and secured a competitive advantage by promoting the ISO/IEC 18974 certification.
• Analysis of success factors:
  • Integrated security checks into the development process and actively used automated security tools to maintain development speed while strengthening security.
  • Reduced security infrastructure build costs by using a cloud-based development environment.
  • Effectively implemented ISO/IEC 18974 requirements using materials and guidelines provided by the OpenChain Project.

Key lesson: Startups can implement ISO/IEC 18974 cost-effectively by integrating security into the development process and using a cloud-based environment.

Table 7.1: Summary of ISO/IEC 18974 Certification Cases by Company Size

This table summarizes ISO/IEC 18974 certification cases by various company sizes. Organizations can refer to cases that match their own size and characteristics to establish an implementation strategy.

7.2 Key Strategies for Successful Implementation

The key strategies for successfully leading ISO/IEC 18974 implementation are as follows. These strategies have been validated through the case studies examined above and can be applied to an organization’s situation to maximize their effect.

7.2.1 Securing Active Support from Executive Management

1. Presenting the ROI (Return on Investment) of security investment:
   • Quantitatively presents the positive impact of open source security management on business continuity, customer trust, and regulatory compliance.
   • Example: Uses specific figures such as “5% reduction in customer churn after obtaining ISO/IEC 18974 certification” or “30% reduction in the number of open source-related security incidents.”
2. Regular status reporting and feedback:
   • Reports the status of open source security to executive management monthly or quarterly and receives feedback.
   • The report includes the status of the Software Bill of Materials (SBOM), the trend of vulnerability occurrence, the status of license compliance, and the results of improvement activities.
3. Building an open source security culture:
   • Executive management leads by emphasizing the importance of open source security and raising organization-wide awareness.
   • Encourages participation in open source security-related education programs and rewards best practices.

Execution steps:

1. Explains the importance of open source security to executive management and emphasizes the need to adopt ISO/IEC 18974.
2. Obtains approval to establish an OSPO (Open Source Program Office) or designate an open source security lead.
3. Secures a budget for open source security and supports securing the necessary tools and personnel.

7.2.2 Adopting a Phased Approach

1. Gradual implementation based on priority:
   • Starts with high-risk areas (e.g., externally exposed services, core business logic) and gradually expands the scope of application.
   • Manages low-risk areas efficiently using automation tools.
2. Maintaining momentum through quick wins:
   • Sets goals that can be achieved in the short term and shares success cases to encourage participation within the organization.
   • Example: “Build an SBOM generation and management system within 3 months,” “Complete vulnerability scanning for key projects within 6 months,” etc.
3. Risk management and control:
   • Identifies new threats through regular risk assessments and prepares appropriate response measures.
   • Systematically manages open source-related risks using a risk management register.

Execution steps:

1. Selects open source components related to core business logic as priority management targets.
2. Introduces SBOM generation and vulnerability scanning tools to quickly generate initial results.
3. Builds a regular security check and audit process to drive continuous improvement.

7.2.3 Actively Using Automation Tools

1. Integrating the CI/CD pipeline:
   • Integrates SBOM generation, license checking, and vulnerability scanning into the Continuous Integration/Continuous Delivery (CI/CD) pipeline to perform automated security checks throughout the development process.
   • This allows developers to automatically perform security checks whenever they commit code and quickly resolve issues.
2. Building a real-time monitoring and alert system:
   • Builds a system that provides immediate notification when a new vulnerability is found, to support a rapid response.
   • Configures notifications to be received through various channels such as Slack, email, and SMS.
3. Minimizing repetitive tasks:
   • Automates repetitive tasks such as license checking, SBOM generation, and vulnerability scanning to allow human resources to focus on more valuable work.
   • Repetitive tasks can be minimized through script writing, API use, and automation tool configuration.

Table 7.2: Key Strategies for Successful ISO/IEC 18974 Implementation

Active support from executive management, a phased approach, and the use of automation tools are essential for successful implementation.

8 - 8. Conclusion and Future Outlook

8.1 The Strategic Importance of Adopting ISO/IEC 18974

ISO/IEC 18974 is an international standard for open source software security assurance, and its importance is becoming increasingly prominent in the modern software development environment. This section reaffirms the strategic importance of adopting ISO/IEC 18974 and examines the specific benefits that can be gained from it.

8.1.1 Role as a Global Standard for Open Source Security Management

ISO/IEC 18974 provides a framework for systematically managing the security of open source software. This promotes a consistent security management approach on a global scale and provides the following benefits:

1. Securing international credibility: Through ISO/IEC 18974 certification, an organization’s open source security management capability can be internationally recognized.
2. Promoting global collaboration: A standardized framework facilitates international collaboration and information sharing.
3. Ease of regulatory compliance: Helps meet the regulatory requirements of various countries and industries.

8.1.2 Strengthening Software Supply Chain Security

Software supply chain security has become important due to the widespread use of open source components. ISO/IEC 18974 contributes to strengthening security across this supply chain:

1. Managing the Software Bill of Materials (SBOM): The SBOM allows all open source components in use to be managed transparently.
2. Improving the vulnerability management process: Enables the establishment of a systematic vulnerability scanning and patch management process.
3. Supplier management: Provides criteria for evaluating and improving the level of open source security management of suppliers.

8.1.3 An Essential Element in the Age of Digital Transformation

As digital transformation accelerates, open source use is increasing. ISO/IEC 18974 provides the foundation for safely pursuing this digital innovation:

1. Balancing innovation and security: Enables rapid innovation using open source while securing security at the same time.
2. Responding to cloud-native environments: Enables management of open source security in modern architectures such as containers and microservices.
3. Supporting DevSecOps: Promotes a DevSecOps culture that integrates development, security, and operations.

Table 8.1: Key Benefits of Adopting ISO/IEC 18974

This table organizes the key benefits gained from adopting ISO/IEC 18974 by area and presents specific examples.

Adopting ISO/IEC 18974 will become a key element in raising an organization’s strategic competitiveness, beyond simply strengthening security. The next section will examine the future outlook and preparation measures based on the importance of this standard.

8.2 Summary of the Key Benefits of Adopting ISO/IEC 18974

This section summarizes, with specific cases, the key benefits an organization can gain through ISO/IEC 18974 implementation.

8.2.1 Building a Systematic Open Source Security Management System

1. Establishing consistent security policy and processes: Establishes an open source security policy applied across the entire organization and builds standardized processes to ensure compliance.
   • Example: Establishes a policy requiring all development teams to follow the same open source use approval procedure and use the same security tools.
2. Systematic identification, tracking, and control of open source components: Uses the Software Bill of Materials (SBOM) to identify and track all open source components used within the organization, and manages security vulnerability and license information.
   • Example: Builds an SBOM management system to identify and manage the version, license, and vulnerability information of open source components in real time.
3. Securing transparency through Software Bill of Materials (SBOM) management: Secures transparency regarding software components and manages risk within the supply chain by generating and sharing an SBOM.
   • Example: Provides an SBOM to customers or partners to increase trust in software components and to respond quickly to security-related inquiries.

8.2.2 Improving Customer Trust and Strengthening Business Competitiveness

1. Securing customer trust through security certification: Externally demonstrates the organization’s open source security management capability through ISO/IEC 18974 certification and gains customer trust.
   • Example: Promotes the fact of obtaining ISO/IEC 18974 certification to attract new customers and strengthen relationships with existing customers.
2. Expanding business opportunities through improved trust within the supply chain: Builds trust with partners within the supply chain through ISO/IEC 18974 compliance and creates new business opportunities.
   • Example: Secures a competitive advantage when a government or public institution grants bonus points to companies that have obtained ISO/IEC 18974 certification during project bidding.
3. Protecting company reputation through security incident prevention: Protects the company’s reputation by managing open source security vulnerabilities in advance and reducing the likelihood of a security incident.
   • Example: Minimizes the possibility of damage to company image and legal liability in the event of a data breach caused by a severe security vulnerability.

8.2.3 Reducing Security Risk and a Proactive Approach

1. Preventing security incidents through early detection of and response to vulnerabilities: Uses automated vulnerability scanning tools to quickly identify known vulnerabilities in open source components and apply patches or mitigation measures.
   • Example: When a new vulnerability is disclosed, identifies affected systems within 24 hours and applies a patch.
2. Rapid response to new threats through continuous monitoring: Collects and analyzes the latest security threat information to build a response system for new threats.
   • Example: Subscribes to a threat intelligence platform and immediately sends a notification to the relevant team when new vulnerability information is disclosed.
3. Efficient management of security costs: Reduces the likelihood of a security incident through proactive security activities and reduces recovery costs when an incident occurs.
   • Example: Reduces costs spent on system recovery, legal response, and customer compensation when a security incident occurs.

8.2.4 Reducing Legal Liability and Regulatory Compliance

1. Reducing legal risk through open source license compliance: Complies with the license terms of open source components and minimizes the possibility of legal disputes such as copyright and patent infringement.
   • Example: When using a GNU General Public License (GPL)-licensed component, complies with the source code disclosure obligation and clearly displays the relevant notices.
2. Supporting compliance with data protection regulations such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA): Through ISO/IEC 18974, complies with privacy protection regulations and reduces legal liability in the event of a data breach.
   • Example: Strengthens data encryption and access control measures when using open source components that process personal information.
3. Meeting industry-specific regulatory requirements: Supports compliance with regulations applicable to specific industries such as finance and healthcare (e.g., the Payment Card Industry Data Security Standard (PCI DSS), the Health Insurance Portability and Accountability Act (HIPAA)).
   • Example: For financial companies, reflects additional security requirements in policy to comply with financial security regulations.

Table 8.2: Summary of Key Benefits of Adopting ISO/IEC 18974

This table summarizes the key benefits that can be gained through the adoption of ISO/IEC 18974. Organizations can use these benefits to evaluate the feasibility of adopting ISO/IEC 18974 and establish an implementation plan.

8.3 Future Outlook for ISO/IEC 18974 and Organizational Preparation

As the importance of open source security continues to increase, the role and importance of the ISO/IEC 18974 standard is also expected to expand further. Organizations must prepare for these changes by strengthening their open source security management system and securing future competitiveness.

8.3.1 Expanding Importance of the Standard Due to Increased Open Source Use

The use of open source software is rapidly increasing in advanced technology fields such as cloud-native technology, artificial intelligence, and machine learning. In line with this trend, the scope of application of the ISO/IEC 18974 standard is also expected to expand.

1. Expanding scope of application:
   • Compliance with ISO/IEC 18974 may be required not only in existing web applications, mobile apps, and server systems, but also in various areas such as Internet of Things (IoT) devices, embedded systems, and AI/ML models.
2. Industry standardization:
   • There is a high possibility that industry-specific open source security standards based on ISO/IEC 18974 will be developed in specific industry fields such as finance, healthcare, and manufacturing.
   • Organizations must identify and prepare for these industry-specific standards in advance.

8.3.2 Evolution of the Standard Due to the Application of New Technologies such as AI/ML

Artificial intelligence and machine learning technologies are expected to have a significant impact on open source security management. The ISO/IEC 18974 standard will also evolve in step with these changes.

1. Automated vulnerability analysis and response:
   • A feature that automatically analyzes vulnerabilities in open source components and suggests response measures using AI/ML technology may be included in the standard.
   • Example: An AI-based vulnerability scanner automatically assesses the severity of a vulnerability and determines the priority for applying patches.
2. Threat prediction and prevention:
   • A feature that predicts new security threats and prevents them in advance using AI/ML technology may be added to the standard.
   • Example: An AI-based threat intelligence system collects new vulnerability information in real time and notifies the organization.

8.3.3 Changes in the Global Regulatory Environment and the Strengthened Role of the Standard

Governments and international organizations around the world are strengthening regulations to strengthen software supply chain security. ISO/IEC 18974 will play an important role in responding to these changes in the regulatory environment.

1. A tool for regulatory compliance:
   • ISO/IEC 18974 certification can be used to demonstrate compliance with new regulations such as the Digital Operational Resilience Act (DORA) and the EU Cyber Resilience Act.
2. International cooperation:
   • As regulations related to cross-border data movement are strengthened, the importance of ISO/IEC 18974 as an international standard will further increase.
   • Organizations can secure competitiveness in the global market through ISO/IEC 18974 compliance.

8.3.4 The Need for Response Strategies Due to the Advancement and Sophistication of Security Threats

Cyberattacks are becoming increasingly advanced and sophisticated, and attacks targeting open source components are also increasing. Organizations must establish a strong security strategy based on ISO/IEC 18974 to respond to these threats.

1. Real-time threat intelligence:
   • Builds an early warning system for attacks by collecting and analyzing the latest threat information in real time.
2. Automated response mechanisms:
   • Minimizes damage by building a system that automatically executes response measures when an incident occurs.
3. Strengthening breach incident response training:
   • Strengthens the response capability of organization members through regular breach incident response training.

Table 8.3: Future Outlook for ISO/IEC 18974 and Organizational Preparation

8.4 Recommendations for Organizations

This section presents specific recommendations that organizations should consider in order to effectively implement ISO/IEC 18974 and continuously strengthen open source security.

1. Reviewing proactive adoption of ISO/IEC 18974
   • Analyzing organizational size and characteristics: Carefully reviews whether to adopt ISO/IEC 18974, considering the organization’s size, industry, technology stack, and business goals.
   • Phased approach: Rather than implementing all requirements at once, it can be more effective to set priorities and implement them in stages. In the early stage, focus on establishing core security policy, building the Software Bill of Materials (SBOM), and building a vulnerability scanning process.
   • Securing resources: Secures the budget, personnel, and tools needed for ISO/IEC 18974 implementation. Consider seeking help from outside experts if necessary.
2. Continuous improvement and monitoring the latest trends
   • Regular internal audits: Operates an internal audit program to regularly check compliance with ISO/IEC 18974 and identify parts that need improvement.
   • Using external evaluation: Has the open source security management system evaluated by outside security experts or certification bodies and seeks advice on the direction of improvement.
   • Acquiring the latest information: Continuously identifies the latest trends related to open source security and prepares response measures for new threats.
     • Uses the OpenChain Project website, security-related newsletters, and conferences.
3. Expanding participation in and contribution to the open source ecosystem
   • Community participation: Participates in open source projects and contributes to the open source community through code contribution, bug reporting, and documentation.
   • Information sharing: Shares open source security-related experience, knowledge, and tools inside and outside the organization.
   • Cooperation: Cooperates with other organizations, research institutions, and government agencies to pursue joint research and development for strengthening open source security.
4. Training experts and building a cooperation network
   • Training in-house experts: Develops education programs to train open source security experts and encourages employee participation.
   • Supporting certification acquisition: Supports employees in acquiring security-related certifications such as SANS and ISC2 to improve their expertise.
   • Using an external network: Builds a cooperation network with open source security experts, consultants, and vendors.

Table 8.4: Specific Recommendations for ISO/IEC 18974 Implementation