Compliance mapping
How the software supply-chain requirements of the Cyber Resilience Act, NIS2, and DORA map to SBOMs, policies, and VEX in SBOM Observer.
The Cyber Resilience Act (CRA), NIS2, and DORA all require you to know which software components are in what you ship or run, and to handle the vulnerabilities in them. They set the requirement and leave the method to you. Compliance mapping turns each requirement into a check that SBOM Observer runs.
SBOMs are the data and policies are the checks. Policy violations show where a requirement is not met today, and the SBOMs and VEX analyses behind them show what you knew and what you decided.
Cyber Resilience Act
The CRA (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements, hardware or software, placed on the EU market. The manufacturer has to handle the vulnerabilities in every component of the product, including open-source components it didn't write.
- Since 11 September 2026, manufacturers report actively exploited vulnerabilities and severe incidents (Article 14). This covers products already on the market.
- From 11 December 2027, the main obligations apply, including the SBOM and vulnerability handling. A product placed on the market before then falls under them only after a substantial modification.
Requirements and what answers them
| Requirement | In SBOM Observer |
|---|---|
| SBOM (Annex I Part II(1)). Document the product's components in an SBOM in a commonly used, machine-readable format, covering at least the top-level dependencies. | Observer CLI generates a CycloneDX SBOM in the build, and SBOMs from other tools are imported as CycloneDX or SPDX. An attestation-scoped policy can check what each SBOM contains. |
| Third-party components (Article 13(5)). Exercise due diligence on components from third parties, open source included. | Components are matched against advisory sources for each supported ecosystem. Supplier SBOMs get the same matching and policies as your own builds. |
| Remediation (Annex I Part II(2)). Address and remediate vulnerabilities without delay. | Component-scoped policies on severity, EPSS, and VEX state flag what needs fixing, and a Rego or JavaScript policy can fail the build. Background rescans match components against new advisories, so a vulnerability disclosed after a release still produces a violation. |
| Support period (Article 13(8)). Keep handling vulnerabilities for the whole support period, at least five years unless the product is expected to be in use for less. | Keep the SBOM of every supported version active, and set the retention keep count to match. Components that appear only in archived SBOMs are not matched against new advisories. |
| Vulnerability records (Article 13(7)). Document the vulnerabilities you become aware of, including information from third parties. | A VEX analysis records whether a component is affected, why, and the response. Each one is dated, and one added in the app also names its author. VEX documents from suppliers attach to the same vulnerabilities. |
| Reporting (Article 14(1) and (2)). Notify ENISA and the coordinating CSIRT of each actively exploited vulnerability, with an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days after a fix or mitigation is available. | Impact analysis lists every application, container, and project that includes the affected component, with its version. The notification itself goes through ENISA's single reporting platform (Article 16). |
| Informing users (Annex I Part II(4), Article 14(8)). Publish information about fixed vulnerabilities, and tell users about actively exploited ones, where appropriate in a machine-readable format. | Select two SBOMs on the Attestations page and choose Compare to list the vulnerabilities the newer one resolved. Export VEX on a component's VEX tab exports an analysis as CycloneDX. |
| Technical documentation (Annex VII points 2(b) and 8). The SBOM is part of it, kept for at least 10 years (Article 13(13)) and given to a market surveillance authority on reasoned request. | Export SBOM on any component or project, as CycloneDX or SPDX. |
Documents for customers and authorities
Part of the CRA is about what you hand over. Buyers must be told when the support period ends (Article 13(19)), and fixed vulnerabilities must be disclosed once a security update is available (Annex I Part II(4)). A market surveillance authority can ask for the SBOM (Annex VII point 8). Giving users the SBOM is up to you, and if you do, the user information says where to find it (Annex II point 9).
Does the CRA apply to your products?
Trust Repository is the Bytesafe product for exchanging these documents with suppliers, customers, and authorities. Suppliers publish their SBOMs, VEX, and end-of-support dates into it, and your customers get yours per release from a Trust Portal. When an authority asks, you share from the same record. Trust Repository can also check SBOMs against BSI TR-03183-2, the German technical guideline on SBOMs for the CRA. Supplier SBOMs collected there can be imported into SBOM Observer for the analysis above.
NIS2 and DORA
NIS2 and DORA apply to organizations by sector, and cover the software they run, whether bought or built. Supplier SBOMs belong in SBOM Observer next to your own.
| Regulation | Requirement | In SBOM Observer |
|---|---|---|
| NIS2, Article 21(2) | Essential and important entities take measures for incident handling (point b), supply chain security (point d), and security in acquisition, development, and maintenance, including vulnerability handling (point e). | SBOMs of your own and your suppliers' software, component-scoped policies, and impact analysis from a vulnerability to every system that includes it. |
| DORA, Articles 8 and 28 | Financial entities keep an inventory of their ICT assets and dependencies, and manage ICT third-party risk. | Supplier SBOMs and supplier records with contacts and registered identifiers, checked by supplier-scoped policies. |
Requirements as policies
Examples of requirements written as policies, with the scope each one runs in:
| Rule | Scope | Requirement |
|---|---|---|
| No library with a vulnerability above a severity and EPSS threshold, unless a VEX analysis rules it out | Component | CRA remediation, NIS2 vulnerability handling |
| No component past its end-of-support date, taken from the SBOM or set on the component with Edit | Component | CRA support period |
| Every SBOM names its supplier and timestamp, identifies each component, and records dependency relationships | Attestation | CRA SBOM |
| Every supplier has a contact or a registered identifier, such as an LEI or a VAT number | Supplier | NIS2 and DORA supplier risk |
Templates for the first and third rules, Library Vulnerabilities EPSS/VEX and NTIA Minimum Elements for SBOM, are under Policies > Templates.
Policies run again whenever the data changes, so Policy Violations shows the gaps as of today, including any opened by a vulnerability disclosed after the last review. A violation disappears once the data no longer breaks the rule. For what was known earlier, look at the SBOMs and VEX analyses, which keep their dates.
Where to start
Start from the regulation that applies to you. A company that sells products and also runs critical services may need both rows.
| If you | Start with |
|---|---|
| Place products with digital elements on the EU market (CRA) | An SBOM for every release from CI/CD (Generate and upload SBOMs), a vulnerability policy that fails the build (Enforce policies in CI/CD), and the SBOMs of supported versions kept active. Publish SBOMs and VEX to customers with Trust Repository. |
| Are an essential or important entity under NIS2, or a financial entity under DORA | SBOMs for the systems in scope, supplier software included (Collect and monitor vendor SBOMs), and supplier-scoped policies. |
Write two or three requirements as policies first, and review the violations with the people responsible for risk and compliance before adding more.
Related
- Concept: Policies
- Concept: Retention strategy
- How-to: Write and test policies
- How-to: Analyze vulnerability impact
- How-to: Share SBOMs with customers