tegwick
7d6ded5743
Read the repo inbox after grading, which is the wrong order and is now recorded as such. flex-auth had answered the NetworkPolicy question on 2026-08-18 (narrow ingress, not default-deny — L3 becomes L2, critical becomes high) and reported RISK-F-0001 fixed at 12:35 today with live 401 probes. F-0001 closes fixed and public; its escalation is withdrawn before it was ever sent. RISK-F-0002's ordering constraint lifts with it and its trigger-6 escalation is withdrawn. audit-core had routed the erasure-versus-audit legal question here on 2026-08-18 asking for an owner. RISK-N-0002 was wrong to call it a note: the remedy is not retrofittable, so the decision can only be taken early. Promoted to RISK-F-0008, owned by this repo as regulatory intake, escalated on trigger 2. Accepted rapp-postgres's record format and ops-warden's typed-act escalation vocabulary. Reading the inbox is now question zero of every review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
120 lines
5.8 KiB
Markdown
120 lines
5.8 KiB
Markdown
---
|
|
id: RISK-RULING-2026-08-19-C
|
|
type: ruling
|
|
title: "The inbox round: two grades corrected, one note promoted"
|
|
status: recorded
|
|
owner: risk-nexus
|
|
date: "2026-08-19"
|
|
workplan: RISK-WP-0001-T06
|
|
---
|
|
|
|
# The inbox round — 2026-08-19
|
|
|
|
The register graded seven findings today and then read its inbox. Six messages
|
|
were waiting, four of them unread since 2026-08-17. Three gradings changed.
|
|
|
|
This ruling records the corrections and the process defect that caused them,
|
|
in that order, because the corrections matter more and the defect is this
|
|
repo's own.
|
|
|
|
## RISK-F-0001 — corrected `critical` → `high`, and closed `fixed`
|
|
|
|
Two messages from `flex-auth`, both already in the inbox at grading time.
|
|
|
|
**2026-08-18, the NetworkPolicy answer.** The exposure question the finding
|
|
left open — and which this register wrote up as "the first question at review"
|
|
— had already been answered. Both production Deployments ship a NetworkPolicy
|
|
narrower than default-deny: one `namespaceSelector` plus one `podSelector` on
|
|
port 8080, egress empty, in force since before the period the `A0` describes.
|
|
The reachable set was the single paired workload, not the cluster. `L3` → `L2`,
|
|
`critical` → `high`.
|
|
|
|
`flex-auth` also volunteered a correction to their own earlier phrasing to
|
|
`ops-warden`, and asked that three caveats be recorded rather than taken from
|
|
them: label selectors are position and not identity, the policy cannot bind the
|
|
asserted `resource.system`, and they could not verify the live cluster because
|
|
`kubectl` returned `Unauthorized`. A reporter who says "I can tell you what is
|
|
specified, not what is admitted" is doing this register's job for it.
|
|
|
|
**2026-08-19 12:35, the fix.** Both Deployments enforce ADR-0004 TokenReview;
|
|
live unbound-request probes return 401 rather than a decision;
|
|
`tenancy.current.A` is 2; `FLEX-WP-0015` is finished. Closed `fixed` on a probe
|
|
against the running system, which is the standard `docs/method/review.md`
|
|
requires. Disclosure flips to `public`; handover to `policy-nexus` is
|
|
outstanding.
|
|
|
|
The trigger-1 escalation is **withdrawn without being sent**, roughly four
|
|
hours after it was raised.
|
|
|
|
## RISK-F-0002 — constraint lifted, escalation withdrawn
|
|
|
|
The trigger-6 escalation existed to make the operator hold an ordering: do not
|
|
enable `policy.enabled` while the oracle is forgeable. The oracle stopped being
|
|
forgeable the same day. Enabling the gate is now `ops-warden`'s availability
|
|
question and no longer an attestation hazard.
|
|
|
|
`ops-warden` judged this did not need the operator and, in the outcome, they
|
|
were right. The register's disagreement was never about the hazard; it was
|
|
about whether "written down in both repos" keeps a thing held. It did not — the
|
|
window closed because `flex-auth` shipped, not because anyone re-read the note.
|
|
Both positions survive intact and the escalation is withdrawn.
|
|
|
|
The finding stays `open` at `medium`. The gate is still off.
|
|
|
|
## RISK-N-0002 promoted to RISK-F-0008 — erasure versus audit
|
|
|
|
Ruled a note this morning on the reasoning that no obligation exists yet. That
|
|
was decided without reading `audit-core`'s message of 2026-08-18, which routes
|
|
the question here explicitly, by both available routes, and asks for an owner
|
|
rather than an opinion.
|
|
|
|
The note failed the second floor test. Recording it *does* change a decision:
|
|
if the exemption does not hold, the remedy is encrypt-then-hash at accept time,
|
|
which is not retrofittable onto events already accepted. A decision that can
|
|
only be taken early is exactly the kind a register exists to surface early.
|
|
|
|
`RISK-F-0008` is the first finding this repo owns itself, which follows from
|
|
`INTENT.md` moving regulatory intake here on 2026-08-17. It escalates on
|
|
trigger 2. What this repo owns is the record — what the source says and what is
|
|
therefore established. Not the legal advice, and not `audit-core`'s redesign.
|
|
|
|
## Two things accepted from reporters
|
|
|
|
**The record format** — `rapp-postgres` asked this register to accept or reject
|
|
the shape `RISK-F-0001` arrived in. **Accepted**, and extended rather than
|
|
replaced: the reporter's fields are unchanged, this repo's grading fields are
|
|
added below them, and the split is now written down in `findings/README.md`.
|
|
Their instinct to keep it minimal until a second finding existed was right; it
|
|
survived five more.
|
|
|
|
**The escalation vocabulary** — `ops-warden` offered the design of their
|
|
`warden plan` classifier: a typed act plus the reasons that produced the
|
|
verdict. Adopted into `docs/method/escalation.md`. Their point that a condition
|
|
without an act tells the operator something is wrong without telling them what
|
|
they are being asked to do is the gap the draft had.
|
|
|
|
`RISK-N-0003` records the remaining open observation from that round —
|
|
everything found by reading, nothing by monitoring — as a note, because no repo
|
|
owns it and there is no defect to route.
|
|
|
|
## The process defect, recorded plainly
|
|
|
|
The NetworkPolicy answer arrived 2026-08-18. The fix notice arrived 2026-08-19
|
|
at 12:35. This register's first grading ran at 21:14 the same day and used
|
|
neither. It graded a fixed defect as live, at a severity one band too high, on
|
|
an exposure question it wrote up as unanswered while the answer sat unread.
|
|
|
|
Nothing about the method caused this and no instrument was wrong. The register
|
|
simply did not look. That is the failure `INTENT.md` names — a finding that
|
|
disappears into whichever document happened to be open — arriving as an
|
|
*answer* rather than a finding.
|
|
|
|
Two changes, both live:
|
|
|
|
- Reading the inbox is **question zero** of every review and step zero of every
|
|
grading (`docs/method/review.md`).
|
|
- `make check` reports escalations awaiting the operator, so a batch that has
|
|
gone stale is visible before it is sent.
|
|
|
|
The register was lucky today: the correction and the fix arrived within hours
|
|
of the mistake, so nothing was acted on. Luck is not a control.
|