coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

WARDEN-WP-0033 T01/T02: two under-graded lanes, and ADR-0008

Browse source 
secrets-engine reviewed our catalog metadata while drafting their five entries
and graded issue-core-ingestion-api-key and reuse-surface-hub-write-token high.
We had both as standard, and had deliberately regraded them DOWN on 2026-08-19.

They are right. Both paths carry a second credential our grade never looked at --
GITEA_BACKEND_TOKEN (CCR-2026-0002, a deliberate field-set decision) and a
dual-consumer webhook HMAC (CCR-2026-0005). Neither is recovered by rotating the
credential the lane is named after.

The defect is structural: we graded the lane by its headline field, but a read
returns every field at the path. Worse, the evidence was already in the CCRs we
cite as authoritative -- not missing, unread -- and a test asserted the wrong
answer, so a correct first-pass grade got overruled by it.

ADR-0008 records the rule: a grade covers every field its path discloses.
ADR-0007 is unchanged and still governs; this says what the grade is of.

Six of the remaining standard lanes have no KV path. Two have paths and no field
evidence; per ADR-0008 they are stated as unknown rather than assumed, and left
for operator-sanctioned grading.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 08:36:42 +02:00
parent 9b7e2e9bd2
commit c357ce5908
8 changed files with 155 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

26
registry/routing/catalog.yaml
View file

@ -283,9 +283,16 @@ entries:
- id: issue-core-ingestion-api-key
title: issue-core ingestion API key (OpenBao KV + ESO)
# Ordinary internal workload secret: an ingestion key for a first-party
# service. Rotatable, no spend, no tenant data, no admin scope (WARDEN-WP-0032-T05).
risk: standard
# Regraded standard -> high 2026-08-21 (WARDEN-WP-0033-T02). The T05 grade below
# was wrong, and wrong systematically: it graded the headline field, not the path.
# was: "Ordinary internal workload secret: an ingestion key for a first-party
# service. Rotatable, no spend, no tenant data, no admin scope."
# CCR-2026-0002 records a deliberate field-set decision to keep GITEA_BACKEND_TOKEN
# at this path alongside the ingestion key, and a read discloses every field there.
# A Forgejo backend token is not recovered by rotating an ingestion key.
# Found by secrets-engine reviewing SECRETS-WP-0006 -- not by us.
risk: high
fields: [ISSUE_CORE_API_KEY, GITEA_BACKEND_TOKEN] # CCR-2026-0002
need_keywords: [issue-core, ingestion, api, key, openbao, issue_core_api_key, eso, external-secrets]
owner_repo: railiance-platform
subsystem: OpenBao + issue-core + activity-core
@ -323,9 +330,16 @@ entries:
- id: reuse-surface-hub-write-token
title: reuse-surface federation hub write bearer token
# Ordinary internal workload secret. Write access to a first-party federation
# surface; damaging to forge, but rotatable and internal (WARDEN-WP-0032-T05).
risk: standard
# Regraded standard -> high 2026-08-21 (WARDEN-WP-0033-T02), same defective T05
# pass as issue-core-ingestion-api-key.
# was: "Ordinary internal workload secret. Write access to a first-party
# federation surface; damaging to forge, but rotatable and internal."
# CCR-2026-0005 declares REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET at this path: a
# dual-consumer HMAC that must stay aligned with Forgejo org webhook id=1 on
# rotation. Disclosure lets an attacker forge webhook deliveries into the
# federation hub, which rotating the write token alone does not undo.
risk: high
fields: [REUSE_SURFACE_TOKEN, REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET] # CCR-2026-0005
need_keywords: [reuse-surface, reuse_surface, hub, register, federation, write, token, bearer, REUSE_SURFACE_TOKEN, REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET, reuse.coulomb.social]
owner_repo: railiance-platform
subsystem: OpenBao + reuse-surface