§4.3 Content Review and Approval

• 1: §4.3.1 SBOM
• 2: §4.3.2 Security Assurance

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

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