Vulnerability handling evidence for the CRA, generated as part of the tested PR review.
Article 11 turns vulnerability disclosure, coordinated handling, and free security updates for the support period into a verifiable record. Bivouac logs every CVE → fix → test → review state with a deterministic hash, then bundles a signed export per quarter. The signed bundle is the auditor's replay file — same input, same root, byte for byte. Evidence for your audit, not a Bivouac certification.
Article 11 + Annex I mapped to the review log
What the CRA asks for, and what Bivouac already records.
The obligations on the left are the regulation. The matchings on the right are what your auditor replays when they ask for evidence — already captured per review, no end-of-quarter rebuild required. Bivouac supports your EU CRA evidence workflow; Bivouac is itself not certified against the framework.
- Article 11(1)
Vulnerability handling — SBOM and coordinated disclosure for the support period
A complete SBOM is rebuilt every calendar quarter from what actually shipped — direct and transitive edges, vendor, version, parent chain. Disclosures attach to the package and version they affected; the support period is stamped per edge so the free-update window is never a guess.
- Article 11(2)
Free security updates and patches for the support period — address without delay
A new CVE fires a signal within minutes. The policy pack pre-classifies the move (forward fix, downgrade, pin), and a draft PR is opened against the real repo. The review row carries the CVE id, the upstream disclosure date, the test outcome, and the review timestamp — the audit trail for "addressed without delay" is the review log, not a separate paper record.
- Annex I.2
Secure-by-design — minimise attack surface, dependency risk, address known vulnerabilities
Every dependency edge is reviewed before a code change. License posture, peer usage, and security-sensitive surfaces are scored by the policy pack, and the chosen direction is recorded BEFORE code is touched. License-sensitive or security-sensitive moves stop at a human; the override is itself a row in the bundle.
- Annex I.1
Secure-by-default — secure configuration out of the box
Patch PRs run the actual project test suite on the actual upgrade path. Green results make a PR ready for human approval, so the default shipped configuration is always the tested configuration. The same approval flag records the human decision on every widening.
- Article 13
Reporting obligations to ENISA on actively exploited vulnerabilities
Every patch row in the bundle is shaped like a report — CVE id, signal source, disclosure date, fix timestamp, classification. The signed export IS the evidence envelope your regulator and ENISA can replay; no second document has to be kept aligned with the code.
- Article 11(3)
5-year support period obligation — manufacturers ensure effective handling through the lifetime
The support window is a per-edge stamp inside the SBOM rollup, not a global setting. The signed attestation includes a coverage table per repo for the chosen quarter; a vendor that slipped out of support is visible at quarter close, not after the regulator asks.
Proof, not a promise
One signed bundle per quarter — replayable, hash-verifiable.
Pick a connected repo and a calendar quarter from /dashboard/attestand download the bundle. Every Article 11 patch event, test outcome, merge vs human override, CVE id, and SBOM rollup — including the support-period stamp per dependency edge — is in the same JSON and on the cover of the branded PDF. The attestation hash is deterministic, so the same data always hashes to the same root. Your notified body's replay matches yours, byte for byte. Bivouac produces the evidence; the certification is your team's, earned in your audit.
Quarter-scoped, deterministic-hashed, downloadable as JSON or PDF. The bundle is the only artifact your notified body needs — Article 11 coverage, decision provenance, support-period alignment, and SBOM provenance all live in the same signed root.
From signal to Article 11 evidence
Four steps run end to end — the same trail your notified body replays.
Nothing on this list is reconstructed at the end of the quarter. Every step is a row in the signed bundle, in order, with the policy-pack decision and the Article 13 SBOM provenance/per-build software-bill-of-materials attached to the last one.
- 01
Signal fires
New CVE, ENISA advisory, or upstream breaking change on a watched repo. The signal carries the disclosure date and severity so Article 11(2) timelines have a clock to start from.
- 02
Policy pack decides
Forward fix, downgrade, or pin chosen locally — license posture, peer usage, and security-sensitive surfaces reviewed BEFORE any code is touched. The chosen direction is recorded on the merge row before the PR exists.
- 03
Test outcome recorded
Project test suite runs against the draft PR; pass/fail attaches to the review row, not just a resulting commit. The row shows whether the patch is ready for human approval; Bivouac does not claim the human merge decision.
- 04
Review or human escalation
Green tests produce a reviewable PR; security-sensitive surfaces stop at a human. Article 13 provenance — vendor, version, parent edge, support-period stamp — is recorded per review so the SBOM rollup is generated, not re-typed.
CRA buyer questions
The questions your notified body and your VP Engineering will ask first.
Bivouac produces the evidence your team hands to the notified body — it isn't itself EU CRA certified.
Generate, sign, ship
Generate your first Article 11 attestation this quarter.
Connect a repo, review a tested patch, and the bundle hashes itself. By the time your notified body opens the export, the file is already self-verifying. Bivouac produces the evidence your team hands to the auditor — it isn't itself EU CRA certified.
Free for the first repo. No card to start.