3. How to Implement ISO/IEC 18974

• 1: 3.1 Program Foundation
• 2: 3.2 Relevant Tasks Defined and Supported
• 3: 3.3 Open Source Software Content Review and Approval
• 4: 3.4 Adherence to the specification requirements

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)

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

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.