Your SBOM Is a Release Artifact. CRA and DORA Need It to Be a System of Record

Executive Summary

CRA and DORA both treat the SBOM as evidence a regulator can demand on any given day, which means a bill of materials generated per build and filed away is not compliance. It is a document you cannot ask questions of.

Key Takeaways

• The CRA SBOM obligation and the CRA Article 14 reporting clock are two different duties on two different timelines. The SBOM is a standing requirement enforceable at full application on 11 December 2027. Article 14 reporting binds from 11 September 2026. Both fail the same way if the inventory underneath is incomplete.
• A vulnerability-driven SBOM that only records components with a known CVE is not a bill of materials. It drops purl, hash, supplier, and license, which are the exact fields a declaration and a version-range match depend on.
• DORA never says the word SBOM. But its ICT-RMF names vulnerability and patch management as a required policy area, and the only way to evidence that is a component inventory you can query per asset. Sell ICT services into a financial entity and the same obligation reaches you through the contract.
• Ingestion source is a compliance boundary. A CI-native pipeline and a manual supplier upload have to land in the same clean inventory, or the gap becomes the first thing an auditor finds.
• The surfaces that make SBOM management workable under audit are a readiness view, a product ledger, and a staged incident export. Most manufacturers have none of them, and neither do most tools still being built for the deadline.

Problem

The shift from static files to a dynamic system of record is the new baseline for manufacturing. With the CRA reporting mandate landing on 11 September, manufacturers must transition to a live, query-able inventory that maps vulnerabilities and exploitation in real time. Filing a document away as a procurement checkbox no longer suffices; under the weight of CRA and DORA, a bill of materials you cannot query is a compliance failure waiting to happen.

Both regulations make the same demand from opposite directions. The CRA is a product regulation, so it requires a manufacturer to draw up and keep a machine-readable SBOM covering at least top-level dependencies and to produce it to a market surveillance authority on request across the declared support period. In practice that means regenerating it per release, since a BOM that lags the shipped software cannot answer for the shipped software. DORA comes at it from operational resilience: financial entities and their ICT third parties have to run vulnerability and patch management as a board-approved policy, which is impossible unless you know what is in production and what is wrong with it at any given moment. Neither obligation has a portal you file into. Both are standing states you have to be able to prove on any given day.

Stored per build, an SBOM answers exactly one question: what shipped in this build. The questions a regulator asks are the ones a stored file cannot reach. Which shipped versions carry this component, and was the vulnerable path even reachable in them? What did we know when we signed off on conformity? When did we first become aware? An SBOM sitting in a bucket answers none of that without a person and the better part of a week. The week is the part you do not have.

New SBOM By Phoenix Security Orange ASM Platform 

The failure is rarely a missing SBOM. It is an SBOM that only records what a scanner flagged. A vulnerability-driven ingestion path walks the vulnerabilities in an incoming CycloneDX document and resolves the affected component from there. A library with no vulnerability at parse time is never persisted. What you get is a vulnerable-component list, and it drops exactly the fields both regulations depend on: purl, content hash, supplier, license, scope.

That gap surfaces the moment you need a version range. Take a product shipping foo@2.4.1. An advisory identifies foo >=2.3,<2.4.3 as affected. If your released SBOM retained pkg:npm/foo@2.4.1, the match is trivial and you can state the affected range early. If ingestion kept only foo, you have an identity problem during the reporting window itself, which is the failure mode CISA’s own VEX guidance warns about: a vendor advisory using a slightly different name than your ingest path can hide the match entirely. The same gap defeats a DORA patch-management audit for a quieter reason. You cannot patch what your inventory does not know is installed.

VEX you already have and throw away

Software composition scanners increasingly return a VEX determination alongside the SBOM, a supplier or a scanning engine saying this path is not affected. An ingestion pipeline that deserializes the SBOM but discards its embedded VEX analysis is throwing away the one statement that keeps scope honest. Under the CRA that determination is what lets you narrow a notification to the builds that actually ship the vulnerable code path instead of declaring worst-case. Under DORA it lets you close a finding with a defensible justification instead of an open ticket that ages past its SLA. Discard it at ingest and you re-derive it later, under a clock.

Two regulations, one inventory, or two problems

The CRA reaches you as a manufacturer. DORA does not bind you as an ICT third party by direct statutory force, but it reaches you anyway: a financial-entity customer carrying its own DORA obligation pushes vulnerability-management and reporting terms into your contract, so the obligation arrives dressed as a contractual requirement. If your ASPM sensor, your firewall, or your agent runs inside a bank, that contract runs in parallel with your own CRA Article 14 clock. Same component, same CVE, two regimes, two cadences. Both have to draw from one inventory. If they draw from two, keyed differently, you can end up reporting different affected-version ranges for the same vulnerability, and that is difficult to defend when an examiner puts the two records side by side.

Phoenix Approach

We ran into this while designing CRA support in Phoenix Security. Most of the hard part was already there: the graph connecting applications, components, vulnerabilities, ownership, reachability, and risk decisions. The risk level includes detection of exploitable vulnerabilities, and together with Blue intelligence, we can detect both vulnerabilities and Malicious libraries. Nonetheless, for EUCRA, we needed to simplify the identification of which library was affected by the regulation (read as containing a vulnerable library with exploitation and being able to surface it when exporting the component Bill of Materials with vulnerable libraries.

What CRA forced us to model that we had not modeled properly was the marketed product and the exact software composition of each released version of it. A readiness check and an incident filing are separate jobs on the dependency list, and they need their own surfaces rather than a single export button on the one we had.

New SBOM Managment and Product SBOM

We redesigned the library screen to enable browsing history, delivering a usable vulnerable library inventory as well as reporting for the 24 and 72 h remediation plan (remediation campaign). 

We also created a dedicated support system for EU CRA Reporting with automated generation of the report in preparation for ENISA API.

Phoenix also supports pipeline direct import and suppliers’ direct import, so you can export the combined component bill of materials for your software and suppliers. 

It already ingests third-party SBOM files and correlates dependency findings against exceptions and risk decisions. What it does not yet do by default is carry the identifiers a CRA declaration needs, and it has no concept of a marketed product as a CRA-scoped commercial unit distinct from an internal application.

SBOM Product View to be able to report quickly on libraries affected by the EU CRA.

72h clock remediation campaign 

Within 72h is important to issue a remediation campaign statement. Phoenix has scoped both the remediation campaign and live remediation to help not only with the reporting but also with the agentic automatic fixing of the libraries with minimal friction.

Phoenix Security SBOM Remediation campaign

We have a new redesigned ingestion to support the full libraries, not just vulnerable ones, store historical SBOMs so you can compare versions and product versions for your reporting, pinpointing which SBOM-software version has SBOM.

This is compliant with CRA. We also introduced a CI-native one that auto-detects https://github.com/Security-Phoenix-demo/Utils/tree/main/SBOM-SCA-CONTAINER-PIPELINE with GitHub Actions, Jenkins, and Azure DevOps, attaches build provenance, and authenticates with a scoped, ingest-only key. This enables calculating final build file dependencies in the pipeline for complex builds, minimizing the false positive rate and exception rate.

This is also useful for uploading supplier SBOMs in bulk, as they usually come via the awkward path, the vendor deliverable, or an air-gapped system with no CI hook, and they come in via upload with format validation and are attached to a chosen asset by hand. 

Phoenix also automated the remediation process with agentic ticket creation with full details to schedule work for your agents or teams avoid token wasted by analyzing over and over a vulnerability. 

On top of that inventory sit three surfaces. The one that matters most is a readiness view, scoped to a single marketed product, that tells a compliance owner whether the thing is filable today: SBOM complete, exports signed, exceptions actually carrying a VEX justification, and coverage across contributing assets measured rather than assumed. It is a status light, not a workflow. This simplifies the false positive detection and justification. 

To simplify reporting to CRA central system and audit, we retain a product ledger for version history of what shipped when, so a BOM pulled months later for an audit is byte-identical to what was declared at release, which is what the CRA support-period duty and a DORA examiner both actually want: a point-in-time answer, not a current-state guess. And a staged incident export follows the Article 14 cascade, an early-warning draft pre-filled from inventory and threat intel, a notification draft that gains corrective measures once a remediation effort is linked, a final report that reads patch completion off that same effort. Every field is labeled by how it got filled, auto from inventory, assisted from a linked plan, or manual where the data honestly is not in the platform, member-state availability being the obvious one.

Finally, to remediate at scale the existing Remediation screen and Asset screen have been augmented with agentic remediation to fix all the libraries affected by exploited vulnerabilities with one click or MCP call. The Phoenix Green remediation pulls live your latest code and push remediation as PR for your team to approve grouping breaking and non-breaking changes in separate PR. 

None of this replaces filing. A human still submits to ENISA’s platform. What changes is how much of the draft is already right when they open it, and whether the SBOM behind it can answer an auditor without a week of reconstruction first.

Real-World Example

The following is a hypothetical internal test fixture, not a customer case. No figures describe an actual incident.

Take a fictional agent product that bundles an inference component, infra-runtime@2.4.1. A researcher publishes a PoC; an advisory lands naming infra-runtime >=2.3,<2.4.3. Because the released SBOM had retained pkg:generic/infra-runtime@2.4.1, resolving which shipped versions fall in that range was a query, not an investigation, so the early warning could carry an affected range instead of spending the first day of the clock reconstructing one. A VEX determination authored earlier for a build that did not compile in the vulnerable path scoped that build out rather than sweeping it in defensively. And because the notification content and the customer advisory were generated from the same underlying declaration, the team produced one signed document rather than hand-building two, which we would argue covers both the regulatory notification and the duty to inform users, though that is our reading of what satisfies each, not a line the regulation draws for you.

The useful failure in the fixture was upstream of all of it. The vendor advisory used a generic package name that did not match the product’s purl, and an early automated check missed it; a human caught it on review. This is why we match on purl and hash rather than package name alone.

Practical Guidance

Start with one of your actual production SBOMs, the file you shipped last week, not the schema and not the scanner docs. Then:

1. Pick ten components that have no CVE against them. Do they each carry a purl, a supplier, and a hash? If the ones without vulnerabilities are missing identity, your ingestion is vulnerability-driven and you have the problem this piece is about. Fixing purl coverage is the highest-leverage move on this list.
2. Confirm whether your ingestion path parses embedded VEX from suppliers or scanners, or silently drops it. If the documentation does not answer it, read the code path.
3. Classify your product against the CRA conformity classes: self-assessment, Class I, Class II, or critical. That determines whether a notified body sits between you and market access, and it is upstream of every Article 14 question.
4. Decide now where member-state availability data comes from. It is entitlement or CRM data, not something a security platform holds by default, and it is a mandatory-if-known field on the early warning.
5. If you sell into financial entities, map which of your components are already in scope for a customer’s DORA vulnerability-management policy. That obligation is contractual and it is already live, from 17 January 2025.

Next Steps

1. Run the identifier-completeness check above against your last three SBOM exports. Purl coverage is the number that tells you whether the rest is even possible.
2. If you are evaluating SBOM or CRA tooling from any vendor, ask to see the readiness view and the staged incident export as running screens, not a roadmap slide. The gap between a dependency list and a declaration console is exactly the gap this piece describes.
3. Run one test. Pick a vulnerability today and ask which exact released products contain it. If answering that means opening three scanners, searching an artifact bucket, and asking engineering which image actually shipped, the problem is not your CRA tooling. It is your inventory. CRA and DORA are just putting a deadline on fixing it, and they are cheaper to fix once, together, than as two programmes that will eventually disagree about the same CVE in front of a regulator.

Status note: the readiness view, product ledger, and staged incident export described under “What we are building” are in active development against an internal draft plan (PRD-ORANGE-CRA-001) and are not generally available. No ship date is committed. The Libraries screen, scanner connectors, and CycloneDX import described under “Available today” are shipped. The 11 September 2026 date is the CRA Article 14 reporting obligation; the SBOM essential requirement itself is enforceable at full CRA application on 11 December 2027.