tegwick
f0db7c83ca
Operator ruled both. Findings publish as the file a reader gets — including RISK-F-0001's record that this register graded it critical while its fix notice sat unread. A summary would be a second document per finding kept in sync by hand, and drift is the failure this repo most distrusts; and a published register containing only other repos' defects reads as an accusation, while one containing its own reads as a record. Method docs public except escalation, which is restricted because it names spend thresholds and describes when the operator personally is interrupted — a map of where attention is scarce, needed by nobody judging a finding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
87 lines
3.7 KiB
Markdown
87 lines
3.7 KiB
Markdown
---
|
|
id: RISK-METHOD-VERIFICATION
|
|
type: method
|
|
title: "What this register may verify for itself, and what it must take from owners"
|
|
status: adopted
|
|
owner: risk-nexus
|
|
adopted: "2026-08-20"
|
|
workplan: RISK-WP-0004-T05
|
|
review_interval: 6m
|
|
disclosure: public
|
|
revision: "adopted-1"
|
|
last_reviewed: "2026-08-20"
|
|
---
|
|
|
|
# Verification
|
|
|
|
`RISK-WP-0004-T05` asked what this repo can legitimately establish itself,
|
|
because two gradings were resting on file comparison. The answer was found by
|
|
trying, on 2026-08-20, rather than by reasoning about it.
|
|
|
|
## The rule
|
|
|
|
**A register may look. It may not touch, and it may not conclude on a system's
|
|
behalf.**
|
|
|
|
Verification here means: running a read-only command a reporter has already
|
|
named, or that answers a question the register itself wrote down as open, and
|
|
recording exactly what came back.
|
|
|
|
Permitted:
|
|
|
|
- read-only reads of live state (`kubectl get`, `bao policy read`, an HTTP
|
|
probe of a documented endpoint);
|
|
- comparing what is deployed against what a repo said is deployed;
|
|
- recording the discrepancy and routing it as a **question**.
|
|
|
|
Not permitted:
|
|
|
|
- any write, apply, patch, restart or rotation — including one that would
|
|
obviously improve things;
|
|
- concluding what a defect means for a system this repo does not own. The
|
|
system stays authoritative about itself (`INTENT.md`);
|
|
- verifying instead of asking. The owner is asked first; verification settles
|
|
what an owner cannot see or has invited someone to check.
|
|
|
|
`rapp-postgres` declined to check the NetworkPolicy on `flex-auth`'s behalf,
|
|
saying that would be reporting on a system they do not own. That was right
|
|
**for a reporter**. This register is the downstream party whose grade depended
|
|
on the answer, and `flex-auth` explicitly named the command and asked for
|
|
someone with credentials to run it. Those two positions are compatible.
|
|
|
|
## What this host can actually reach — established 2026-08-20
|
|
|
|
| Target | Result | Consequence |
|
|
| --- | --- | --- |
|
|
| Kubernetes (`railiance01`) | **reads work** — `kubectl get ns`, `get networkpolicy -o json` | Live cluster state is verifiable by this register |
|
|
| OpenBao (`bao.coulomb.social`) | **403 permission denied** on `token lookup` and `policy read` | Policy claims are not verifiable here; `RISK-F-0009` rests on file comparison |
|
|
|
|
The asymmetry is worth stating plainly: **the register can check what the
|
|
cluster admits, and cannot check what the secret store permits.** Every grade
|
|
touching an OpenBao policy is therefore a grade on a document, and says so.
|
|
|
|
That is not a gap to close by acquiring credentials. A risk register holding
|
|
production secret-store access has traded a verification problem for a much
|
|
worse one. If OpenBao claims need verifying, the right answer is for the owner
|
|
to run the read and report it, which is what `ops-warden` did — the obstacle
|
|
there was an expired token, not the arrangement.
|
|
|
|
## Recording a verification
|
|
|
|
One file per verification in `docs/verifications/`, `RISK-V-NNNN`, stating the
|
|
command, the raw result, what it confirms, what it contradicts, and what it
|
|
does not establish. It names the findings it bears on, and those findings link
|
|
back.
|
|
|
|
A verification is evidence, not a ruling. It can move a grade; it does not
|
|
close a finding on its own, and it never speaks for the owning repo.
|
|
|
|
## Verification and the cadence ladder
|
|
|
|
A verification that contradicts something is a check that is **not clean**: the
|
|
affected findings reset to `instant`. A verification that confirms what was
|
|
already recorded is clean, and may be exactly the evidence a rung is built on.
|
|
|
|
The first one (`RISK-V-0001`) did both — it confirmed the ingress claim
|
|
`RISK-F-0001` was graded on, contradicted the egress claim in the same message,
|
|
and surfaced a third policy nobody had mentioned that bears on `RISK-F-0002`.
|