[Feature] Map Annex I Part I as well, including a documented risk assessment #556

New issue

Closed

opened 2026-07-22 13:45:03 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 13:45:03 +00:00

Owner

assurance/CRA-2024-2847-positie.md measures us against Annex I Part II — vulnerability handling — and says so deliberately: that is the part which says something substantive for a project like this. The mapping table in proposals/gen-two-tier-approach.md (orcwg/cra-attestations) shows the other side of that choice: every row of Annex I Part I is marked not addressed, and so are Annex II.5 (foreseeable cybersecurity risks) and Annex VII.3 (the cybersecurity risk assessment). The proposal is explicit that a heavy-weight attestation is precisely the one that demonstrates conformity to Part I, and that the risk assessment is best written by the people who maintain the project.

Part I is where OciDeck is strong, and we never say so. Walking the thirteen product requirements against what exists:

secure by default — local-first, network off unless explicitly enabled (NetGuard, docs/SECURITY_DESIGN.md §3)
data minimisation — OciWacht detects personal data and never displays the value it found (§8)
confidentiality and integrity — classification, integrity and secure storage (§9), key management (§13)
limiting attack surface — web-build hardening (§1), asset-path containment (§4), HTML-export sanitisation (§5), AI egress control (§7)
monitoring security-relevant activity — what is logged (§14)
no known exploitable vulnerabilities — make deps-check, make sast, make check-secrets
secure deletion — needs checking; probably the weakest row

Nearly every one has a documented design section behind it. What is missing is the map, not the work.

The genuine gap is the risk assessment. docs/SECURITY_DESIGN.md §Threat model is a threat model: who attacks, along which path. A risk assessment is a different artefact — what could go wrong, how likely, how bad, what we decided to do about it, and what we consciously accepted. Annex I Part I.1 makes it the first requirement, and Annex VII.3 makes it documentation. It is also the thing that explains our asymmetries to an outsider: S3, loopback and PBKDF2 are already recorded in assurance/ as deliberate deviations, and a risk assessment is the frame those three belong in.

Deliverable

A Part I section in assurance/CRA-2024-2847-positie.md, in the same three-column form as the Part II table: what the regulation describes, where we stand, what is open. Guideline, no conformity claim, no audit — the file's own register.
A risk assessment as its own artefact under assurance/, with accepted risks named as accepted.
A second lens while doing it: the Eclipse Trustable Software Framework, raised at the ORC WG's October 2025 workshop as the outcome-based counterpart to a process checklist — provenance, construction, updatability, confidence that it does what it says, and human assessment of possible harm. The last two are the questions our gates do not ask, and this project builds a tool used on other people's systems. Worth an honest paragraph even if we adopt nothing.

Order. After #550: the steward question changes how much of this we would ever publish, versus keep as an internal working document.

[`assurance/CRA-2024-2847-positie.md`](assurance/CRA-2024-2847-positie.md) measures us against **Annex I Part II** — vulnerability handling — and says so deliberately: that is the part which says something substantive for a project like this. The mapping table in `proposals/gen-two-tier-approach.md` ([orcwg/cra-attestations](https://github.com/orcwg/cra-attestations)) shows the other side of that choice: every row of **Annex I Part I** is marked *not addressed*, and so are Annex II.5 (foreseeable cybersecurity risks) and Annex VII.3 (the cybersecurity risk assessment). The proposal is explicit that a heavy-weight attestation is precisely the one that demonstrates conformity to Part I, and that the risk assessment is best written by the people who maintain the project. **Part I is where OciDeck is strong, and we never say so.** Walking the thirteen product requirements against what exists: - **secure by default** — local-first, network off unless explicitly enabled (NetGuard, `docs/SECURITY_DESIGN.md §3`) - **data minimisation** — OciWacht detects personal data and never displays the value it found (§8) - **confidentiality and integrity** — classification, integrity and secure storage (§9), key management (§13) - **limiting attack surface** — web-build hardening (§1), asset-path containment (§4), HTML-export sanitisation (§5), AI egress control (§7) - **monitoring security-relevant activity** — what is logged (§14) - **no known exploitable vulnerabilities** — `make deps-check`, `make sast`, `make check-secrets` - **secure deletion** — needs checking; probably the weakest row Nearly every one has a documented design section behind it. What is missing is the map, not the work. **The genuine gap is the risk assessment.** `docs/SECURITY_DESIGN.md §Threat model` is a threat model: who attacks, along which path. A risk assessment is a different artefact — what could go wrong, how likely, how bad, what we decided to do about it, and what we consciously accepted. Annex I Part I.1 makes it the first requirement, and Annex VII.3 makes it documentation. It is also the thing that explains our asymmetries to an outsider: S3, loopback and PBKDF2 are already recorded in `assurance/` as deliberate deviations, and a risk assessment is the frame those three belong in. **Deliverable** - A Part I section in `assurance/CRA-2024-2847-positie.md`, in the same three-column form as the Part II table: what the regulation describes, where we stand, what is open. Guideline, no conformity claim, no audit — the file's own register. - A risk assessment as its own artefact under `assurance/`, with accepted risks named as accepted. - **A second lens while doing it:** the Eclipse Trustable Software Framework, raised at the ORC WG's October 2025 workshop as the outcome-based counterpart to a process checklist — provenance, construction, updatability, confidence that it does what it says, and human assessment of possible harm. The last two are the questions our gates do not ask, and this project builds a tool used on other people's systems. Worth an honest paragraph even if we adopt nothing. **Order.** After #550: the steward question changes how much of this we would ever publish, versus keep as an internal working document.

brenno added the

docs

triage

enhancement

labels

2026-07-22 13:45:03 +00:00

brenno referenced this issue

2026-07-22 16:18:14 +00:00

[Feature] Label a first issue, and write down how accepted and declined are decided #596

brenno referenced this issue from a commit

2026-07-22 16:18:15 +00:00

docs(cra): breng Annex I deel I in kaart, en schrijf de risicoafweging