CRA Art. 10 documentation-completeness checklist
This is the auditor-facing completeness checklist for the CRA Art. 10 accompanying documentation. It is the artifact the first public npm publish is gated on: every Art. 10 requirement maps to a now-resolvable, clickable artifact — zero unresolved-stub rows for the four CRA-scoped JS-family SDKs.
Assessment metadata
Section titled “Assessment metadata”| Field | Value |
|---|---|
assessed_at | 2026-06-19 (ISO-8601) |
| Produced by | Story 29-6 (CRA documentation set & SDK Support/Lifecycle trust page) |
| Version range covered | 0.x pre-publish (JS family) |
| Manufacturer | CRE8EVE Sp. z o.o. — see manufacturer.md |
Re-run trigger (load-bearing). This assessment covers the JS family at
0.x. It MUST be re-run and re-dated at the first 1.0 publish, because CRA Art. 10 documentation accompanies a distribution, and0.xis not yet distributed. The first public npm publish points its readiness evidence at this page; that publish re-dates this assessment.
Article 10 requirement → artifact
Section titled “Article 10 requirement → artifact”| CRA Art. 10 requirement | Resolvable artifact | State |
|---|---|---|
| Intended purpose + intended user | Per-SDK README + each Getting Started quickstart (leads with intended purpose/user) | ✅ resolvable |
| Manufacturer identification | manufacturer.md + /SECURITY.md | ✅ resolvable |
| Single point of contact | security@rakomi.com + security.txt | ✅ resolvable |
| Configuration recommendations + secure default settings | Secure defaults (per-runtime) | ✅ resolvable |
| Vulnerability disclosure policy | /SECURITY.md + per-package SECURITY.md | ✅ resolvable |
| Support period / end-of-life | SDK Support & Lifecycle + sdk-support.json | ✅ resolvable (dated windows attach at 1.0) |
| Cybersecurity risk assessment summary | security/threat-model/traceability-matrix.yaml (categorised by CWE) | ✅ resolvable |
| Vulnerability records | security/cra-vulnerability-records/ (10-year retention) | ✅ resolvable |
| Software bill of materials (SBOM) | Per-package sbom.cdx.json (CycloneDX) | ⚠ partial — see negative space |
| Patch / update policy | SemVer + per-package CHANGELOG.md + GitHub Releases | ✅ resolvable |
Source-tree artifact reachability (0.x pre-publish): links into
github.com/rakomidev/rakomi-js/…and baresecurity/…source-tree paths above resolve publicly when the source repository is made public at the first public release — pre-publish (0.x) the source repository is private. The same artifacts (SECURITY.md,sbom.cdx.json,CHANGELOG.md) also travel inside each published npm tarball, so they accompany the distribution regardless. The publish-time re-run of this assessment (see Assessment metadata) re-confirms every such link resolves for an unauthenticated public visitor.
Honest negative space (explicitly out of scope / scheduled)
Section titled “Honest negative space (explicitly out of scope / scheduled)”These rows are not over-claimed as complete — they are scheduled or owned by sibling work:
- SBOM for
@rakomi/sdk-coreand@rakomi/react-native— not yet generated.sbom.cdx.jsonexists today for@rakomi/nodeand@rakomi/react(plus the native Swift/Flutter sources); the two missing files are generated at first publish. The support page and the Art. 10 map render an honest “SBOM generated at first publish” placeholder for these two — no fabricated link. - Native Swift/Flutter Art. 10 documentation — owned by the native-SDK distribution work (separate story); those packages are not done and not published here.
- Live coordinated-vulnerability-disclosure reporting capability — national CSIRT identification,
EU single-reporting-platform onboarding, and statutory 24h/72h/14d filing are owned by the CRA
Art. 14 reporting-readiness work and are not yet operational.
SECURITY.mdstates the policy; the capability is being stood up separately (hard deadline 11 Sep 2026). - Provenance attestation (npm
--provenance/ SLSA Build L2) — attaches at first publish; nothing is signed or provenanced today. No “verify our signatures” claim resolves yet.
Periods & retention reconciliation (distinct clocks — do not conflate)
Section titled “Periods & retention reconciliation (distinct clocks — do not conflate)”| Clock | Period | Basis |
|---|---|---|
| Vulnerability-record retention | 10 years | CRA Art. 14 (live filing capability fenced to the Art. 14 reporting work — documentation only here) |
| SDK support period | ≥5 years (60 months) per MAJOR (attaches at 1.0) | CRA Art. 13(8) — see SDK support windows |
security.txt Expires | RFC 9116 freshness (≤ 1 year) | RFC 9116 — a contact-file freshness signal, not a retention or support period |
Control mapping (evidence-chain citability only)
Section titled “Control mapping (evidence-chain citability only)”The documentation set and CVD policy map to the following controls. This is documentation-only citability for a SOC 2 / ISO 27001 evidence chain — no control implementation is claimed here.
| Framework | Control | Mapped artifact |
|---|---|---|
| ISO 27001:2022 | A.5.5 — contact with authorities | EU-authority reporting policy in SECURITY.md |
| ISO 27001:2022 | A.8.8 — management of technical vulnerabilities | CVD policy + security/cra-vulnerability-records/ |
| ISO 27001:2022 | A.5.36 — compliance with policies | this checklist + the Art. 10 map |
| SOC 2 | CC2.3 — external communication | security.txt + SDK Support & Lifecycle |
| SOC 2 | CC7.x — vulnerability monitoring | post-market surveillance section of SECURITY.md |