risk-nexus/findings/RISK-F-0006-apps-pg-no-backup-configured.md
tegwick 00106ffcdd Operator decisions on RISK-F-0006 and RISK-F-0007
F-0006: backup spend approved, no ceiling stated. Permission is no longer
the blocker; the embargo still needs a demonstrated restore.

F-0007: pragmatic default before production — accepted (not closed, keeps
its severity, review interval and production re-score, stays visible in
the register), with a written on-request path so a named consumer
boundary can be verified when someone asks. The acceptance expires at the
production transition, which is an event and not a date.

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

4.6 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 embargo_condition embargo_since embargo_review escalation escalation_trigger escalation_status escalation_answered escalation_answered_by escalation_act decision last_reviewed review_by graded_by ruling
RISK-F-0006 finding apps-pg has no backup configured at all: R0 means no recovery open railiance-platform flex-auth risk-nexus 2026-08-17 2026-08-19 railiance-platform production railiance-platform unset (railiance-platform to open)
RISK-F-0001
high critical I4 L2 false true embargoed a backup exists and a restore has been demonstrated once 2026-08-19 2026-09-18 answered 3 approved 2026-08-19 the-custodian approve spend for apps-pg backup storage approved; no ceiling stated 2026-08-19 2026-09-18 risk-nexus RISK-RULING-2026-08-19-B

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.