As cybersecurity threats continue to rise, governments and organizations worldwide are implementing strict SBOM regulations to strengthen software supply chain security. These regulations are designed to enhance transparency, reduce vulnerabilities, and ensure that businesses take proactive measures to secure their software ecosystems.To remain compliant, companies must adhere to these evolving standards, which help mitigate security risks, prevent potential cyberattacks, and avoid costly legal consequences.This page provides a comprehensive breakdown of the most critical global regulations, detailing their specific requirements, impact on businesses, and the role of SBOM in ensuring compliance. With a clear and structured format, this guide simplifies complex regulatory frameworks, making it easier for organizations to understand and implement the necessary security measures.
Track SBOM, vulnerability disclosure, incident reporting, and software transparency obligations by region, industry, and enforcement stage.
115regulations tracked
0explicit SBOM signals
0dated deadlines
115 matching obligations
Need to map these obligations to your products?Turn global SBOM, vulnerability, and software supply chain requirements into a concrete evidence workflow with Exodos.
ISO/IEC 27090 AI Security Threats and Compromises
Global · International · AI & Data, Software & Digital Services, Critical Infrastructure · effective
effective
ISO and IEC published ISO/IEC 27090:2026 on 14 October 2026 as a voluntary guidance standard for understanding, detecting and mitigating security threats and compromises specific to AI systems throughout their lifecycle. It covers protection needs spanning training data, AI models, workflows, operation, updates and retraining, including data poisoning and model theft. Publication makes the standard available for adoption but does not itself create a regulatory mandate.
Primary provisionISO/IEC 27090:2026, Clause 1 (scope) and Clauses 5-6 (application of information security and types of potential compromise to AI systems)ISO/IEC 27090 provides guidance on understanding, detecting and mitigating security threats specific to artificial intelligence (AI) systems throughout their life cycle.
AI SecurityAI Supply ChainLifecycle SecurityThreat DetectionData and Model ProtectionEvidenceadjacent SBOM relevanceStandard
Effective
Evidence to prepare
AI system and lifecycle inventory; training-data, model and workflow protection records; AI threat models; data-poisoning and model-theft detection evidence; mitigation decisions; controls for operational data used in model updates or retraining; mappings to established ISO/IEC 27001 and ISO/IEC 27002 practices.
Relevant reference
ISO/IEC 27090:2026, Clause 1 (scope) and Clauses 5-6 (application of information security and types of potential compromise to AI systems)
Exodos note
Use ISO/IEC 27090 as the AI-security layer beside software, model and data inventories: map each AI asset and dependency to its threat, detection control, mitigation and lifecycle evidence. It is not an AIBOM specification or a legal mandate.
ISO/IEC 27090 provides guidance on understanding, detecting and mitigating security threats specific to artificial intelligence (AI) systems throughout their life cycle.
UK DWP Security Standard SS-003: Software Development
Europe · United Kingdom · Government & Public Sector, Software & Digital Services, AI & Data · effective
effective
DWP's version 2.1 software-development security standard, approved 30 July and published on GOV.UK on 7 October 2026, applies across DWP and its contracted supplier base for software handling Authority data when incorporated into the contract security schedule. It requires complete SBOMs for bespoke applications, microservices and integrated third-party components; automated CycloneDX or SPDX generation and SCA in modern CI/CD; release-by-release SBOM maintenance for legacy environments; supplier assessment, secure artefacts and build provenance; and controls for AI-generated code, coding assistants and agentic workflows. Publication of a changed standard does not automatically change existing contracts.
Primary provisionDWP Security Standard - Software Development (SS-003), version 2.1, Sections 10, 11.1.5, 11.1.24-11.1.28, 11.13.5 and 11.14.1-11.14.9; approved 30 July 2026 and published on GOV.UK 7 October 2026A complete Software Bill of Materials (SBoM) must be generated, maintained, and made available upon request for all bespoke applications, microservices, and integrated third-party components.
Applicable DWP contract security schedule; complete application, microservice and integrated-component SBOMs; automated build-phase CycloneDX or SPDX outputs; SCA and vulnerability-feed results; legacy SBOM baselines updated before each major and minor release; supplier assurance and third-party test records; signed artefacts and build provenance; AI-generated code tests, peer review, SAST, DAST and SCA results; package provenance checks; agent permission and human-consent records; versioned and scanned system prompts; approved exceptions and risk-register entries.
Relevant reference
DWP Security Standard - Software Development (SS-003), version 2.1, Sections 10, 11.1.5, 11.1.24-11.1.28, 11.13.5 and 11.14.1-11.14.9; approved 30 July 2026 and published on GOV.UK 7 October 2026
Exodos note
Treat the contract schedule as the applicability gate, then automate one signed SBOM per releasable unit and connect it to SCA, release, supplier and exception evidence. Extend the same provenance controls to AI-suggested packages and preserve reviews, scans and approvals for agentic changes. This is a DWP procurement standard, not a general UK statutory SBOM mandate.
A complete Software Bill of Materials (SBoM) must be generated, maintained, and made available upon request for all bespoke applications, microservices, and integrated third-party components.
UK DWP Technical Vulnerability and Continuous Threat Exposure Management Security Policy
Europe · United Kingdom · Government & Public Sector, Software & Digital Services, General Enterprise · effective
effective
Updated DWP policy published 7 October 2026 for DWP teams and contracted third-party suppliers whose systems or services handle Authority information, where the policy is incorporated into the contract security schedule. It requires continuous threat exposure management, near-real-time asset visibility, a continuously maintained hardware, software, firmware and service inventory, continuous scanning of internet-facing assets, at least weekly authenticated internal scanning, documented risk-based remediation and supplier monitoring. Mature environments must include SBOMs in the inventory. Publication of a changed policy does not automatically change existing contracts.
Primary provisionDWP Technical Vulnerability and Continuous Threat Exposure Management Security Policy, updated 7 October 2026, Sections 3.1-3.5, 6.1-6.17 and 8.5-8.9; DWP procurement publication applicability noticeIn mature environments, this must include Software Bill of Materials (SBOM), Identity and Access Data, and Firewall Rule Analysis.
Applicable DWP contract security schedule; approved CTEM process; current hardware, software, firmware and service inventory with versions, patch and lifecycle states; SBOMs for mature environments; near-real-time exposure telemetry; continuous external and weekly authenticated internal scan evidence; vendor advisory monitoring; contextual-risk and exploitability assessments; remediation and mitigation decisions; threat-intelligence records; assurance tests, audits and approved exceptions.
Relevant reference
DWP Technical Vulnerability and Continuous Threat Exposure Management Security Policy, updated 7 October 2026, Sections 3.1-3.5, 6.1-6.17 and 8.5-8.9; DWP procurement publication applicability notice
Exodos note
Use the contract schedule to confirm scope. Link SBOM component versions to the enterprise asset inventory, vendor advisories, exploit intelligence, patch state and remediation decisions so exposure can be prioritised by business impact. The policy is a DWP supplier control, not a general UK legal requirement, and its SBOM language is expressly tied to mature environments.
In mature environments, this must include Software Bill of Materials (SBOM), Identity and Access Data, and Firewall Rule Analysis.
UK Government Functional Standard GovS 005: Digital
Europe · United Kingdom · Government & Public Sector, Software & Digital Services, AI & Data · effective
effective
Updated mandatory functional standard for UK government departments and in-scope bodies governing digital and data activity across the full lifecycle. The October 2026 version expressly covers AI-enabled components, supplier assurance, vulnerability identification and remediation, secure patching, component and dependency documentation, configuration management and retirement of technology that can no longer be updated or secured.
Primary provisionGovernment Functional Standard GovS 005: Digital, updated 1 October 2026, Sections 5.3, 5.4, 6.2, 6.3 and 8.8Services should be documented so their architecture, components and connections are defined and understood.
Service architecture and component maps including AI-enabled components; supplier standards and contractual responsibilities; vulnerability identification, remediation and patch records; service and technology catalogues; dependency records; configuration-management traceability; legacy and end-of-support plans; AI assurance, monitoring and retirement records.
Relevant reference
Government Functional Standard GovS 005: Digital, updated 1 October 2026, Sections 5.3, 5.4, 6.2, 6.3 and 8.8
Exodos note
Maintain a service-level inventory that links software and AI components to owners, suppliers, versions, dependencies, vulnerabilities and support status. GovS 005 does not prescribe an SBOM or AIBOM format, but structured component evidence supports its lifecycle, assurance and retirement expectations.
Services should be documented so their architecture, components and connections are defined and understood.
Japan Information Security Early Warning Partnership Guideline
Asia-Pacific · Japan · Software & Digital Services, Connected Products & IoT, Critical Infrastructure · guidance
guidance
IPA and JPCERT/CC's 2026 coordinated vulnerability disclosure guideline defines intake, developer verification, remediation and coordinated publication for software and website vulnerabilities. The revision integrates NICT and a Cabinet Office notification path under Japan's Active Cyber Defense Act for exploited, suspected-exploited, severe or potentially wide-impact vulnerabilities.
Primary provisionInformation Security Early Warning Partnership Guideline (2026), Section IV.1 and Section IV.5; Appendix 7; Active Cyber Defense Act Articles 37, 38, 40-42 and 45製品開発者は、製品に脆弱性が存在する場合には、その対策に関して適切な対応をすることが望まれます。
Published vulnerability contact; intake and acknowledgment records; affected product, version and component mapping; developer verification results; remediation or workaround records; JPCERT/CC communications; agreed disclosure schedule; exploitation and severity evidence; Cabinet Office coordination records where applicable; public advisory.
Relevant reference
Information Security Early Warning Partnership Guideline (2026), Section IV.1 and Section IV.5; Appendix 7; Active Cyber Defense Act Articles 37, 38, 40-42 and 45
Exodos note
Link component and version inventories to the product contact and remediation workflow so developers can verify scope, coordinate with JPCERT/CC and publish accurate fixes quickly. The guideline does not mandate an SBOM; component-level traceability is a pragmatic implementation aid.
Europe · Italy · Critical Infrastructure, Software & Digital Services, Government & Public Sector · guidance
guidance
ACN's first NIS implementation vademecum explains Italy's existing NIS2 compliance calendar. Shared information includes relevant suppliers, with changes reported within 14 days and an annual verification window from 15 April to 31 May. For the 2025-listed cohort, base security measures are due in October 2026; for entities registered by 28 February 2025 the precise statutory deadline is 18 months after receipt of the inclusion notice. The 2026-listed cohort's calendar places base measures in July 2027.
Primary provisionACN Vademecum NIS, version 1.0 (September 2026; release announced 11 September 2026), Sections 2 (p. 3, footnotes 2-3) and 3.2 (pp. 4-5, relevant supplier list); Legislative Decree 138/2024, Article 7(4), 7(7) and 42l’elenco dei fornitori rilevanti.
Relevant supplier register; dated supplier changes and NIS portal update receipts; annual information verification records; inclusion notice and cohort-specific deadline calculation; base security implementation evidence.
Relevant reference
ACN Vademecum NIS, version 1.0 (September 2026; release announced 11 September 2026), Sections 2 (p. 3, footnotes 2-3) and 3.2 (pp. 4-5, relevant supplier list); Legislative Decree 138/2024, Article 7(4), 7(7) and 42
Exodos note
Map software and ICT suppliers to the NIS supplier register and preserve the evidence behind each change. Use component inventories to support supplier risk reviews. Calculate the security deadline from the entity's inclusion notice rather than assuming a universal October date. The vademecum explains existing Italian NIS duties and does not create an SBOM mandate.
Europe · European Union · Healthcare & Life Sciences, Government & Public Sector, Software & Digital Services · guidance
guidance
ENISA guidance translating EU healthcare cybersecurity policy into procurement measures for hospitals and healthcare providers, including supplier assessment, tender requirements, security documentation, contract clauses, secure operation, vulnerability disclosure, patching, and end-of-life handling.
Primary provisionENISA Procurement Guidelines for the Cybersecurity of Hospitals and Healthcare Providers, Annex B procurement checklistcertified or independently assessed security postures
Supplier certification and compliance evidence, MDS2 form for medical devices, encryption, MFA and logging requirements, NIS2 supplier assessment, MDR/GDPR/EHDS procurement checklist, vulnerability disclosure clauses, patching obligations, incident notification terms, secure end-of-life and disposal plan.
Relevant reference
ENISA Procurement Guidelines for the Cybersecurity of Hospitals and Healthcare Providers, Annex B procurement checklist
Exodos note
This is buyer-side pressure on healthcare technology vendors: EU hospitals can turn NIS2, MDR, GDPR and EHDS expectations into concrete tender evidence. SBOM programs help answer the supplier, software, vulnerability and patching parts even though the guidance does not prescribe SBOM format.
certified or independently assessed security postures
US FY2027 NDAA Artificial Intelligence Functional Bill of Materials (AIBOM)
North America · United States · Government & Public Sector, AI & Data, Software & Digital Services · proposed
proposed
Proposed FY2027 NDAA Section 1652 would require DFARS updates barring DoD contracts for goods or services that use AI unless the contractor submits an AIBOM before award, renewal, or extension and maintains it for updates to DoD components within 48 hours.
Primary provisionS. 4784 RS, FY2027 NDAA, Section 1652(a)-(d), Artificial Intelligence Functional Bill of Materialsinclude details related to the software, data, and hardware
Machine-readable AIBOM, SBOM for software underpinning AI systems, model identifiers and versions, training data and inference-time data provenance, licensing, sensitivity, lineage, country of origin and processing history, hardware and compute inventory, cloud environments and deployment boundaries, update workflow capable of responding within 48 hours, access controls, digital signing or hashing, secure sharing and repository evidence.
Relevant reference
S. 4784 RS, FY2027 NDAA, Section 1652(a)-(d), Artificial Intelligence Functional Bill of Materials
Exodos note
Treat this as a leading AI supply chain transparency signal: practical AIBOM evidence has to join SBOMs, model metadata, dataset provenance, hardware/cloud deployment context, and secure repository controls. The IST AIBOM memo reinforces that AIBOM should build on SBOM formats instead of replacing them.
include details related to the software, data, and hardware
CISA/G7 Software Bill of Materials for AI Minimum Elements
Global · G7 / United States / European Union / Japan / United Kingdom / Canada · AI & Data, Software & Digital Services, Critical Infrastructure · guidance
guidance
Joint CISA and G7 guidance defining supplemental minimum elements for SBOMs used with AI systems, including model, dataset, infrastructure, security, and system-level transparency.
Primary provisionCISA/G7 Software Bill of Materials for AI - Minimum ElementsAI systems are software systems
AI SBOM metadata, model records, dataset properties, system-level properties, key performance indicators, security properties, infrastructure dependencies.
Relevant reference
CISA/G7 Software Bill of Materials for AI - Minimum Elements
Exodos note
This is the clearest public baseline for AI BOM data: treat models, datasets, infrastructure, and AI services as supply chain evidence, not just software packages.
North America · United States · Critical Infrastructure, Healthcare & Life Sciences, Financial Services · proposed
proposed
US critical infrastructure incident reporting law requiring CISA to finalize rules for covered cyber incident and ransom payment reporting by covered entities.
Primary provisionCIRCIA covered cyber incident and ransom payment reportingreport covered cyber incidents to CISA
North America · United States · Connected Products & IoT · guidance
guidance
Voluntary US cybersecurity labeling program for consumer IoT products, built around conformance testing, label authorization, registry information, and NIST technical criteria.
Primary provisionFCC IoT cybersecurity labeling program, Report and Order FCC 24-26U.S. Cyber Trust Mark
Europe · United Kingdom · Critical Infrastructure, Software & Digital Services · effective
effective
UK framework for network and information system security in operators of essential services and relevant digital service providers, with security and incident reporting duties.
Europe · United Kingdom · Software & Digital Services, General Enterprise, Government & Public Sector · guidance
guidance
UK government software vendor guidance designed to reduce software supply chain attacks and resilience incidents through secure design, development, deployment, communication, and procurement practices.
Primary provisionUK Software Security Code of Practice and NCSC implementation guidance, Theme 1reducing the likelihood and impact of software supply chain attacks
Software inventory or SBOM, third-party component inventory, build system and compiler inventory, supplier security requirements, validated and regularly updated inventory, vulnerability response evidence.
Relevant reference
UK Software Security Code of Practice and NCSC implementation guidance, Theme 1
Exodos note
This is not binding law, but it is a strong UK procurement signal: customers should expect vendors to evidence component inventory, supplier controls, and secure development practices.
reducing the likelihood and impact of software supply chain attacks
Asia-Pacific · Australia · Connected Products & IoT, Software & Digital Services · effective
effective
Australian rules introducing mandatory cyber security standards for most consumer smart devices, with obligations that create a need for product software inventory, update, and vulnerability evidence.
Smart-device software inventory, component and dependency evidence, update support policy, vulnerability disclosure process, conformity statement, consumer security information.
Relevant reference
Cyber Security (Security Standards for Smart Device) Rules 2025
Exodos note
Manufacturers should connect smart-device conformity evidence to firmware and software component inventories so vulnerability exposure can be answered quickly.
Singapore CSA Advisory on Securing the Software Supply Chain
Asia-Pacific · Singapore · Software & Digital Services, Government & Public Sector, General Enterprise · guidance
guidance
Singapore CSA guidance for managing software supply-chain risk across third-party acquisition, package installation, build automation, API integration, and development workflows. It calls for a visible SBOM, dependency controls, secure CI/CD, continuous monitoring, and contractual vendor safeguards.
Primary provisionCyber Security Agency of Singapore Advisory AD-2026-003, Recommended Measures: Strengthen Governance of Software ComponentsVisible Software Bill of Material (SBOM).
Cyber Security Agency of Singapore Advisory AD-2026-003, Recommended Measures: Strengthen Governance of Software Components
Exodos note
Use the advisory as a practical SBOM-consumption baseline: connect component inventory to approved dependency intake, CI/CD provenance, vulnerability monitoring, and supplier contract evidence.
Singapore Government ICT&SS Software Supply Chain Controls
Asia-Pacific · Singapore · Government & Public Sector, Software & Digital Services · guidance
guidance
Singapore Government ICT&SS control catalogue for protecting the integrity of the software supply chain. The SC control group covers repositories, commit signing, peer review, dependency pinning, reproducible build and release records, deployment controls, and artefact signing and verification.
Primary provisionSingapore Government ICT&SS Policy Reform, Software Supply Chain controls SC-1 through SC-9Pin direct and transitive dependency versions.
Version-controlled repository, signed-commit enforcement, peer-review approvals, dependency manifests and lockfiles, build and deployment records, artefact signing and verification evidence.
Relevant reference
Singapore Government ICT&SS Policy Reform, Software Supply Chain controls SC-1 through SC-9
Exodos note
This is an unusually concrete buyer-side control set. Map SBOM and build-provenance evidence to SC-4 dependency pinning, SC-5 release records, and SC-7/SC-8 artefact signing and verification.
North America · Canada · Critical Infrastructure, Financial Services, Software & Digital Services · effective
effective
Canadian cyber security law establishing a framework to protect critical cyber systems, including operator obligations for cyber security programs, incident reporting, supply chain risk, and third-party dependencies.
Primary provisionBill C-8, Critical Cyber Systems Protection Actprotect critical cyber systems
Critical system inventory, supplier and service-provider dependency map, software and SaaS supplier evidence, incident reporting records, cyber security program controls, risk mitigation plans.
Relevant reference
Bill C-8, Critical Cyber Systems Protection Act
Exodos note
Covered operators should treat SBOM, supplier, and service-provider evidence as part of the cyber system record needed for supply chain and third-party risk decisions.
Canadian Centre for Cyber Security Software Supply Chain Guidance
North America · Canada · Critical Infrastructure, Government & Public Sector, Software & Digital Services · guidance
guidance
Canadian guidance for protecting organizations from software supply chain threats, including supplier assessment and software component inventory/SBOM considerations.
Asia-Pacific · Japan · Software & Digital Services · guidance
guidance
Final METI and National Cybersecurity Office guidelines defining roles and evaluation checklists for providers and customers that develop, supply, and operate software, cloud services, embedded software, firmware, and cyber infrastructure. The final framework organizes supply-chain cybersecurity responsibilities into six categories.
Primary provisionMETI and National Cybersecurity Office, Guidelines on the Roles Expected of Cyber Infrastructure Providers, final version and evaluation checklistsimprove cybersecurity resilience across the entire software supply chain
Provider and customer role map, completed evaluation checklist, secure development evidence, supplier controls, vulnerability handling records, customer-facing assurance materials.
Relevant reference
METI and National Cybersecurity Office, Guidelines on the Roles Expected of Cyber Infrastructure Providers, final version and evaluation checklists
Exodos note
The final provider-role model fits a trust center that separates producer, supplier, and operator evidence. Use the evaluation checklists in software-supplier selection and periodic assurance reviews.
improve cybersecurity resilience across the entire software supply chain
Asia-Pacific · China · Critical Infrastructure, General Enterprise · effective
effective
Foundational Chinese cybersecurity law covering network operator security duties, critical information infrastructure protections, security incidents, and network product obligations.
Middle East · Saudi Arabia · Government & Public Sector, Critical Infrastructure, General Enterprise · effective
effective
Minimum cybersecurity requirements for Saudi government organizations and critical national infrastructure operators, covering governance, defense, resilience, cloud, third parties, and ICS.
GovernanceRisk ManagementThird-Party RiskCloud SecurityIndustrial Control SystemsEvidenceimplicit SBOM relevanceFramework
Middle East · Saudi Arabia · Government & Public Sector, Critical Infrastructure · effective
effective
Saudi critical systems controls extending the ECC for national critical systems across governance, defense, resilience, and third-party/cloud cybersecurity.
Global · International · Automotive & Mobility · guidance
guidance
Automotive industry guidance on SBOM program design, supplier exchange, vulnerability operations, confidentiality, and automation across OEM and multi-tier supplier ecosystems.
Primary provisionAuto-ISAC SBOM Informational Report, automotive SBOM useautomation is essential to SBOM adoption
Automotive SBOM policy, supplier exchange workflow, NDA or cybersecurity interface agreement controls, vulnerability triage records, SBOM tooling and automation evidence.
Relevant reference
Auto-ISAC SBOM Informational Report, automotive SBOM use
Exodos note
Auto-ISAC frames automotive SBOM as an operating model: trusted exchange, access control, vulnerability context, and supplier-tier visibility all need to work together.
Global · IMDRF Members · Healthcare & Life Sciences · guidance
guidance
International regulator guidance on SBOM principles and practices for medical device cybersecurity across manufacturers, healthcare providers, and other stakeholders.
Primary provisionIMDRF N73 SBOM principles and practices for medical device cybersecuritySoftware Bill of Materials for Medical Device Cybersecurity
CISA and International Partners Shared Vision for SBOM
Global · International · Software & Digital Services, Critical Infrastructure, Government & Public Sector · guidance
guidance
Joint international guidance setting a shared vision for SBOM as a core tool for vulnerability management, secure-by-design development, and software supply chain transparency.
Primary provisionCISA and international partners shared vision for SBOMSoftware Bill of Materials
IEC 62443-4-2 Technical Security Requirements for IACS Components
Global · International · Industrial & Manufacturing, Critical Infrastructure · effective
effective
Component-level security standard for industrial control system products, covering embedded devices, host devices, network devices, and software applications.
ISO/IEC 27001 Information Security Management Systems
Global · International · General Enterprise, Software & Digital Services · effective
effective
International information security management system standard used as a baseline for governance, risk treatment, supplier controls, and audit evidence.
Primary provisionISO/IEC 27001:2022, information security management systemsinformation security management systems
Global · International · General Enterprise, Software & Digital Services · effective
effective
Reference control catalogue for information security controls, including supplier relationships, secure development, vulnerability management, and asset management.
Primary provisionISO/IEC 27002:2022, information security controlsinformation security controls
North America · United States · Software & Digital Services, Industrial & Manufacturing, Critical Infrastructure · guidance
guidance
Final NIST report on verifiable supply-chain traceability, including software build provenance and component inventories. Its software procurement example links artifacts to attested build environments and upstream open-source components. Lifecycle guidance records firmware updates and component substitutions to support vulnerability response. The report is a conceptual framework, not a regulatory standard or compliance mandate.
Primary provisionNIST IR 8536 (final, 9 September 2026), Sections 1.3, 3.3 Principle 3 (Software Supply Chain and Build Provenance example, p. 20), 3.6 Principle 6 (Firmware Updates and Continuous SCRM example, p. 24)connecting software artifacts to attested, secure build environments and upstream open-source components using interoperable standards
NIST IR 8536 (final, 9 September 2026), Sections 1.3, 3.3 Principle 3 (Software Supply Chain and Build Provenance example, p. 20), 3.6 Principle 6 (Firmware Updates and Continuous SCRM example, p. 24)
Exodos note
Use a living SBOM as one input to a verifiable product history: connect versions to build attestations and upstream components, preserve firmware changes and expose provenance gaps to procurement teams. Start with critical software and OT suppliers. These are voluntary traceability principles; IR 8536 neither prescribes an SBOM format nor creates a new compliance deadline.
connecting software artifacts to attested, secure build environments and upstream open-source components using interoperable standards
North America · United States · Government & Public Sector, Critical Infrastructure, Software & Digital Services · guidance
guidance
Cybersecurity supply chain risk management guidance for federal systems and organizations, covering suppliers, products, services, and system components.
Global · United States / International · Software & Digital Services, Government & Public Sector, Critical Infrastructure · guidance
guidance
CISA update to the SBOM minimum elements baseline, reflecting the current state of maturity in software transparency and supply chain security and expanding expected SBOM capabilities.
Primary provisionCISA 2025 Minimum Elements for a Software Bill of Materialscurrent state of maturity
Current SBOM minimum elements, component identity, supplier identity, dependency relationships, hashes where available, lifecycle process evidence, vulnerability management linkage.
Relevant reference
CISA 2025 Minimum Elements for a Software Bill of Materials
Exodos note
Use the 2025 CISA baseline as the updated acceptance bar for supplier SBOMs, especially where procurement, vulnerability operations, and federal assurance evidence intersect.
CISA Joint Coordinated Vulnerability Disclosure Program Guidance
Global · United States / International · Software & Digital Services, Connected Products & IoT, Critical Infrastructure · guidance
guidance
Joint CISA, NSA, JPCERT/CC, NCSC-NL, and NCSC-UK guidance for software suppliers and online service providers to establish coordinated vulnerability disclosure programs with clear reporting paths, researcher communication, triage, remediation, and disclosure processes.
Primary provisionCISA joint guide, Establishing a Coordinated Vulnerability Disclosure Program to Work With Security ResearchersCoordinated Vulnerability Disclosure Program
CISA joint guide, Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers
Exodos note
This guidance is not a regulation, but it belongs in supplier assurance programs because SBOM, KEV, CVE, and multi-party software supply chain disclosures become more useful when vendors have a repeatable CVD process.
Global · International · Software & Digital Services · guidance
guidance
OWASP verification standard for software components and supply chain controls, including inventory, integrity, provenance, and vulnerability practices.
Primary provisionOWASP Software Component Verification StandardSoftware Component Verification Standard
Global · International · Software & Digital Services, Critical Infrastructure, General Enterprise · guidance
guidance
CycloneDX CBOM capability for representing cryptographic assets, relationships, algorithms, keys, certificates, and dependencies to support cryptographic risk and post-quantum readiness.
Primary provisionCycloneDX Cryptography Bill of Materials capabilityalgorithms, keys, certificates
North America · United States · Government & Public Sector, Critical Infrastructure, General Enterprise · guidance
guidance
NIST NCCoE practice guide for cryptographic discovery during post-quantum migration, including testing discovery tools and building inventory architecture.
North America · United States · Government & Public Sector, Software & Digital Services · effective
effective
Federal cloud security authorization baseline based on NIST SP 800-53 Rev. 5 controls, including supply chain, vulnerability, and configuration evidence.
Europe · European Union · Critical Infrastructure, Software & Digital Services, Government & Public Sector · proposed
proposed
European Commission proposal to revise the Cybersecurity Act and introduce a trusted ICT supply chain security framework for risks from high-risk suppliers and third-country dependencies.
Primary provisionProposal for a Regulation for the EU Cybersecurity Act, trusted ICT supply chain security frameworktrusted ICT supply chain
ICT supplier risk classification, high-risk supplier exposure evidence, software and service dependency map, certification evidence, product and service security assurance records.
Relevant reference
Proposal for a Regulation for the EU Cybersecurity Act, trusted ICT supply chain security framework
Exodos note
Organizations exposed to EU critical sectors should prepare supplier and software dependency evidence now, because high-risk supplier reviews become stronger when tied to product-level component data.
EU Medical Device Regulation Cybersecurity Expectations
Europe · European Union · Healthcare & Life Sciences · effective
effective
EU medical device framework requiring safety, performance, technical documentation, risk management, and post-market surveillance for software-enabled devices.
Primary provisionRegulation (EU) 2017/745 medical devicesmedical devices
EU In Vitro Diagnostic Regulation Cybersecurity Expectations
Europe · European Union · Healthcare & Life Sciences · effective
effective
EU in vitro diagnostic medical device framework covering software-enabled diagnostics, technical documentation, lifecycle risk, and post-market evidence.
Primary provisionRegulation (EU) 2017/746 in vitro diagnostic medical devicesin vitro diagnostic medical devices
Germany BSIG and KRITIS Cybersecurity Requirements
Europe · Germany · Critical Infrastructure, Government & Public Sector · effective
effective
German IT security law and critical infrastructure obligations covering security measures, incident reporting, and evidence for operators and providers.
Asia-Pacific · Malaysia · Critical Infrastructure, Government & Public Sector · effective
effective
Malaysian cybersecurity law establishing national critical information infrastructure duties, incident reporting, and cybersecurity service provider licensing.
Asia-Pacific · Australia · Financial Services · effective
effective
Information security standard requiring APRA-regulated entities to manage information security capability, controls, incidents, testing, audit, and third-party control assurance.
Information SecurityIncident ReportingThird-Party RiskControl AssuranceAudit Trailimplicit SBOM relevanceStandard
Effective
Deadline
Evidence to prepare
Information asset inventory, third-party control assurance, security testing, incident notification records, internal audit evidence.
Exodos note
Component and supplier inventories support information asset classification and third-party assurance.
North America · United States, Canada · Critical Infrastructure · effective
effective
Reliability standard requiring covered electric-sector entities to identify and manage cybersecurity risks from vendors and supply chain relationships.
OMB M-23-02 Migrating to Post-Quantum Cryptography
North America · United States · Government & Public Sector, Critical Infrastructure, General Enterprise · effective
effective
OMB memorandum directing federal agencies to prepare for post-quantum cryptography by inventorying cryptographic systems, prioritizing high-value and high-impact assets, and assessing migration funding.
Primary provisionOMB M-23-02, Section II prioritized inventory of cryptographic systemsprioritized inventory of cryptographic systems
North America · United States · Healthcare & Life Sciences · effective
effective
FDA cybersecurity expectations for medical device submissions and postmarket lifecycle management, including software component transparency and vulnerability management.
Primary provisionFD&C Act Section 524B(b)(3)provide a software bill of materials
Asia-Pacific · India · Financial Services · effective
effective
RBI directions for regulated entities outsourcing IT services, covering governance, risk management, confidentiality, business continuity, audit, and third-party oversight.
North America · United States · General Enterprise, Financial Services · effective
effective
Requires public companies to disclose material cybersecurity incidents and annually describe cybersecurity risk management, strategy, governance, and oversight.
Canada OSFI Guideline B-13 Technology and Cyber Risk Management
North America · Canada · Financial Services · effective
effective
OSFI guidance setting expectations for federally regulated financial institutions to manage technology and cyber risks, including incident reporting and resilience.
MAS technology risk obligations for payment service providers, including fast notification of relevant incidents and controls over technology operations.
US EO 14028 and Federal Secure Software Attestation
North America · United States · Government & Public Sector, Software & Digital Services · effective
effective
Federal software supply chain policy requiring software producers serving the US government to attest to secure development practices, with SBOMs and artifacts used by agencies as supporting evidence.
Primary provisionExecutive Order 14028, Section 4(e)(vii)providing a purchaser a Software Bill of Materials
UK Product Security and Telecommunications Infrastructure Regime
Europe · United Kingdom · Connected Products & IoT · effective
effective
UK consumer connectable product security regime requiring manufacturers, importers, and distributors to meet minimum security requirements and provide statements of compliance.
Primary provisionUK PSTI product security regime, security requirements for connectable productsstatement of compliance
Statement of compliance, password/security requirement evidence, vulnerability reporting channel, support period disclosure, importer/distributor records.
Relevant reference
UK PSTI product security regime, security requirements for connectable products
Exodos note
A product trust center can connect PSTI support-period and vulnerability-channel evidence with component transparency.
North America · Canada · Financial Services · effective
effective
OSFI third-party risk guidance requiring federally regulated financial institutions to manage risks across outsourced and other third-party arrangements.
Europe · European Union · Critical Infrastructure, Software & Digital Services, Government & Public Sector · effective
effective
EU-wide cybersecurity framework for essential and important entities, including risk management, incident reporting, supervision, and supply chain security measures.
Primary provisionDirective (EU) 2022/2555, Article 21 supply chain securitysecurity in network and information systems acquisition, development and maintenance
Asia-Pacific · China · AI & Data, Software & Digital Services, General Enterprise · effective
effective
Chinese network data security regulation requiring data processors to implement protection measures and report network product or service security defects and vulnerabilities.
Japanese IoT product security conformity assessment scheme with baseline and higher assurance labels intended to support procurement and international alignment.
Global · Payment Card Industry · Financial Services, Software & Digital Services · effective
effective
PCI DSS v4.0.1 Requirement 6.3.2 requires entities to maintain an inventory of bespoke and custom software and third-party software components incorporated into that software to support vulnerability and patch management.
Primary provisionPCI DSS v4.0.1 Requirement 6.3.2 and testing procedures 6.3.2.a-binventory of bespoke and custom software
Inventory of bespoke and custom software, third-party software components, libraries, APIs, payment software components and dependencies, supported execution platforms or environments, vulnerability and patch management records, software documentation, software composition analysis evidence.
Relevant reference
PCI DSS v4.0.1 Requirement 6.3.2 and testing procedures 6.3.2.a-b
Exodos note
PCI DSS does not prescribe a specific SBOM format, but Requirement 6.3.2 creates a practical SBOM control: payment software teams need component-level inventory tied to vulnerability and patch evidence.
EU Radio Equipment Directive Cybersecurity Delegated Regulation
Europe · European Union · Connected Products & IoT · phased
phased
Activates cybersecurity, privacy, and fraud-protection essential requirements for categories of internet-connected radio equipment under the Radio Equipment Directive.
Primary provisionDelegated Regulation (EU) 2022/30, Article 3 internet-connected radio equipmentdoes not harm the network or its functioning
Cybersecurity framework for critical information infrastructure, expanded by 2024 amendments to cover additional classes such as foundational digital infrastructure providers.
China GB 44495 and GB 44496 Vehicle Cybersecurity Standards
Asia-Pacific · China · Automotive & Mobility · effective
effective
Mandatory Chinese vehicle cybersecurity and software update standards covering CSMS-style governance, technical controls, inspection and test methods, software update management, and vehicle evidence.
OMB Memorandum M-26-05 Risk-Based Software and Hardware Security
North America · United States · Government & Public Sector, Software & Digital Services · effective
effective
Federal policy shifting software and hardware security assurance from universal attestation to agency risk-based contractual and validation approaches.
Primary provisionOMB M-26-05, software and hardware security validationprovide a current software bill of materials
Europe · United Kingdom · Automotive & Mobility · phased
phased
Great Britain type approval implementation of UN R155 cybersecurity and UN R156 software update requirements, with phased dates for new vehicle types, complete vehicles, completed vehicles, and special purpose vehicles.
Asia-Pacific · Australia · Financial Services · effective
effective
APRA standard requiring regulated entities to manage operational risks, maintain critical operations through disruption, and manage service-provider arrangements.
Asia-Pacific · China · Connected Products & IoT · upcoming
upcoming
China cybersecurity labeling framework for internet-connected products, including security capability levels, testing, reports, conformity statements, and vulnerability handling.
Europe · European Union · AI & Data, Software & Digital Services, Healthcare & Life Sciences · phased
phased
Risk-based AI regulation requiring technical documentation, logging, post-market monitoring, incident reporting, and cybersecurity measures for high-risk AI systems.
Primary provisionRegulation (EU) 2024/1689, Annex IV technical documentationtechnical documentation shall be drawn up before that system is placed on the market
EU CRA Delegated Regulation on Delayed Notification Sharing
Europe · European Union · Software & Digital Services, Connected Products & IoT, Critical Infrastructure · effective
effective
Delegated CRA rule defining the cybersecurity-related grounds and conditions under which a CSIRT may delay dissemination of incident and vulnerability notifications through the CRA reporting ecosystem. It is an operational reporting rule alongside the CRA's 11 September 2026 reporting obligations.
Primary provisionCommission Delegated Regulation (EU) 2026/881 supplementing Regulation (EU) 2024/2847, CRA Article 14(9)delaying the dissemination of notifications
CRA reporting workflow, notification timestamps, vulnerability and incident triage record, ENISA and CSIRT escalation contacts, evidence of any delayed-sharing decision.
This rule does not change a manufacturer's CRA notification duty. Build one auditable incident and vulnerability record that can support the manufacturer report and downstream CSIRT or ENISA information-sharing workflow.
US Executive Order on Defense Supply Chain BOM and Critical Materials
North America · United States · Government & Public Sector, Critical Infrastructure, Industrial & Manufacturing · phased
phased
Executive Order directing defense acquisition supply chain mapping, domestic and allied sourcing for critical materials, and future implementing regulations requiring prime contractors and subcontractors to provide complete indentured Bill of Materials evidence from raw materials to delivered systems.
Primary provisionExecutive Order, Sec. 3(b)(i), critical supply chain mapping and illumination; Sec. 2, 10 U.S.C. 4872 waiver restrictionscomponents, parts, equipment, software, and materials
Bill of MaterialsSBOMSupply Chain MappingSupplier RiskProcurement SecurityCritical MaterialsRisk MitigationCorrective Action PlansEvidenceexplicit SBOM relevanceExecutive Order
Effective
Deadline
Evidence to prepare
Complete indentured Bill of Materials tracing components, parts, equipment, software, and materials to raw material origin, supplier vetting records, 10 U.S.C. 4872 covered material evidence, mitigation plans, supply chain risk notifications within 15 days, corrective action plans within 45 days, closeout reports.
Relevant reference
Executive Order, Sec. 3(b)(i), critical supply chain mapping and illumination; Sec. 2, 10 U.S.C. 4872 waiver restrictions
Exodos note
This order pushes BOM practice beyond software into defense acquisition illumination. Contractors should connect SBOM, hardware, supplier, critical-material, and raw-material provenance data before the January 1, 2027 waiver restriction and follow-on regulations.
components, parts, equipment, software, and materials
Europe · European Union · Industrial & Manufacturing · upcoming
upcoming
Updates EU machinery safety rules for connected and software-enabled machinery, including protection against corruption where safety functions depend on software or data.
Primary provisionRegulation (EU) 2023/1230, Annex III 1.1.9 protection against corruptionidentify the software installed on it
Asia-Pacific · Singapore · Critical Infrastructure, Government & Public Sector, Software & Digital Services · guidance
guidance
CSA's 14 October 2026 advisory urges organisations exposed to quantum risk to plan early, favour quantum-ready software and services and build cryptographic agility. It reiterates Singapore's CII expectations in linked guidance: CIIO migration plans are due 31 March 2027, new CII procurement must include quantum-safe considerations from 1 January 2028, and CII migration must finish by 31 December 2031. Other organisations are encouraged to plan by end-2027 and complete migration by 2035. These are guidance and supervisory expectations, not a general statutory mandate.
Primary provisionCSA advisory, Singapore's Quantum-Safe Migration Milestones and What You Can Do sections 1-6; linked CII guidance Sections 5-8 and FAQ 2Other organisations exposed to quantum risks are encouraged to complete migration by 2035.
Named migration owner and accountable leader; list of CII assets using vulnerable cryptography; cryptographic protocols and algorithms; asset source and dependencies; migration approach and timeline; third-party vendor plan; interim controls and justifications; quantum-risk treatment in procurement policies; contract evidence for quantum-safe or quantum-ready systems; test results and migration progress records.
Relevant reference
CSA advisory, Singapore's Quantum-Safe Migration Milestones and What You Can Do sections 1-6; linked CII guidance Sections 5-8 and FAQ 2
Exodos note
Treat the required CII asset list as a cryptographic inventory and connect it to software components, suppliers and procurement evidence. Record where RSA or ECC is used, who owns the migration, which vendor upgrade is required and how readiness will be tested. The wider 2035 target is encouraged guidance, not a universal legal deadline.
Other organisations exposed to quantum risks are encouraged to complete migration by 2035.
Europe · Poland · Critical Infrastructure, Software & Digital Services, Government & Public Sector · guidance
guidance
Non-binding NASK and Ministry of Digital Affairs implementation guide for Poland's effective KSC 2.0 law. It explains how essential and important entities should operationalize information-security management, incident procedures and statutory ICT supply-chain controls, including supplier risk, product and service quality, dependency monitoring, supported software updates and vulnerability remediation. In-scope entities existing when the amendment entered into force have until 3 April 2027 to implement duties and begin using S46.
Primary provisionNASK and Ministry of Digital Affairs, KSC 2.0 practical guide, pages 43-44; KSC Act Article 8(1)(2)(e) and Article 8(2)(1)-(4); adaptation deadline 3 April 2027Ustawa nakłada obowiązek zarządzania ryzykiem związanym z dostawcami produktów, usług i procesów ICT.
Information-security management system; supplier and ICT dependency inventory; supplier risk and high-risk dependency assessments; security requirements in procurements and contracts; software support, update and vulnerability-remediation records; S46 onboarding and incident reports; policy, training and audit evidence.
Relevant reference
NASK and Ministry of Digital Affairs, KSC 2.0 practical guide, pages 43-44; KSC Act Article 8(1)(2)(e) and Article 8(2)(1)-(4); adaptation deadline 3 April 2027
Exodos note
Use component and supplier inventories to identify which systems depend on each ICT provider, track supported versions and evidence vulnerability remediation. KSC 2.0 does not name an SBOM requirement, so treat SBOM data as supporting evidence rather than a statutory deliverable.
Ustawa nakłada obowiązek zarządzania ryzykiem związanym z dostawcami produktów, usług i procesów ICT.
Europe · European Union · Software & Digital Services, Connected Products & IoT, Industrial & Manufacturing · phased
phased
EU cybersecurity law for products with digital elements, with phased secure development, vulnerability handling and SBOM requirements. Manufacturer reporting duties have applied since 11 September 2026 through ENISA's operational Single Reporting Platform, including for products placed on the market before 11 December 2027. ENISA's 1 October 2026 version 1.4 glossary defines the product, component, version, mitigation and exploitation fields used at each reporting stage. Main product requirements and open-source software steward reporting apply from 11 December 2027. July 2026 non-binding guidance clarifies remote data processing and free and open source software scope.
Primary provisionRegulation (EU) 2024/2847, Articles 14(2), 14(4), 16(1), 24(3), 71(2); Annex I Part II(1); ENISA CRA SRP Glossary version 1.4, common fields 1-18 and AEV fields v19-v30 (1 October 2026); ENISA SRP FAQ 4, 7, 9, 12-13 and 29; Commission guidance C(2026) 5252Name of the software or hardware component in which the vulnerability or incident is located or observed.
SBOM or equivalent component records; manufacturer early warning within 24 hours of awareness and notification within 72 hours of awareness; vulnerability final report within 14 days after a corrective or mitigating measure becomes available; severe-incident final report within 1 month after the 72-hour notification; product name and version, software or hardware component name and version, affected Member States, mitigations, exploitation facts and SRP submission records.
Relevant reference
Regulation (EU) 2024/2847, Articles 14(2), 14(4), 16(1), 24(3), 71(2); Annex I Part II(1); ENISA CRA SRP Glossary version 1.4, common fields 1-18 and AEV fields v19-v30 (1 October 2026); ENISA SRP FAQ 4, 7, 9, 12-13 and 29; Commission guidance C(2026) 5252
Exodos note
Connect component inventories to affected product versions and record when exploitation or a severe incident becomes known. Map evidence to ENISA's reporting-stage fields before an event occurs, including component, version, corrective measure and awareness timestamps. Assign SRP representatives with EU Login MFA, select the coordinating CSIRT and track the separate notification clocks. ENISA FAQ 13 clarifies that exploitation already known before 11 September 2026 need not be reported retrospectively.
Name of the software or hardware component in which the vulnerability or incident is located or observed.