tegwick
00106ffcdd
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>
115 lines
4.6 KiB
Markdown
115 lines
4.6 KiB
Markdown
---
|
||
id: RISK-F-0006
|
||
type: finding
|
||
title: "apps-pg has no backup configured at all: R0 means no recovery"
|
||
status: open
|
||
reported_by: railiance-platform
|
||
reported_via: flex-auth
|
||
routed_by: risk-nexus
|
||
date_reported: "2026-08-17"
|
||
date_filed: "2026-08-19"
|
||
system: railiance-platform
|
||
environment: production
|
||
fix_owner: railiance-platform
|
||
fix_tracking: unset (railiance-platform to open)
|
||
related: [RISK-F-0001]
|
||
# Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-second-grading.md
|
||
severity: high
|
||
severity_at_production: critical
|
||
impact: I4
|
||
likelihood: L2
|
||
fidelity_modifier: false
|
||
production_rescore: true
|
||
disclosure: embargoed
|
||
embargo_condition: "a backup exists and a restore has been demonstrated once"
|
||
embargo_since: "2026-08-19"
|
||
embargo_review: "2026-09-18"
|
||
escalation: answered
|
||
escalation_trigger: 3
|
||
escalation_status: approved
|
||
escalation_answered: "2026-08-19"
|
||
escalation_answered_by: the-custodian
|
||
escalation_act: approve
|
||
decision: "spend for apps-pg backup storage approved; no ceiling stated"
|
||
last_reviewed: "2026-08-19"
|
||
review_by: "2026-09-18"
|
||
graded_by: risk-nexus
|
||
ruling: 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.
|