Supply Chain Security Regulations Tracker

Amends the SOCI Act 2018. Strengthens obligations for critical infrastructure owners on data storage protection, risk management programs, and telecom security. Schedule 5 uplifts telecom security obligations. Risk management program requirements implicitly require understanding of software components in critical infrastructure systems.

References security incidents and risk management for critical infrastructure. Risk management programs must address cyber threats. Telecom security uplift includes vulnerability management for network infrastructure. No specific vulnerability disclosure timelines.

ISO 26262 does not name SBOM explicitly but creates strong implicit requirements through SOUP qualification (Part 8, Clause 12), which mandates identification, classification, and verification of all pre-existing software components — functionally equivalent to SBOM content. Configuration management (Part 8, Clause 7) requires traceability of all software elements. The SPDX Safety Profile (under development) maps SBOM data directly to ISO 26262 safety analysis needs. Growing interdependence with ISO/SAE 21434 cybersecurity standard means vulnerability tracking of safety-critical components increasingly requires component-level visibility that SBOM provides. SDV complexity makes manual component tracking infeasible.

ISO 26262 requires monitoring and managing safety-relevant software components throughout the product lifecycle. Interdependence with ISO/SAE 21434 means cybersecurity vulnerabilities in safety-critical ECU components pose direct safety risks, creating implicit requirements for vulnerability awareness and management of embedded software components.

Joint ISO/SAE international standard for cybersecurity risk management across the entire lifecycle of road vehicle E/E systems. Covers concept, development, production, operation, maintenance, and decommissioning. Clause 7 and Clause 13 require tracking of software components and their vulnerabilities. SBOM not named but component inventory and supply chain transparency are foundational requirements.

Full cybersecurity engineering lifecycle including TARA, continuous vulnerability monitoring, incident response, and supply chain cybersecurity management. Requires monitoring publicly reported vulnerabilities affecting vehicle E/E components.

References software dependencies and software lifecycle. Addresses secure software development practices including third-party component management. No explicit SBOM requirement.

Vulnerability handling processes, security update mechanisms for payment software

References software components, software composition analysis, third-party software controls, and software lifecycle management. Requirement 6.3 mandates identification of all bespoke and custom software including third-party components. No direct SBOM mention but Req 6.3.2 requires maintaining an inventory of bespoke and custom software and third-party components to facilitate vulnerability and patch management.

Comprehensive vulnerability management program: Req 6.2 requires vulnerability scanning. Req 6.3 mandates identification and remediation of vulnerabilities. Req 11 requires penetration testing. Critical/high patches within 1 month. Quarterly vulnerability scans. Annual penetration tests.

Joint guidance authored by CISA, NSA, and 17 international cybersecurity agencies. Presents the shared international vision for SBOM adoption. Covers SBOM value proposition, vulnerability management, supply chain risk management, license compliance, software development lifecycle improvements, and SBOM sharing practices. References Log4Shell as a case study. TLP:CLEAR.

Joint 15 country guidance on SBOM for vulnerability management and supply chain risk. References Log4Shell as case study.

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 commissioned by FSFE examining whether RED Article 3(3)(i) software lockdown requirement conflicts with GPL-2.0, GPL-3.0, LGPL-2.1, and AGPL-3.0 license terms. Concludes lockdown requirement conflicts with copyleft licenses requiring users to install modified versions. References SPDX identifiers in the licensing context. Relevant to understanding FOSS/OSS software supply chain implications under RED and CRA. Implicit classification based on software component licensing and composition discussion.

Pure licensing/IP law study with no vulnerability management content. Analysis focuses on radio equipment software lockdown requirements and FOSS license compatibility, not cybersecurity or vulnerability management.

Administrative instrument (4 pages) that formally publishes EN 18031-1/2/3:2024 as harmonised standards for RED Art. 3(3)(d)(e)(f). The decision document itself contains no SBOM or software component requirements. The underlying EN 18031-1:2024 standard contains GEC-1 (General Essential Condition 1) which requires a software and hardware component list (effectively an SBOM/HBOM) and continuous vulnerability monitoring. EN 18031 standards themselves not stored separately.

Decision points to EN 18031-1/2/3:2024 as harmonised standards. The underlying EN 18031-1 standard includes GEC-1 requiring manufacturers to maintain lists of software/hardware components, identify publicly known exploitable vulnerabilities, and conduct continuous vulnerability monitoring throughout the product lifecycle. No specific disclosure timelines in the decision text.

European baseline standard for consumer IoT cybersecurity. 13 top level provisions, 33 mandatory requirements, 35 recommendations. Adopted 19 Jun 2020. Section 3.3 defines "SBOM" as abbreviation for Software Bill of Materials (p. 12). Provision 5.2-3 (p. 15) explicitly describes building an SBOM to identify third party components and versions for vulnerability monitoring. Provision 5.2 requires secure update mechanisms. Provision 5.3 mandates public vulnerability disclosure policy. Provision 5.4 requires acting on security vulnerabilities in product software. Widely referenced in RED compliance and EU CRA alignment. BOM refs: SBOM: pp. 12, 15

Coordinated vulnerability disclosure policy, vulnerability reporting mechanism, security updates throughout defined support period

Supersedes the June 2025 guidance (GUI00001825). Issued February 3, 2026 to align with the new Quality Management System Regulation (QMSR) effective February 2, 2026, which harmonizes 21 CFR Part 820 with ISO 13485:2016. Replaces all QSR references with QMSR/ISO 13485 references. Substantive cybersecurity requirements unchanged from June 2025. Section VII.C.3 covers SBOM under Section 524B(b)(3) of the FD&C Act. Requires machine readable SBOM (SPDX or CycloneDX) for all cyber device premarket submissions. FDA can issue Refuse to Accept (RTA) for missing SBOM since October 1, 2025. Covers SPDF, threat modeling, security architecture, cybersecurity testing, transparency, and labeling. BOM refs: SBOM, Software Bill of Materials, Bill of Materials found

Supersedes June 2025 guidance. Aligns with QMSR/ISO 13485:2016. Substantive cybersecurity requirements unchanged. SBOM required for all cyber device premarket submissions. FDA RTA for missing SBOM since Oct 2025

Released June 27, 2025. Supersedes the September 2023 guidance. Implements Section 524B of the FD&C Act, shifting cybersecurity from voluntary recommendations to enforceable legal requirements for "cyber devices." Major addition is Section VII covering 524B compliance. SBOM is now mandatory for all premarket submissions of cyber devices, not optional. Must adhere to NTIA minimum elements, provided in machine readable format (SPDX or CycloneDX preferred), listing all commercial, open source, and off the shelf components with version, supplier, license type, and end of support dates. SBOM treated as a living document, updated with every software release. Requires adoption of a Secure Product Development Framework (SPDF); lists IEC 81001-5-1 and AAMI SW76 as possible frameworks. Premarket submissions must include approximately 12 cybersecurity documents via eSTAR: SBOM, threat model and risk management plan (continuously updated during postmarket), coordinated vulnerability disclosure (CVD) policy, code review methods (SAST and DAST), defined patch/update timelines aligned to risk level, event detection and logging, supply chain cybersecurity risk management, security architecture views, and labeling/management plans. Requires customer notification within 30 days of vulnerability discovery. Distinguishes uncontrolled risks (immediate action) from controlled risks (scheduled maintenance). Noncompliance may result in refusal to accept or technical screening holds. Silent on legacy device compliance with 524B. BOM refs: SBOM: pp. 4, 16, 20-21, 33, 39-40, 49, 51, 53-54, 56, 62

Released Jun 27, 2025. Supersedes 2023 guidance. Implements Section 524B of FD&C Act making cybersecurity legally enforceable. Full vulnerability management lifecycle: mandatory CVD policy, SBOM as living document (NTIA minimum elements, SPDX/CycloneDX format) for continuous vulnerability monitoring, NIST NVD and CISA KEV monitoring, code review (SAST/DAST), vulnerability scanning, penetration testing, threat model continuously updated during postmarket surveillance, defined patch/update timelines by risk tier (uncontrolled = immediate, controlled = scheduled maintenance), end of support dates per SBOM component, event detection and logging, supply chain cybersecurity risk management. Requires SPDF adoption (IEC 81001-5-1 or AAMI SW76). Approximately 12 cybersecurity documents submitted via eSTAR. Noncompliance may result in refusal to accept. Silent on legacy device compliance.

Pre-SBOM/VEX era guidance (2016). Does not mention SBOM or VEX by name, but Section V.B (p.13) requires manufacturers to monitor third party software components for new vulnerabilities throughout the device's total product lifecycle, effectively mandating component-level inventory. Section IV.I (p.11-12) explicitly defines and requires threat modeling. Section VI (p.15-17) establishes CVSS 3.0 based risk assessment producing controlled vs uncontrolled risk determination. References ISO/IEC 29147:2014 (vulnerability disclosure) and ISO/IEC 30111:2013 (vulnerability handling). Conceptual foundation for SBOM and VEX requirements formalized in the 2023/2025 premarket guidance under Section 524B of FD&C Act.

Section V.B: continuous monitoring of OTS/third party components for vulnerabilities across full device lifecycle. Section IV.I: threat modeling required. Section VI: CVSS 3.0 risk assessment (controlled vs uncontrolled). ISO/IEC 29147:2014 disclosure, ISO/IEC 30111:2013 handling. Predates VEX but describes equivalent status communication.

The foundational CISA SBOM framing document. Third edition updates and expands on the 2021 NTIA minimum elements. Defines SBOM attributes, baseline and aspirational maturity levels, new "license" and "copyright holder" baseline attributes. Section 3.6.1 covers Vulnerability Management and VEX integration. BOM refs: SBOM: throughout (300+ mentions); VEX: Section 3.6.1

Dedicated Section 3.6.1 on Vulnerability Management and VEX. Defines how VEX communicates vulnerability exploitability status for SBOM components. Covers not affected, affected, fixed, under investigation statuses

Report to the President from PCAST (Biden administration). Recommends strengthening critical infrastructure resilience. Explicitly references SBOMs and VEX as tools for software transparency and vulnerability management. Recommends SBOM adoption across critical infrastructure sectors. Calls for standardised SBOM formats and automated SBOM processing capabilities.

Presidential advisory report on critical infrastructure resilience. References vulnerability sharing programs, vulnerability disclosure, bug bounty programs, and VEX. High-level policy recommendations without specific disclosure timelines or mandates. Recommends strengthening cyber incident information sharing and automated vulnerability tracking.

OMB Director Russell Vought memo to all agency heads. Rescinds M-22-18 and M-23-16. Adopts risk-based approach, agencies may contractually require SBOM from software producers. References CISA 2025 SBOM Minimum Elements and HBOM Framework. BOM refs: SBOM, Software Bill of Materials, Bill of Materials found

Rescinds M-22-18 and M-23-16. Agencies may contractually require SBOM from software producers for vulnerability management. References CISA 2025 SBOM Minimum Elements and HBOM Framework

Draft manual (never finalized as 5000.UY; superseded by DoW Manual 5000.103, Feb 2026). Uses bills of materials (BOMs) substantively throughout: review of BOMs required during cyber DT&E initiation, BOM analysis for known vulnerability identification, and BOM provenance evaluation for supply chain risk. Defined in glossary as a formal record containing the details and supply chain relationships of various components used in building a system's firmware, hardware, and software. Companion Cyber DT&E Guidebook V3 (June 2025) includes Table F-1 on SBOM attribute analysis.

Extensive cyber DT&E vulnerability management requirements: cross-reference against National Vulnerability Database (NVD), identify and track known exploitable vulnerabilities, verify vulnerability remediation per DoDI 8531.01, assess simultaneous exploitation of multiple vulnerabilities. Vulnerability deficiencies reported through Joint Deficiency Reporting System. Supply chain risk management assessment integrated. No specific public disclosure timelines (internal DoD acquisition framework).

Industry response to CISA's RFC. Explicitly discusses SBOM element retention, firmware SBOM, HBOM interoperability, and supply chain transparency. Useful for understanding regulatory intent and industry positions. BOM refs: SBOM: pp. 1-11 · CBOM: pp. 8-9 · HBOM: pp. 1, 10

Industry comments on SBOM vulnerability management capabilities, zero day response, vulnerability database integration

CISA's update to the original 2021 NTIA minimum elements. Public comment draft defining updated required SBOM fields, depth requirements, machine-readability, and automation expectations. Core SBOM regulatory document. BOM refs: SBOM: pp. 1-17

Defines minimum SBOM elements supporting vulnerability management and vulnerability database querying

Signed by Douglas R. Bush, Assistant Secretary of the Army (Acquisition, Logistics and Technology). Implements Army policy for SBOM use across all acquisition pathways (Software Acquisition, Urgent Capability, Middle Tier, Major Capability, Defense Business Systems). Requires PEOs/PMs to incorporate SBOM contract language in new solicitations, collect SBOMs from vendors for all covered computer software and COTS, securely store and continuously monitor SBOMs for vulnerability and incident management. Defines "covered computer software" broadly (government funded, contractor developed, commercial, COTS, and open source). Excludes cloud services. DASA(DES) to provide SBOM Management and Implementation Guide, sample contract language, and establish cross-PEO/PM SBOM Working Group within 90 days. References EO 14028, OMB M-22-18, M-23-16, Army Directive 2023-16, Army Directive 2024-02. BOM refs: SBOM, Software Bill of Materials, Bill of Materials found

Requires PEOs/PMs to collect SBOMs and continuously monitor for vulnerability and incident management. Mandates SBOM contract language in new solicitations across all acquisition pathways

NSA guidance for National Security Systems on SBOM management tooling. Covers SBOM ingestion, storage, analysis, CycloneDX, SPDX, VEX integration, and risk-based decision-making. Directly applicable to defense contractors and federal agencies. BOM refs: SBOM: pp. 1-14

SBOM as enabler for vulnerability management. Covers vulnerability database integration, vulnerability identification and remediation through SBOM analysis

Direct NIST implementation guidance for EO 14028. Explicitly defines SBOM minimum elements, outlines how agencies should request SBOM from software producers, and establishes the baseline for federal procurement SBOM requirements. BOM refs: SBOM: p. 7

Vulnerability disclosure programs for federal software producers, vulnerability scanning requirements

Builds on EO 14028. References software supply chain security and third-party software risk management. Reinforces EO 14028 SBOM obligations and adds new requirements for software attestation and secure development practices. Does not repeat SBOM explicitly in the initial sections but relies on the EO 14028 framework. Extends to AI systems and cloud services.

Builds on EO 14028. Adds vulnerability management and patch management requirements for federal systems. Mandates vulnerability disclosure programs, security patch requirements, and continuous monitoring. Expands scope to AI systems and emerging technologies.

The foundational US federal SBOM mandate. Section 4 explicitly directs NIST to define minimum SBOM elements and requires SBOM for software sold to the federal government. Triggered the entire US SBOM regulatory ecosystem. BOM refs: SBOM: pp. 6-7, 14

Foundational US federal cybersecurity EO. Mandates vulnerability disclosure programs, penetration testing for federal software

Final rule from the Bureau of Industry and Security addressing ICTS supply chain security for connected vehicles. Explicitly references SBOM as a tool for assessing software provenance and foreign adversary risk in vehicle software stacks. BOM refs: SBOM: pp. 9, 12, 95-98, 120, 122, 125-126, 128, 136, 153, 164, 166, 169, 185, 189, 197 · HBOM: pp. 9, 12, 75-77, 120, 122, 125-126, 128, 135-136, 153, 164, 166, 169, 183, 188, 197

References vulnerability database for assessing software provenance and foreign adversary risk in connected vehicle software stacks

UK government code of practice for public telecoms providers, issued by the Department for Digital, Culture, Media and Sport. Sets tiered security requirements across network architecture, software supply chain, monitoring, and incident reporting. Script analysis found references to software components, vulnerability disclosure, open source components, and third party software. Ofcom is the enforcement authority. Does not name SBOM but the supply chain security and software integrity requirements are aligned with SBOM practices.

Vulnerability management, vulnerability disclosure, actively exploited vulnerability handling, security updates and patches throughout product lifecycle, penetration testing, security monitoring

Updated version of global IoT security standard underpinning UK PSTI Act (in force 29 Apr 2024). 13 provisions including vulnerability disclosure, software updates, and minimised attack surfaces. Does not name SBOM but Provision 5.3 requires manufacturers to keep all software components updated and to publish a defined support period. Component tracking and software update mechanisms implicitly require software component visibility.

Vulnerability disclosure policy mandatory (Provision 5.2). Software updates throughout defined support period (Provision 5.3). Security update mechanisms required (Provision 11). Manufacturers must act on vulnerabilities in a timely manner and make updates available. Defined support period must be published and communicated to consumers.

NCSC toolkit for vulnerability disclosure processes. Covers communication channels, disclosure policy, and security.txt (RFC 9116). SBOM adjacent practice mandated by Software Security Code Principle 3.2. References ETSI EN 303 645 and PSTI Act.

Dedicated vulnerability reporting channel, disclosure policy, security.txt (RFC 9116), validation and triage, public acknowledgement

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

Explicitly discusses SBOM. 87% of respondents supported technical guidance on SBOMs, 82% supported a secure central database of SBOMs. Government committed to publishing SBOM content with NCSC. Covers vulnerability disclosure, supply chain accountability, and procurement standardization.

Vulnerability testing and reporting, incident risk management communication, regular vulnerability testing, planned certification scheme

Principle 1.2 explicitly requires component inventory "such as a software bill of materials (SBOM)." Vendors must share inventory with customers. Also covers vulnerability disclosure (3.2), vulnerability management (3.3), and customer communication. Complementary to US SSDF and EU CRA.

Vulnerability disclosure process (3.2), proactive vulnerability detection and management (3.3), report vulnerabilities to relevant parties (3.4), timely security updates (3.5), incident notification (4.3)

Indian Computer Emergency Response Team (CERT-In), Ministry of Electronics and Information Technology. Comprehensive technical guidelines covering SBOM, Quantum BOM (QBOM), Cryptographic BOM (CBOM), AI BOM (AIBOM), and Hardware BOM (HBOM). Covers SBOM levels, classification, preparation, vulnerability tracking, distribution, and best practices. BOM refs: SBOM, Software Bill of Materials, Bill of Materials found

Comprehensive BOM guidelines covering SBOM vulnerability tracking, distribution, and best practices. Covers vulnerability identification through component visibility across SBOM, QBOM, CBOM, AIBOM, and HBOM

Reserve Bank of India circular mandating cybersecurity preparedness for all scheduled commercial banks (excluding Regional Rural Banks). RBI now mandates Regulated Entities to adopt CERT-In SBOM guidelines for enhanced transparency, security, and supply chain risk management. REs must generate, maintain, and update SBOMs for all software components including legacy systems, integrate SBOM requirements into vendor contracts, maintain CBOM for quantum safe preparedness, and conduct regular audits to verify SBOM accuracy. For 2026 compliance, regulators are moving toward a unified approach including SBOM, CBOM (cryptography), and AIBOM (AI models). BOM refs: SBOM via CERT-In mandate

Mandates SOC setup, continuous surveillance, penetration testing at reasonable intervals, vulnerability assessment, patch management, zero day threat monitoring, incident reporting to RBI/CERT-In

The primary CSCRF circular establishing cybersecurity and cyber resilience requirements for all SEBI Regulated Entities. Follows a graded approach with five categories of REs. Compliance deadline: Jan 2025 for existing REs, Apr 2025 for new REs. Script analysis confirmed explicit SBOM, Software Bill of Materials, and Bill of Materials references, plus software component terms. Includes SBOM requirements as part of software supply chain security, asset inventory, and vulnerability management obligations. The FAQ document above provides clarifications on the SBOM provisions. BOM refs: SBOM, Software Bill of Materials, Bill of Materials found

Vulnerability management program, patch management, zero day response, 24 hour incident reporting framework, annual penetration testing, security monitoring

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

Protocol specification document covering SSH, TLS 1.2/1.3, IPsec, DTLS, OAuth 2.0, CMPv2, SFTP, and certificate management for O-RAN interfaces. No traditional SBOM reference, but the cryptographic protocol and cipher suite specifications constitute the input data for a Cryptographic Bill of Materials (CBOM). CBOM — defined alongside SBOM in CERT-In Technical Guidelines v2.0 — catalogs algorithms, key lengths, certificate profiles, and protocol versions to enable crypto-agility and post-quantum migration. TS 104 107 is effectively the cryptographic inventory source for O-RAN deployments. Substantive SBOM/software component requirements appear in companion spec TS 104 104.

Specifies security protocol suites (SSHv2, TLS 1.2/1.3, IPsec, DTLS) forming part of O-RAN's defense-in-depth. The only explicit vulnerability reference is the standard ETSI CVD boilerplate footer. Substantive vulnerability management requirements are in TS 104 104. Implicit classification reflects the security protocol context; the document itself does not contain independent VM mandates.

Threat model covering open source code threats (7.4.3), application lifecycle threats (7.4.1.11), security principles for open source component risk management (SP-OPNS 8.1.9) and continuous vulnerability handling (SP-SLC 8.1.12). Risk assessment framework with severity and likelihood ratings. Does not name SBOM directly but threat analysis drives the SBOM requirements in TS 104 104.

Threat model with vulnerability analysis across O-RAN components, open source threats (7.4.3), application lifecycle threats (7.4.1.11), security principles for vulnerability handling (SP-SLC 8.1.12), risk assessment methodology

Extensive SBOM test specifications in section 9.4 covering SBOM signature, data fields, format, depth, completeness check, version verification, vulnerability cross check, delivery, vulnerabilities field, and OSC components. Also covers open source software component analysis (9.2), binary static analysis (9.3), software image signing (9.5), and system vulnerability scanning (8.2).

System vulnerability scanning test cases, SBOM vulnerability cross check, open source component analysis, binary static analysis, software image signing verification

Dedicated section 5.3.1 on Software Bill of Materials. Mandates SBOM for every O-RAN software delivery following NTIA guidance. Covers security requirements per O-RAN interface and component, software supply chain security, secure update, package protection, and application lifecycle management.

Security requirements per O-RAN interface, SBOM mandated for every software delivery, secure update, software package protection, application lifecycle management, vulnerability scanning

Activates RED cybersecurity requirements for internet-connected radio equipment under Art. 3(3)(d)(e)(f). Mandates network protection, data privacy, and fraud prevention. Compliance practically requires SBOM to demonstrate software component visibility and vulnerability management. EN 18031 harmonised standards (implementing these requirements) include GEC-1 requiring software/hardware component lists. Being subsumed by CRA effective Dec 2027. Application delayed to Aug 2025 (was originally Aug 2024).

Cybersecurity requirements activated by this regulation implicitly require vulnerability awareness and management of software components. EN 18031-1 GEC-1 (implementing standard) mandates continuous vulnerability monitoring and identification of publicly known exploitable vulnerabilities. No specific disclosure timelines in the delegated regulation itself.

Base directive (2014) focused on radio spectrum, EMC, and market access. Article 3(3)(d)(e)(f) lay the hooks for cybersecurity, privacy, and fraud prevention but had no content until activated by Delegated Regulation (EU) 2022/30 (see separate entry). EN 18031 harmonised standards (published 2024) provide substantive SBOM and vulnerability management requirements. The RED text itself contains no cybersecurity, SBOM, or software component transparency content.

Base directive with no vulnerability management content. Cybersecurity activation and substantive VM requirements flow entirely through the delegated regulation (2022/30) and EN 18031 harmonised standards. See separate entries for those documents.

interpretation sheet published December 2025 clarifying IEC 81001-5-1. Key clarifications: (1) Health software is always part of a networked, socio technical health IT system, meaning security evaluations must account for component interactions, not isolated items. This reinforces the need for complete component visibility. (2) Transitional software applies to entire products developed before the standard existed and is not a fourth classification alongside Maintained/Supported/Required. (3) Software item categories are nested but not hierarchical for risk profiles. (4) Manufacturers may downgrade categories over a product's lifetime (e.g. Maintained to Supported) but must document the risk transfer with clearly defined accompanying documents. (5) All software items regardless of category must have risks identified, updates communicated, and integrity checks performed. BOM refs: Reinforces component interaction analysis and transparency requirements that depend on SBOM

Clarifies security evaluations cannot be limited to isolated software components, must account for interactions. Strengthens risk transfer documentation. Defines transitional software classification. Reinforces full component transparency requirement.

International standard for health software security lifecycle. Team NB and IGNB (German Association of Notified Bodies) have endorsed it as "state of the art" for EU MDR cybersecurity compliance since 2022; formal harmonization postponed to 2028. Uses its own software item classification (Maintained, Supported, Required) rather than IEC 62304's SOUP/OTSS terminology. Mandates identifying and assessing risks for all software items including third party components, tracking their updates, and performing post production security surveillance. The standard itself describes SBOM as "a documentation that tracks all incorporated software" and distinguishes Maintained/Supported/Required status for components within it. While it does not prescribe specific SBOM fields or formats, the component tracking, vulnerability management, and configuration management requirements cannot be met without maintaining what is effectively an SBOM. The FDA 2025 premarket cybersecurity guidance lists IEC 81001-5-1 as one framework manufacturers may use, though the FDA goes further by mandating NTIA minimum elements, machine readable formats (SPDX/CycloneDX), and end of support dates per component. TUV SUD provides compliance guidance that includes SBOM as part of the documentation set. BOM refs: SBOM described in standard text; de facto requirement through component tracking and vulnerability management clauses

Mandates comprehensive software component risk assessment including all SOUP/OTSS. Requires vulnerability management, security update processes, and incident response throughout product lifecycle. Component tracking constitutes de facto SBOM requirement.

MDR text (2017) does not name SBOM. However, GSPR 17.4 (Annex I) requires manufacturers to set out minimum requirements for hardware, IT networks, and security measures for software. MDCG 2019-16 (implementing guidance) explicitly states the Software Bill of Materials or equivalent SOUP list must be kept current and feed into vulnerability monitoring. IEC 81001-5-1, now recognised by notified bodies as the harmonised standard for MDR cybersecurity, explicitly mandates SBOM. Implicit classification reflects the established regulatory expectation even though the MDR text itself predates SBOM terminology.

GSPR 17.2 (Annex I) requires post-market surveillance of software, including monitoring for newly discovered vulnerabilities in SOUP/OTS components. Article 83 mandates post-market surveillance systems. MDCG 2019-16 specifies infield vulnerability monitoring and patch delivery. Serious incident reporting within 24 hours. No specific CVD disclosure timelines in MDR text; MDCG 2019-16 provides the operational framework.

Swiss Financial Market Supervisory Authority circular on operational risk management for banks. Requires institutions to maintain real-time inventories of ICT assets including hardware and software (margin 53), but this is an operational IT asset management obligation (CMDB-style), not a structured software component transparency (SBOM) requirement. No reference to CycloneDX, SPDX, software composition analysis, or supply chain software transparency. Compliance deadline for inventory requirements was January 2025.

Explicit vulnerability management obligations: penetration testing mandated (margin 53, footnote 16 references targeted audit and exploitation of software vulnerabilities), vulnerability scanning required (footnote 15). Incident lifecycle management for significant ICT incidents (margins 57-62). Monitoring of inventoried ICT assets for cyber risks required. Incident reporting to FINMA within 24h (critical) or 72h (significant).

Replaces NIS 1 (2016/1148). Art. 21(2)(d) mandates supply chain security including security related aspects of relationships between each entity and its direct suppliers or service providers. Art. 22 establishes EU level coordinated security risk assessments of critical supply chains. Art. 7/12 create the coordinated vulnerability disclosure framework. Art. 12(2) establishes the ENISA European vulnerability database. Covers 18 sectors (energy, transport, banking, health, digital infrastructure, ICT service management, public administration, space, etc.). Member State transposition deadline was 17 Oct 2024. Does not name SBOM explicitly but supply chain security, vulnerability disclosure, and software component visibility are core use cases throughout.

Coordinated vulnerability disclosure framework, European vulnerability database (ENISA), mandatory incident reporting for essential/important entities, penetration testing. See Quick Reference above.

Defines the technical descriptions for product categories listed in CRA Annexes III (important, Class I and II) and IV (critical). Covers operating systems, hypervisors, firewalls, VPNs, intrusion detection systems, routers, microcontrollers, and industrial automation systems. Product categorization determines SBOM obligations: Class II and critical products face third-party conformity assessment which will scrutinize SBOM completeness and quality.

Product categorization determines conformity assessment level, indirectly affecting vulnerability management obligations. Higher-category products (Class II, critical) face stricter vulnerability handling requirements and third-party assessment of their vulnerability management processes.

Establishes the European Digital Identity Framework, mandating that every Member State offer at least one EUDI Wallet to citizens and residents by December 2026. Covers electronic identification, trust services, electronic signatures, seals, timestamps, registered delivery, and website authentication. Script analysis found software component references. Does not name SBOM directly, but the wallet certification requirements, trust service provider audits, and security evaluation of digital identity components create implicit dependencies on software supply chain transparency. Four implementing regulations on wallet technical standards were adopted in late 2025.

Trust service providers must notify supervisory body of security breaches within 24 hours. Wallet certification includes security evaluation.

Lays down rules for applying the EU Cybersecurity Act (Regulation 2019/881) to establish the EUCC scheme for ICT products. Defines two assurance levels: substantial (AVA_VAN 1-2) and high (AVA_VAN 3-5). Requires evaluation of software components and dependencies as part of certification. Software composition analysis is implicit in the vulnerability assessment methodology. No direct SBOM mandate but component-level evaluation creates implicit need for software inventory.

Vulnerability management as part of certification maintenance. Vulnerability assessment levels (AVA_VAN) define depth of vulnerability analysis required. Certified products must maintain security posture post-certification including vulnerability disclosure and patch management. Vulnerability database monitoring referenced.

Dedicated SBOM technical report by ETSI. Covers SBOM formats, use cases, tooling, CycloneDX and SPDX schema details, VEX integration, and regulatory mapping including EU CRA and ETSI EN 303 645. BOM refs: SBOM: pp. 1, 3-20 · AIBOM: p. 9 · MLBOM: pp. 10, 15 · CBOM: pp. 9, 15, 17 · HBOM: pp. 10, 15, 17

Vulnerability management via SBOM, coordinated disclosure, vulnerability database, vulnerability reporting

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

DG CONNECT legislative overview presentation (9 slides) summarizing the CRA proposal. Slide 7 explicitly covers SBOM in the CRA: manufacturers must draw up an SBOM in a commonly used format covering at minimum top-level dependencies; no requirement to make the SBOM publicly available; SBOM included in technical documentation and provided to market surveillance authorities on request; Commission empowered to specify format and elements referencing international standards.

Legislative briefing deck with no specific vulnerability management content. VM requirements are covered extensively in the full CRA text (see separate entry for Regulation 2024/2847).

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

Covers vulnerability disclosure and notification requirements. References software component-level vulnerability tracking and VEX-adjacent concepts without naming SBOM directly. SBOM is the natural upstream dependency.

Dedicated to vulnerability reporting. Covers coordinated disclosure, actively exploited vulnerability notification, vulnerability report format and content, vulnerability database integration

Updated version. Adds logical/identified component definitions, updates CycloneDX minimum to 1.6, SPDX minimum to 3.0.1. Supersedes v2.0.0. BOM refs: SBOM: pp. 1, 3-5, 7-22, 29, 33-37

Updated SBOM standard supporting vulnerability handling and vulnerability database integration

Living document aligned with EU CRA. Explicitly references SBOM as a required artifact for manufacturers of products with digital elements. Cross-references Part 2 for SBOM specifics. BOM refs: SBOM: pp. 17, 25

Vulnerability handling processes, coordinated disclosure, actively exploited vulnerability reporting, security update delivery, incident notification, penetration testing

The primary CRA legal text. Entered into force 10 December 2024; full application from 11 December 2027. Explicitly mandates SBOM and software transparency requirements in Annex I. Sets out mandatory cybersecurity requirements for all products with digital elements placed on the EU market. BOM refs: SBOM: pp. 5, 18, 25, 31, 38, 68, 70, 75

Full vulnerability lifecycle: actively exploited vulnerability notification via ENISA platform, coordinated disclosure, security updates for entire support period, vulnerability handling with SBOM, European vulnerability database. See Quick Reference above.

China's national mandatory standard for vehicle cybersecurity. Issued by SAMR and SAC. Defines requirements for vehicle cybersecurity management systems, technical cybersecurity measures, risk assessment, and component-level security testing. Software supply chain management and component verification requirements create implicit SBOM needs. Aligned with WP.29 UN R155/R156 cybersecurity framework.

Covers software update security and component-level security testing. Requires cybersecurity management system including threat monitoring and incident response capabilities. Based on WP.29 framework which includes continuous vulnerability monitoring. No specific public disclosure timelines defined in the standard.

Explicitly defines "cybersecurity bill of materials (BOM)" on p.8 as a list of commercial, open source, and OTS software and hardware components that are or could become susceptible to vulnerabilities. Section 2.3.1 (p.16) requires the BOM to list all third party or open source software components with version and build as part of Class III/IV device licence applications. Applies to all device classes (I to IV) under the Medical Devices Regulations. Section 2.2 (p.15) requires post-market vigilance plan including patching, vulnerability disclosure per coordinated process, and participation in ISAOs/ISACs. References NIST CSF, ISO 14971, AAMI TIR57:2016, IEC 62304, UL 2900-1:2017 and UL 2900-2-1:2018. Appendix A maps NIST CSF five functions (Identify, Protect, Detect, Respond, Recover) to medical device design controls.

Section 2.2: post-market vigilance, patching, vulnerability disclosure, ISAO/ISAC participation. Section 2.1.3: V&V including NVD vulnerability testing, fuzz testing, penetration testing, static analysis. References AAMI TIR57, UL 2900, IEC 62304, ISO 14971, NIST CSF.

Contains dedicated "Mitigation of Supply-chain and Third-party Risks" provisions (Sections 15-16). Section 9(1)(a) requires cyber security programs to identify and manage risks "associated with supply chains and the use of third-party products and services." Section 15.2(j)(k) enables mandatory vulnerability assessments on telecom networks. No direct SBOM mention, but supply chain risk management, third-party product controls, and vulnerability mitigation are core implicit SBOM use cases. Nearly identical to C-26 with minor judicial review transparency amendments.

Mandatory incident reporting to CSE within 72 hours for designated operators of critical cyber systems

Official Australian government security guidelines for software development. References secure software development practices, third party component management, and supply chain security. ACSC has separately endorsed SBOM adoption through the Shared Vision document but the ISM does not mandate SBOM by name.

Vulnerability disclosure process, coordinated vulnerability handling, security update delivery

Part of Australia's Cyber Security Legislative Package 2024. Establishes limited use obligations for incident reporting, smart device security standards, ransomware payment reporting, and a Cyber Incident Review Board. Amends the SOCI Act 2018 to strengthen obligations for critical infrastructure entities. Supply chain security provisions create implicit SBOM requirements for visibility into software components used in critical infrastructure.

Mandatory ransomware payment reporting within 72 hours. Establishes incident reporting framework for critical infrastructure entities. Cyber Incident Review Board for post-incident analysis. Security standards for smart devices include vulnerability management obligations.

South Korean government plan mandating SBOMs for IT systems and products across public, financial, telecommunications, and platform operator sectors, with institutionalization targeted by 2027. Requires real-time vulnerability inspection across software components and supply chain traceability. Announced October 2025 following SK Telecom and Lotte Card breaches. Coordinated across MSIT, KISA, and partner agencies.

Plan explicitly requires real-time vulnerability inspection across software components as part of the SBOM framework. Includes supply chain traceability and response capabilities. Vulnerability security assessments mandated for approximately 1,600 key IT systems across public institutions, financial sector, and telecom operators. No specific CVD disclosure timelines; focus is on continuous monitoring and inspection capability.

Japan's IoT security conformity assessment and labeling scheme. STAR-1 baseline began May 2025; STAR-3/4 for critical national infrastructure finalized late 2025. Requires security evaluation of product components and supply chain. SBOM is the natural upstream mechanism for component visibility though not named in the scheme itself. Will be required in government procurement.

Requires vulnerability disclosure process for IoT products in the labeling scheme

Japan's primary SBOM implementation guide. Covers SBOM creation, management, and use for both software suppliers and procurers. Addresses SBOM formats (CycloneDX, SPDX), depth requirements, and integration into vulnerability management workflows. Ver 2.0 expands scope to include software procurement side.

Comprehensive vulnerability management lifecycle using SBOM. Covers vulnerability monitoring, vulnerability database querying (NVD), coordinated disclosure, zero day handling, incident response