tegwick
a1fdd33477
The reframe is that the un-erasable set grows daily, so the decision to take now is whether to keep manufacturing records that could never be erased while the legal question is settled. Suggests a keyed commitment (HMAC or per-subject salt) as a cheaper hedge than encrypt-then-hash, since the confirmation oracle exists only because the digest is over cleartext with no secret in it. Not sent to audit-core: the hedge is an engineering ask and waits on the operator. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| README.md | ||
| RISK-F-0001-flex-auth-unauthenticated-check.md | ||
| RISK-F-0002-ops-warden-sign-ungated.md | ||
| RISK-F-0003-ops-warden-read-boundary-ungraded-lanes.md | ||
| RISK-F-0004-agent-boundary-policy-covers-a-third-of-high-risk-lanes.md | ||
| RISK-F-0004-tenant-engine-unfiltered-event-read.md | ||
| RISK-F-0005-audit-core-unfiltered-read-path.md | ||
| RISK-F-0006-apps-pg-no-backup-configured.md | ||
| RISK-F-0007-unverified-tenant-boundary.md | ||
| RISK-F-0008-audit-retention-legal-basis-assumed.md | ||
Filing a finding
One file per finding: findings/RISK-F-NNNN-<slug>.md, YAML front-matter,
then prose. Next id is one past the highest here.
What the reporter fills in
id: RISK-F-0004
type: finding
title: "one line, what is true — not what should be done"
status: open # open | fixed | accepted | withdrawn
reported_by: <repo> # who found it
reported_via: <repo> # who routed it here, if different
date_reported: "YYYY-MM-DD"
system: <repo> # the system the defect is in
environment: production # production | build | both
fix_owner: <repo> # who owns the fix — never risk-nexus
fix_tracking: <WP-ID or unset>
related: [RISK-F-0001] # optional
What risk-nexus fills in — leave these out
severity, severity_at_production, impact, likelihood,
fidelity_modifier, production_rescore, disclosure, embargo_*,
escalation*, constraint*, last_reviewed, review_by, graded_by,
ruling.
Setting them yourself is not an error to be corrected — it is a boundary this
repo would rather keep. The reporter says what is true; this repo says how bad
it is and who hears about it (INTENT.md). Leaving them out, or writing
unset, both work; the nag reports either way until they are graded.
What makes a good finding here
- State exposure only as far as you can support it. "Not established" is a
complete answer and grades better than a guess.
RISK-F-0001declining to assume a NetworkPolicy is the model. - Say how it was found. Provenance is a grading input.
- Suggest a direction if you have one, marked as a suggestion. The fix is yours; the grade is ours.
- A note is fine. If it would not change anyone's decision, it belongs in
notes/— see the floor indocs/method/severity.md.
Asking for a tenant-boundary verification
Separate from filing. The estate carries RISK-F-0007 — no consumer's tenant
boundary is verified anywhere — as an accepted risk until production, on the
operator's ruling of 2026-08-19, with verification available on request.
Message risk-nexus naming one consumer boundary and what would have to be
true of it. The owning repo of that consumer does the verification; this repo
scopes and records it and verifies nothing itself. A boundary that holds is
evidence; one that does not is a finding with its own owner.
After filing: make check. Then this repo grades it.