From SBOM to Declaration: Closing the CRA 24-Hour Clock Across One Platform

Executive summary: The Cyber Resilience Act’s 24-hour early warning is a detection, attribution and decision capability rather than a document, and Phoenix delivers it as one evidence chain across Purple, Orange, Blue, Blue Shield and Green.

Key takeaways

• Generate the SBOM inside the build and store it against the release artefact. Coverage percentage per shipped version is the only metric worth reporting before 11 September 2026.
• Connect exploitation intelligence and malicious-package detection to that inventory. If awareness depends on CVE enrichment landing, the 24-hour clock has already run.
• Resolve every component back to the build file that declared it. That turns “which products contain this version” from an investigation into a lookup.
• Treat the risk exception register as the VEX corpus. Four exception decisions already carry the analysis state, justification, approver and expiry a VEX statement needs.
• Run a timed 24-hour tabletop against a real event from your own history. Whatever cannot be produced on a calm Tuesday will be missing on the day it counts.

1. The problem

From 11 September 2026, the Cyber Resilience Act’s reporting obligations apply directly. Any manufacturer placing a product with digital elements on the EU market ships a machine-readable Software Bill of Materials under Annex I §2(1), and files an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident through the ENISA Single Reporting Platform. A full notification follows at 72 hours. A final report follows at 14 days once a corrective measure exists, or one month for severe incidents.

Two other cascades run alongside it. DORA has required a 4-hour, 72-hour and 1-month sequence for major ICT incidents since RTS 2025/301 came into force. The AI Act adds a 15-day serious-incident report for high-risk systems, dropping to 2 days for widespread infringement. One incident can trigger all three: an actively exploited flaw in an inference microservice sold to an EU bank fires CRA Article 14 at the manufacturer, DORA Article 19 at the bank, and AI Act Article 73 at the high-risk AI provider. Three channels, three clocks, one set of facts that had better agree.

Most CRA programmes are scoped as documentation work. The obligation is operational. The hard word in Article 14 is not report, it is awareness, and awareness is produced by a detection and triage capability that either exists on 11 September or does not.

Three things have to be true within hours of an event:

1. You detect that something in your product is being exploited or has been compromised.
2. You establish which products, which versions and which customers contain it.
3. You say something defensible about whether it is actually exploitable there.

Step 2 is what the SBOM is for. Step 3 is what VEX is for. 

Step 1 is where most programmes fail, because the intelligence they run on is CVE-shaped and the CRA’s trigger is not.

2. Technical analysis

The enrichment cadence outlives the deadline

A CVE identifier is reserved, then published, then enriched with CVSS, CPE and references. Those steps are not simultaneous. A scanner cannot match an unenriched record to an inventory, so nothing appears in the queue. Regulatory awareness has already started; internal awareness has not.

Active exploitation is not a field in a CVE record

Article 14 does not fire on vulnerable. It fires on actively exploited. That signal arrives separately: CISA KEV membership, EPSS movement, ransomware association, published proof of concept, threat-actor tracking. Correlating those by hand, per CVE, inside 24 hours does not scale. The same gap cuts both ways, because a programme that cannot evidence exploitation also cannot evidence its absence when it decides not to file. Recheability analysis is not explicitly mentioned for library and could be a justification for a limited ability to patch. 

The fastest-growing trigger category never receives a CVE

When an attacker publishes a typosquatted package, takes over a maintainer account, or ships a registry artefact that differs from the source repository, there is no vulnerability to disclose, only a live compromise sitting inside the build. A malicious update to an open-source dependency is squarely an Article 14 trigger for the affected product, and NVD will never carry it, because malware is not a vulnerability record. A vulnerability-shaped programme is structurally blind to the whole category.

Attribution is the second failure, and it is quieter

Detection without attribution produces an early warning nobody can complete. The regulator’s question is never whether a CVE is severe. It is whether the CVE is in what you shipped, in which version, to whom. Programmes that inventory repositories instead of released artefacts can answer a question adjacent to the one being asked.

VEX is a decision problem wearing a format problem’s clothes

Publishing an SBOM without a Vulnerability Exploitability eXchange statement makes the position worse. Every component becomes a CVE match, every match becomes a customer question, and the manufacturer has published a false-positive generator with its own name on it. VEX corrects that with a per-product, per-component, per-CVE statement of not_affected, affected, fixed or under_investigation, plus a justification code.

Authoring it is not a tooling exercise. Someone has to determine that the vulnerable function is never reached, that a compensating control already covers it, or that the risk is accepted, and someone has to be accountable for that determination. Security teams have made those calls for years. They have been filing them as risk exceptions.

3. The Phoenix Platform approach

Phoenix Security runs the same five-stage pipeline the CRA, DORA and the AI Act all assume, with the platform doing the work stage by stage. The order is deliberate and follows the platform philosophy: context first, prioritisation second, agent assistance third. Risk = Exploitability + Exposure + Reachability + Business Context.

Phoenix Security Purple: the component and model inventory, produced by analysis rather than assertion

Phoenix Purple is the graph-native code analysis layer covering SAST and SCA. It produces the dependency and component picture from the code and build rather than from a declared manifest, which matters because Annex I sets top-level dependencies as a floor and expects the depth reached to be stated.

Two Purple capabilities carry directly into a CRA position. Static reachability establishes whether a vulnerable function is on a call path at all, which is the technical basis for a not_affected justification later. Code Navigator traces the finding to the code that introduced it, which is what makes a 72-hour notification specific about the nature of the flaw instead of restating the advisory.

Model, dataset and prompt inventory sits in the same lane. CycloneDX 1.6/1.7 ML-BOM and the SPDX 3.0 AI profile now describe those components, and the AI Act’s Annex IV documentation duty assumes an organisation can enumerate them. Phoenix treats AI-BOM as an extension of the same inventory discipline rather than a separate compliance product.

Phoenix Security Orange: one inventory, one owner, one decision record

Phoenix Orange is where the declaration is assembled. It ingests CycloneDX SBOMs directly through the import API, enriching components with vulnerability data on the way in, or accepting a pre-enriched document as-is. Around that sit connectors for more than 40 commercial and open-source scanners across SAST, SCA, cloud, container, infrastructure and web, so the inventory is not limited to what one tool happened to see. Contextual deduplication collapses the same finding across those sources into one actionable item.

The build-file pivot. Phoenix resolves each component back to the build file that declared it, producing one asset per pom.xml, package.json or equivalent, keyed to its repository. Every library row then carries how many applications and assets reference that exact name-and-version pair, its license risk classification, and its open and closed finding counts by severity. “Which products we placed on the EU market contain this version” becomes a query.

Ownership attribution. Phoenix PYRUS metadata maps each component and finding to an accountable team, so a 24-hour early warning does not stall while someone works out who maintains the service. Security visibility without ownership is noise, and under Article 14 it is expensive noise.

Risk exceptions as the declaration record. The exception workflow captures four decision types, each mapping onto the VEX vocabulary:

Every record carries who requested it, who approved it, the justification, the scope and the expiry. Exceptions expire automatically and the finding returns to the queue, which is what stops a VEX corpus from rotting into stale claims a market surveillance authority can take apart. Because the exception engine applies decisions by policy as well as by hand, one determination can cover thousands of findings on a schedule, on an event, or on demand. That is the difference between VEX as an artisanal document and VEX as a produced artefact.

Orange also holds the register the briefing packs ask boards to maintain, exportable as CSV or JSON with CVE and CWE identifiers, CVSS score, EPSS probability, status, SLA target and breach state, owning team, application, component, asset identity, originating scanner and open and close dates.

Phoenix Security Blue: awareness that does not queue behind a database

Phoenix Blue is the intelligence plane, and it exists because the CRA trigger is exploitation rather than existence. Instead of treating the CVE record as the unit of truth, Blue assembles the picture a reporting decision needs and keeps it current independently of any single upstream’s publication cadence:

• Exploitation evidence: CISA KEV membership and dates, EPSS score and percentile, ransomware association, published proof of concept.
• Threat context: threat impact and type, mapped threat actors, and the CWE, CAPEC and MITRE ATT&CK chain behind them.
• Package intelligence: license category and risk, end-of-life status, popularity and blast radius, and a composite PS-OSS risk score per library.
• Prioritisation signals: the PS-HP high-profile score and the PS-EW enterprise watchlist, which surface the CVEs that matter for a given product mix rather than the ones that merely scored highly.

Blue ingests ENISA’s own EUVD alongside NVD, KEV, VulnCheck KEV, OSV, GHSA and native CSAF producers. For an EU regulation, citing the EU’s own vulnerability database as a corroborating source is not a footnote. Commit-diff monitoring runs in parallel, analysing changes in monitored repositories to surface patched vulnerabilities before CVE assignment. Same instinct at the other end of the timeline: watch the behaviour, not the identifier.

Malware Package Intelligence handles the category with no CVE. It monitors package registries continuously and analyses every new publication in three independent stages. A deterministic heuristic engine scores everything and acts as a gate rather than a verdict. Anything past the gate receives source-to-sink data-flow tracing, ATT&CK technique mapping, and intent discrimination, separating a package that legitimately spawns a subprocess from one that ships process.env to a domain registered yesterday. An adversarial judge then attempts to falsify that conclusion and hunts for false positives and prompt injection in the package under analysis. Agreement produces a hard verdict; disagreement produces a warning or a quarantine, never a silent pass. Mean time to detection runs under 15 minutes from publication, which is the number that decides whether a 24-hour clock is survivable.

Package history is the strongest single predictor Blue holds. A package, maintainer or namespace compromised before is far more likely to be compromised again, and PS-OSS encodes that as score floors rather than weighted contributions:

A floor cannot be averaged back down into the noise by healthy popularity numbers or a permissive license. Campaign membership is tracked across the registries, so a package caught in a coordinated wave inherits the urgency of the wave, which is exactly the read an early warning needs at 03:00.

Blue Shield: moving awareness ahead of installation

Phoenix Blue Shield enforces the same intelligence at four surfaces: a workstation PATH shim in front of npm install and pip install, native CI/CD plugins, hooks into eight supported AI coding agents, and a network proxy. Three enforcement modes cover the rollout path, from audit through warn to enforce.

The compliance consequence is worth stating plainly. Every gate that stops a compromised package before it enters a build is an Article 14 notification that never needs filing, because the product placed on the market never contained the component. Where a gate fires after the fact, the block itself is timestamped evidence of when awareness began.

Green: corrective measures on the 72-hour and 14-day clocks

The 24-hour early warning is the hardest deadline. The 72-hour notification is the most demanding, because it asks for corrective and mitigating measures taken or planned, and the 14-day final report closes only when a corrective measure is available.

Phoenix Green is the remediation pipeline that produces those measures. It clusters related findings into fix bundles so one pull request closes a family of issues rather than one row, generates dependency upgrade and IaC changes, and routes work to the owner Orange already identified. The tier ladder runs from Core through Plus and Plus Autofix to Premium, and human review is mandatory on Premium pull requests. Agents assist after context is established; they do not merge unsupervised.

Green also maintains a catalogue of 30 compensating controls. That artefact is doing double duty under the CRA: it is remediation guidance when a fix is not yet available, and it is the evidence behind a not_affected VEX statement citing an existing inline mitigation.

The clock, walked through

4. Real-world example

The reason inventory reduction belongs in a compliance article is arithmetic. A 24-hour decision requires a triage surface small enough for a human to reason about, with an owner attached to every row.

ClearBank moved from 112,000 findings to 7,300 after contextual deduplication and prioritisation, then to 300 actionable items, a 98% reduction, with $15M in annual developer time saved. Bazaarvoice cut vulnerabilities by 94% and container findings from 88,000 to 1,100. Across container estates, lineage analysis has taken 467,000 container vulnerabilities down to under 8,000 actionable items.

Those numbers describe developer productivity in a normal quarter. On 11 September they describe whether a regulatory question can be answered in a day.

5. Practical guidance

Four questions worth answering while there is still time to be wrong about them.

Can you enumerate what you shipped? The question covers the artefacts placed on the EU market, per version and per customer, rather than the contents of your repositories.

Where does exploitation signal come from? If the honest answer is that you wait for the CVE to be enriched, the 24-hour clock is already lost.

Can you see attacks with no CVE? Malicious packages and compromised maintainers move faster than any advisory pipeline, and a vulnerability-shaped programme cannot see them at all.

Are exception decisions structured or in a spreadsheet? On 11 September those decisions stop being internal risk management and become regulatory statements.

A 90-day sequence that works in that order:

Days 1 to 30, know what you ship. Generate an SBOM on every release build and store it against the artefact. Measure coverage. Format arguments can wait; you cannot triage against an inventory you do not have.

Days 31 to 60, know what is being exploited. Wire exploitation intelligence and malicious-package detection to that inventory. Run enforcement in audit mode first and measure the verdict distribution, including how many packages NVD had nothing to say about.

Days 61 to 90, know what you would say. Run a 24-hour tabletop against a real event from your own history and produce the early warning, the affected-product list and the exception statements.

What is in the platform today, and what is direction

Next steps

1. Baseline SBOM coverage across the products you place on the EU market, measured per released version rather than per repository.
2. Export your current exception register and check it field by field against the CycloneDX VEX and CSAF 2.0 schemas. The gap is usually expiry dates and approver identity, not analysis states.
3. Book the 24-hour tabletop before September, using a malicious-package event rather than a CVE, since that is the trigger most programmes cannot see.

Note:

Regulatory deadlines synthesise publicly available EU legal texts as of 12 August 2026 and are not legal advice; final interpretations should be validated with counsel and the relevant competent authorities. Capability availability varies by module, and items marked Direction are in active development.