ehoandClaude Opus 5
12f17d9d73
Two backlog trees are complete: `docs/project/backlog/` (75 files, every WP done) and `docs/project/refactor-backlog-setup/` (the arc before it). Move both under `docs/project/archive/` with `git mv`, so history stays intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them, because it points at the now-archived backlog README. Add `docs/project/archive/README.md`. It states that these trees are historical and names the two directories that are still live. Repoint every inbound reference named in RD-30's Files table: CLAUDE.md, the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the `document-feature` and `new-ssp` skills, and the readable-codebase PLAN, README, and RD-19 ticket. Fix two upward-relative links inside the moved WP files (WP-68, WP-69) that gained a directory level and would otherwise break. Repoint `.prettierignore`'s two agent-prompt exclusions to their new path, so prettier keeps leaving those files' exact wording alone. Mark RD-30 done and check off its acceptance criteria; flip its README row to done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.9 KiB
RB-02 — stop concatenating the BSN into AuthzAudit.Resource
Status: implemented · 2026-08-27 · Source findings: 07-bio2-compliance.md BIO-008 · 99-backlog.md RB-02
What was wrong
Program.cs (was :674) built the reveal attempt's audit resource ref as
"brief/" + ctx.Zorgverlener().Bsn. AuditAuthz persists that string to the
AuthzAudit.Resource column in SQLite, and GET /admin/audit renders it on the admin
audit page — so a BSN was written to durable storage and shown in a UI, on the one trail
four documents describe as data-minimised and PII-free.
The endpoint is the BIG-nummer reveal, whose own comment says the audit carries "NO PII. Never the value that was (or wasn't) revealed" — and it did not carry the BIG-nummer. It carried the BSN instead, in the adjacent argument.
Why the existing test did not catch it
AuthzAuditTests.The_audit_schema_carries_no_pii asserts on column names:
Assert.DoesNotContain(names, n => Regex.IsMatch(n, "naam|name|bsn|value|waarde", …));
A BSN inside a column called Resource is invisible to a regex over the word Resource.
The test was structurally incapable of failing on this defect, which is why the
value-asserting test is part of this ticket's definition of done rather than a follow-up.
What changed
| File | Change |
|---|---|
Program.cs |
resource ref is "brief"; a comment records why the id added nothing |
AuthzAuditTests.cs |
new No_audit_row_carries_a_subjects_bsn — asserts on stored values, every string field |
No identifier was lost. BriefStore keys one brief per owner, so brief/<bsn> named the
same thing the row's acting principal already implies; there is no second brief the ref
could have disambiguated.
The new test drives a denied reveal as a non-default subject (X-Subject: 999999990),
then scans every string field of every audit row for that BSN and for
DocumentStore.DemoOwner. Asserting against the two BSNs actually in play, rather than a
\d{9} shape, keeps it deterministic — a hex correlation id can hold nine consecutive
digits by chance.
Confirmed it fails without the fix: reverting only the Program.cs line turns
No_audit_row_carries_a_subjects_bsn red, and restoring it turns it green.
Not in scope
AuditEntry.Actor on document audit rows also holds a raw BSN. That is a different store
(DocumentStore.Audit) and is RB-04, which is where the masking decision for it lives.
Verification
dotnet format --verify-no-changes clean. dotnet test: 251 passed, 1 failed — the
failure is OpenZaakIntegrationTests.Admin_cases_…, which needs a live OpenZaak container
and fails identically on a stashed tree.