History

tegwick 46d0a62dab RISK-F-0009: live verification, and a correction to my own count ops-warden filed this static, saying its OpenBao token was expired. It was not -- bao policy read succeeded, so the deployed policy has now been compared directly. Coverage confirmed at 6 of 17. But the uncovered count was wrong: eight included a path pattern and a broker grant, neither of which a policy can deny, and the finding's own prose already said so about the first. Six stand. New: the deployed policy differs from the file in railiance-platform -- the file denies core-hub/runtime, the server does not. No ops-warden lane maps there, so the numbers are unchanged. It matters because this finding named "the deployed policy may differ from the file" as unconfirmed, and it does. Severity, disclosure and embargo left untouched -- risk-nexus's to set. The embargo condition is a coverage report from railiance-platform, which this does not satisfy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-21 00:50:25 +02:00
..
README.md	Adaptive check cadence: the interval is earned, not assigned	2026-08-20 07:43:51 +02:00
RISK-F-0001-flex-auth-unauthenticated-check.md	Type the publication handover as a wait like any other	2026-08-20 22:44:46 +02:00
RISK-F-0002-ops-warden-sign-ungated.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0003-ops-warden-read-boundary-ungraded-lanes.md	Work the register due list, and add the one-check-per-sitting rule	2026-08-20 12:03:12 +02:00
RISK-F-0004-tenant-engine-unfiltered-event-read.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0005-audit-core-unfiltered-read-path.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0006-apps-pg-no-backup-configured.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0007-unverified-tenant-boundary.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0008-audit-retention-legal-basis-assumed.md	RISK-F-0008 accepted: no external determination, policy set instead	2026-08-20 23:36:44 +02:00
RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md	RISK-F-0009: live verification, and a correction to my own count	2026-08-21 00:50:25 +02:00

README.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-0001 declining 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 in docs/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.