CRA
Regulation (EU) 2024/2847
The requirement. The CRA (Regulation (EU) 2024/2847, full application on 2027-12-11) requires products with software elements to have an exact SBOM, a controlled supply chain and documented vulnerability handling.
The usual problem. The SBOM of a modern web application counts hundreds of transitive npm entries that shift with every install. It is exact one day, wrong the next — and nobody has reviewed those packages.
The AWA answer, by construction. AWA's distributed packages have no external npm dependency at runtime: the inventory (SBOM) follows directly from that. The little third-party code (vendored crypto) is committed as source, pinned by SHA-256 with its SPDX licence, with a provenance record per vendored tree. No opaque bundler: what runs is what you read.
Check it yourself: open any front package.json in the repository — every dependencies entry is another @awacloud/* package of the monorepo itself (workspace:*, resolved in the repository). No third-party package, nothing is downloaded from a registry.
Compliance evidence pack — executive summary
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.
| Pack generated | Evidence verified |
|---|---|
| 2026-10-01 | 2026-10-01 |
AwaCloud status
In progress — full application of the CRA on 2027-12-11 · status as of 2026-09-15.