ISO/IEC 18974 Conformance Guide

• 1: §4.1 Program Foundation
• 1.1: §4.1.1 Policy
• 1.2: §4.1.2 Competence
• 1.3: §4.1.3 Awareness
• 1.4: §4.1.4 Program Scope
• 1.5: §4.1.5 Standard Practice Implementation
• 2: §4.2 Relevant Tasks
• 2.1: §4.2.1 Access
• 2.2: §4.2.2 Effectively Resourced
• 3: §4.3 Content Review and Approval
• 3.1: §4.3.1 SBOM
• 3.2: §4.3.2 Security Assurance
• 4: §4.4 Conformance
• 4.1: §4.4.1 Completeness
• 4.2: §4.4.2 Duration
• 5: ISO/IEC 5230 vs 18974 Comparison

1 - §4.1 Program Foundation

1.1 - §4.1.1 Policy

1. Clause Overview

§4.1.1 corresponds to ISO/IEC 5230 §3.1.1 (License Compliance Policy), but the focus shifts to Security Assurance. A policy that systematically manages known and newly discovered vulnerabilities in open source components of the supplied software must be documented and communicated internally. The key difference from ISO/IEC 5230 §3.1.1 is the requirement for a periodic review process for the policy itself and its communication method. It is not enough to establish a policy; a review system must be in place to ensure the policy always remains valid and up to date.

2. What to Do

• Document and formalize a policy for managing security vulnerabilities in open source components included in the supplied software.
• Include vulnerability detection, assessment, response, and notification principles, as well as a Coordinated Vulnerability Disclosure (CVD) policy.
• Establish and document a procedure for communicating the policy to Program Participants (developers, security personnel, legal, IT, etc.).
• Specify in the policy a review process that periodically reviews the policy and its communication method to keep them current and valid.
• Record the review completion date, reviewer, and change history in the document.

3. Requirements and Verification Materials

§4.1.1 Policy A written open source software security assurance policy shall exist that governs open source software security assurance of the supplied software. The policy shall be internally communicated. The policy and its method of communication shall have a review process to ensure they remain current and valid.

Verification Material(s): 4.1.1.1 A documented open source software security assurance policy. 4.1.1.2 A documented procedure that makes program participants aware of the security assurance policy.

4. How to Comply and Samples per Verification Material

4.1.1.1 Documented Security Assurance Policy

How to Comply

If an Open Source Policy for ISO/IEC 5230 is already in place, you can either add a security assurance section to that policy or create a separate security assurance policy document. Both approaches satisfy Verification Material 4.1.1.1.

The policy should include: ① principles for identifying, tracking, and responding to security vulnerabilities; ② risk assessment criteria based on CVSS and remediation timelines; ③ Coordinated Vulnerability Disclosure (CVD) policy; ④ post-deployment monitoring principles; and ⑤ periodic review cycle and reviewer. The key difference from ISO/IEC 5230 §3.1.1.1 is that the periodic review process must be explicitly stated within the policy document.

Considerations

• Integration with 5230 Policy: It can be managed in an integrated manner by expanding the §5 Security Vulnerability Response section of the existing ISO/IEC 5230 policy.
• Specify Review Cycle: Include a clause stating that a minimum of one annual periodic review is conducted, with an immediate review triggered by changes in the threat environment or legal requirements.
• Adopt CVSS Criteria: Use CVSS (Common Vulnerability Scoring System) for vulnerability severity assessment and specify remediation timelines in the policy (e.g., Critical: 7 days, High: 30 days).
• Include CVD Policy: Include a CVD procedure in the policy for collaborating confidentially to resolve externally reported vulnerabilities before public disclosure.
• Version Control: Record the policy version number, change history, and review completion date.

Sample

The following is a sample of the security assurance section of an open source policy.

## §5 Open Source Security Assurance

### 5.1 Purpose
The company systematically identifies and responds to security vulnerabilities
in open source components included in the supplied software to minimize security risks.

### 5.2 Vulnerability Response Principles
Remediation timeline criteria for known vulnerabilities (CVEs) are as follows:
- Critical (CVSS 9.0–10.0): Patch or mitigation within 7 days
- High (CVSS 7.0–8.9): Patch or mitigation within 30 days
- Medium (CVSS 4.0–6.9): Establish patch plan within 90 days
- Low (CVSS 0.1–3.9): Address in next scheduled update

### 5.3 Coordinated Vulnerability Disclosure (CVD) Policy
When a vulnerability is reported externally, it will be resolved in cooperation
with the reporter before public disclosure.
Vulnerability reporting channel: security@company.com

### 5.4 Policy Review
This policy and its communication method shall be reviewed at least annually
to remain current and valid.
The review completion date and reviewer shall be recorded in the document.

4.1.1.2 Documented Procedure for Security Assurance Policy Awareness

How to Comply

A procedure for communicating the security assurance policy to Program Participants must be documented, in the same manner as the policy communication procedure for ISO/IEC 5230 (§3.1.1.2). The additional requirement of §4.1.1 is that the communication procedure itself must also be periodically reviewed to maintain its validity. You can either add security assurance policy content to the existing 5230 policy communication procedure, or establish a separate security policy communication procedure.

Considerations

• Reuse 5230 Procedure: Respond efficiently by adding the security assurance policy to existing open source policy communication channels (onboarding, internal wiki, email).
• Review the Communication Procedure: Specify the review cycle (annually) and the reviewer in the communication procedure document to manage the validity of the procedure itself.
• Retain Evidence: Keep notification history and training completion records for a minimum of 3 years.

Sample

Subject: [Security] Open Source Security Assurance Policy Notice and Acknowledgment Request

To: All employees in development/deployment/security-related roles
From: Open Source Program Manager

Dear all,

The company's open source security assurance policy has been established (or revised).
Please review and familiarize yourself with the policy document at the link below.

- Policy document: [Internal portal link]
- Key content: Vulnerability response principles, CVSS-based remediation timelines, CVD policy
- Policy version: v1.0 (Effective date: YYYY-MM-DD) / Next review scheduled: YYYY-MM-DD

Inquiries: Open Source Program Manager (oss@company.com)

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.1 Policy
• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template

1.2 - §4.1.2 Competence

1. Clause Overview

§4.1.2 has the same basic structure as ISO/IEC 5230 §3.1.2 (Competence), but requires 3 additional Verification Material items. While 5230 requires three items — a list of roles, a definition of competencies per role, and evidence of competency assessment — 18974 additionally requires a list of participants and their role mappings (4.1.2.3), evidence of periodic review and process changes (4.1.2.5), and verification of alignment with internal best practices (4.1.2.6). These three additional items require demonstrating that the competence framework is not merely formal, but is actively kept up to date and aligned with industry standards.

2. What to Do

• Create a list of responsibilities per program role (same as 5230).
• Define and document the competencies required for each role (same as 5230).
• Create a separate list mapping participant names to their respective roles (added in 18974).
• Assess and record the competencies of each participant (same as 5230).
• Periodically review the competence framework and record process changes (added in 18974).
• Confirm that the competence framework aligns with the company’s internal best practices and assign a person responsible (added in 18974).

3. Requirements and Verification Materials

★ = Additional items compared to ISO/IEC 5230 §3.1.2

§4.1.2 Competence The organization shall:

• Identify the roles and responsibilities that impact the performance and effectiveness of the program;
• Determine the necessary competence of program participants fulfilling each role;
• Ensure that program participants are competent on the basis of appropriate education, training, and/or experience;
• Where applicable, take actions to acquire the necessary competence;
• Retain appropriate documented information as evidence of competence.

Verification Material(s): 4.1.2.1 A documented list of roles with corresponding responsibilities for the different participants in the program. 4.1.2.2 A document that identifies the competencies for each role. 4.1.2.3 List of participants and their roles. 4.1.2.4 Documented evidence of assessed competence for each program participant. 4.1.2.5 Documented evidence of periodic reviews and changes to the process. 4.1.2.6 Documented evidence that these processes align with and are up-to-date with company internal best practices, and that a person has been assigned to make sure they remain so.

4. How to Comply and Samples per Verification Material

4.1.2.1 Documented List of Roles and Responsibilities

This is the same as ISO/IEC 5230 §3.1.2.1. From a security assurance perspective, the roles of security personnel (DevSecOps, vulnerability analysis) must be clearly included. Refer to §3.1.2.1 Documented List of Roles and Responsibilities for how to prepare this.

4.1.2.2 Document Identifying Competencies per Role

This is the same as ISO/IEC 5230 §3.1.2.2. The security personnel role should include competencies in CVSS score interpretation, operation of vulnerability analysis tools (OSV-SCALIBR, Dependency-Track, etc.), and DevSecOps understanding. Refer to §3.1.2.2 Document Identifying Competencies per Role for how to prepare this.

4.1.2.3 List of Participants and Their Roles ★

How to Comply

Unlike the list of roles in 4.1.2.1, this item requires a list mapping actual individuals by name to the roles they are assigned. The purpose is to clearly identify who the actual personnel participating in the program are, not just the organizational roles. This list must be updated immediately when personnel changes occur.

Considerations

• Name or job title: Using a job title instead of a personal name is acceptable, but it must be specific enough to identify a particular individual.
• Multiple roles: If someone holds multiple roles, list all of them.
• Timely updates: Update the document and increment the version immediately when an assignee changes.

Sample

| Name | Role | Contact | Assigned Date |
|------|------|---------|---------------|
| Gil-dong Hong | Open Source Program Manager | oss@company.com | 2025-01-01 |
| Chul-su Kim | Security (DevSecOps) | security@company.com | 2025-01-01 |
| Young-hee Lee | Legal | legal@company.com | 2025-01-01 |
| Infra Park | IT | it@company.com | 2025-03-15 |

4.1.2.4 Evidence of Assessed Competence

This is the same as ISO/IEC 5230 §3.1.2.3. Refer to §3.1.2.3 Evidence of Assessed Competence for how to prepare this.

4.1.2.5 Evidence of Periodic Reviews and Process Changes ★

How to Comply

The competence framework (role definitions, competency criteria, assessment methods) must be periodically reviewed, and any changes resulting from the review process must be recorded. The key is to verify that new security tool adoption, organizational restructuring, and improvements to vulnerability response processes have been reflected in the competence framework. The review record itself serves as Verification Material 4.1.2.5.

Considerations

• Review cycle: Conduct a minimum annual periodic review and an immediate review when the organization or processes change.
• Record changes: Record the content of changes, reasons for changes, change dates, and who made the changes.
• Evidence format: Review meeting minutes, review completion confirmations, and change history logs can all serve as evidence.

Sample

[Competence Framework Periodic Review Record]

| Review Date | Review Content | Changes | Reviewer |
|-------------|---------------|---------|----------|
| 2025-01-10 | Full review of all roles and competencies | Added CVSS v4.0 interpretation item to security competency | Gil-dong Hong |
| 2026-01-08 | Full review of all roles and competencies | Added Dependency-Track operation competency to IT role | Gil-dong Hong |

4.1.2.6 Verification of Alignment with Internal Best Practices ★

How to Comply

It must be confirmed that the competency definitions and assessment processes are aligned with the company’s internal best practices (HR policy, technical training standards, etc.), and a person responsible for continuously managing this must be assigned. The purpose is to ensure that the competence framework does not deviate from industry standards or internal guidelines.

Considerations

• Assign a responsible person: Explicitly assign and record a person responsible for managing the currency of the competence framework and its alignment with internal best practices.
• Best practice criteria: Industry standards (NIST SSDF, ISO 27001, etc.), internal security policies, and DevSecOps guidelines can be used as best practice criteria.

Sample

[Internal Best Practice Alignment Confirmation]

Competence Framework Manager: Gil-dong Hong (Open Source Program Manager)
Last alignment review date: 2026-01-08
Reference best practice criteria: Internal Security Training Standard v3.0, NIST SSDF 1.1

Review results:
- Security competency criteria align with the internal security training curriculum ✓
- Vulnerability analysis tool competency reflects the latest tools (Dependency-Track v4.x) ✓
- Next alignment review scheduled: 2027-01-08

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.2 Competence
• Related guide: Enterprise Open Source Management Guide — 1. Organization
• Related template: Open Source Policy Template — Appendix 1. Personnel Status

1.3 - §4.1.3 Awareness

1. Clause Overview

§4.1.3 has the same Verification Material structure as ISO/IEC 5230 §3.1.3 (Awareness). It requires that awareness of program objectives, how individuals contribute to the program, and the implications of non-compliance be assessed and recorded for Program Participants. The difference from 5230 is that the focus of the awareness assessment shifts to Security Assurance. Participants must be aware not only of license compliance but also of the vulnerability management process, CVD procedures, and CVSS-based response criteria.

2. What to Do

• Confirm that Program Participants understand the objectives of the open source security assurance program (vulnerability detection, assessment, response, and notification).
• Assess whether each participant is aware of how their role contributes to the security assurance framework.
• Assess awareness of the legal, business, and security implications of failing to comply with the vulnerability response process.
• Record and retain the results of awareness assessments as documentation.
• Provide additional training to participants with gaps and retain the results of re-assessments.

3. Requirements and Verification Materials

§4.1.3 Awareness The organization shall ensure that the program participants are aware of:

• The open source software security assurance policy and where to find it;
• Relevant open source software security assurance objectives;
• Their contribution to the effectiveness of the program; and
• The implications of not following the program’s requirements.

Verification Material(s): 4.1.3.1 Documented evidence of assessed awareness for the program participants - which shall include the program’s objectives, contributions within the program, and implications of failing to follow the program’s requirements.

4. How to Comply and Samples per Verification Material

4.1.3.1 Evidence of Assessed Awareness for Program Participants

How to Comply

The basic approach is the same as ISO/IEC 5230 §3.1.3.1, but the awareness assessment questions must focus on Security Assurance. The three core awareness items are: ① the objectives of the security assurance program (vulnerability identification, assessment, response, and CVD); ② how one’s own role contributes to the security framework; and ③ the security, legal, and business risks of non-compliance with the process.

The method for recording and retaining assessment results as documentation is the same as for 5230. Conduct a minimum annual periodic assessment, and perform an initial assessment for new participants immediately upon joining.

Considerations

• Design security-specific questions: Include content specific to security assurance in the assessment questions, such as vulnerability response procedures, CVSS criteria, and CVD policy.
• Role-specific in-depth assessment: For security personnel, assess awareness up to technical vulnerability analysis; for developers, assess awareness of secure coding practices as well.
• Assessment cycle and evidence retention: Conduct assessments at a minimum annually and immediately upon a new participant joining, and retain results for a minimum of 3 years.

Sample

The following is a sample security assurance policy awareness acknowledgment form.

[Open Source Security Assurance Policy Awareness Acknowledgment]

I confirm that I have familiarized myself with the following:

1. The existence and location of the company's open source security assurance policy
2. The objectives of the open source component vulnerability detection, assessment,
   response, and CVD program
3. How my role contributes to the operation of the security assurance program
4. The security breaches, legal liabilities, and business risks that may arise
   from failing to comply with the vulnerability response process

Name: ________________  Role: ________________
Signature: ________________  Date: ________________

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.3 Awareness
• Related guide: Enterprise Open Source Management Guide — 5. Training
• Related template: Open Source Policy Template — §6 Training and Awareness

1.4 - §4.1.4 Program Scope

1. Clause Overview

§4.1.4 is the clause from ISO/IEC 5230 §3.1.4 (Program Scope) with 2 additional Verification Materials. While 5230 only requires a written statement that clearly defines the program’s scope, 18974 additionally requires a set of performance metrics the program seeks to improve upon (4.1.4.2) and documented evidence from each review, update, or audit demonstrating continuous improvement (4.1.4.3). These two items are intended to demonstrate that the security assurance program is not static compliance, but a system with measurable goals that continuously improves.

2. What to Do

• Create a documented written statement that clearly defines the program scope (target software, organizational units, exclusions) (same as 5230).
• Define the performance metrics that the program seeks to improve upon (added in 18974).
• Maintain records demonstrating that continuous improvement is achieved through periodic reviews, updates, and audits (added in 18974).
• Periodically measure actual performance against metric targets and record the results.
• Identify areas for improvement and document the history of follow-up actions.

3. Requirements and Verification Materials

★ = Additional items compared to ISO/IEC 5230 §3.1.4

§4.1.4 Program Scope Different programs may be designed to address different scopes depending on the supplier’s needs and business model. The scope needs to be clear.

Verification Material(s): 4.1.4.1 A written statement that clearly defines the scope and limits of the program. 4.1.4.2 A set of metrics the program seeks to improve upon. 4.1.4.3 Documented evidence from each review, update, or audit to demonstrate continuous improvement.

4. How to Comply and Samples per Verification Material

4.1.4.1 Written Statement of Program Scope

This is the same as ISO/IEC 5230 §3.1.4.1. Refer to §3.1.4.1 Written Statement of Program Scope for how to prepare this. From a security assurance perspective, explicitly state that “response to known and newly discovered vulnerabilities” is included within the scope.

4.1.4.2 Set of Performance Metrics ★

How to Comply

The performance metrics that the security assurance program seeks to improve must be defined and documented. Metrics must be measurable and realistic, and connected to the program’s key objectives (vulnerability detection rate, response time, SBOM completeness, etc.). The metrics set itself is Verification Material 4.1.4.2.

Considerations

• Measurability: Set quantitative indicators rather than qualitative descriptions.
• Realistic targets: Set targets at an achievable level initially and progressively raise them.
• Periodic measurement: Measure metrics at a minimum quarterly and record the results.

Sample

[Security Assurance Program Performance Metrics]

| Metric | Measurement Method | Target | Measurement Cycle |
|--------|--------------------|--------|--------------------|
| SBOM Completeness | Proportion of distributed software with an SBOM | 100% | Quarterly |
| Critical Vulnerability Average Response Time | Detection date to patch application date | 7 days or less | Quarterly |
| High Vulnerability Average Response Time | Detection date to patch application date | 30 days or less | Quarterly |
| Vulnerability Recurrence Rate | Rate of re-vulnerability in the same component | 10% or less | Semi-annually |
| New Participant Awareness Assessment Completion Rate | Rate of assessment completion within 30 days of joining | 100% | Quarterly |
| External Vulnerability Inquiry Response Compliance Rate | Rate of response completion within 14 days | 95% or more | Quarterly |

4.1.4.3 Evidence of Continuous Improvement ★

How to Comply

Records showing that the security assurance program is actually improving through periodic reviews, process updates, internal audits, etc. must be maintained. Document the issues found, improvement actions taken, and improvement results at each review or audit. These records themselves are Verification Material 4.1.4.3.

Considerations

• Regular audit schedule: Conduct a full program audit at a minimum annually and record the results.
• Track improvement history: Track and record whether issues raised in previous audits were resolved in subsequent audits.
• Link to metrics: Use the performance trend of the metrics defined in 4.1.4.2 as evidence of improvement.

Sample

[Security Assurance Program Periodic Review Record]

Review date: 2026-01-10
Reviewers: Gil-dong Hong (Open Source Program Manager), Chul-su Kim (Security)

Metrics performance:
- SBOM Completeness: 97% → 100% (target achieved)
- Critical vulnerability average response time: 9 days → 6 days (target achieved)
- High vulnerability average response time: 35 days → 28 days (target achieved)

Improvements identified:
1. External vulnerability inquiry response compliance rate 88% → target of 95% not met
   Action: Additional inquiry monitoring assignee designated (completed 2026-02-01)
2. Delays in awareness assessment for new participants identified
   Action: Awareness assessment added as mandatory item to onboarding checklist (completed 2026-01-20)

Next review scheduled: 2027-01-09

5. References

• Corresponding ISO/IEC 5230 clause: §3.1.4 Program Scope
• Related guide: Enterprise Open Source Management Guide — 2. Policy
• Related template: Open Source Policy Template — §1.4 Scope

1.5 - §4.1.5 Standard Practice Implementation

1. Clause Overview

§4.1.5 is a new clause exclusive to 18974 that does not exist in ISO/IEC 5230. It requires establishing documented procedures for each of the 8 standard handling methods for open source vulnerabilities. This clause goes beyond a simple declaration of “responding” to vulnerabilities, requiring the formalization of the entire vulnerability lifecycle into procedures — from threat identification, detection, follow-up, customer notification, post-deployment monitoring, continuous security testing, risk verification, to information export. This clause, together with §4.3.2 Security Assurance, forms the core of ISO/IEC 18974.

2. What to Do

Establish documented procedures for each of the 8 methods:

1. Identification of structural and technical threats: Define a method to identify threats affecting the supplied software.
2. Detection of known vulnerabilities: Define a method to detect the existence of known vulnerabilities (CVEs) in open source components.
3. Follow-up on vulnerabilities: Define a method to take follow-up actions such as patching, mitigation, or acceptance for identified vulnerabilities.
4. Customer notification: Define a method to communicate identified vulnerabilities to customers, where applicable.
5. Post-deployment analysis for newly disclosed vulnerabilities: Define a method to analyze already-deployed software for newly published CVEs.
6. Continuous security testing: Define a method to apply continuous and iterative security testing to all supplied software before release.
7. Verification of risk resolution: Define a method to verify that identified risks have been addressed before release.
8. Export of risk information: Define a method to export risk information to third parties, where appropriate.

3. Requirements and Verification Materials

§4.1.5 Standard Practice Implementation A program shall demonstrate defined and implemented processes for sound and robust handling of known vulnerabilities and security software development, specifically by defining and implementing the following:

• A method to identify structural and technical threats to the supplied software;
• A method to detect the existence of known vulnerabilities in the supplied software;
• A method to follow up on identified known vulnerabilities;
• A method to communicate identified known vulnerabilities to customers, where applicable;
• A method to analyze the supplied software for newly disclosed known vulnerabilities when they are published;
• A method to apply continuous and iterative security testing to all supplied software before release;
• A method to verify that identified risks have been addressed before release; and
• A method to export information about identified risks to third parties, where appropriate.

Verification Material(s): 4.1.5.1 A documented procedure exists for each of the methods identified above.

4. How to Comply and Samples per Verification Material

4.1.5.1 Documented Procedures for the 8 Vulnerability Handling Methods

How to Comply

A procedure explaining “how” each of the 8 methods is performed must be documented. These procedures together constitute Verification Material 4.1.5.1. You can create 8 separate documents, or organize all 8 as sections within a single integrated vulnerability management procedure document. The latter approach is recommended as it reduces management burden and is easier to maintain consistency.

Method 1 — Identification of Structural and Technical Threats

Define a method to identify structural (architecture design, dependency structure) and technical (known vulnerable patterns, risky components) threats that may affect the supplied software. Using threat modeling (STRIDE, PASTA, etc.) or periodically analyzing the dependency tree to identify risky components is a common approach.

[Threat Identification Procedure Overview]
- Conduct threat modeling when designing a new software architecture.
- Analyze the dependency tree quarterly to identify EOL (End-of-Life) components,
  abandoned projects, and components with high dependency concentration.
- Register identified threats in the Risk Registry and assign a responsible party.

Method 2 — Detection of Known Vulnerabilities

Define a method to detect the existence of CVEs (Common Vulnerabilities and Exposures) in open source components based on the SBOM. Integrating automated tools (OSV-SCALIBR, Dependency-Track, Grype, etc.) into the CI/CD pipeline to scan for vulnerabilities at every build is an effective approach.

[Vulnerability Detection Procedure Overview]
- Integrate SCA (Software Composition Analysis) tools into the CI/CD pipeline.
- Automatically run SBOM-based vulnerability scans on every build.
- Reference multiple vulnerability databases such as OSV (Open Source Vulnerabilities),
  NVD (National Vulnerability Database), and GitHub Advisory Database.
- Automatically notify the security team of detected vulnerabilities along with their severity.

Method 3 — Follow-up on Vulnerabilities

Define a method to take follow-up actions on identified vulnerabilities, such as applying patches, implementing mitigations, replacing components, or accepting risk. Specify priority and remediation timelines based on CVSS scores in the procedure.

[Follow-up Procedure Overview]
- Determine remediation priority and timelines based on CVSS score:
  Critical (9.0+): within 7 days / High (7.0-8.9): within 30 days
  Medium (4.0-6.9): within 90 days / Low (0.1-3.9): at next release
- If no patch is available, implement mitigation measures (network isolation, WAF rule additions, etc.)
  and risk acceptance decisions require joint approval from the security team and open source PM.
- Record the remediation outcome in the vulnerability tracking system and verify completion.

Method 4 — Customer Notification

Define a method to communicate vulnerabilities to customers when they are discovered in supplied software and may affect customers. Specify the notification criteria (severity, customer impact scope), notification channels, and notification timelines in the procedure.

[Customer Notification Procedure Overview]
- Notify customers for Critical/High vulnerabilities that affect distributed products.
- Notification channels: Product security notice (website), customer security contact email,
  security advisory publication
- Notification timeline: Within 7 days of confirming patch or mitigation measures
- Notification content: Affected components, CVE ID, severity, recommended actions, patch delivery schedule

Method 5 — Post-deployment Analysis for Newly Disclosed Vulnerabilities

Define a method to analyze whether newly published CVEs affect already-deployed software. A monitoring system is needed that retains the SBOM for deployed software and automatically cross-references newly published CVEs against those SBOMs.

[Post-deployment Newly Disclosed Vulnerability Analysis Procedure Overview]
- Retain SBOMs for deployed software by version.
- Use tools such as Dependency-Track to automatically cross-reference newly published CVEs
  against deployed SBOMs and generate a list of affected software versions.
- When affected versions are confirmed, process them according to Method 3 (follow-up)
  and Method 4 (customer notification) procedures.
- Monitoring is performed automatically at all times, with weekly summary reports
  sent to the security team.

Method 6 — Continuous Security Testing

Define a method to apply continuous and iterative security testing to all supplied software before release. Integrating SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and SCA into the CI/CD pipeline is the common approach.

[Continuous Security Testing Procedure Overview]
- Security testing by CI/CD pipeline stage:
  · On code commit: SAST (static analysis), SCA (open source vulnerability scan)
  · On PR merge: Verify passage of security gate (blocking if Critical/High unresolved)
  · On release candidate build: DAST (dynamic analysis), container image scan
- Automatically block release on security test failure and notify the security team.
- Continuously monitor test coverage and results on a dashboard.

Method 7 — Verification of Risk Resolution

Define a method to verify that identified risks have actually been resolved before release. After applying a patch, confirm via rescan that the vulnerability has been eliminated and record the result.

[Risk Resolution Verification Procedure Overview]
- Run a rescan using the same tool after patch or mitigation is complete.
- Confirm that the vulnerability has been eliminated in the rescan result and record
  it in the vulnerability tracking system.
- For Critical/High vulnerabilities, the security team approves the verification result.
- If releasing with unresolved risks, document management approval and a mitigation plan.

Method 8 — Export of Risk Information

Define a method to export identified risk information to third parties (supply chain partners, customers, vulnerability databases, etc.) where appropriate. This includes using the VEX (Vulnerability Exploitability eXchange) format, or procedures for reporting vulnerability information to upstream projects through CVD channels.

[Risk Information Export Procedure Overview]
- When a new vulnerability is independently discovered, report it to the upstream project
  or CERT following CVD procedures.
- Use VEX format when sharing vulnerability impact information with supply chain partners.
- Before sharing with third parties, conduct a legal review to ensure no trade secrets
  or undisclosed information are included.
- Record and retain a log of information exports (recipient, date, content summary).

5. References

• No corresponding ISO/IEC 5230 clause (new clause exclusive to 18974)
• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related tools: OSV-SCALIBR, Dependency-Track

2 - §4.2 Relevant Tasks

2.1 - §4.2.1 Access

1. Clause Overview

§4.2.1 has the same structure as ISO/IEC 5230 §3.2.1 (External Inquiry Response), but the focus shifts from license compliance inquiries to vulnerability inquiries. A publicly visible channel must be established for third parties to make inquiries about known or newly discovered vulnerabilities in the supplied software, and an internal procedure for systematically handling these inquiries must be documented. Since the security vulnerability reporting channel is connected to the Coordinated Vulnerability Disclosure (CVD) procedure, a system for safely receiving and processing vulnerabilities discovered by security researchers or customers is required.

2. What to Do

• Specify a public contact (email address, web form, etc.) on the product or website where third parties can send vulnerability-related inquiries.
• Document the internal procedure for handling vulnerability reports received through the public channel.
• Include the processing stages — receipt, triage, assignment, response, and closure — in the procedure.
• Specify in the procedure a handling policy following CVD principles (confidential collaboration followed by public disclosure).
• Record and retain inquiry receipt and response history for a designated period.

3. Requirements and Verification Materials

§4.2.1 Access Maintain a process to effectively respond to external vulnerability inquiries. Publicly identify a means by which a third party can make an inquiry about known vulnerabilities or newly discovered vulnerabilities.

Verification Material(s): 4.2.1.1 Publicly visible method that allows any third party to make a known vulnerability or newly discovered vulnerability inquiry (e.g., via a published contact email address, or web portal that is monitored by program participants). 4.2.1.2 An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.

4. How to Comply and Samples per Verification Material

4.2.1.1 Publicly Available Vulnerability Inquiry Channel

How to Comply

A public contact for third parties to report or inquire about vulnerabilities must be established and published externally. Publishing a security-dedicated email address (e.g., security@company.com) on product documentation, the website’s security policy page, or in a SECURITY.md file (for GitHub or other open source repositories) is common practice. This public channel itself is Verification Material 4.2.1.1.

This can be operated separately from the ISO/IEC 5230 §3.2.1.1 license inquiry channel, or configured by adding a channel dedicated to security vulnerability reporting.

Considerations

• Separate security-dedicated channel: Operating a license inquiry channel (oss@company.com) and a security vulnerability reporting channel (security@company.com) separately makes it easier to manage processing priorities.
• Guarantee of response: State explicitly that the reporting channel is actively monitored (e.g., “acknowledgment response within 3 business days”).
• Use the security.txt standard: Applying the RFC 9116 security.txt standard makes it easy for security researchers to find contact information.

Sample

[Website Security Policy Page / SECURITY.md Sample]

## Security Vulnerability Reporting

To report a security vulnerability in our software, please use the channel below.
We follow Coordinated Vulnerability Disclosure (CVD) practices.

- Reporting email: security@company.com
- Acknowledgment: Within 3 business days
- Handling policy: Vulnerabilities are reviewed confidentially and disclosed after patching

4.2.1.2 Internal Vulnerability Inquiry Response Procedure

How to Comply

A procedure for internally handling vulnerability reports received from external parties must be documented. Following CVD principles, the basic framework involves collaborating confidentially with the reporter to resolve the vulnerability and then disclosing it after the patch is ready. This procedure document is Verification Material 4.2.1.2.

Considerations

• Follow CVD principles: Maintain confidentiality with the reporter until the vulnerability is resolved and agree on a disclosure schedule.
• Processing timelines: Specify timelines for each stage — acknowledgment, vulnerability verification, patch delivery, and disclosure — in the procedure.
• Record retention: Retain the report content, review process, response actions, and disclosure history for a minimum of 3 years.

Sample

[External Vulnerability Report Response Procedure]

1. Receipt and Acknowledgment (within 3 business days)
   - Check the security@company.com inbox daily.
   - Reply to the reporter with an acknowledgment and a promise of confidential handling.

2. Vulnerability Verification (within 7 business days)
   - The security team verifies the reproducibility and impact scope of the reported vulnerability.
   - Calculate the CVSS score and classify the severity.

3. Patch Development and Remediation (7–90 days depending on severity)
   - Perform patching or mitigation according to the §4.1.5 Method 3 (follow-up) procedure.
   - Share the patch schedule with the reporter and coordinate as needed.

4. Disclosure (after patch is complete)
   - Draft a Security Advisory, confirm with the reporter, and publish.
   - Request CVE ID issuance if necessary.
   - Notify affected customers according to the §4.1.5 Method 4 (customer notification) procedure.

5. Record Retention
   - Retain the report content, review process, remediation outcome, and disclosure history
     for a minimum of 3 years.

5. References

• Corresponding ISO/IEC 5230 clause: §3.2.1 External Inquiry Response
• Related guide: Enterprise Open Source Management Guide — 3. Process

2.2 - §4.2.2 Effectively Resourced

1. Clause Overview

§4.2.2 corresponds to ISO/IEC 5230 §3.2.2 (Effectively Resourced) but has two key differences. First, while 5230 requires 5 Verification Materials, 18974 requires 4. The §3.2.2.5 item from 5230 (procedure for reviewing and correcting non-compliance cases) is absorbed into §4.1.5 Standard Practice Implementation in 18974. Second, §3.2.2.3 (method for accessing legal expertise) is replaced in §4.2.2.3 by vulnerability resolution expertise. Rather than legal expertise for license matters, the organization must secure technical and security expertise capable of actually resolving known vulnerabilities and document how that expertise is accessed.

2. What to Do

• Document the names or job titles of personnel assigned to each role in the program.
• Confirm and record that sufficient time and budget are allocated to each role assignee.
• Identify and document the internal or external security expertise available to resolve known vulnerabilities (different focus from 5230).
• Document the procedure for assigning internal responsibility for security assurance compliance to each role.

3. Requirements and Verification Materials

★ = Different from ISO/IEC 5230 §3.2.2.3 (legal expertise) — focus shifted to security expertise

§4.2.2 Effectively Resourced Identify and Resource Program Task(s):

• Assign accountability to ensure the successful execution of program tasks.
• Program tasks are sufficiently resourced.

Verification Material(s): 4.2.2.1 A document with the names of the persons, group or function in program role(s) identified. 4.2.2.2 The identified program roles have been properly staffed and adequate funding provided. 4.2.2.3 A document identifying the expertise available to address identified known vulnerabilities. 4.2.2.4 A documented procedure that assigns internal responsibilities for security assurance.

4. How to Comply and Samples per Verification Material

4.2.2.1 Document Identifying Role Assignees

This is the same as ISO/IEC 5230 §3.2.2.1. Security assurance roles (DevSecOps engineer, vulnerability analysis personnel, etc.) must be specified. Refer to §3.2.2.1 Document Identifying Role Assignees for how to prepare this.

4.2.2.2 Confirmation of Staffing and Budget Support

This is the same as ISO/IEC 5230 §3.2.2.2. Security-related budget items such as vulnerability scanning tools, security training, and external security consulting should be included. Refer to §3.2.2.2 Confirmation of Staffing and Budget Support for how to prepare this.

4.2.2.3 Document Identifying Vulnerability Resolution Expertise ★

How to Comply

The expertise available to actually analyze and resolve identified known vulnerabilities must be identified and documented. This differs in nature from the legal expertise access method in ISO/IEC 5230 §3.2.2.3. If an internal security team exists, record that team’s competencies and contact information; if internal expertise is insufficient, document how external security experts or PSIRT (Product Security Incident Response Team) services are utilized.

Considerations

• Internal expertise list: Identify internal experts or responsible teams by vulnerability type (web security, firmware security, cryptography, etc.).
• Securing external expertise: For vulnerability types that are difficult to handle internally, record contract details or contact methods with external security organizations (CERT, security consulting firms).
• Escalation criteria: Specify the criteria under which external expertise is utilized.

Sample

[Vulnerability Resolution Expertise Status]

Internal expertise:
- Security (Chul-su Kim): Web vulnerabilities, open source component CVE analysis, CVSS assessment
- DevSecOps team: CI/CD security pipeline operation, container vulnerability analysis

Criteria for utilizing external expertise:
- When zero-day vulnerabilities, firmware vulnerabilities, or cryptography-related vulnerabilities occur
- When the internal team determines that resolution within 30 days is not feasible

External organizations:
- [External Security Consulting Firm Name] (annual contract, vulnerability analysis service)
- KrCERT/CC (vulnerability coordination and reporting channel)

4.2.2.4 Internal Responsibility Assignment Procedure

This has the same structure as ISO/IEC 5230 §3.2.2.4, but must include the assignment of security assurance-specific responsibilities (vulnerability detection, CVSS assessment, customer notification, CVD management, etc.) to each role. Refer to §3.2.2.4 Internal Responsibility Assignment Procedure for preparation, and reflect security tasks as shown in the sample below.

Sample

| Task | Open Source PM | Security | IT | Developer |
|------|----------------|----------|----|-----------|
| Vulnerability scan tool operation | I | C | A/R | I |
| CVE detection and classification | I | A/R | C | I |
| CVSS score assessment | I | A/R | - | C |
| Patch application and verification | C | A | C | R |
| Customer notification decision | A | R | - | I |
| CVD external report response | C | A/R | - | I |
| Vulnerability record management | I | A/R | C | I |

R: Responsible / A: Accountable / C: Consulted / I: Informed

5. References

• Corresponding ISO/IEC 5230 clause: §3.2.2 Effectively Resourced
• Related guide: Enterprise Open Source Management Guide — 1. Organization

3 - §4.3 Content Review and Approval

3.1 - §4.3.1 SBOM

1. Clause Overview

§4.3.1 has the same basic structure as ISO/IEC 5230 §3.3.1 (SBOM), but the emphasis differs. While 5230 covers the SBOM for license management of open source components, §4.3.1 of 18974 emphasizes continuously recording and retaining the SBOM throughout the entire software lifecycle. In particular, the SBOM must be maintained even after deployment so it can be integrated with the vulnerability monitoring in §4.3.2 Security Assurance. Without an SBOM, post-deployment impact analysis for newly published CVEs (§4.1.5 Method 5) cannot be performed.

2. What to Do

• Establish a procedure for identifying, tracking, reviewing, and approving open source components in the supplied software (same as 5230).
• Establish a procedure for continuously recording and retaining the SBOM throughout the software lifecycle (emphasized in 18974).
• Retain SBOMs by version for deployed software to use in post-deployment vulnerability impact analysis.
• Integrate SBOM information with vulnerability management tools (such as Dependency-Track) so that automatic impact analysis occurs whenever new CVEs are published.
• Define triggers for immediately updating the SBOM when components are added, changed, or removed.

3. Requirements and Verification Materials

§4.3.1 Software Bill of Materials A process shall exist for creating and managing a software bill of materials that includes each open source software component (and its identified licenses) from which the supplied software is comprised, in a manner that ensures the supplied software’s open source software components are continuously recorded throughout the supplied software’s life cycle, including archiving.

Verification Material(s): 4.3.1.1 A documented procedure to ensure that all open source software used in the supplied software is continuously recorded during the life cycle of the supplied software. This includes an archive of all open source software used in the supplied software. 4.3.1.2 Open source software component records for the supplied software that demonstrates the documented procedure was followed.

4. How to Comply and Samples per Verification Material

4.3.1.1 SBOM Lifecycle Continuous Recording Procedure

How to Comply

Building on the SBOM management procedure from ISO/IEC 5230 §3.3.1.1, the procedure must be strengthened to focus on continuous lifecycle recording and archiving. This procedure document is Verification Material 4.3.1.1.

From a security assurance perspective, the key to SBOM management is that the SBOM must remain valid even after deployment so it can be immediately used for impact analysis whenever new CVEs are published. To this end, the procedure must include archiving the SBOMs of all deployed software versions and integrating with vulnerability management tools.

Considerations

• Maintain SBOM at each lifecycle stage: Define procedures to keep the SBOM current at each stage — development, build, deployment, and post-deployment monitoring.
• Archive policy: Archive the SBOMs of all deployed versions by version and specify the retention period (minimum: support period of the relevant software + 3 years).
• Integration with vulnerability tools: Import SBOMs into tools such as Dependency-Track so that automatic cross-referencing occurs every time new CVEs are published.
• Update triggers: Mandate SBOM updates upon the following events: component addition, version upgrade, component removal, license change, and replacement due to newly discovered vulnerabilities.

Sample

The following is a sample overview of an SBOM management procedure enhanced from a security assurance perspective.

[SBOM Lifecycle Management Procedure Overview]

(1) Development stage
    - Register open source components in the SBOM immediately upon introduction.
    - SCA tools (Syft, cdxgen, etc.) in the CI/CD pipeline automatically detect them.

(2) Build stage
    - Automatically generate the latest SBOM on every build (SPDX or CycloneDX format).
    - Integrate with vulnerability scanning tools to record the vulnerability status at build time.

(3) Deployment stage
    - Finalize the SBOM for the release version and store it in the archive repository.
    - Import the SBOM into Dependency-Track to activate continuous monitoring.

(4) Post-deployment monitoring
    - When new CVEs are published, automatically cross-reference against all archived version SBOMs.
    - When affected versions are confirmed, process them according to the §4.1.5 Method 5 procedure.

(5) Update triggers
    - Update the SBOM immediately upon the following events:
      · Component addition, version upgrade, component removal
      · License change, replacement due to newly discovered vulnerability

(6) Archive retention
    - Retain SBOMs of all deployed versions by version.
    - Retention period: Minimum 3 years after the official support end of the relevant software

4.3.1.2 Open Source Component Records (SBOM)

This is the same as ISO/IEC 5230 §3.3.1.2. From a security assurance perspective, recording the known vulnerability status of each component or a link to the vulnerability management tool alongside license information in the SBOM makes integration with §4.3.2 easier. Refer to §3.3.1.2 Open Source Component Records for how to prepare this.

5. References

• Corresponding ISO/IEC 5230 clause: §3.3.1 SBOM
• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related tools: Syft, cdxgen, Dependency-Track

3.2 - §4.3.2 Security Assurance

1. Clause Overview

§4.3.2 is the core clause of ISO/IEC 18974 and is a new clause exclusive to 18974 that does not exist in ISO/IEC 5230. It requires establishing a procedure covering the entire process — vulnerability detection → risk assessment → remediation decision → customer consent (where applicable) → remediation → post-deployment newly disclosed vulnerability response → continuous monitoring — for each open source component in the SBOM, and maintaining implementation records. If §4.1.5 requires the existence of vulnerability handling methods, §4.3.2 requires that those methods have actually been applied to each component with records retained.

2. What to Do

• Detect the existence of known vulnerabilities in each open source component in the SBOM.
• Assign a risk/impact score (CVSS) to each detected vulnerability.
• Determine and document the necessary remediation or mitigation steps for each vulnerability.
• Obtain customer consent above a pre-determined threshold, where applicable.
• Perform appropriate actions based on the risk/impact score and record them.
• Perform appropriate actions for newly disclosed vulnerabilities in already-deployed software.
• Monitor and respond to vulnerability disclosures for the supplied software after its release.
• Maintain detection and remediation results per vulnerability as component records.

3. Requirements and Verification Materials

§4.3.2 Security Assurance There shall exist a process to apply security assurance activities to each open source software component that is to be included in the bill of materials (SBOM):

• Applying a method to detect the existence of known vulnerabilities;
• Assign a risk/impact score to each identified known vulnerability;
• Determine and document the necessary remediation or mitigation steps for each detected and scored known vulnerability;
• Obtain customer approval above a pre-determined threshold, where applicable;
• Perform appropriate action based on risk/impact score;
• Perform appropriate action for newly disclosed known vulnerabilities in previously released supplied software;
• Ability to monitor and respond to vulnerability disclosures for the supplied software after its release.

Verification Material(s): 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.2 For each open source software component, a record is maintained of the identified known vulnerabilities and action taken (including a determination that no action was required).

4. How to Comply and Samples per Verification Material

4.3.2.1 Vulnerability Detection and Resolution Procedure

How to Comply

A documented procedure covering the entire process from vulnerability detection to resolution for each open source component in the SBOM is Verification Material 4.3.2.1. This procedure is a concrete operational flow that integrates the individual methods defined in §4.1.5.

The flowchart below illustrates the entire flow from CVE detection to remediation completion.

flowchart TD
    A([SBOM Component]) --> B[Vulnerability Scan\nSCA Tool]
    B --> C{CVE Detected?}
    C -- No --> D[Record: No Detection\nAwait Periodic Rescan]
    C -- Yes --> E[Calculate CVSS Score\nRisk/Impact Assessment]
    E --> F{Severity Classification}
    F -- Critical/High --> G[Immediate Response\n7–30 day deadline]
    F -- Medium --> H[Planned Response\n90 day deadline]
    F -- Low --> I[Address at Next Release]
    G --> J{Customer Impact?}
    H --> J
    J -- Yes --> K[Customer Notification\n§4.1.5 Method 4]
    J -- No --> L[Remediation Decision]
    K --> L
    L --> M{Patch Available?}
    M -- Yes --> N[Apply Patch\nRescan Verification]
    M -- No --> O[Mitigation Measures\nor Risk Acceptance]
    N --> P[Record Remediation Result\n§4.3.2.2]
    O --> P
    P --> Q([Continuous Monitoring\n§4.1.5 Method 5])

Detailed Steps

The following is a sample describing each step of the flowchart in procedure document form.

[Vulnerability Detection and Resolution Procedure]

Step 1 — Vulnerability Detection
- At CI/CD pipeline build, SCA tools (Dependency-Track, OSV-SCALIBR, etc.)
  automatically scan for vulnerabilities based on the SBOM.
- Reference multiple vulnerability DBs such as NVD, OSV, and GitHub Advisory Database.
- Even after deployment, automatically cross-reference against archived SBOMs
  when new CVEs are published.

Step 2 — Risk/Impact Score Assessment
- Calculate the CVSS v3.1 base score for each detected CVE.
- Adjust the Environmental Score by considering the actual usage context of the
  company's product (network exposure, privilege requirements, etc.).
- Severity classification: Critical (9.0+) / High (7.0-8.9) / Medium (4.0-6.9) / Low (0.1-3.9)

Step 3 — Remediation Decision and Documentation
- Determine the remediation method based on severity and customer impact scope:
  · Patch application: Upgrade to a newer version or apply a patch
  · Mitigation: Network isolation, disabling functionality, etc. when no patch is available
  · Risk acceptance: When the actual exploitability is low and mitigation is also unnecessary
    (joint approval from security team + open source PM required)
- Record the basis for the remediation decision in the vulnerability tracking system.

Step 4 — Customer Consent (where applicable)
- For Critical/High vulnerabilities affecting customer-distributed products:
  · Proactively notify the customer's security contact of vulnerability information
    and the response plan.
  · Share the patch deployment schedule and mitigation methods.

Step 5 — Remediation
- Perform the determined remediation within the remediation deadline.
- Run a rescan after patch application to confirm the vulnerability is eliminated.
- Update the remediation completion result in the §4.3.2.2 record.

Step 6 — Continuous Monitoring
- Continuously monitor the vulnerability status of deployed software using tools
  such as Dependency-Track.
- When new CVEs are published, automatically or immediately re-execute steps 1–3.

4.3.2.2 Vulnerability and Action Records

How to Comply

For each open source component in the SBOM, records of identified vulnerabilities and actions taken (including a determination that no action was required) must be maintained. These records are Verification Material 4.3.2.2. The phrase “including a determination that no action was required” is important — components where no vulnerability was detected must also record the fact that a scan was performed and the detection result.

Records can be managed using various tools such as Dependency-Track, a Jira security issue tracker, or spreadsheets, and must be maintained in a form that can be produced immediately during an audit.

Considerations

• Record per component: Maintain individual records for each component in the SBOM.
• Record “no detection” as well: Record the scan date and result even for components where no vulnerability was detected.
• Track remediation history: Manage the history of vulnerability occurrence, remediation, and rescan for the same component in chronological order.
• Retention period: Retain for the support period of the relevant software plus a minimum of 3 years.

Sample

The following is a sample per-component vulnerability and action record.

| Software | Version | Component | Component Version | CVE ID | CVSS | Severity | Action | Action Date | Assignee | Notes |
|----------|---------|-----------|-------------------|--------|------|----------|--------|-------------|----------|-------|
| MyProduct | v1.2.0 | openssl | 3.0.7 | CVE-2023-0286 | 7.4 | High | Upgraded to 3.0.8 | 2023-02-10 | Chul-su Kim | Rescan confirmed |
| MyProduct | v1.2.0 | zlib | 1.2.11 | CVE-2022-37434 | 9.8 | Critical | Upgraded to 1.2.13 | 2022-10-15 | Chul-su Kim | Customer notified |
| MyProduct | v1.2.0 | libpng | 1.6.37 | None | - | - | No action required | 2023-03-01 | Chul-su Kim | Periodic scan result |
| FirmwareX | v2.3.0 | busybox | 1.35.0 | CVE-2022-28391 | 9.8 | Critical | Risk acceptance (network isolation mitigation) | 2022-11-20 | Chul-su Kim | No patch available, PM approval obtained |

5. References

• No corresponding ISO/IEC 5230 clause (new clause exclusive to 18974)
• Related guide: Enterprise Open Source Management Guide — 3. Process
• Related tools: Dependency-Track, OSV-SCALIBR
• Related clauses: §4.1.5 Standard Practice Implementation, §4.3.1 SBOM

4 - §4.4 Conformance

4.1 - §4.4.1 Completeness

1. Clause Overview

§4.4.1 corresponds to ISO/IEC 5230 §3.6.1 (Conformance). A document must be prepared affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974. The structure is the same as 5230 §3.6.1, but the difference is that the subject of confirmation covers all 25 Verification Material items of 18974. When preparing for ISO/IEC 5230 and 18974 certification simultaneously, it is efficient to conduct an integrated review of the common items of both standards and then additionally confirm the 9 items exclusive to 18974 (marked with ★).

2. What to Do

• Conduct a self-assessment to verify that all Verification Materials (25 items) of all clauses from §4.1 to §4.3 are in place.
• Prepare a document affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974 within the defined scope.
• Record the reviewer, approver, and confirmation date in the confirmation document.
• When simultaneously complying with ISO/IEC 5230 and 18974, use an integrated checklist to reduce duplicated review burden.

3. Requirements and Verification Materials

§4.4.1 Completeness In order for a program to be deemed conformant with this specification, the organization shall affirm that the program satisfies the requirements presented in this specification.

Verification Material(s): 4.4.1.1 Documented evidence affirming the program specified in §4.1.4 satisfies all the requirements of this specification.

4. How to Comply and Samples per Verification Material

4.4.1.1 Specification Conformance Confirmation Document

How to Comply

A document affirming that the program defined in §4.1.4 satisfies all requirements of ISO/IEC 18974 within the defined scope must be prepared. This document is Verification Material 4.4.1.1. Use the checklist below to review all 25 Verification Material items and record the confirmation results.

ISO/IEC 18974 Conformance Self-Assessment Checklist

§4.1 Program Foundation
[ ] 4.1.1.1 Documented security assurance policy
[ ] 4.1.1.2 Procedure for communicating policy awareness
[ ] 4.1.2.1 List of roles and responsibilities
[ ] 4.1.2.2 Document identifying competencies per role
[ ] 4.1.2.3 List of participants and role mapping ★
[ ] 4.1.2.4 Evidence of assessed competence
[ ] 4.1.2.5 Evidence of periodic reviews and changes ★
[ ] 4.1.2.6 Verification of alignment with internal best practices ★
[ ] 4.1.3.1 Evidence of assessed awareness for participants
[ ] 4.1.4.1 Written statement of program scope
[ ] 4.1.4.2 Set of performance metrics ★
[ ] 4.1.4.3 Evidence of continuous improvement ★
[ ] 4.1.5.1 Documented procedures for 8 vulnerability handling methods ★

§4.2 Relevant Tasks
[ ] 4.2.1.1 Publicly available vulnerability inquiry channel
[ ] 4.2.1.2 Internal vulnerability inquiry response procedure
[ ] 4.2.2.1 Document identifying role assignees
[ ] 4.2.2.2 Confirmation of staffing and budget
[ ] 4.2.2.3 Document identifying vulnerability resolution expertise ★
[ ] 4.2.2.4 Internal responsibility assignment procedure

§4.3 Content Review and Approval
[ ] 4.3.1.1 SBOM lifecycle continuous recording procedure
[ ] 4.3.1.2 Open source component records (SBOM)
[ ] 4.3.2.1 Vulnerability detection and resolution procedure ★
[ ] 4.3.2.2 Vulnerability and action records ★

§4.4 Conformance
[ ] 4.4.1.1 Document affirming all requirements are satisfied
[ ] 4.4.2.1 Document affirming requirements satisfied within past 18 months

★ = Additional items compared to ISO/IEC 5230 (9 items)

Considerations

• Integrated review with 5230: If ISO/IEC 5230 certification is held, reuse existing materials for the 16 common items and focus on the 9 items exclusive to 18974.
• Approval procedure: Formalize the document through review by the Open Source Program Manager and approval by management.
• Specify specification version: Specify ISO/IEC 18974:2023 (version 1.0) as the specification confirmed for conformance in the document.

Sample

[ISO/IEC 18974 Specification Conformance Confirmation]

Program name: [Company name] Open Source Security Assurance Program
Scope: [Scope as defined in §4.1.4]
Specification confirmed for conformance: ISO/IEC 18974:2023 (version 1.0)
Confirmation date: YYYY-MM-DD

This document affirms that the above program satisfies all requirements
(25 Verification Material items) of ISO/IEC 18974:2023 from §4.1 through §4.4.

Conformance confirmation summary:
- §4.1 Program Foundation (5 clauses, 13 Verification Materials): Satisfied ✓
- §4.2 Relevant Tasks (2 clauses, 6 Verification Materials): Satisfied ✓
- §4.3 Content Review and Approval (2 clauses, 4 Verification Materials): Satisfied ✓
- §4.4 Conformance (2 clauses, 2 Verification Materials): Satisfied ✓

Reviewer: [Open Source Program Manager name]
Approver: [Management or OSRB head name]
Approval date: YYYY-MM-DD

5. References

• Corresponding ISO/IEC 5230 clause: §3.6.1 Conformance
• ISO/IEC 18974 self-certification: https://certification.openchainproject.org/
• Full clause checklist: ISO/IEC 18974 Conformance Guide

4.2 - §4.4.2 Duration

1. Clause Overview

§4.4.2 has the same structure as ISO/IEC 5230 §3.6.2 (Duration). It requires organizations to maintain a document confirming that all requirements of the specification are met within the past 18 months of obtaining conformance. When a new version of the specification is published, conformance under the previous version is maintained for a grace period of 18 months, during which it is recommended to update to the latest version.

2. What to Do

• Record and manage the date on which conformance was obtained.
• Within the past 18 months of obtaining conformance, re-confirm and document that all requirements of the specification are still met.
• If a new version of ISO/IEC 18974 is published, update the program to meet the latest version and re-confirm within 18 months.
• Conduct periodic internal audits to verify that all 25 verification material items remain continuously compliant.

3. Requirements and Verification Materials

4. How to Comply with Each Verification Material

4.4.2.1 Document Confirming All Requirements Met Within 18 Months

How to Comply

In the same manner as ISO/IEC 5230 §3.6.2.1, review and update the specification conformance document from §4.4.1.1 at least once a year. Each time it is updated, record the review date and reviewer to demonstrate that a review was conducted within the past 18 months.

For organizations operating both ISO/IEC 5230 and 18974 simultaneously, consolidating the periodic re-confirmation schedules for both specifications into a single annual integrated audit improves management efficiency.

Sample

[ISO/IEC 18974 Specification Conformance Periodic Re-confirmation Record]

Initial Conformance Date: YYYY-MM-DD
Specification Version Confirmed: ISO/IEC 18974:2023 (Version 1.0)

| Re-confirmation Date | Result | Changes | Reviewer | Notes |
|----------------------|--------|---------|----------|-------|
| 2025-01-10 | Fully Met | Vulnerability resolution expertise document updated (§4.2.2.3) | John Doe | - |
| 2026-01-08 | Fully Met | Performance metric targets raised (§4.1.4.2) | John Doe | - |

Next re-confirmation scheduled: YYYY-MM-DD
18-month validity deadline: YYYY-MM-DD

5. References

• Corresponding ISO/IEC 5230 clause: §3.6.2 Duration
• Check latest OpenChain specification version: https://www.openchainproject.org/security-assurance

5 - ISO/IEC 5230 vs 18974 Comparison

1. Relationship Between the Two Standards

ISO/IEC 5230 and ISO/IEC 18974 are both international open source standards led by the OpenChain Project, but they address different problems. 5230 covers open source license compliance (fulfillment of copyright obligations, SBOM management, and distribution of Compliance Artifacts), while 18974 covers open source security assurance (vulnerability detection, assessment, response, and CVD). The two standards do not have a complete superset/subset relationship. They share 9 common clauses covering policy, competence, SBOM, and similar areas, but each has its own exclusive clauses — 5230 has clauses for license compliance, artifacts, and contributions, while 18974 has clauses for Standard Practice Implementation and Security Assurance.

Complying with both standards simultaneously allows license obligation fulfillment and security vulnerability management to be operated as a single integrated open source program. Common foundational documents (policy, competence records, SBOM procedures) can be written once and used for both standards simultaneously, so the practical additional work required to prepare for 18974 after obtaining 5230 certification is approximately 30–40% of the total.

2. Clause-by-Clause Comparison Table

Summary

• Common clauses: 9 (16 Verification Materials)
• 5230-exclusive clauses: §3.3.2, §3.4.1, §3.5.1 (6 Verification Materials)
• 18974-exclusive clauses: §4.1.5, §4.3.2 (3 Verification Materials)
• Common clauses expanded in 18974: 4 — §4.1.1, §4.1.2, §4.1.4, §4.2.2 (+6 Verification Materials)

3. Verification Material Count Comparison

4. Strategy for Simultaneous Conformance with Both Standards

The most efficient path is to obtain 5230 first and then prepare for 18974 as an addition. The policy documents, competence records, and SBOM procedures built during the 5230 certification process can be directly used for 18974’s common clauses (§4.1.1–§4.1.4, §4.2.1, §4.2.2, §4.3.1, §4.4.1, §4.4.2). What needs to be separately prepared are additions to existing documents and 2 new clauses exclusive to 18974.

The items that need to be newly prepared exclusively for 18974 are as follows:

• §4.1.5 Standard Practice Implementation: Documented procedures for each of the 8 vulnerability handling methods (threat identification, detection, follow-up, customer notification, post-deployment analysis, security testing, risk verification, and information export)
• §4.3.2 Security Assurance: Full process from CVE detection → risk assessment → remediation decision → execution → monitoring, and per-component vulnerability action records
• Supplementing common clauses: Additional preparation of §4.1.2 list of participants (4.1.2.3), evidence of periodic review (4.1.2.5), alignment with best practices (4.1.2.6), §4.1.4 performance metrics (4.1.4.2), and evidence of continuous improvement (4.1.4.3)

The practical workload for an organization with a 5230 framework to additionally prepare for 18974 is estimated to be approximately 30–40% of the total 5230 preparation work.

5. Reference Links

• ISO/IEC 5230 Conformance Guide
• ISO/IEC 18974 Conformance Guide
• Enterprise Open Source Management Guide
• OpenChain Self-Certification