Supply Chain Security Standards, Regulations and Frameworks Tracker

Regulation (EU) 2023/1230 on machinery (consolidated 29 June 2023, 126 pages). Replaces Directive 2006/42/EC. Applies generally from 20 January 2027. The text does not explicitly mention SBOM, Software Bill of Materials, CycloneDX, SPDX, or VEX. Classification is Implicit because the regulation treats safety-critical software as a first-class object with transparency and identification requirements.

SBOM-adjacent provisions

• Annex III 1.1.9 (Protection against corruption) - "The machinery or related product shall identify the software installed on it that is necessary for it to operate safely, and shall be able to provide that information at all times in an easily accessible form" - a direct software-inventory requirement for safety-critical software.
• Article 3(3) - "safety component" explicitly includes physical or digital components, including software.
• Article 3(35) - defines "source code" as the currently installed software version.
• Annex I items 18-19 - software ensuring safety functions and ML-based self-evolving safety systems listed as high-risk categories requiring full conformity assessment.
• Article 20 - Cybersecurity Act (EU) 2019/881 certificates can be used to demonstrate conformity with Annex III 1.1.9 and 1.2.1.

No explicit vulnerability disclosure process, timelines, or patch mandates. Classification is Implicit because cybersecurity-adjacent integrity requirements apply to safety-critical software.

• Annex III 1.1.9 (Protection against corruption) - Safety-critical software and data must be identified and protected against accidental or intentional corruption. Machinery must collect evidence of legitimate or illegitimate intervention (tamper evidence).
• Annex III 1.2.1 (Safety and reliability of control systems) - Control systems must withstand "reasonably foreseeable malicious attempts from third parties leading to a hazardous situation".
• Article 20 - Compliance with 1.1.9 and 1.2.1 may be demonstrated via Cybersecurity Act (EU) 2019/881 certificates.

No specific disclosure hours mandated.

DRAFT amendment to IEC 62443-4-2:2019 (Technical Security Requirements for IACS Components). Being developed to align IACS component cybersecurity with the EU Cyber Resilience Act, giving manufacturers a standards-based path to CRA compliance and market access.

• Purpose: Voluntary standard that helps manufacturers demonstrate conformity to CRA essential cybersecurity requirements.
• Scope: Technical security requirements for IACS components: embedded devices, network components, host components, and software applications. Builds on the seven Foundational Requirements of 62443-4-2:2019.
• SBOM addition: Introduces SBOM as a first-class evaluation artifact, with SBOM validation, SBOM-based vulnerability checks, and binary software composition analysis across escalating test-grade profiles.
• Role vs CRA: The CRA is the mandatory regulation; this amendment is voluntary technical best practice that supports CRA obligations.
• Status: Public enquiry 13 March 2026 to 6 May 2026 via BSI (committee GEL/65/3). Full draft text accessible only to registered commenters.

DRAFT amendment. Expands component-level vulnerability-management testing to support CRA compliance.

• Scope: Component technical capabilities including Timely Response to Events and Support for Updates; the companion 62443-4-1 defines the surrounding vulnerability-handling process.
• Amendment focus: Adds security test modules covering vulnerability scanning, patch-level scanning, and SBOM-driven vulnerability checks.
• CRA alignment: Helps manufacturers demonstrate conformity to CRA vulnerability-handling requirements.
• Final requirements: Confirmed when the final amendment is published.

DRAFT amendment to IEC 62443-4-1:2018 (Secure Product Development Lifecycle for IACS). Being developed to align IACS development practices with the EU Cyber Resilience Act so manufacturers have a standards-based path to CRA compliance and market access.

• Purpose: Voluntary standard that helps manufacturers demonstrate conformity to CRA essential cybersecurity requirements.
• Scope: Secure development lifecycle for IACS product makers: security management, requirements, design, implementation, verification, defect management, and security update management.
• SBOM addition: Adds explicit SBOM generation and maintenance into the development lifecycle, tying component inventory to product release and vulnerability response.
• Role vs CRA: The CRA is the mandatory regulation; this amendment is voluntary technical best practice that supports CRA obligations.
• Status: Public enquiry 13 March 2026 to 6 May 2026 via BSI (committee GEL/65/3). Full draft text accessible only to registered commenters.

DRAFT amendment. Ties IACS vulnerability handling to SBOM-driven component visibility and aligns with EU CRA Article 14 reporting obligations.

• Scope: Vulnerability-handling process manufacturers implement for IACS products, building on the security-management and security-update-management practices in 62443-4-1:2018.
• Amendment focus: Strengthens pre-release verification that security issues have been addressed and requires SBOM-driven component tracking as the foundation for vulnerability response.
• CRA alignment: Provides a voluntary standards path that supports CRA vulnerability-handling and notification duties.
• Final requirements: Confirmed when the final amendment is published.

EU Cyber Resilience Act (Regulation 2024/2847) mandates SBOM as an Annex I essential requirement for products with digital elements. Full application date: 11 December 2027.

SBOM-related provisions

• Article 13: Manufacturers ensure products meet essential cybersecurity requirements.
• Annex I Part I: Products must deliver appropriate cybersecurity by design.
• Annex I Part II(1): Identify components and produce Software Bill of Materials.

EU CRA vulnerability management obligations include 24h/72h/14-day notification of actively exploited vulnerabilities to ENISA and mandatory coordinated vulnerability disclosure.

Vulnerability management requirements

• Article 14(2): Notify ENISA of exploited vulnerability within 24 hours.
• Article 14(3): Provide detailed vulnerability notification within 72 hours.
• Article 14(5): Submit final vulnerability report within 14 days.
• Annex I Part II(2): Address vulnerabilities without delay via security updates.
• Annex I Part II(5): Adopt and enforce coordinated vulnerability disclosure policy.

EU AI Act (Regulation (EU) 2024/1689) establishes horizontal rules for AI systems placed on the EU market. The Act does not name "AIBOM" but its technical-documentation requirements in Annex IV align closely with emerging SPDX 3.0 AIBOM and CycloneDX ML-BOM specifications — research (Frontiers, 2026) shows SPDX 3.0 AIBOM satisfies 13 of 14 Annex IV obligations. High-risk AI providers must document datasets, model training, and software components. Main application date: 2 August 2026 (prohibitions from 2 February 2025; general-purpose AI from 2 August 2025).

SBOM / AIBOM-related provisions

• Article 10: Data governance: training, validation, and test dataset documentation.
• Article 11: Technical documentation per Annex IV before placing on market.
• Article 12: Record-keeping and automatic log retention.
• Article 13: Transparency and information obligations to deployers.
• Article 53: GPAI providers: technical documentation of training content.
• Annex IV: Detailed technical-documentation content list (AIBOM-equivalent).

AI Act vulnerability management focuses on robustness, cybersecurity, and post-market incident reporting for high-risk AI systems. Article 73 sets incident-reporting timelines to national market-surveillance authorities.

Vulnerability management requirements

• Article 9: Risk management system across the AI lifecycle.
• Article 15: Accuracy, robustness, and cybersecurity requirements for high-risk AI.
• Article 55: GPAI with systemic risk: incident tracking and mitigation.
• Article 72: Post-market monitoring by providers.
• Article 73(2): Report serious incidents to market-surveillance authorities.
• Article 73(3): 15-day deadline (2 days for widespread infringement or critical-infrastructure damage; 10 days for death).

FDA guidance (Feb 2026) requires machine-readable SBOM per FD&C Act §524B(b)(3) for all cyber devices. FDA may issue Refuse to Accept (RTA) for missing SBOM.

SBOM-related provisions

• Section IV.A: Integrate cybersecurity into the Quality Management System.
• Section VI: Provide cybersecurity transparency through device labeling.
• Section VII.C.3 (§524B(b)(3)): Provide machine-readable SBOM with premarket submission.

Companion reading: MITRE Cybersecurity Risk Analysis for Medical Devices in the Era of Evolving Technologies (April 2026) extends SBOM scope to cloud, AI/ML, and cryptographic components.

FDA guidance requires security risk management, cybersecurity testing, coordinated vulnerability disclosure, and postmarket monitoring throughout the device lifecycle.

Vulnerability management requirements

• Section V.A: Apply security risk management with threat modeling.
• Section V.C: Perform cybersecurity testing including penetration testing.
• Section VII.A (§524B(b)(1)): Monitor and address postmarket vulnerabilities.
• Section VII.B (§524B(b)(2)): Maintain coordinated vulnerability disclosure processes.

OMB Memorandum M-26-05 (23 Jan 2026) moves federal cybersecurity to risk-based contractual approach. Rescinds M-22-18 and M-23-16.

SBOM-related provisions

• Section 2: Agencies may contractually require SBOM from producers.
• Section 4: References CISA SBOM and HBOM framework guidance.

OMB M-26-05 transitions from mandatory attestation to risk-based determination of software/hardware security requirements.

Policy provisions

• Section 1: Purpose and policy transition from mandatory attestation.
• Section 3: Risk-based determination of software and hardware requirements.
• Section 5: Rescission of M-22-18 and M-23-16.

GB 44495-2024 (China, in force 1 Jan 2026) is a mandatory vehicle cybersecurity standard. Software supply-chain visibility is a component of vehicle cybersecurity management.

SBOM-related provisions

• Clause 7: In-vehicle system security requirements.
• Clause 9: Software update security (OTA) requirements.

GB 44495-2024 requires vehicle cybersecurity management, risk assessment across lifecycle, vulnerability management, and type-approval conformity.

Vulnerability management requirements

• Clause 5: Vehicle cybersecurity management system requirements.
• Clause 6: Risk-assessment requirements across vehicle lifecycle.
• Clause 8: External communication interface security.
• Clause 10: Vulnerability management and incident response.
• Clause 11: Type-approval conformity assessment procedures.

Commission Implementing Regulation (EU) 2025/2392 specifies technical descriptions of CRA-important and CRA-critical product categories (Annex III, IV).

Scope provisions

• Article 1: Defines technical scope of CRA Annex III and IV products.
• Article 2: Links product categories to essential-requirement obligations.
• Annex I: Detailed technical description of important Class I and II products.
• Annex II: Detailed technical description of critical products.
• Annex III: Software categories: operating systems, hypervisors, firewalls.
• Annex IV: Identity and access management, PKI, secure elements.

This Implementing Regulation is a scope/classification instrument. Vulnerability obligations flow through the parent CRA (2024/2847) Article 14 and Annex I Part II.

Linked CRA obligations

• Parent CRA Article 14: 24h/72h/14-day vulnerability notification.
• Parent CRA Annex I Part II: Coordinated vulnerability disclosure.

IEC 81001-5-1:2021/ISH1:2025 Interpretation Sheet 1 clarifies component handling and transparency requirements of Ed.1.0.

SBOM-related provisions

• Interpretation 2: Guidance on third-party software component handling.

Note: specific interpretation content not reproduced due to IEC copyright.

Interpretation Sheet 1 clarifies vulnerability management boundaries and security update processes in IEC 81001-5-1 Ed.1.0.

Vulnerability-adjacent provisions

• Interpretation 1: Clarifies applicability of security-process requirements.
• Interpretation 3: Vulnerability management process boundaries.
• Interpretation 4: Security update delivery clarifications.
• Interpretation 5: Documentation and evidence requirements.

ACSC Information Security Manual: Guidelines for Software Development (Jun 2025). Australian cybersecurity controls for software development lifecycle and supply-chain.

SBOM-related provisions

• Application development: Secure programming practices and code review.
• Supply chain: Third-party component vetting and SBOM practices.

ACSC ISM mandates application testing, web vulnerability controls, coordinated vulnerability disclosure, and change-management security reviews.

Vulnerability management requirements

• Application testing: Static and dynamic security testing required.
• Web application development: OWASP-aligned web development controls.
• Vulnerability disclosure: Coordinated vulnerability disclosure process.
• Change management: Security reviews required for all code changes.

NIAP Policy Letter #30 (signed 12 May 2025) mandates SBOMs in NIAP Common Criteria evaluations.

Policy provisions

• Scope: Evaluations and Assurance Maintenance claiming AppSW PP or AppSW cPP conformance.
• International: Applies to other nations' requests for posting on the NIAP Product Compliant List (PCL).
• Confidentiality: SBOM may be submitted as vendor proprietary.
• Review gate: Mandatory sync session where NIAP reviews the SBOM for use in the vulnerability process.
• Checkout timing: SBOM for the evaluated version must accompany or precede the checkout package.
• Final deadline: Final SBOM due no later than 30 days prior to evaluation termination.
• PCL posting: Final SBOM must be approved before the product posts on the NIAP PCL.
• Effective triggers: Evaluations from 1 Mar 2024, assurance maintenance from 1 Sep 2024, international postings from 1 Jan 2025.
• Scope expansion: Initial coverage is AppSW PP and AppSW cPP; will extend to other protection profiles.

Addendum 1 (SBOM Field Table Mapping v2.0, 19 Dec 2025): adapts NTIA minimum elements to 14 required fields using SPDX v3.0.1 or CycloneDX v1.6.

• Metadata (7): SBOM Name, Version, Author, Timestamp, Hash, Supplier, Tool.
• Components (7): Name, Version, Identifier (purl), Supplier, Dependency Relationship, Hash, Data Type.
• Transmission: SBOMs emailed to NIAP-SBOM@niap-ccevs.org.
• Hash algorithms: Must comply with NIST SP 800-186 and FIPS 186-5.
• Naming rule: Root component in the SBOM JSON must match the commercial product name and version.

Policy 30 ties SBOM content directly into NIAP vulnerability triage. No explicit vulnerability disclosure timelines are set.

• Vulnerability process: SBOMs reviewed during mandatory sync session for compatibility with vulnerability handling.
• References: Aligns with NSM-8, CNSSP No. 11, OMB M-23-16, and Executive Order 14028.
• PCL gating: Products cannot be posted to the NIAP Product Compliant List until the final SBOM is approved.
• Future scope: Policy will extend beyond AppSW PP and AppSW cPP to additional protection profiles.

SEBI CSCRF mandates SBOM for SEBI Regulated Entities as part of software supply-chain security and asset inventory. Effective from 1 April 2025 for regulated entities.

SBOM-related provisions

• Section 3.2: Identify: asset inventory and risk assessment.
• Section 3.3: Protect: access control, data protection, secure development.
• Section 3.7: SBOM and software inventory for critical applications.

SEBI CSCRF requires continuous monitoring, 6-hour incident reporting, annual penetration testing, and severity-based vulnerability remediation timelines.

Vulnerability management requirements

• Section 3.1: Governance: cybersecurity policy, board oversight.
• Section 3.4: Detect: continuous monitoring and anomaly detection.
• Section 3.5: Respond: incident response and communication plans.
• Section 3.6: Recover: business continuity and recovery processes.
• Section 3.8: Vulnerability management with severity-based timelines.
• Section 3.9: Annual third-party cybersecurity audit required.

US BIS Rule on Securing the ICTS Supply Chain: Connected Vehicles (15 CFR Part 791). Applies to software in vehicle connectivity systems (VCS) and automated driving systems (ADS) from foreign-adversary countries.

SBOM-related provisions

• §791.102: Scope, definitions of VCS and ADS hardware/software.
• §791.301: Software supply-chain reviewable transactions criteria.

BIS rule establishes licensing, reporting, and annual declaration obligations for prohibited transactions involving foreign-adversary components.

Enforcement sections

• §791.201: Prohibited transactions involving foreign-adversary components.
• §791.302: Transaction-specific licensing and authorizations.
• §791.401: Information and transaction reporting requirements.
• §791.501: Annual declaration of compliance required from importers.

European Cybersecurity Certification Scheme on Common Criteria (EUCC) establishes a voluntary EU-wide certification scheme. SBOM is a recommended practice for certificate holders.

Certification provisions

• Article 1: Establishes EUCC scheme under Cybersecurity Act Article 49.
• Article 3: Assurance levels: substantial, high based on Common Criteria EAL.
• Annex I: Elements of certificates and applicable evaluation standards.

EUCC requires vulnerability handling and disclosure obligations from certificate holders. Continuous compliance monitoring is mandatory for maintained certificates.

Vulnerability management requirements

• Article 7: Vulnerability handling and disclosure obligations for certificate holders.
• Article 8: Monitoring and continuous compliance requirements.
• Article 13: Mutual recognition within EU certification framework.

EN 18031-3:2024 defines cybersecurity requirements for radio equipment handling virtual money or monetary value under RED Art. 3(3)(f). Harmonised via Commission Implementing Decision 2025/138. No explicit SBOM; secure updates and financial-asset protection imply component tracking.

SBOM-adjacent provisions

• Clause 6.3 (SUM): Secure update mechanism with financial-asset criteria (6.3.2.4).
• Clause 6.4 (SSM): Secure storage for cryptographic keys and financial data.

EN 18031-3 mandates VMP alongside strict financial-asset protection, secure update, and authentication for monetary-value equipment.

Vulnerability management requirements

• Clause 6.1 (ACM): Access control for financial transactions.
• Clause 6.2 (AUM): Authentication mechanism for payment operations.
• Clause 6.3 (SUM): Secure update mechanism (financial-asset criteria).
• Clause 6.5 (SCM): Secure communication for financial transactions.
• Clause 6.9 (CCK): Confidential cryptographic key handling.
• Clause 6.11 (VMP): Vulnerability management procedures mandatory.

EN 18031-2:2024 defines cybersecurity and data-protection requirements for radio equipment processing personal, traffic, or location data (wearables, smart toys, childcare equipment) under RED Art. 3(3)(e). Harmonised via Commission Implementing Decision 2025/138. No explicit SBOM; secure updates imply component tracking.

SBOM-adjacent provisions

• Clause 6.3 (SUM): Secure update mechanism for personal-data-processing equipment.
• Clause 6.4 (SSM): Secure storage mechanism for personal data.

EN 18031-2 mandates VMP (vulnerability management procedures) with additional privacy-focused mechanisms for equipment processing personal, traffic, or location data.

Vulnerability management requirements

• Clause 6.1 (ACM): Access control including childcare-equipment restrictions (6.1.3, 6.1.6).
• Clause 6.2 (AUM): Authentication mechanism requirements.
• Clause 6.3 (SUM): Secure update mechanism.
• Clause 6.5 (SCM): Secure communication mechanism (encryption).
• Clause 6.9 (CCK): Confidential cryptographic key handling.
• Clause 6.11 (VMP): Vulnerability management procedures mandatory.

EN 18031-1:2024 defines cybersecurity requirements for internet-connected radio equipment under RED Art. 3(3)(d). Harmonised per Commission Implementing Decision 2025/138. No explicit SBOM; secure update mechanisms and vulnerability handling imply component visibility.

SBOM-adjacent provisions

• Clause 6.3 (SUM): Secure update mechanism requires software component identification.
• Clause 6.10 (GEC): General equipment capabilities including secure defaults.

EN 18031-1 includes explicit vulnerability management procedures (VMP) as a mandatory cybersecurity requirement for internet-connected radio equipment.

Vulnerability management requirements

• Clause 6.1 (ACM): Access control mechanism requirements.
• Clause 6.2 (AUM): Authentication mechanism including password handling (6.2.5.1, 6.2.5.2).
• Clause 6.3 (SUM): Secure update mechanism for patching vulnerabilities.
• Clause 6.6 (REM): Resilience mechanism against network misuse.
• Clause 6.7 (NMM): Network monitoring mechanism.
• Clause 6.11 (VMP): Vulnerability management procedures mandatory.

Commission Implementing Decision (EU) 2025/138 adds the EN 18031 series as harmonised standards for RED cybersecurity requirements under Delegated Reg 2022/30.

Harmonisation provisions

• Article 1: Adds EN 18031-1:2024, 18031-2:2024, 18031-3:2024 as harmonised.
• Annex: Amended list of harmonised standards for RED Art. 3(3)(d)(e)(f).

The Implementing Decision publishes restrictions on certain clauses of EN 18031 standards. Vulnerability handling is defined by the EN 18031 standards themselves.

Restriction provisions

• Article 2: Restrictions on default-password clauses (6.2.5.1, 6.2.5.2).
• Article 3: Restriction on access control for childcare equipment.
• Article 4: Restriction on financial-asset secure update criteria.

EO 14144 (Biden, Jan 2025) extended EO 14028 with tighter software supply-chain transparency requirements. The EO did not explicitly name "SBOM" but required software providers to submit machine-readable attestations and supporting artifacts to CISA's Repository for Software Attestation and Artifacts (RSAA), where SBOM serves as the primary implicit artifact. Sections 2(a) and 2(b) were rescinded in June 2025 by the "Sustaining Select Efforts" amending EO; federal software-security direction shifted to OMB M-26-05 (Jan 2026).

SBOM-adjacent provisions

• Section 2: Operationalizing third-party software supply-chain transparency (rescinded Jun 2025).
• Section 2(a): Preamble framing insecure software as a Federal Government and critical-infrastructure risk.
• Section 2(b): Machine-readable attestations and supporting artifacts submitted to CISA RSAA; list of federal agency customers.

EO 14144 addressed identity and credentials, federal communications hardening, AI cybersecurity, and acquisition alignment. Sections 2(a), 2(b) and several others were rescinded in June 2025 by the "Sustaining Select Efforts" amending EO.

Vulnerability management requirements

• Section 3: Strengthen federal identity, credentials, and access management.
• Section 4: Harden federal communications against cyber threats.
• Section 6: Promote cybersecurity for AI systems used by government.
• Section 7: Align federal acquisition policy with cybersecurity requirements.

Australia SOCI Amendment Act 2024 (C2024A00100) strengthens critical-infrastructure risk management, data storage, and telecom security. SBOM not explicit; supply-chain risk is implicit.

SBOM-adjacent provisions

• Schedule 2: Risk management programs strengthened across sectors.

SOCI Amendment expands incident response, systems-of-national-significance declarations, and telecom security obligations (from 4 Apr 2025).

Vulnerability management requirements

• Schedule 1: Data storage systems as critical-asset protection requirement.
• Schedule 3: Declaration of systems of national significance enhanced.
• Schedule 4: Government assistance for serious cyber incidents.
• Schedule 5: Telecommunications security obligations uplift (from 4 Apr 2025).
• Schedule 6: Review and consequential amendments.

Australia SOCI Amendment Act 2024 (C2024A00100) strengthens critical-infrastructure risk management, data storage, and telecom security. SBOM not explicit; supply-chain risk is implicit.

SBOM-adjacent provisions

• Schedule 2: Risk management programs strengthened across sectors.

SOCI Amendment expands incident response, systems-of-national-significance declarations, and telecom security obligations (from 4 Apr 2025).

Vulnerability management requirements

• Schedule 1: Data storage systems as critical-asset protection requirement.
• Schedule 3: Declaration of systems of national significance enhanced.
• Schedule 4: Government assistance for serious cyber incidents.
• Schedule 5: Telecommunications security obligations uplift (from 4 Apr 2025).
• Schedule 6: Review and consequential amendments.

Australia Cyber Security Act 2024 (C2024A00098) includes smart device security standards. SBOM is not explicitly mandated; supply-chain visibility underlies critical-infrastructure risk obligations.

SBOM-related provisions

• Part 2: Security standards for smart devices (IoT).

Australia Cyber Security Act mandates 72-hour ransomware payment reporting and establishes the incident response framework and Cyber Incident Review Board.

Vulnerability management requirements

• Part 3: Ransomware payment reporting obligations (72 hours).
• Part 4: Limited use obligations for incident information.
• Part 5: Cyber Incident Review Board establishment.
• Part 6: Information-sharing and coordination mechanisms.

NIS 2 Directive (EU) 2022/2555 mandates supply-chain security and secure-development practices for essential and important entities. Member-state application date: 18 October 2024.

SBOM-related provisions

• Article 21(2)(d): Supply-chain security including assessment of third parties.
• Article 21(2)(e): Security in network-information-system acquisition and development.

NIS 2 incident reporting follows the 24h/72h/1-month cadence. Includes coordinated vulnerability disclosure framework with European vulnerability database at ENISA.

Vulnerability management requirements

• Article 21(1): Implement appropriate cybersecurity risk-management measures.
• Article 21(2)(a): Policies on risk analysis and information-system security.
• Article 21(2)(i): Use of cryptography and, where appropriate, encryption.
• Article 23(4)(a): Submit early incident warning within 24 hours.
• Article 23(4)(b): Provide incident notification within 72 hours.
• Article 23(4)(d): Submit final incident report within one month.

NERC CIP-013-3 mandates supply-chain cybersecurity risk management for BES entities, including vendor software integrity and authenticity verification.

SBOM-related provisions

• R1 Part 1.2.4: Vendor software integrity and authenticity verification.

NERC CIP-013-3 requires processes for vendor vulnerability notification, incident coordination, and remote access controls.

Vulnerability management requirements

• R1: Develop supply-chain cybersecurity risk management plan.
• R1 Part 1.2.1: Process to notify entity of vendor-identified vulnerabilities.
• R1 Part 1.2.2: Process for coordinating incident response with vendors.
• R1 Part 1.2.3: Process for remote access vendor account disabling.
• R1 Part 1.2.5: Coordination of controls for vendor remote access.
• R2: Implement and periodically review the supply-chain plan.
• R3: CIP Senior Manager approves the plan every 15 months.

U.S. Army ASA(ALT) SBOM Policy Memorandum (16 Aug 2024) implements SBOM policy across all Army acquisition pathways.

SBOM-related provisions

• Section 1: Purpose: operationalize SBOM use across Army acquisitions.
• Section 2: Applicability: all PEOs, PMs, and covered computer software.
• Section 3: PEOs/PMs collect SBOMs from vendors for all covered software.
• Section 4: Include SBOM contract language in new solicitations.
• Section 5: Securely store SBOMs with access controls.

Army memo requires continuous SBOM monitoring for vulnerabilities and integration with RMF/ATO processes.

Vulnerability management requirements

• Section 6: Continuously monitor SBOMs for vulnerability and incident management.
• Section 7: Integration with Risk Management Framework and ATO processes.

EU Delegated Regulation 2022/30 activates RED cybersecurity essential requirements. SBOM is not mandated directly; compliance via EN 18031 standards drives component visibility.

Product-scope provisions

• Article 1(1): Activates RED Art. 3(3)(d) for internet-connected radio equipment.
• Article 1(2): Activates Art. 3(3)(e) for childcare, wearable, IoT devices.
• Article 1(3): Activates Art. 3(3)(f) for equipment handling virtual money.

EU Delegated Regulation 2022/30 is an activating instrument. Vulnerability handling obligations arise through EN 18031 harmonised standards referenced by Implementing Decision 2025/138.

Scope and activation provisions

• Article 2: Exempts devices already covered by MDR and IVDR.
• Article 3: Application date of 1 August 2024.

FCC Report and Order and Further Notice of Proposed Rulemaking, "Cybersecurity Labeling for Internet of Things" (PS Docket No. 23-239, FCC 24-26, 125 pages). Adopted 14 March 2024, released 15 March 2024, published in Federal Register 30 July 2024. Establishes a voluntary U.S. Cyber Trust Mark labeling program for wireless consumer IoT products based on NISTIR 8425 (IoT Core Baseline for Consumer Products).

SBOM-related provisions

• Registry data element (10) (paras 113-114) requires "Disclosure of whether the manufacturer maintains a Hardware Bill of Materials (HBOM) and/or a Software Bill of Materials (SBOM)."
• Footnote 368: "In addition to the declaration, the SBOM and HBOM will be made available upon request by the Commission, CyberLAB, and/or CLA."
• The public registry publishes only the yes/no maintenance declaration, not SBOM contents; full SBOM must be furnished on request to FCC, Cybersecurity Testing Lab (CyberLAB), or Cybersecurity Label Administrator (CLA).

ioXt Alliance named Lead Administrator effective 13 April 2026.

Explicit vulnerability management commitments required of applicants:

• Applicants commit that "until the support period end date disclosed in the registry, [they will] diligently identify critical vulnerabilities in our products and promptly issue software updates correcting them" (unless not reasonably needed).
• Registry element (9) requires disclosure of the minimum support period and end date, or a statement that the device is unsupported.
• Registry element (10) requires SBOM/HBOM maintenance declaration.
• Coordinated Vulnerability Disclosure (CVD) referenced, citing ETSI CVD's 90-day resolution benchmark.
• Applicants must be secure-by-design and take every reasonable measure to create a securable product.

Program is voluntary; no specific disclosure hours mandated in the rule itself.

PCI DSS v4.0.1 (PCI SSC, June 2024) requires an inventory of bespoke/custom and third-party software components (6.3.2), enforceable after 31 March 2025. Functions as an SBOM equivalent; the standard does not use the term "SBOM" explicitly.

SBOM-related provisions

• Requirement 6.3.2: Maintain inventory of bespoke/custom and third-party software components.

PCI DSS v4.0.1 vulnerability management spans Requirements 6 (patching) and 11 (scanning). Internal quarterly scans, external ASV quarterly scans, and critical-patch installation within one month.

Vulnerability management requirements

• Requirement 6.3.1: Identify, risk-rank, and manage known software vulnerabilities.
• Requirement 6.3.3: Patch critical vulnerabilities within one month of release.
• Requirement 11.3.1: Perform internal vulnerability scans at least every three months.
• Requirement 11.3.1.1: Manage lower-risk vulnerabilities via targeted risk analysis.
• Requirement 11.3.1.2: Run internal scans authenticated with sufficient privileges.
• Requirement 11.3.1.3: Re-scan internal systems after any significant change.
• Requirement 11.3.2: Perform quarterly external scans via PCI-approved ASV.

Regulation (EU) 2024/1183 (eIDAS 2.0) establishes the European Digital Identity Wallet framework with cybersecurity requirements. SBOM is implicit in wallet certification.

Wallet and software provisions

• Article 5a: European Digital Identity Wallet technical requirements.
• Article 5c: Security, reliability, and cyber-resilience requirements for wallets.
• Article 5e: Certification of European Digital Identity Wallets.
• Article 6a: Wallet architecture and data-protection safeguards.

eIDAS 2.0 requires trust service providers to notify supervisory bodies of security breaches within 24 hours. Wallet certification includes security evaluation and vulnerability response.

Vulnerability management requirements

• Article 12b: Supervision of qualified trust service providers.
• Article 24: Identity verification and security-incident reporting (24 hours).

Swiss Financial Market Supervisory Authority circular on operational risk management for banks. 15 pages. Covers ICT risk management, cyber risk, critical data handling, outsourcing governance, and scenario based cyber risk exercises. References software assets and ICT inventory (p. 3, 8) but does not reference SBOM, software components, supply chain security, vulnerability disclosure, or any software transparency concepts. Focuses on organizational and process level operational resilience rather than software supply chain. Switzerland is not EU but placed here for European geographic proximity.

Incident reporting to FINMA within 24h (critical) or 72h (significant), penetration testing requirements, cyber risk scenario exercises

UK Telecommunications Security Code of Practice (Dec 2022). Applies to public electronic communications providers. SBOM not explicitly mandated; supply-chain security is a Section 4 measure.

SBOM-related provisions

• Section 4: Supply-chain security and vendor-risk management.
• Section 5: Secure network-function design and implementation.

UK Telecom CoP requires patch management, vulnerability response, incident reporting to Ofcom, monitoring, and governance of security operations.

Vulnerability management requirements

• Section 6: Patch management and vulnerability response obligations.
• Section 7: Incident management including reporting to Ofcom.
• Section 8: Monitoring, detection, and forensic readiness.
• Section 9: Governance and training obligations for providers.

NIST Guidance under EO 14028 Section 4(e) on software supply chain security (Feb 2022). Implements the SSDF and software verification practices mandated by the Executive Order.

SBOM-related provisions

• Section 1: EO 14028 Section 4(e) mandate and scope.
• Section 2: Apply NIST SP 800-218 Secure Software Development Framework.

The NIST SSSC guidance defines minimum software verification activities: code review, testing, and scanning for federal software producers.

Vulnerability management requirements

• Section 3: Software verification including automated testing.
• Section 4: Source code review and static analysis testing.
• Section 5: Executable code testing including dynamic analysis.
• Section 6: Web application vulnerability scanning.
• Section 7: False-positive minimization and reporting practices.

IEC 81001-5-1 Ed.1.0 requires comprehensive software component risk assessment including SOUP/OTSS. Component tracking constitutes de facto SBOM requirement.

SBOM-related provisions

• Clause 6: Specification of security-related requirements including components.
• Clause 7: Secure design and implementation practices.

IEC 81001-5-1 defines vulnerability handling and security update management across the product lifecycle for health software.

Vulnerability management requirements

• Clause 4: General requirements for security in the product lifecycle.
• Clause 5: Security management process.
• Clause 8: Security verification and validation.
• Clause 9: Management of security-related issues (vulnerability handling).
• Clause 10: Security update management and patch delivery.

ISO/SAE 21434:2021 requires distributed cybersecurity activities and supplier management, functionally encompassing SBOM practices for automotive supply chains.

SBOM-related provisions

• Clause 7: Distributed cybersecurity activities and supplier management.
• Clause 10: Product development including secure coding.

ISO/SAE 21434 mandates TARA, continuous vulnerability management, and incident response across the vehicle lifecycle.

Vulnerability management requirements

• Clause 5: Organizational cybersecurity management.
• Clause 6: Project-dependent cybersecurity management.
• Clause 8: Continuous cybersecurity activities (threat analysis, vulnerability management).
• Clause 13: Post-development activities: production, operation, maintenance.
• Clause 15: Threat analysis and risk assessment (TARA).

EU Medical Device Regulation (MDR, 2017/745) sets safety and cybersecurity requirements for medical devices. Software-related cybersecurity is concentrated in Annex I §17. SBOM is not named in the regulation text but becomes an implicit expectation through MDCG 2019-16 Rev.1 guidance, which treats SBOM and third-party software component documentation as state-of-the-art cybersecurity practice for CE marking. Medical devices under MDR/IVDR are excluded from the EU CRA scope (CRA Art. 2); however, associated non-device companion apps, wearables, and cloud components may still fall under CRA and its explicit SBOM mandate.

Software security provisions

• Annex I §17.1: Software must be developed according to state-of-the-art.
• Annex I §17.2: Minimum requirements on IT security and cybersecurity.
• Annex I §17.4: Manufacturers shall set out minimum requirements for hardware.
• MDCG 2019-16 Rev.1: Implementing guidance referencing SBOM and third-party component documentation.

MDR post-market surveillance and serious-incident reporting operationalize cybersecurity vulnerability response for medical devices in the EU market.

Vulnerability management requirements

• Article 10: General manufacturer obligations including risk management.
• Article 15: Person responsible for regulatory compliance including cybersecurity.
• Article 83: Post-market surveillance system by the manufacturer.
• Article 87: Report serious incidents and field safety corrective actions.

EO 14028 is the first US federal order referencing SBOM explicitly. Directs NIST to publish SSSC guidance implementing software supply-chain security for federal acquisitions.

SBOM-related provisions

• Section 4(e): Require SBOMs and secure software development practices.
• Section 4(f): NIST to publish critical software security guidance.

EO 14028 mandates vulnerability disclosure programs, incident detection, and zero-trust adoption across federal agencies.

Vulnerability management requirements

• Section 2: Remove contractual barriers to sharing threat information.
• Section 3: Adopt zero trust architecture for federal agencies.
• Section 5: Establish the Cyber Safety Review Board.
• Section 6: Standardize federal incident response playbook.
• Section 7: Deploy endpoint detection on federal networks.

Health Canada Pre-market Requirements for Medical Device Cybersecurity (Jun 2019) explicitly defines "cybersecurity Bill of Materials (BOM)" and requires it in Class III/IV licence applications.

SBOM-related provisions

• Section 2.1.1: Secure design as part of medical device strategy.
• Section 2.3.1: Maintain cybersecurity Bill of Materials (BOM) in submissions.

Health Canada requires device-specific risk management, vulnerability scanning and testing, and post-market monitoring. References AAMI TIR57, UL 2900, IEC 62304, NIST CSF.

Vulnerability management requirements

• Section 2.1.2: Device-specific cybersecurity risk management required.
• Section 2.1.3: Verification and validation testing including vulnerability scans.
• Section 2.2: Post-market monitoring and response to emerging risks.

PCI SSF Secure Software Program Guide is the PCI SSC validation program for payment software. Third-party component management is a validation requirement.

SBOM-related provisions

• Section 2: Secure Software Standard overview and control objectives.
• Section 3: Secure Software Lifecycle (Secure SLC) standard overview.
• Section 6: Third-party component management requirements.

PCI SSF requires vulnerability management, security update delivery, and QSA validation of payment software vendors.

Vulnerability management requirements

• Section 4: Validation process for payment software vendors.
• Section 5: Qualified Security Assessor (QSA) requirements.
• Section 7: Vulnerability-management practices for payment software.
• Section 8: Security update delivery and patch timelines.

ISO 26262:2018 is an automotive functional safety standard. Part 8 supporting processes include configuration management, which is adjacent to SBOM practices.

SBOM-adjacent provisions

• Part 6: Product development at the software level.
• Part 8: Supporting processes including configuration management.

ISO 26262 is functional-safety-focused, not cybersecurity. Vulnerability management in vehicles is covered by the companion ISO/SAE 21434 standard.

Vulnerability-adjacent provisions

• Companion ISO/SAE 21434: Vehicle cybersecurity engineering with TARA and vulnerability management.

FDA Postmarket Management of Cybersecurity in Medical Devices (Dec 2016) predates SBOM terminology but requires manufacturers to manage third-party components in post-market.

SBOM-adjacent provisions

• Section V.A: Ongoing cybersecurity risk assessment including components.

FDA Postmarket guidance requires a cybersecurity risk-management program, coordinated vulnerability disclosure, and FDA notification of uncontrolled vulnerabilities.

Vulnerability management requirements

• Section V: Postmarket cybersecurity risk management program.
• Section V.B: Information sharing through ISAO participation encouraged.
• Section VI: Responding to cybersecurity vulnerabilities and exploits.
• Section VI.B: Coordinated vulnerability disclosure policies required.
• Section VII: Reporting uncontrolled cybersecurity vulnerabilities to FDA.

EU Radio Equipment Directive (RED) sets essential requirements for radio equipment on the EU market. Software security is not explicitly addressed; cybersecurity essentials at 3(3)(d-f) require harmonised standards (EN 18031).

Essential requirements

• Article 3(1): Health and safety essential requirements.
• Article 3(3)(d): Network protection essential cybersecurity requirement.
• Article 3(3)(e): Personal data and privacy protection requirement.
• Article 3(3)(f): Fraud protection essential requirement.

RED is a conformity-assessment directive. Vulnerability handling obligations arise through harmonised standards and downstream EU regulations (CRA).

Conformity provisions

• Article 10: Manufacturer conformity assessment obligations.
• Article 20: Technical documentation required for each device.

RBI Cyber Security Framework in Banks (2016) is a cybersecurity baseline for Scheduled Commercial Banks. No explicit SBOM; focus is on IT asset inventory and patch management.

SBOM-adjacent provisions

• Annex 1 Para 4: Patch and vulnerability management for network and systems.

RBI mandates SOC setup, continuous surveillance, penetration testing, patch management, zero-day monitoring, and incident reporting to RBI/CERT-In.

Vulnerability management requirements

• Para 3: Board-approved cybersecurity policy distinct from IT policy.
• Annex 1: Baseline cybersecurity and resilience requirements (40+ controls).
• Annex 1 Para 11: Anti-malware and endpoint vulnerability controls.
• Annex 2: Cyber Security Operations Centre (SOC) requirements.
• Annex 3: Template for cyber incident reporting to RBI within 2-6 hours.

CER, UITP and UNIFE Expert Guidance on the Implementation of the CRA in Mainline and Urban Railways, v1.0.0 (April 2026). Voluntary industry guidance produced by the European rail sector — CER (Community of European Railway and Infrastructure Companies), UITP (International Association of Public Transport), and UNIFE (Association of European Rail Industry) — to support a coherent rail-sector implementation of Regulation (EU) 2024/2847 (CRA). Not legally binding; does not represent the position of EU institutions.

SBOM provisions

• Section 1.1 (SBoM definition) — SBoM is a formal, machine-readable inventory documenting components, libraries and dependencies within a software product; CRA Annex I Part II mandates SBoM creation.
• Section 1.4.2 (point 5) — Manufacturer must ensure life-cycle processes for vulnerability handling and continuous risk analysis update across the defined support period.
• Section 1.4.4 — SBoM is the basis for identifying and documenting vulnerabilities.
• Section 2.8 (dedicated SBoM section) — Manufacturers must maintain an SBoM for each PDE to perform vulnerability management and meet patching obligations; manufacturers must share the SBoM with a Market Surveillance Authority on request; manufacturers are recommended to provide a top-level dependencies SBoM in a commonly used, machine-readable format to users.
• Top-level definition — SBoM shall contain at minimum the description of all components on which the primary component directly depends, in addition to the primary component itself.
• B2B sharing — Sharing of detailed SBoM with users is subject to B2B contracts; IP and patent-law considerations may restrict detailed SBoM availability.
• Cross-reference — Notes that an EU Commission implementing act on SBOM is anticipated and points to BSI TR-03183 as a practical reference framework.

The guide details CRA Article 14 reporting obligations and Article 13 vulnerability-handling obligations as they apply to rail-sector products with digital elements (PDEs).

Reporting obligations (Section 1.4.3) — effective 11 September 2026, applicable to ALL PDEs regardless of placement date

• Manufacturer must report any actively exploited vulnerability and any serious security incident immediately, in any case within 24 hours after becoming aware (early warning).
• Details of the exploit within 72 hours.
• Final report within 14 days after corrective measures are made available (actively exploited vulnerability) or within one month in the case of a severe incident.
• Notifications submitted via CRA Art. 16 single platform to the CSIRT coordinator and ENISA.
• Manufacturer must inform impacted users of actively exploited vulnerabilities or severe incidents in a timely, and where appropriate automatic, manner.

Vulnerability handling (Section 1.4.4) — applies to PDEs placed on the market after 11 December 2027

• Identify and document vulnerabilities based on SBoM and regular and effective testing.
• Address vulnerabilities in line with associated risk and without delay; security updates free of charge (except for tailor-made products under section 2.5).
• Inform impacted users of actively exploited vulnerabilities, major incidents and security update availability without undue delay through coordinated disclosure (B2B agreement for tailor-made PDEs).

Manufacturer obligations summary (Section 1.4.2)

• Cybersecurity risk assessment, third-party component due diligence including SBOM review, secure-by-design, life-cycle process for vulnerability handling, continuous risk analysis update across the support period (minimum five years unless shorter expected lifetime).
• Importers and distributors (Section 1.4.5) become manufacturers under CRA Art. 21 if they place a PDE under their own name or carry out a substantial modification.

Rail-sector implementation

• Annex A — ongoing project progressivity and prioritisation across the 11/12/2027 cutover.
• Annex B — use-case approach (project, sub-system & system, components).
• Annex C — illustrated use-cases.
• Conditions of use (SecRACs) — Manufacturer / asset owner risk acceptance via mutual agreement (Section 2.7.2) for components that remain as-is after 11/12/2027.

OWASP CycloneDX Authoritative Guide to AI/ML-BOM, First Edition (3 March 2026), produced by the OWASP Foundation and the CycloneDX AI/ML Working Group. ML-BOM (Machine Learning Bill of Materials) is a CycloneDX BOM document covering AI/ML systems. The CycloneDX format is ratified as ECMA-424. The guide targets transparency, compliance, and security across the AI supply chain and is written to align with the EU AI Act, the BSI G7 SBOM-for-AI position paper, and similar guidance.

SBOM / ML-BOM provisions

• Introduction — ML-BOM defined as an inventory of components, configurations, and processes for AI/ML system development, training, deployment, and hosting.
• Core Concepts — Key components include identifying elements, architecture, supply chain, configurations, and execution considerations.
• ML-BOM Design — CycloneDX 1.7 specVersion examples with serialNumber, manufacturer, supplier (e.g., Hugging Face), purl, and externalReferences (vcs, model-card).
• Model Cards — Overview, structure, and examples.
• Model Parameters — Model metadata; datasets (training, validation, test).
• Quantitative Analysis — Benchmarks, metrics, and graphics.
• Model Design Considerations — Users / use cases, technical limitations, performance tradeoffs, ethical considerations, fairness assessments, environmental considerations (CO2, energy).
• Additional Information — CycloneDX AI/ML properties, supported languages, free-form tags, tokenizers and prompt templates, manufacturing information.
• Appendices — Glossary and references.

The guide explicitly positions Security & Vulnerability Management as a primary use case for ML-BOM, but does not mandate timelines or set out CVD obligations.

Vulnerability management provisions

• Introduction — ML-BOM helps identify security risks, including malicious open-source models or vulnerable dependencies, before they are integrated into production applications.
• Model Design — Adversarial Testing (Verification) recommends intentional challenge of AI models with edge cases to uncover hidden biases or vulnerabilities.
• Examples — Document model vulnerabilities such as adversarial attacks, prompt hacking, and jailbreaking in the model card.
• Cross-reference — Builds on the CycloneDX Authoritative Guide to SBOM for traditional component-vulnerability workflows; ML-BOM adds AI-specific dimensions for downstream vulnerability and risk analysis.

BSI G7 SBOM-for-AI Food for Thoughts (June 2025) is a shared G7 Cybersecurity Working Group position paper on extending the SBOM concept to AI systems. The entire document is dedicated to defining SBOM for AI, its properties, and minimum elements. Not a binding regulation.

SBOM provisions:

• Section 2 — Improving cybersecurity through transparency along the AI supply chain via an SBOM for AI, in conjunction with vulnerability management software.
• Section 3 Properties — SBOM for AI must capture static and dynamic aspects of AI systems, be machine-readable and tool-generated, and use structured data formats.
• Section 3 Minimum elements (eight clusters) — Models used by the AI system; Learning (training techniques and pipelines, datasheets for datasets); Datasets used during the lifecycle (identity, creation, use, provenance); Safety and security characteristics (guardrails, alignment, compliance attestations); System level characteristics (flow between AI elements, input data consumption); Key Performance Indicators (model benchmark evaluation results); Licensing information about components; Infrastructure used by the AI system.
• Section 3 Verifiability — SBOM for AI should be digitally signed by its manufacturer; individual components signed via cryptographic hashes or signatures from manufacturers; signature of the entire SBOM verifiable from the outside.
• Section 4 — Builds on existing model cards, system cards, and traditional SBOM concepts (NTIA minimum elements referenced) while adding AI-specific dimensions.

G7 SBOM-for-AI explicitly positions vulnerability management as a primary use case but does not mandate timelines.

Vulnerability management provisions:

• Section 1 — SBOM for AI fosters vulnerability management and patching by minimizing response time to check for known vulnerabilities deployed within AI system components.
• Section 2 — SBOM for AI in conjunction with vulnerability management software helps secure the supply chain and reduce response time to known vulnerabilities.
• Section 4 Challenges — Notes the need to develop a framework to effectively track AI vulnerabilities and weaknesses, given the still largely experimental results in the field of AI model red teaming.
• Section 4 Future work — Calls for shared technical vision tackling AI supply chain vulnerability tracking, status quo analysis of existing frameworks (second half 2025), and further work on technical recommendations and guidelines for a common G7 framework.

NIST AI RMF 1.0 (NIST AI 100-1, Jan 2023) is a voluntary, rights-preserving, non-sector-specific framework for managing AI risks. SBOM is not named explicitly. Software supply chain transparency is addressed implicitly through references to third-party software, data, and models, the Secure Software Development Framework, and the NIST Cybersecurity Framework.

SBOM-adjacent provisions:

• Sec 1.2.3 — Risks related to third-party software, hardware, and data complicate AI risk measurement.
• GOVERN 6.1 — Policies and procedures for managing AI risks and benefits arising from third-party software and data and other supply chain issues.
• MAP 4.1 — Approaches for mapping legal and technology risks of AI components, including third-party data or software.
• MAP 4.2 — Internal risk controls for components of the AI system, including third-party AI technologies, are identified and documented.
• MANAGE 3 — AI risks and benefits from third-party resources are regularly monitored.
• Appendix B — References to NIST Cybersecurity Framework, Privacy Framework, Risk Management Framework, and Secure Software Development Framework as related supply-chain controls.

AI RMF 1.0 addresses vulnerability management implicitly through the Secure and Resilient trustworthy characteristic and references to existing security frameworks. No specific disclosure timelines, CVD requirements, or PSIRT obligations.

Vulnerability management provisions:

• Sec 3.3 Secure and Resilient — AI systems should withstand unexpected adverse events, maintain confidentiality, integrity, and availability through protection mechanisms that prevent unauthorized access and misuse.
• GOVERN 1.2 — Trustworthy AI characteristics integrated into organizational processes including security and resilience.
• MEASURE 2.6 / 2.7 — AI system is evaluated for safety risks, security and resilience including adversarial, unauthorized access, and other security threats.
• MANAGE 4.1 — Post-deployment monitoring plans implemented including mechanisms for capturing and evaluating input from users, appeal and override, decommissioning, incident response, recovery, and change management.
• Appendix B — Refers organizations to NIST Cybersecurity Framework, Secure Software Development Framework, and similar resources for security and resilience guidance.

MITRE discussion paper (April 2026, Public Release 26-0682) produced under HHS contract 75FCMC23D0004 as companion reading to FDA Premarket Cybersecurity Guidance. Treats SBOMs - alongside their cryptographic-asset counterpart CBOM and AI-asset counterpart AIBOM - as the primary mechanism for managing vulnerabilities across emerging technology stacks.

SBOM / CBOM / AIBOM-related provisions

• Section 3.4 (Cloud / Resilient Architecture): SBOM scope for cloud-based medical devices extends to virtual machines, containers, container image layers, machine images, and cloud-native services.
• Section 4 (AI/ML): SBOM usage extended to AI/ML and cryptographic components alongside traditional software inventory. Aligns with the emerging AIBOM / AI-BOM concept - an inventory of AI/ML models, datasets, learned weights and hyperparameters, training-data provenance, and third-party model dependencies - and the MITRE ATLAS framework for adversarial AI threats.
• Section 5.2.2 (PQC Strategic Plan): Calls out Automated Cryptographic Discovery and Inventory (ACDI) - the cryptographic-asset equivalent of SBOM, aligned with the emerging CBOM / CycloneDX 1.7 Cryptography-BOM concept - as central to PQC migration planning against the harvest-now-decrypt-later threat, anchored to NIST FIPS 203/204/205, EO 14144, EO 14306, NSM-8/10, CNSA 2.0, and H.R.7535. Notes a gap: current ACDI/CBOM tooling targets general enterprise IT and does not yet address specialized medical device systems.
• Section 6 (Summary): Positions SBOMs plus threat modeling as the core practices to incrementally adapt for cloud, AI/ML, and PQC era.
• Appendix A-1: References CISA SBOM hub and MITRE's Data Normalization Challenges in SBOM Processing paper.

Discusses vulnerability management concepts without specific timelines, CVD mandates, or PSIRT obligations. Defers to FDA Premarket Cybersecurity guidance for authoritative requirements.

Vulnerability management discussion

• Section 3.3 (Cloud Threats and Risks): Ransomware and supply-chain impact on cloud-based medical devices, citing the Elekta cloud ransomware incident that affected 170+ facilities.
• Section 3.4 (Cloud Mitigations): DevSecOps for CI/CD pipelines, container vulnerability scanning, VM observability, and contingency planning framed through ISO 13485:2016 clauses 7.4.1-7.4.3.
• Section 4.2 (AI/ML Threats and Risks): Model and training-data poisoning, prompt injection, adversarial inputs, membership inference, and AI-generated code risks.
• Section 4.4 (AI/ML Mitigations): Secure learning environment, guardrails with robustness testing, threat modeling via MITRE ATLAS.
• Section 5 (PQC): Harvest-now-decrypt-later threat and transition planning anchored to NIST FIPS 203/204/205, EO 14144, EO 14306, NSM-8/10, CNSA 2.0, and H.R.7535.

ENISA National Capabilities Assessment Framework 2.0 (NCAF 2.0), April 2026, 126 pages (ISBN 978-92-9204-789-4, DOI 10.2824/5812948). 2026 Edition, updated for NIS2 alignment (original NCAF published 2020). Maturity model for EU Member State governments to self-assess their National Cybersecurity Strategies (NCSSs); audience is "policymakers, subject-matter experts and government officials", not vendors.

The document does not mention SBOM, Software Bill of Materials, CycloneDX, SPDX, or VEX. Classification is Implicit via Objective 17 - "Improve the cybersecurity of the supply chain" (Cluster #4, pp. 93-94). Member States are assessed on:

• Supplier risk assessment frameworks incorporating geopolitical, legal, sector-specific and cybersecurity factors
• National-level risk assessment of critical and high-risk ICT suppliers
• Multi-vendor / strategic dependency monitoring (e.g. >50% market share thresholds)
• Baseline supply chain security requirements harmonised with ISO/IEC 27001
• Procurement policies mandating cybersecurity and excluding high-risk suppliers
• Coordinated security risk assessments of critical supply chains as specified in NIS2
• Supplier compliance audits and monitoring

This is policy-level maturity benchmarking, not vendor obligations.

Classification is Implicit via Objective 19 - "Establish a Coordinated Vulnerability Disclosure (CVD) policy" (Cluster #4, pp. 99-100). Member States are assessed on:

• National CVD policy with a designated coordinating authority (CSIRT)
• Structured process for reporting vulnerabilities specifying "timelines for response and remediation that balance urgency, transparency and cybersecurity"
• Safe harbour / limited liability for researchers acting in good faith
• Secure portals (e.g. dedicated portals, validation systems) for vulnerability submission
• Participation in the European Vulnerability Database (EUVD)
• Encouragement of private-sector entities, "suppliers of network and information systems or manufacturers", and researchers to share information in the EUVD
• Bug bounty programme promotion among essential and important entities

No vendor-level disclosure hours mandated. National-policy maturity framework, not vendor obligations.

EEI Model Procurement Contract Language Addressing Cybersecurity Supply Chain Risk (Version 3.0, October 2022). Voluntary industry contract template for US electric utilities to embed in BES Cyber System procurement contracts, supporting compliance with NERC CIP-013-1 Requirement R1.2. Not a regulation itself; the enforceable instrument is NERC CIP-013-3.

SBOM-related provisions

• R1.2.5 Hardware/Firmware/Software and Patch Integrity (e): Contractor shall provide an SBOM for procured (including licensed) products listing components and associated metadata.
• R1.2.5(a): Risk-management practices for supply-chain delivery of hardware, software, and firmware through end-of-life.
• R1.2.5(c): FIPS 140-2 hash provided with software and patches for independent integrity verification.
• R1.2.5(d): Country-of-origin disclosure for the product and its components, with 180-day advance notice of changes.
• R1.2.5(h): Chain-of-custody documentation for procured products.

EEI Model Procurement Contract Language includes incident notification, response planning, coordinated vulnerability disclosure, and patching governance aligned with NIST SP 800-53/800-61 and ISO/IEC 30111 / 29147.

Vulnerability management requirements

• R1.2.1 Notification: Contractor notifies Company immediately on known or suspected Security Incident with written summary and follow-up updates.
• R1.2.2 Response Plan: Incident response plan aligned with NIST SP 800-61 Rev. 2 and SP 800-53 Rev. 4 CP-1 to CP-13 and IR-1 to IR-10 controls.
• R1.2.4 Vulnerability Disclosure: Summary documentation of vulnerabilities within 30 calendar days, consistent with ISO/IEC 30111 and 29147 coordinated vulnerability disclosure.
• R1.2.4(c): Disclosure of all known authentication-bypass backdoors with attestation of remediation.
• Patching Governance (d): Critical vulnerability remediation within a negotiated window (e.g. 7, 14, or 21 days); mitigations required if patches cannot be delivered in time.
• Patching Governance (e): Third-party component vulnerabilities remediated within 30 days of upstream availability; critical within 30/60/90 days.
• End-of-Life OS: Contractor solutions must not run on end-of-sale, end-of-support, or end-of-life operating systems absent mutual agreement.

AIA Civil Aviation Cybersecurity Subcommittee recommendations on SBOM use across the civil aviation sector. Voluntary industry guidance (no enforcement) targeting government, regulators, aircraft operators, OEMs, and suppliers. Lays out a multi-phased plan for SBOM generation, distribution, and use in vulnerability management.

SBOM-related provisions

• Section 1.1: SBOM defined as inventory of software components, dependencies, and hierarchical relationships.
• Section 1.2: Use cases: vulnerability management, incident response, code origin, obsolescence management, license compliance.
• Section 1.3.2: NTIA minimum elements: data fields, automation support, practices and processes.
• Section 2.2.1: Integration with RTCA DO-178B/C and AS9115A software release and SCI (Software Configuration Index) processes.
• Section 2.3.2: Aviation-specific minimum SBOM elements using SPDX or CycloneDX for third-party, FOSS, and COTS components.
• Section 3 phases: Phase I context, Phase II minimum elements, Phase III prototype SBOM database, Phase IV Proof-of-Concept with AIA members.

AIA recommends vulnerability management processes across the aviation ecosystem with aviation-specific adaptations: long product lifecycles, precautionary safety principle, and legacy product prioritization.

Vulnerability management requirements

• Section 2.1: Design Approval Holder (DAH) monitors products for defects under 14 CFR 21 and issues Airworthiness Directives.
• Section 2.2.2: Obsolete-software monitoring where vendor patches are unavailable; SBOM supports obsolescence tracking.
• Section 2.3.1: VM process must define asset catalog, risk assessment based on applicability / exploitability / impact, notification criteria, and remediation triggers.
• VEX adoption: Recommends DHS/CISA Vulnerability Exploitability eXchange format for sharing vulnerability impact across tiers.
• Regulator expectations: Regulators should require VM processes across the aviation ecosystem with quantitative analysis and reporting thresholds.
• Supplier flow-down: Timely analysis and notification responsibility must flow to suppliers or use alternate compliance means.

Auto-ISAC SBOM Informational Report v3.0 (17 Jan 2025) captures findings from the Auto-ISAC SBOM Working Group proceedings in 2023-2024 on effective practices of SBOM usage in the automotive industry. TLP:CLEAR (publicly distributable). 101 pages. Surveys SBOM projects across US, EU, and Japan governments plus industry, academia, and open source, and identifies automotive-specific SBOM considerations including complex supply chains, safety coupling, and update complexity.

SBOM-related provisions

• Section 2: SBOM projects in US, EU, Japan governments plus industry and standards.
• Section 3: Ways the auto industry is unique for SBOM (supply chain, updates, privacy).
• Section 4: Contracts, agreements, and infrastructure for SBOM exchange (CIA, DIA, IAM, NDA).
• Section 4.13: SBOM formats (CycloneDX, SPDX).
• Section 4.14: Vulnerability exchange and disclosure formats (VEX, CSAF).
• Section 5: SBOMs in development; actionable vs complete SBOMs; software provenance.
• Section 6: Exchanging and collaborating with SBOMs across OEM/Tier-N supplier tiers.

Auto-ISAC SBOM-IR covers incident management and vulnerability disclosure as a core automotive SBOM use case, aligning with ISO/SAE 21434 and UNECE WP.29 R155 practices.

Vulnerability management requirements

• Section 3.5: Risk assessment and vulnerability disclosure in automotive.
• Section 4.10: Incident management and vulnerability disclosure agreements.
• Section 4.14: Vulnerability Exchange and Disclosure formats (VEX, CSAF).
• Section 6: Vulnerability-communication practices across supply-chain tiers.

ENISA Technical Advisory for Secure Use of Package Managers, v1.1 (March 2026). First in a planned series of regular ENISA technical advisories on product security. Focuses on how developers can securely consume third-party packages throughout the software development lifecycle. Addresses supply-chain attack vectors including malicious packages, compromised maintainers, typosquatting, and dependency confusion. SBOM is implicit in the package-inventory and monitoring practices recommended.

The advisory structures vulnerability management around package selection, integration, monitoring, and mitigation. Covers vulnerability detection in dependencies, coordinated disclosure for package-ecosystem vulnerabilities, and mitigation approaches when vulnerable packages are discovered in a software supply chain.

CISA/NSA + 17 International Partners Shared Vision of SBOM for Cybersecurity (3 Sep 2025). SBOM-focused joint guidance endorsed by 20+ cybersecurity agencies.

SBOM-related provisions

• Section 1: Shared international vision for SBOM adoption.
• Section 2: SBOM value proposition across producer, operator, procurer roles.
• Section 4: Supply-chain risk management using SBOM data.
• Section 5: License compliance and open-source management.
• Section 6: SBOM sharing practices and access controls.
• Section 7: Call to action and next steps for international cooperation.

Shared Vision document highlights vulnerability management as the primary SBOM use case, referencing Log4Shell as case study.

Vulnerability management requirements

• Section 3: Vulnerability management and SBOM integration (Log4Shell).

Multi-organization global standard (Cisco, BSI, Red Hat, CISA, Dell, Oracle, Flexera). Explicitly references SBOM as the primary mechanism for delivering lifecycle/EoL data. Defines how EoL fields integrate into SBOM formats (CycloneDX, SPDX) and VEX documents. BOM refs: SBOM: p. 4

Defines end of security support lifecycle milestones, security patch availability periods

Legal analysis of RED Art. 3(3)(i) lockdown requirements and their impact on Free and Open Source Software (FOSS). Examines whether RED software compliance verification obligations conflict with FOSS license terms (GPL 3.0, LGPL). References SPDX identifiers for license categorization. Discusses the shift of legal responsibility from users to manufacturers for software loaded on radio equipment. Relevant context for understanding FOSS/OSS software supply chain implications under RED, though pre dates SBOM as a regulatory concept.

Legal analysis of RED impact on FOSS, no vulnerability management content

ETSI EN 303 645 V2.1.1 (30 Jun 2020) is the foundational European Consumer IoT baseline. Provision 5.2-3 explicitly requires building an SBOM.

SBOM-related provisions

• Provision 5.2-3: Build SBOM identifying third-party components and versions.
• Provision 5.3: Keep software updated throughout defined support period.

ETSI EN 303 645 v2.1.1 mandates coordinated vulnerability disclosure, secure defaults, and minimized attack surfaces. 13 top-level provisions.

Vulnerability management requirements

• Provision 5.1: No universal default passwords on devices.
• Provision 5.2: Coordinated vulnerability-disclosure policy required.
• Provision 5.4: Securely store sensitive security parameters.
• Provision 5.6: Minimize exposed attack surfaces.
• Provision 5.10: Examine system telemetry data for security anomalies.

CISA Framing Software Component Transparency: Establishing a Common SBOM (3rd Edition, Sep 2024). Defines baseline, recommended, and aspirational SBOM attributes.

SBOM-related provisions

• Section 2: Defines SBOM concept, scope, and terminology.
• Section 3: Baseline, recommended, and aspirational SBOM attributes.
• Section 3.1-3.2: Author and supplier identification requirements.
• Section 3.3-3.4: Component name and version tracking mandates.
• Section 3.5: Component hash for integrity verification.
• Section 3.7-3.8: Component relationships and license information.
• Section 5: Automation expectations for machine-readable SBOMs.

CISA Framing SBOM 3rd Edition dedicates Section 3.6.1 to Vulnerability Management and VEX integration for communicating vulnerability exploitability status.

Vulnerability management requirements

• Section 3.6.1: VEX integration for vulnerability-status communication.

PCAST Report on Cyber-Physical Resilience (Feb 2024). Advisory report recommending strengthening open-source and software supply-chain security including SBOM.

SBOM-related provisions

• Recommendation 3: Strengthen open-source software and software supply-chain security.
• Recommendation 4: Promote SBOM, SSDF, and vulnerability-disclosure adoption.

PCAST recommends strengthening critical infrastructure cyber resilience including vulnerability disclosure programs and cyber-physical research and development.

Vulnerability management requirements

• Recommendation 1: Establish performance goals for critical-infrastructure cyber resilience.
• Recommendation 2: Overhaul sector-risk-management agency authorities and resources.
• Recommendation 5: Build cyber-workforce pipeline and retention programs.
• Recommendation 6: Expand cyber-physical resilience research and development.

Draft DoD manual for cyber DT&E process. Focused on test and evaluation procedures for defense acquisition programs. No SBOM mention in the current draft text. SBOM requirements for defense software come from other DoD directives.

Vulnerability management in defense acquisition, vulnerability database usage, penetration testing requirements for defense systems

CISA 2025 Minimum Elements for SBOM (Draft, Aug 2025). Updated NTIA minimum elements reflecting the current state of software transparency. Public-comment draft; comment period closed 3 Oct 2025. 92 public comments were received on the regulations.gov docket CISA-2025-0007.

SBOM-related provisions

• Section 2: Defines required SBOM minimum data fields.
• Section 2.1: Existing fields: name, version, supplier, dependencies, timestamp.
• Section 2.2: New fields: component hash, license, tool name, generation context.
• Section 3: Accepted machine-readable formats: SPDX and CycloneDX.
• Section 4: Practices for SBOM generation and maintenance.
• Section 5: Distribution, sharing, and access-control guidelines.

CISA 2025 Min Elements defines the minimum SBOM data supporting vulnerability management and database querying for federal and commercial use.

Vulnerability-adjacent provisions

• Section 2: Minimum SBOM data supporting vulnerability database queries.

NSA CSI Recommendations for SBOM Management v1.1 (Jan 2024). Guidance for National Security Systems on SBOM ingest, storage, analysis, and monitoring.

SBOM-related provisions

• Section 1: Background on software supply-chain risk for NSS.
• Section 2: SBOM management capabilities for NSS operators.
• Section 2.1: SBOM ingestion from multiple formats and sources.
• Section 2.2: Secure SBOM storage and version management.

NSA CSI ties SBOM management to vulnerability analysis and continuous monitoring against vulnerability databases.

Vulnerability management requirements

• Section 2.3: Vulnerability analysis using SBOM component data.
• Section 2.4: Continuous monitoring against vulnerability databases.
• Section 3: Risk-based decision making using SBOM data.

ETSI EN 303 645 v3.1.3 (Sep 2024) is the Consumer IoT baseline standard referenced by the UK PSTI Act. Provision 5.2-3 requires building an SBOM of third-party components.

SBOM-related provisions

• Provision 5.2-3: Build SBOM identifying third-party components and versions.
• Provision 5.3: Keep software updated throughout defined support period.

ETSI EN 303 645 v3.1.3 mandates coordinated vulnerability disclosure policy, secure defaults, and minimized attack surfaces.

Vulnerability management requirements

• Provision 5.1: No universal default passwords on devices.
• Provision 5.2: Coordinated vulnerability-disclosure policy required.
• Provision 5.4: Securely store sensitive security parameters.
• Provision 5.6: Minimize exposed attack surfaces.

NCSC Vulnerability Disclosure Toolkit v2 is a VM-focused toolkit. No explicit SBOM content; supports CVD processes that feed SBOM-based vulnerability remediation.

SBOM-adjacent provisions

• Element 4: Validation and triage workflow for reports.

NCSC toolkit establishes a coordinated vulnerability disclosure process for UK organizations, aligned with ISO/IEC 29147 and RFC 9116.

Vulnerability management requirements

• Element 1: Dedicated vulnerability-reporting communication channel.
• Element 2: Published vulnerability disclosure policy document.
• Element 3: security.txt file (RFC 9116) on web properties.
• Element 5: Coordinated disclosure and public acknowledgement.
• Element 6: Internal vulnerability-management handoff and tracking.

NCSC guidance entirely focused on SBOM. Covers generation, signing, dynamic updates, developer considerations, end user utility, and limitations. Notes SBOMs should be cryptographically signed and paired with vulnerability scanners. References US EO 14028 and EU CRA.

SBOM paired with vulnerability scanners, regular vulnerability checking of components, supply chain vulnerability monitoring

UK DSIT Government Response to the Call for Views on the Code of Practice for Software Vendors (CP 1281, March 2025, 60 pages). The document does not explicitly mention SBOM, Software Bill of Materials, CycloneDX, SPDX, or VEX. Classification is Implicit because the code addresses multiple SBOM-adjacent concepts.

SBOM-adjacent provisions

• Principle 3.3 - Proactively detect and manage vulnerabilities in software components the organisation uses and software it develops.
• Principle 4 (Communication with customers) - Provide sufficient information to enable effective risk and incident management.
• Executive summary - "Greater transparency and better communication are needed across software supply chains."
• Open-source software is acknowledged 11 times; government commits to minimise burden on OSS developers and maintainers.

Technical controls and full implementation guidance are being developed by DSIT with the NCSC as accompanying material and may contain explicit SBOM references when published.

Principle 3 (Secure deployment and maintenance) explicitly covers vulnerability management. Provisions for Senior Responsible Officers:

• 3.1 (shall) - Ensure software is distributed securely to customers.
• 3.2 (shall) - Implement and publish an effective vulnerability disclosure process.
• 3.3 (shall) - Proactively detect and manage vulnerabilities in software components used and developed, with documented severity assessment and response prioritisation.
• 3.4 (shall) - Report vulnerabilities appropriately to relevant parties.
• 3.5 (shall) - Provide timely security updates, patches, and notifications to customers.
• 3.6 (should) - Public affirmation welcoming security researcher testing (support divided: 44% shall, 39% should).

Voluntary code with no specific disclosure hours mandated. 71% of respondents supported adding an assurance or certification scheme.

UK Software Security Code of Practice (DSIT, May 2025; updated January 2026, co-sealed by CCCS). 14 voluntary principles. SBOM practice is implicit in the secure SDLC and third-party management requirements.

SBOM-related provisions

• Principle 1.1: Senior leadership owns software security outcomes.
• Principle 2.1: Follow a secure development lifecycle approach.
• Principle 2.2: Manage risk from third-party software components.
• Principle 4.1: Provide clear security information to customers.
• Principle 4.2: Communicate support periods and end-of-life transparently.

UK Software Security Code of Practice requires timely security updates, a public vulnerability disclosure policy, and awareness of actively exploited vulnerabilities.

Vulnerability management requirements

• Principle 3.1: Timely security updates delivered to customers.
• Principle 3.2: Publish and operate a vulnerability disclosure policy.
• Principle 3.3: Maintain awareness of actively exploited vulnerabilities.

CERT-In Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM v2.0 (Jul 2025) is India's primary technical reference for Bill-of-Materials practices across software, crypto/quantum, AI, and hardware.

SBOM-related provisions

• Section 2: SBOM necessity, scope, and implementation overview.
• Section 3: Levels, classification, adoption roadmap, license management.
• Section 4: SBOM preparation with minimum-element data fields.
• Section 5: Roles, responsibilities, distribution, and SBOM sharing.
• Section 8: Quantum BOM (QBOM) and Cryptographic BOM (CBOM).
• Section 9: Artificial Intelligence Bill of Materials (AIBOM) minimum elements.
• Section 10: Hardware Bill of Materials (HBOM) minimum elements.

CERT-In guidelines couple BOM practices with vulnerability tracking. Section 6 details how to use SBOM data for vulnerability identification and remediation.

Vulnerability management requirements

• Section 6: Vulnerability tracking and analysis using SBOM data.
• Section 7: Recommendations and best practices for vulnerability workflows.

Section 3.7 directly addresses SBOM requirements. Mandates SBOM for SEBI Regulated Entities as part of software supply chain security and asset inventory obligations. BOM refs: SBOM: pp. 1, 3, 13

Clarifies patch management obligations, penetration testing requirements for SEBI Regulated Entities

ETSI TS 104 107 is the O-RAN security protocols specification covering cryptography and authentication protocols. No explicit SBOM content.

SBOM-adjacent provisions

• Clause 8: Key management and certificate lifecycle.

ETSI TS 104 107 defines authentication, TLS/mTLS, IPsec, cryptographic, and key management protocols that underpin vulnerability-free O-RAN communications.

Vulnerability management requirements

• Clause 5: Authentication and authorization protocols for O-RAN interfaces.
• Clause 6: TLS and mTLS requirements for O-RAN interfaces.
• Clause 7: IPsec and VPN requirements for backhaul protection.
• Clause 9: Confidentiality and integrity protection of O-RAN messages.
• Clause 10: Cryptographic algorithm requirements and suite selection.

ETSI TR 104 106 on O-RAN threat modeling includes supply-chain and open-source component risk considerations.

SBOM-related provisions

• Clause 10: Supply-chain and open-source component risk considerations.

ETSI TR 104 106 documents threat models and risk assessment methodology for O-RAN deployments with vulnerability analysis.

Vulnerability management requirements

• Clause 5: O-RAN architecture attack surface description.
• Clause 6: Threat catalog for O-RAN interfaces and functions.
• Clause 7: Threat actor profiles and motivations.
• Clause 8: Risk assessment methodology and likelihood scoring.
• Clause 9: Mitigations mapped to O-RAN security controls.

ETSI TS 104 105 defines security test specifications for O-RAN components including SBOM vulnerability cross-check and open-source analysis.

SBOM-related provisions

• Clause 9: Vulnerability scanning tests including SBOM cross-check and open-source component analysis.

ETSI TS 104 105 specifies normative test cases validating security controls of O-RAN components and interfaces.

Vulnerability management requirements

• Clause 5: Authentication and authorization test cases.
• Clause 6: TLS and mTLS configuration test cases.
• Clause 7: Integrity and confidentiality protection tests.
• Clause 8: Key management and certificate-lifecycle tests.
• Clause 10: Security logging and auditability tests.

ETSI TS 104 104 is the core O-RAN security requirements specification. Clause 10 mandates SBOM for every software delivery.

SBOM-related provisions

• Clause 10: Supply-chain security including SBOM requirements.

ETSI TS 104 104 defines O-RAN vulnerability management, secure update delivery, authentication, and security logging requirements.

Vulnerability management requirements

• Clause 5: O-RAN security principles and objectives.
• Clause 6: Authentication, authorization, and access control requirements.
• Clause 7: Confidentiality and integrity protection requirements.
• Clause 8: Secure boot, trusted execution, and runtime integrity.
• Clause 9: Vulnerability management and security update delivery.
• Clause 11: Security logging, monitoring, and incident response.

ETSI TR 104 034 V1.1.1 is an SBOM compendium covering practices, formats, and use cases across industries.

SBOM-related provisions

• Clause 4: SBOM concepts, terminology, and scope.
• Clause 5: SBOM formats (CycloneDX, SPDX) and comparison matrices.
• Clause 6: SBOM generation, publication, and distribution patterns.
• Clause 8: Regulatory landscape: EU CRA, US EO 14028, NIS 2 context.

ETSI TR 104 034 maps SBOM consumption to vulnerability management and VEX use cases.

Vulnerability-adjacent provisions

• Clause 7: SBOM consumption use cases: vulnerability and licensing.
• Annex A: Mapping of SBOM to vulnerability databases and VEX.

Parliamentary briefing on Regulation (EU) 2024/2847. Explicitly mentions SBOM as one of the CRA's key transparency tools alongside vulnerability disclosure requirements. BOM refs: SBOM: p. 12

Parliamentary summary of CRA vulnerability handling, actively exploited vulnerability notification, security update obligations, penetration testing

Annual EU threat intelligence report. References software supply chain attacks and the need for software component visibility. Does not explicitly name SBOM but the attack patterns described are the core SBOM use case.

Documents vulnerability exploitation trends, zero day attacks, vulnerability disclosure practices, patch management recommendations, vulnerability scanning

Entirely focused on SBOM. Covers SBOM formats (CycloneDX, SPDX), tooling landscape, component inventory, software transparency, and implementation guidance aligned with EU CRA. BOM refs: SBOM: pp. 1-83 · MLBOM: p. 16

Vulnerability monitoring, vulnerability management via SBOM, vulnerability database integration, vulnerability scanning, patch management, zero day handling

Commission briefing deck on CRA implementation. Explicitly mentions SBOM as a key compliance artifact required under CRA Annex I. No specific date on document. BOM refs: SBOM: p. 7

Briefing presentation, no vulnerability management detail

European Commission implementation FAQs for Regulation (EU) 2024/2847. Explicitly addresses SBOM obligations, scope, and compliance timelines under the CRA. BOM refs: SBOM: p. 47

Vulnerability handling obligations, coordinated disclosure, actively exploited vulnerability notification, zero day scenarios, security update delivery, penetration testing

BSI TR-03183 Part 3 v1.0.0 focuses on vulnerability reports and notifications. SBOM linkage is via companion Part 2; component identification feeds into vulnerability advisories.

SBOM-adjacent provisions

• Chapter 8: Linking SBOM components to vulnerability information.

BSI TR-03183 Part 3 defines CSAF-aligned vulnerability report content, format, and timelines. Aligned with EU CRA Article 14 (24h/72h/14d).

Vulnerability management requirements

• Chapter 3: Terms, actors, and vulnerability-report roles.
• Chapter 4: Required content for vulnerability reports and advisories.
• Chapter 5: CSAF and machine-readable advisory format requirements.
• Chapter 6: Timeline requirements aligned with CRA Art. 14 (24h/72h/14d).
• Chapter 7: Coordinated vulnerability disclosure policy and practice.

BSI TR-03183 Part 2 v2.1.0 is Germany's normative SBOM technical guideline aligned with EU CRA Annex I. Defines SBOM content, required fields, accepted formats, levels, and delivery.

SBOM-related provisions

• Chapter 3: Defines SBOM and component types (logical, external, identified).
• Chapter 4: Accepted SBOM formats: CycloneDX 1.6, SPDX 3.0.1.
• Section 5.2.1: Required SBOM-level fields: author, timestamp, version.
• Section 5.2.2: Required per-component fields: name, version, relationships.
• Section 5.2.3: Additional SBOM fields including vulnerability information.
• Section 8.1.15: Digital signature required for SBOM authenticity.
• Section 8.3: SBOM levels: top-level, n-level, transitive, complete.
• Section 8.4: SBOM classification: design, source, build, deployed, runtime.

BSI TR-03183 Part 2 is an SBOM standard. Vulnerability handling process is defined in companion Part 3 (Vulnerability Reports and Notifications).

Vulnerability-adjacent provisions

• Section 5.2.3: Vulnerability information field in additional SBOM fields.
• Companion Part 3: Defines vulnerability report format and CVD process.

BSI TR-03183 Part 1 v0.10.0 (Sep 2025) defines general cyber-resilience requirements for products with digital elements. SBOM obligation is detailed in companion Part 2.

SBOM-related provisions

• Chapter 3: Scope covering manufacturers and products with digital elements.
• Chapter 4: Cyber-resilience principles and security-by-design obligations.
• Chapter 5: Product cybersecurity requirements aligned with CRA Annex I Part I.
• Chapter 8: Software Bill of Materials obligation (references TR-03183 Part 2).

BSI TR-03183 Part 1 references the vulnerability handling process in companion Part 3. Security-update delivery and incident response are general Chapter 6-7 themes.

Vulnerability management requirements

• Chapter 6: Vulnerability handling process (references TR-03183 Part 3).
• Chapter 7: Security-update delivery throughout support period.
• Chapter 9: Technical documentation and conformity-assessment evidence.

Bill C-8 (Canada Critical Cyber Systems Protection Act, introduced 18 Jun 2025). Successor to Bill C-26 (died on prorogation Jan 2025); currently in SECU committee study. Contains supply-chain and third-party risk provisions; SBOM implicit in software component visibility obligations.

SBOM-adjacent provisions

• Section 9(1)(a): Identify supply-chain and third-party risks.
• Section 15: Mitigate supply-chain and third-party risks.

Bill C-8 mandates 72-hour incident reporting to CSE for designated critical cyber systems operators and periodic program review. Successor to Bill C-26 (died on prorogation Jan 2025); currently in SECU committee study.

Vulnerability management requirements

• Section 11: Manage risks to critical cyber systems in use.
• Section 16: Review and adjust cyber security programs regularly.
• Section 17: Mandatory cybersecurity incident reporting to CSE (72 hours).
• Section 15.2(j)(k): Mandatory vulnerability assessments on telecom networks.

Korea MSIT/KISA Comprehensive Plan (22 Oct 2025) mandates SBOM submission for regulated-sector IT systems, with full institutionalization by 2027.

SBOM-related provisions

• Pillar 2: Mandate SBOM submission for regulated-sector IT systems.
• Pillar 4: Enhance supply-chain cybersecurity for public-sector procurement.

Korea MSIT Plan enables real-time vulnerability inspection across software components in public, financial, telecom, and platform sectors.

Vulnerability management requirements

• Pillar 1: Strengthen national cybersecurity governance structures.
• Pillar 3: Real-time vulnerability inspection across software components.
• Pillar 5: Full institutionalization of requirements by end of 2027.

METI/IPA JC-STAR IoT Product Security Labeling Scheme (launched 25 Mar 2025). Tiered labeling with SBOM required at the highest assurance level.

SBOM-related provisions

• Level 4: Highest assurance including penetration testing and SBOM.

JC-STAR requires vulnerability disclosure policy and security-update commitment from manufacturers across all assurance levels.

Vulnerability management requirements

• Level 1: Self-declaration baseline IoT security requirements.
• Level 2: Third-party evaluation of enhanced security controls.
• Level 3: Advanced security aligned with ETSI EN 303 645.
• Scheme element: Mandatory vulnerability disclosure policy for labeled products.
• Scheme element: Security-update period commitment required.

METI Guide on SBOM for Software Management v2.0 (Aug 2024) is Japan's primary SBOM implementation guide for suppliers and procurers. v2.0 expands to procurement side.

SBOM-related provisions

• Section 1: Overview of SBOM concepts and benefits.
• Section 2: SBOM use-case scenarios for suppliers and procurers.
• Section 3: SBOM formats (CycloneDX, SPDX) and minimum data elements.
• Section 4: Step-by-step SBOM implementation process.
• Section 6: Operational considerations: depth, accuracy, update cadence.
• Section 7: Procurement-side SBOM requirements and evaluation.
• Section 8: SBOM sharing, access control, and confidentiality.

METI guide Section 5 details a vulnerability management workflow using SBOM data, covering monitoring, NVD querying, CVD, and zero-day handling.

Vulnerability management requirements

• Section 5: Vulnerability management workflow using SBOM data.