CRA
Règlement (UE) 2024/2847
L'exigence. Le CRA (règlement UE 2024/2847, application complète le 11/12/2027) impose aux produits comportant du logiciel un SBOM exact, la maîtrise de la chaîne d'approvisionnement, une gestion documentée des vulnérabilités.
Le problème habituel. Le SBOM d'une application web moderne compte des centaines d'entrées npm transitives, mouvantes à chaque install. Il est exact un jour, faux le lendemain — et ces paquets sont rarement relus.
La réponse AWA, par construction. Les packages distribués d'AWA n'ont aucune dépendance npm externe à l'exécution : l'inventaire (SBOM) en découle directement. Les rares éléments de code tiers (crypto vendorisée) sont commités en source, épinglés par SHA-256 avec leur licence SPDX, avec un enregistrement de provenance par arbre vendorisé. Pas de bundler opaque : ce qui s'exécute est ce qui se lit.
Vérifiez dans le code : ouvrez n'importe quel package.json front du dépôt — chaque entrée de dependencies est un autre package @awacloud/* du monorepo lui-même (workspace:*, résolu dans le dépôt). Aucun package tiers, rien n'est téléchargé depuis un registre.
Dossier de preuves relatives à la conformité — synthèse exécutive
CRA-01 proven Annex I Pt II §1 — SBOM covering top-level dependencies
Each published package release carries a standard-format SBOM in two formats — SPDX 2.3 and CycloneDX 1.6 — generated by tools/sbom, attached to the release and listed in its signed digest manifest (the five lot-1 releases of 2026-09-29). The dependency graph behind it is closed and machine-derivable: the 59 bun-resolved workspace-member manifests declare exactly 1 external runtime dependency (playwright@1.60.0, in services/acvp — a test-harness service, not a distributed package); zero across all 16 distribution packages.
Reclassified gap → proven on 2026-10-01: the condition this row set for itself — tools/sbom exists — is met, and the SBOMs ship. Scoped to the five lot-1 releases: packages not yet published carry no SBOM. The SBOM files are not individually signed; their digests are covered by the signed release manifest (CRA-05). BL-811 is closed on this evidence.
CRA-02 proven Annex I Pt II §1 — identification of third-party components
Every vendored third-party tree is pinned by URL, ref, SHA-256 and SPDX licence, with a per-tree NOTICE, and the pinning is test-enforced. 6 trees: mlkem-native v1.2.0, pqclean (commit 202a8f9), openssl-slh-dsa 3.5.0, bearssl v0.6, fiat-crypto v0.1.6, libsodium 1.0.22.
CRA-03 proven Art. 13(8) + Annex I Pt II §5 — coordinated vulnerability disclosure policy
A coordinated-vulnerability-disclosure policy is published: SECURITY.md at the repository root names the reporting channel (security@awacloud.com, with a published encryption key), response targets (acknowledgment ≤ 2 business days, triage ≤ 5 business days, fix or documented mitigation for critical/high issues targeted ≤ 30 days), a 90-day coordinated-disclosure window and a safe-harbor section.
Former absence claim, falsified by the delivery of BL-810 (2026-09-15); SECURITY.md is also at the root of the public repository published on 2026-09-29. The targets are a published policy, not a contractual SLA. security.txt on the sites ships with the sites themselves.
CRA-04 partial Annex I Pt II §2, §8 — security-update distribution channel
A security-update distribution channel exists since the first publication: five packages are published on the npm registry and as GitHub releases carrying signed digest manifests (2026-09-29), and support windows are stated in MAINTENANCE.md.
Former absence claim, falsified by the 2026-09-29 publication. The run changed: the former scan of the distribution packages' private/version fields (still 16/16 private: true at 0.1.0 in the monorepo) no longer measures publication, because tools/pkg-export flips private at export — published.json is the publication record. Partial: no security update has yet been issued through the channel, and 11 of the 16 distribution packages are not published. BL-813 is closed on this evidence.
CRA-05 proven Annex I Pt II §8 — authenticity of updates
The release signing chain is delivered and in use: release tags are signed with an ed25519 key (classical), each release's artifact-digest manifest is signed with a hybrid ML-DSA-65 + ECDSA P-256 envelope, and the verification instructions are published. The five lot-1 releases and the public-tree release of 2026-09-29 were signed this way.
Reclassified partial → proven on 2026-10-01: the key ceremony was held and the verification page written (BL-815, delivered 2026-09-15), and lot 1 was signed on 2026-09-29. The former wording "PQC-hybridised PGP chain" was wrong and is withdrawn: no OpenPGP is used anywhere in the release chain (ai/conventions/release-process.md § Signing chain). The tag signature is classical-only; the post-quantum half is the manifest envelope (PQC-07).
CRA-06 proven Annex I Pt I §1(e) — integrity of distributed artifacts
The WASM tier ships a per-artifact SHA-256 manifest (22 entries) with a drift check wired as a workspace script, and every published release carries an artifact-digest manifest covering each published file, signed (CRA-05).
Reclassified partial → proven on 2026-10-01: the repo-wide, signed artifact-digest manifest this row's note asked for now exists, one per release. Scope: published releases only; the integrity of a buyer's own build stays the buyer's.
CRA-07 partial Annex I Pt II §1 / supply-chain assurance — reproducible builds
Path-scoped only. A rebuild of the @awacloud/fw dist with the build path held fixed is byte-identical, exactly as scoped by ai/conventions/release-process.md § Build path pinning & reproducibility scope. Full, path-independent reproducibility is not claimed.
D35 was ruled option (b) by the owner on 2026-08-25 and implemented by tools/BATCH_56: BL-697 (both wall-clock stamps), the debugId half of BL-698, and the authorising section itself — closing BL-812. Two path-dependent residuals stay open by design under option (b) and are eliminated only by building from the pinned path, never by a build-time normalisation: path-dependent minifier identifier allocation (Bun minifier; 32 of 629 blobs at fw scale, tools/BATCH_54 task 09) and Bun-embedded // <path> source-path comments in non-minified output, which also move the meta's dev, devGz and hashSha256.dev fields (tools/BATCH_56 task 01). They are why this row is partial and not proven: no general, path-independent reproducibility is claimed here, or anywhere in this pack. The control above also ran at a fixed path that is not the pinned release path (the primary checkout root), so it evidences same-path determinism, of which the pinned-path case is one instance.
CRA-08 proven Annex I Pt I §1(d),(j) — minimise attack surface / limit exposure
Zero external npm runtime dependencies in every distributed package; no bundler and no registry at runtime (browser resolution via HTML import maps, present in 6 of 7 tracked app HTML entry points); three explicit hardening tiers with a published, honest threat model including stated non-guarantees.
The development toolchain is not dependency-free: bun.lock resolves 188 packages (GDPR-05). The claim is about what ships, not what builds.
CRA-09 partial Art. 13 + Annex II — information and instructions to the user (licence, identity, contact)
A fail-closed compliance gate exists in the export pipeline: it refuses to export a package whose licence value is absent from the ruled tiering, materialises LICENSE/NOTICE from two repo-tracked precedent texts rather than re-typing them, and makes an aggregating vendor/NOTICE a named precondition for any package shipping a vendored tree.
The gate is proven and the state is now nearly so: licences and license fields are stamped on all 16; two CHANGELOGs remain. BL-814 stays open for those two.
Dossier généré le 2026-10-01 · preuves vérifiées le 2026-10-01
Statut AwaCloud
En cours — application complète du CRA le 11/12/2027 · statut au 15/09/2026.