Seventeen regimes across seven jurisdictions, plus the frameworks and guidance that shape them. Every one reduces to the same three questions about your code: which components are in it, what cryptography it uses, and who decided that was acceptable.
17
Regimes tracked
7
Jurisdictions mapped
3
Domains · OSS · crypto · AI
1
Policy set · one export
Where the rules apply, and when they take effect.
Select as many jurisdictions as you need: click highlighted regions, timeline entries or the filters below. Then open a regulation to see what it demands and what Earnie produces against it.
Where software supply chain regulations apply1.0×
Drag to pan · double-click or use + to zoomIn forcePhasing inScheduledChanging
When these rules take effect
2021
2022
2023
2024
2025
2026
2030
All regulations17 regulations
What it requires
EO 14028 set the SSDF and SBOM expectations for software sold to US federal agencies. OMB M-26-05 (23 January 2026) rescinded the common attestation memos M-22-18 and M-23-16: each agency now sets its own risk-based software assurance terms, and may require an SBOM on request in the contract.
Affects: Federal software suppliers
What Earnie does
Whatever an agency's terms ask for, the merge-time gate already records what was scanned, under which policy version, with which verdict. The evidence exists before the contract clause does.
Evidence produced
SBOM on request · merge-time gate record
What it requires
Report cyber incidents to CERT-In within six hours of noticing them, and retain logs for 180 days within Indian jurisdiction. CERT-In's technical guidelines (v2, July 2025) add advisory SBOM, CBOM/QBOM, AIBOM and HBOM practices for government, essential services and software exporters.
Affects: All entities operating in India
What Earnie does
Findings and triage decisions are timestamped and retained per project, so a six-hour report draws on a standing record. SBOM, CBOM and AIBOM come out of the same scan.
Evidence produced
retained finding log · SBOM · CBOM · AIBOM
What it requires
Supply-chain expectations for technology and service providers: know your components, assess supplier risk, and maintain the inventory that supports both.
Affects: Tech and service providers
What Earnie does
Component inventory resolved from source rather than declared in a manifest, with supplier and licence attached to every match.
Evidence produced
component inventory · supplier attribution
What it requires
Secure-by-design development practices, including third-party component management and provenance for anything pulled into a build.
Affects: All developers
What Earnie does
Write-time and merge-time enforcement on the same rule set, so guidance becomes a gate rather than a document.
Evidence produced
policy.cel · write-time decision log
What it requires
Cyber device submissions include an SBOM covering commercial, open-source and off-the-shelf components, plus a plan to monitor and address postmarket vulnerabilities.
Affects: Medical device manufacturers
What Earnie does
Per-release SBOM with support status and open findings on each component, kept current after the submission rather than frozen at it.
Evidence produced
SBOM per release · finding timeline
What it requires
Practical guidance on introducing SBOM management: scope, tooling, minimum fields, and how to operate it across a supply chain.
Affects: Software providers
What Earnie does
SBOM generation is the scan output, in CycloneDX or SPDX, so introduction is configuration rather than a programme.
Evidence produced
sbom.cyclonedx.json · sbom.spdx.json
What it requires
SBOMs in cybersecurity documentation for regulated medical devices, harmonised across participating regulators.
Affects: Regulated medical devices
What Earnie does
One inventory serves every regulator that asks for it, exported per device release.
Evidence produced
SBOM per device release
What it requires
Transactions involving information and communications technology and services from foreign adversaries can be prohibited or conditioned. The connected vehicles rule bars covered Chinese- and Russian-linked vehicle software from model year 2027, with hardware following.
Affects: ICTS, automotive, consumer devices
What Earnie does
Component provenance per project: where code originated, not only which package declared it.
Evidence produced
provenance attribution per component
What it requires
Article 21(2) requires supply-chain security measures covering direct suppliers and service providers, alongside policies on the use of cryptography and encryption. Management bodies carry the accountability. Most member states have transposed it; in July 2026 the Commission took Ireland, Spain, France and the Netherlands to court over late transposition.
Affects: Critical infrastructure, digital services
What Earnie does
One policy set covers both the supply-chain and the cryptography duty, with the policy version recorded next to every verdict.
Evidence produced
policy.cel · verdict history
What it requires
Maintain a register of information on all contractual arrangements for ICT services, and manage ICT third-party risk across the contractual chain.
Affects: Financial institutions
What Earnie does
The register is reconciled on every full scan rather than assembled for the filing. Partial coverage gates; full coverage reconciles.
Evidence produced
third-party register · coverage.json
What it requires
SBOMs delivered with software acquired by the Army, including COTS and open source, as a condition of the contract and flowed down to subcontractors.
Affects: Department of Defense suppliers
What Earnie does
The SBOM is produced by the pipeline on every release, so delivery is a fetch and not a build.
Evidence produced
SBOM per delivered release
What it requires
Requirement 6.3.2 requires an inventory of bespoke and custom software, and of third-party software components incorporated into it, to support vulnerability and patch management.
Affects: Card-handling environments
What Earnie does
The inventory is the scan output for the in-scope environment, with licence, version and open findings on every component.
Evidence produced
component inventory export
What it requires
Designated operators in federally regulated critical sectors must run cyber security programmes, manage supply-chain and third-party risk, and report cyber security incidents. Obligations come into force in phases as regulations are made.
Affects: Designated operators: finance, telecom, energy, transport
What Earnie does
Third-party component risk recorded per system and per release, so the programme a regulator asks for is documented against the actual code.
Evidence produced
component inventory · third-party risk record
What it requires
Article 14 reporting has applied since 11 September 2026: an early warning within 24 hours of an actively exploited vulnerability and a full notification within 72, through the ENISA Single Reporting Platform. Full application follows on 11 December 2027, including Annex I vulnerability handling and an SBOM for every product.
Affects: All products with digital elements
What Earnie does
A component inventory per release with exploitability and reachability already resolved. The 24-hour clock starts against a known set rather than a discovery exercise.
Evidence produced
sbom.cyclonedx.json · finding timeline per product
What it requires
Technical documentation and record-keeping for high-risk and general-purpose AI systems. The Digital Omnibus on AI, Regulation (EU) 2026/1744, deferred stand-alone Annex III obligations to 2 December 2027 and embedded Annex I systems to 2 August 2028. Article 50 transparency was not deferred; generative systems already on the market before 2 August 2026 have until 2 December 2026 to apply Article 50(2) marking.
Affects: Providers and deployers of AI systems
What Earnie does
AI provenance across the codebase: which code an agent wrote, which model produced it, and which policy passed it at write-time. The MCP guardrail emits a decision log whether or not it blocks.
Evidence produced
AIBOM · write-time decision log
What it requires
Widens the NIS Regulations 2018 to managed service providers and data centres, adds designated critical suppliers, and introduces a 24-hour early warning with a 72-hour full report. Most duties take effect through secondary legislation, expected around 2028.
Affects: Essential services, MSPs, data centres
What Earnie does
The same policy set as NIS2, mapped down. One posture record answers both regimes, so a UK implementation does not start a second programme.
Evidence produced
cross-regime policy mapping
What it requires
NIST IR 8547, still an initial public draft, sets quantum-vulnerable public-key algorithms (RSA, ECDSA, ECDH and finite-field Diffie-Hellman) as deprecated after 2030 and disallowed after 2035. NSA CNSA 2.0 sets earlier required dates for national security systems.
Affects: Federal systems and NSS suppliers
What Earnie does
Cryptographic inventory read from source: algorithm, key size, and whether the call site is reachable from a real entry point. Reachability is what makes the migration list finite and orderable.
Evidence produced
cbom.json · reachability path per finding
Not binding, but they shape what the binding rules ask for.
Cross-border initiatives, sector alignments and agency guidance. None of them carry a penalty.
Frameworks
Reusable models for secure development or SBOMs.
United States, Canada, Japan
NIST SSDF
Widely adopted guidance for secure software development, referenced in EO 14028 and used across public and private sectors.
United States
CNSS Policy 15
Requires national security system operators to assess software component risk, maintain inventories, and align with secure development baselines.
Global
ISO/IEC 5230
International standard developed by the OpenChain project for managing open source licence compliance and component inventories.
Global
NTIA/CISA SBOM minimum elements
Defines the minimum structure and fields required in a valid SBOM. Implemented in SPDX and CycloneDX tooling.
Policy initiatives
Government or global push shaping future rules.
Quad countries
Quad Secure Software Principles
High-level government commitment to promote SBOM use and secure development practices among Quad member countries.
OECD member countries
OECD Transparency Recommendation
Draft for an ongoing effort to align software supply chain practices across OECD member states.
Sectoral alignments
Sector bodies converging on the same artefact.
Global
IMDRF medical devices
SBOMs required in cybersecurity documentation for medical device approvals.
Global
GSMA & 5G supply chain security
Telecom operators are aligning around SBOM use and software transparency standards for 5G and mobile infrastructure.
Guidance
Non-binding recommendations from public agencies.
Germany
BSI software guidance
Germany's BSI outlines SBOM use, secure-by-design practices, and component traceability aligned with EU regulation.
European Union
ENISA good practices
Recommends SBOM use, supplier audits, and vulnerability management for EU Member States. Supports NIS2 implementation.
United States
CISA/NSA/ODNI series
US inter-agency practices for developers, suppliers, and customers. Emphasises SBOM, secure tooling, and component trust.
Who is affected
Department
Impact
Legal
Disclosure, liability (NIS2, CRA)
Procurement
Supplier compliance, SBOM validation
Engineering
Inventory, SBOM formats
Security
OSS risk & compliance
Product
Documentation, provenance
Executives
Jurisdictional strategy, risk exposure
What to have in place
SBOM generation embedded in CI/CD
Retention policies (FDA, DORA)
3rd-party component visibility
Region-specific readiness plans
Unified compliance dashboards
Legal, security and procurement coordination
One export, read by people who never log in.
Counsel and procurement reviewers get an artefact, not a login. It comes from the same store the operator triages in.
Component inventory
SBOM in CycloneDX or SPDX, per project and per release, with licence and version resolved from source rather than declared in a manifest. This is the artefact the CRA, DORA, PCI DSS, FDA and SSDF all reduce to.
Cryptographic inventory, with reachability
Algorithms and key sizes with the call path that reaches them from a real entry point. Reachability turns a post-quantum migration from an estimate into a finite, ordered list of call sites.
Decision record
Every triage verdict with the policy that produced it, the approver and the timestamp. Identity is (project, locator, rule), so triage survives re-scans and the record stays continuous across releases.
Whatever you explore on this page becomes your map. Download it as one PDF: what each regulation requires, what Earnie does about it, and the evidence it produces.
1Explore. Filter by jurisdiction on the map, the chips or the timeline.
2Add. Use "Add to my map" on the regulations you care about. No picks? Your map is whatever you're filtering.
3Download. One PDF, ready to share with legal, security or procurement.
Regulatory summaries on this page are for orientation and reflect published status as of 23 October 2026. They are not legal advice. Confirm scope, applicability and dates against the instruments themselves. Country boundaries from Natural Earth (public domain).
All regulations · 17 regulations
Software supply chain regulations map | EarnieSkip to content
Seventeen regimes across seven jurisdictions, plus the frameworks and guidance that shape them. Every one reduces to the same three questions about your code: which components are in it, what cryptography it uses, and who decided that was acceptable.
17
Regimes tracked
7
Jurisdictions mapped
3
Domains · OSS · crypto · AI
1
Policy set · one export
Where the rules apply, and when they take effect.
Select as many jurisdictions as you need: click highlighted regions, timeline entries or the filters below. Then open a regulation to see what it demands and what Earnie produces against it.
Where software supply chain regulations apply{{zoomLabel}}
{{tip.name}}
{{tip.list}}
{{geoMsgText}}
Drag to pan · double-click or use + to zoomIn forcePhasing inScheduledChanging
When these rules take effect
{{yr.y}}
{{listTitle}}{{listCount}}
What it requires
{{r.requires}}
Affects: {{r.affects}}
What Earnie does
{{r.earnie}}
Evidence produced
{{r.artefact}}
Not binding, but they shape what the binding rules ask for.
Cross-border initiatives, sector alignments and agency guidance. None of them carry a penalty.
Frameworks
Reusable models for secure development or SBOMs.
United States, Canada, Japan
NIST SSDF
Widely adopted guidance for secure software development, referenced in EO 14028 and used across public and private sectors.
United States
CNSS Policy 15
Requires national security system operators to assess software component risk, maintain inventories, and align with secure development baselines.
Global
ISO/IEC 5230
International standard developed by the OpenChain project for managing open source licence compliance and component inventories.
Global
NTIA/CISA SBOM minimum elements
Defines the minimum structure and fields required in a valid SBOM. Implemented in SPDX and CycloneDX tooling.
Policy initiatives
Government or global push shaping future rules.
Quad countries
Quad Secure Software Principles
High-level government commitment to promote SBOM use and secure development practices among Quad member countries.
OECD member countries
OECD Transparency Recommendation
Draft for an ongoing effort to align software supply chain practices across OECD member states.
Sectoral alignments
Sector bodies converging on the same artefact.
Global
IMDRF medical devices
SBOMs required in cybersecurity documentation for medical device approvals.
Global
GSMA & 5G supply chain security
Telecom operators are aligning around SBOM use and software transparency standards for 5G and mobile infrastructure.
Guidance
Non-binding recommendations from public agencies.
Germany
BSI software guidance
Germany's BSI outlines SBOM use, secure-by-design practices, and component traceability aligned with EU regulation.
European Union
ENISA good practices
Recommends SBOM use, supplier audits, and vulnerability management for EU Member States. Supports NIS2 implementation.
United States
CISA/NSA/ODNI series
US inter-agency practices for developers, suppliers, and customers. Emphasises SBOM, secure tooling, and component trust.
Who is affected
Department
Impact
Legal
Disclosure, liability (NIS2, CRA)
Procurement
Supplier compliance, SBOM validation
Engineering
Inventory, SBOM formats
Security
OSS risk & compliance
Product
Documentation, provenance
Executives
Jurisdictional strategy, risk exposure
What to have in place
SBOM generation embedded in CI/CD
Retention policies (FDA, DORA)
3rd-party component visibility
Region-specific readiness plans
Unified compliance dashboards
Legal, security and procurement coordination
One export, read by people who never log in.
Counsel and procurement reviewers get an artefact, not a login. It comes from the same store the operator triages in.
Component inventory
SBOM in CycloneDX or SPDX, per project and per release, with licence and version resolved from source rather than declared in a manifest. This is the artefact the CRA, DORA, PCI DSS, FDA and SSDF all reduce to.
Cryptographic inventory, with reachability
Algorithms and key sizes with the call path that reaches them from a real entry point. Reachability turns a post-quantum migration from an estimate into a finite, ordered list of call sites.
Decision record
Every triage verdict with the policy that produced it, the approver and the timestamp. Identity is (project, locator, rule), so triage survives re-scans and the record stays continuous across releases.
Whatever you explore on this page becomes your map. Download it as one PDF: what each regulation requires, what Earnie does about it, and the evidence it produces.
1Explore. Filter by jurisdiction on the map, the chips or the timeline.
2Add. Use "Add to my map" on the regulations you care about. No picks? Your map is whatever you're filtering.
3Download. One PDF, ready to share with legal, security or procurement.
Regulatory summaries on this page are for orientation and reflect published status as of 23 October 2026. They are not legal advice. Confirm scope, applicability and dates against the instruments themselves. Country boundaries from Natural Earth (public domain).
