coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Work the register due list, and add the one-check-per-sitting rule

Browse source 
Nine records checked. Five clean and climbed to 1h: RISK-F-0003, 0004,
0005, 0006, 0009 and RISK-REG-0001. Three moved and stay at instant —
RISK-F-0002 (RISK-V-0001 found the flex-auth-ops-warden policy admits no
ingress, so the live question there is now availability rather than
attestation), RISK-F-0007 (the on-request path walked for the first time
as RISK-V-0002), RISK-F-0008 (the determination now exists).

The rule: a finding recorded as moved is not clean-checked in the same
sitting. Re-reading your own keystrokes and climbing produces a rung that
says the world held still when what held still was the last five minutes.
The rung carries stability information or it carries nothing.

record_check.py now handles regulatory records as well as findings.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-20 12:03:12 +02:00
parent 2ebdc133bc
commit 56b8d61583
12 changed files with 116 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

37
findings/RISK-F-0002-ops-warden-sign-ungated.md
View file

@ -29,8 +29,8 @@ embargo_review: "2026-11-17"
escalation: withdrawn
escalation_trigger: 6
escalation_status: withdrawn-hazard-window-closed
last_checked: "2026-08-19T21:30:00Z"
next_check: "2026-08-19T21:30:00Z" # due now: the ladder starts at instant
last_checked: "2026-08-20T10:02:41Z"
next_check: "2026-08-20T10:02:41Z"
cadence: instant
clean_streak: 0
graded_by: risk-nexus
@ -234,3 +234,36 @@ the thing that had gone stale was this register's own grading, four hours old.
- **2026-08-19** — constraint lifted, escalation withdrawn, severity unchanged.
Open at review: has `ops-warden` presented SA tokens and enabled the gate;
is `FLEX-WP-0007` still the stated blocker or has it too gone stale.
## Check — 2026-08-20: a new availability fact, and it is the one that matters now
`RISK-V-0001` verified `flex-auth`'s NetworkPolicies against the live cluster
and found a third policy nobody had mentioned:
```
flex-auth-ops-warden, created 2026-08-19T12:47:18Z
policyTypes: [Ingress, Egress]
ingress: no rules at all
```
`Ingress` in `policyTypes` with zero rules means deny all ingress. On its face,
nothing reaches that pin.
**This is now the live question on this finding.** The attestation hazard
lifted when `flex-auth` shipped; what remained was whether enabling
`policy.enabled` breaks signing on availability grounds. If the pin
`ops-warden` calls admits no ingress, a `fail_closed: true` gate against it
fails closed — every `warden sign` stops.
The register is **not** concluding that, and said so to both owners: the policy
may be mid-rollout, it may not be the pin `ops-warden` targets, and another
policy may admit the traffic. Both were told on 2026-08-20, before either flips
a switch, which is the entire reason this finding is carried as a peer rather
than folded into `RISK-F-0001`.
The severity is unchanged at `medium`. What changed is the evidence, and it
changed in the direction of "do not enable this yet" for a completely different
reason than the one this finding was filed for. That is the second time in two
days that this finding's blocker turned out to be a claim about the world at a
date.
- **2026-08-20** — not clean: RISK-V-0001 found the flex-auth-ops-warden policy admits no ingress; the live question is now availability, not attestation. Cadence instant → instant; checked again immediately.