89 lines
3.4 KiB
Markdown
89 lines
3.4 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
|
|||
|
|
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: required
|
|||
|
|
escalation_trigger: 3
|
|||
|
|
escalation_status: pending-operator
|
|||
|
|
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.
|