Twenty-four hours, and what has to be ready before them
The full Cyber Resilience Act chain, runnable offline and deterministically: component inventory, vulnerability triage, the Article 14 clocks, a signed update, the Annex VII pack.
Figures for the six governance repositories taken on 21 August 2026, those for Cartocortex on 17 October 2026, by running the test suites. None is copied from the README files.
The organising fact is a date
From 11 September 2026, a manufacturer of a product with digital elements has 24 hours to file an early warning with ENISA and its coordinating CSIRT after becoming aware of an actively exploited vulnerability, 72 hours for the substantive notification, and 14 days from a fix becoming available for the final report. Full application of the Regulation follows on 11 December 2027.
Twenty-four hours pose an inventory problem, a triage problem and a clock problem, and most organisations discover which of the three they failed at somewhere around hour nineteen. This repository runs the whole chain in one command, with no network, so the question is asked before the incident rather than during it.
A file that cannot say no amounts to an archive
"An SBOM without identifiers is paperwork."
Every link is allowed to refuse. A component the SBOM cannot identify is counted as unmatchable. A VEX statement left under investigation past its window is flagged as stale rather than carried forward. And an update that would take the device below its security-version floor is refused, correctly signed or not.
SBOM 9 components, 88.9% matchable
scan 6 raw match(es) → 3 actionable → 1 with an Article 14 deadline
VEX audit 1 stale 'under_investigation' statement
Article 14 case CASE-2026-004
early_warning due 2026-09-16T07:20:00.000Z filed
notification due 2026-09-18T07:20:00.000Z filed
final_report due 2026-10-03T06:40:00.000Z filed
update 2.3.1 accepted: True
rollback to 2.2.1 : False ← security_version 6 is below the device's 8
Annex VII pack: 4 gap(s), retain until 2036-03-01The refused rollback is the line to keep. The signature was valid and the manifest well formed: what stopped the operation was the security-version floor, which is a rule working as designed.
What the suite exercises
One hundred and thirty-four tests, run on 21 August 2026 against the public repository. Coverage is measured in CI against a 90 per cent floor, and anything below that floor fails the build.
| Group | Tests | What it exercises |
|---|---|---|
test_sbom_vex_vuln.py | 41 | The inventory, the VEX statements and vulnerability triage |
test_fleet_updates_techdoc.py | 28 | The signed update and the Annex VII technical file |
test_article14.py | 26 | The three Article 14 clocks, and what starts them |
test_adversarial.py | 24 | What the chain does with hostile or malformed input |
test_cli_and_chain.py | 15 | The whole chain, from component to filed pack |
| Total | 134 | 91 % |
The integration gate chains static analysis, strict typing, source security review, dependency advisories and the coverage floor. Every one of them fails the build; none is advisory.
The known gaps, as the repository states them
The repository's threat model lists six residual risks. The four that matter to an outside reader are these.
- Nothing on the filing side is signed. Case files, inventories and the advisory feed are ordinary files: whoever can write them can rewrite history consistently. Detection covers editing, not a recomputed forgery.
- The advisory feed has no freshness check. A stale feed silently passes a vulnerability through, and it is on the reader to know it.
- Release signing keys sit in the clear on disk. There is no hardware root of trust here, and that is an accepted decision, documented as one.
- No real inventory has been run through this chain. The 88 per cent matchable figure is a prediction from the build log, not a field measurement.
Four documents, in the order they are read
- docs/GETTING_STARTED.mdAssumes neither a terminal nor Python, and leads to the first full run.
- docs/ARCHITECTURE.mdThe design decisions, and what they rule out.
- docs/CONTROL_MAP.mdEvery control mapped to the article of the Regulation it answers.
- docs/THREAT_MODEL.mdThe six residual risks, stated without mitigation.
A governance claim is verifiable, or it is worth nothing
The code of each link is public. To discuss this work, write to the author.