coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
risk-nexus/findings/RISK-F-0006-apps-pg-no-backup-configured.md
tegwick e482423523 Five owner replies worked through: one fix closed, two grades corrected, one control retired 
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.

RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.

RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.

RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.

RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00

6.4 KiB
Raw Blame History

id type title status reported_by reported_via routed_by date_reported date_filed system environment fix_owner fix_tracking related severity severity_at_production impact likelihood fidelity_modifier production_rescore disclosure publication embargo_lifted embargo_since embargo_review escalation escalation_trigger escalation_status date_fixed escalation_answered escalation_answered_by escalation_act decision last_checked next_check cadence clean_streak graded_by ruling checked_by
RISK-F-0006 finding apps-pg has no backup configured at all: R0 means no recovery fixed railiance-platform flex-auth risk-nexus 2026-08-17 2026-08-19 railiance-platform production railiance-platform RPF-WP-0019 (finished)
RISK-F-0001
high critical I4 L2 false true public pending-handover 2026-08-20 — backup live, restore demonstrated with matching row counts 2026-08-19 2026-09-18 answered 3 answered 2026-08-20 2026-08-19 the-custodian approve spend for apps-pg backup storage approved; no ceiling stated 2026-08-21T07:32:09Z 2026-08-21T07:32:09Z instant 0 risk-nexus RISK-RULING-2026-08-19-B risk-nexus

RISK-F-0006 — the platform database cannot be recovered

What is true, as reported

apps-pg (railiance-platform) has no backup configured at all: no barmanObjectStore, no retention policy, and BestEffort QoS on the pod. Reported in the same round as RISK-F-0001, whose author noted that R0 here means no recovery, not merely no erasure policy.

Not verified by this repo. railiance-platform owns it.

Why it is graded highest of the round despite being the least exciting

The other findings in this round are about someone reaching something. This one is about nothing coming back. There is no attacker in it and no clever step — an ordinary node failure, a lost volume, a mistaken DROP, and the data that was in apps-pg is gone.

BestEffort QoS makes the pod the first candidate for eviction under memory pressure. Eviction alone is an availability event and recoverable. What is not recoverable is anything that damages the volume, and that is the case with no answer today.

Register ruling — 2026-08-19

high today (I4 × L2, non-adversarial reading), critical at production, embargoed, and escalated on trigger 3 (spend).

I4: apps-pg is shared platform infrastructure, so the loss is not confined to one system, and it is unrecoverable rather than degraded. L2 on the non-adversarial reading the scale gained for this finding: irrecoverable loss needs a volume or corruption event, which is an ordinary failure the estate has seen the shape of but not an expected weekly occurrence.

production_rescore: true: at production this is L3, because the surface area of ordinary operational events grows with real traffic and real operators.

Escalation, trigger 3. Object storage for backups is recurring spend that is not currently committed, and no repo can authorise it for itself. The ask is narrow: approve a backup target and its cost, or state that the estate accepts running apps-pg with no recovery and for how long. The second is a legitimate answer in build mode and needs saying out loud rather than happening by default.

The disclosure condition deliberately includes a demonstrated restore. A backup nobody has restored from is a claim, not a control — the same class of error as the gate in RISK-F-0002.

Reviews

  • 2026-08-19 — filed and graded from RISK-F-0001's unfiled list. Open at review: has the spend been ruled on; is a backup configured; has a restore been demonstrated; does railiance-platform track it anywhere.

Operator decision — 2026-08-19: approved

The spend is approved. railiance-platform may provision backup storage for apps-pg without returning for authorisation.

No ceiling was stated, so none is recorded. The register asks railiance-platform to report the actual target and its monthly cost once chosen; a figure materially above the trigger-3 band (recurring €50/month) comes back for confirmation rather than being assumed covered. That is the register being careful with an open approval, not a condition on it.

What is now blocking is work, not permission. The finding stays open at high, and the embargo condition is unchanged: a backup exists and a restore has been demonstrated once. A backup nobody has restored from is a claim, not a control.

fix_tracking is still unset and is now railiance-platform's to open.

Reviews

  • 2026-08-19 — escalation answered, spend approved. Open at review: is a backup configured; has a restore been demonstrated; what does it cost.
  • 2026-08-20 — clean check: checked against the inbox and the owner's record; nothing moved. Cadence instant → 1h (1 clean in a row); next check 2026-08-20 11:02Z.

Check — 2026-08-21: fixed, and the evidence was read rather than taken

railiance-platform finished RPF-WP-0019 on 2026-08-20. This register read their evidence file rather than accepting the report: railiance-platform/docs/evidence/RPF-WP-0019-backup-restore-2026-08-20.md.

  • Governed target live at s3://railiance-platform-pg-backup/platform-pg/apps-pg/, 30-day retention, continuous WAL.
  • apps-pg-daily-20260820204148 completed in 8s, LastBackupSucceeded=True.
  • A separately named scratch cluster restored both consumer databases in 56s, with exact database sizes and all 13 coulomb_social user-table row counts matching. The scratch namespace was deleted; production stayed Ready.

The embargo condition required a demonstrated restore and got one. That condition existed because a backup nobody has restored from is a claim, not a control — and the demonstration is the difference between this finding closing and merely appearing to.

They also fixed something the grading had cited but not asked for: apps-pg-1 moved from BestEffort to Burstable QoS, with requests and limits, which was part of why L2 rather than L1. And their evidence records a failed first WAL attempt against the wrong prefix rather than only the successful one, which is the standard this register keeps asking of reporters.

fixed, public, escalation closed. The spend approved on 2026-08-19 has a real target behind it.

  • 2026-08-21 — not clean: owner replied; see the dated check section Cadence 1h → instant; checked again immediately.