sjat
2f4218814a
Resolve the conflict between ADR-011 (tags-not-digests) and the security work (digest pinning) with one coherent rule that respects ADR-011's stateless/stateful split: - Stateful → pin `tag@digest` (readable tag + integrity digest): legible diffs AND tamper-evidence. Snapshots cover broken updates; the digest covers swapped images. - Stateless → rolling tags (latest/stable); digest-pinning would defeat the rolling design. Integrity rests on official/verified images + disposability. Aligned across ADR-011 (decision 2), ADR-004 (image management), ADR-002 (supply-chain row), accepted-risk R1, the service checklist, and TODO 15.6. TODO 16.7 marked decided. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.9 KiB
Accepted security risks
Conscious security trade-offs we are choosing to live with — recorded so "what we are not doing" is explicit and revisitable, not forgotten. This register is a living document, deliberately kept out of ADR-002 (which records durable decisions) so the ADR stays stable.
Owned by ADR-002 (Security baseline and strategy). Re-challenged during the
periodic security review (planned /security-review; see docs/TODO.md).
Each entry: the risk · why we accept it (rationale) · what would make us revisit (trigger).
| # | Accepted risk | Rationale | Revisit trigger |
|---|---|---|---|
| R1 | Active supply-chain scanning deferred — baseline hygiene is required (tiered image pinning per ADR-011 — stateful tag@digest, stateless rolling — prefer official/verified images; gitleaks), but images and dependencies are not actively vulnerability-scanned (Trivy/Grype) or signature-verified |
Scanning only pays off with the capacity to triage its output; the realistic threat is opportunistic, not a targeted supply-chain attack | A monitoring/triage stack is live; hosting high-value data/finances for others; a relevant upstream compromise |
| R2 | SELinux not used — no SELinux mandatory access control | AppArmor — Debian-native and enforced via the CIS baseline — already provides MAC; adding SELinux means two MAC systems, non-native to Debian, for no real gain | A service that ships and requires its own SELinux policy; threat model shifts toward targeted attackers |
Last reviewed: 2026-06-04. The prior gaps (full CIS hardening, SELinux/AppArmor,
IDS) were re-challenged and adopted rather than accepted: CIS Debian L1+L2 + CIS
Docker, AppArmor (enforce), AIDE file-integrity, and Suricata network IDS are now
part of the security strategy (ADR-002). See STATUS.md / docs/TODO.md for build
status. As CIS is implemented, any specific item that proves impractical is added
here as a named exception.