tegwick
e482423523
RISK-F-0006 fixed and public — railiance-platform's restore evidence was read, not taken: 56s restore, all 13 coulomb_social row counts matching, plus the BestEffort QoS this register had graded on, plus a failed first WAL attempt recorded alongside the successful one. RISK-F-0004 high -> medium. tenant-engine corrected in both directions: payloads are returned (worse than graded) but there is no HTTP event-read route, so the live network-reachable read this register wrote down does not exist. L3 was a reachability claim inherited from a summary and never tested. RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is off by decision. ADR-0006 retires it in favour of zone-scoped enforcement. Ruled: the framing is superseded, the risk is not. A control retired before its replacement exists is still an absent control. The successor's blocker is 26 of 27 lanes having no identifiable workload, which is RISK-N-0004 with a number on it. RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against themselves; the token was never expired; and the deployed policy differs from the file, which moves 'a file is not a safe proxy for the server' from suspicion to evidence and amends verification.md — including the admission that fix_tracker.py reads records, and a record can be stale. RISK-V-0001 reconciled: ops-warden reaches the pin from the node through a tunnel, so a podSelector ingress rule does not constrain it. The observation was right and the inference was not. 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-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 | ||
| RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md | ||
Filing a finding
One file per finding: findings/RISK-F-NNNN-<slug>.md, YAML front-matter,
then prose.
Ids are allocated by risk-nexus. Take the next id past the highest you
can see and file — that is the right thing to do — but if two reporters take
the same one, the earlier commit keeps it and the newcomer is renumbered here,
with the original id recorded as filed_as. This happened on 2026-08-20
(RISK-F-0009, filed as RISK-F-0004), which is why it is written down. Do
not renumber your own finding after filing; the register does it and tells you.
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_checked, next_check, cadence,
clean_streak, graded_by, ruling.
cadence is the check-frequency rung, and it is earned rather than assigned:
a clean check climbs one rung (instant → 1h → 8h → 24h → 48h → 96h
→ 7d → 14d → 1mo → 1q), and anything moving drops it straight back to
instant. So the rung on your finding is a public statement about how settled
the matter has been — which is why it is not yours to set.
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.