boma/docs/security/accepted-risks.md
sjat 19dd89b875 Re-challenge accepted risks; adopt CIS hardening + IDS
Walked the seeded accepted-risk register (R1-R4) and turned inherited gaps into
deliberate decisions:

- Supply chain (R1): tightened to required baseline hygiene (digest pinning,
  official/verified images); active scanning deferred — stays an accepted risk
- CIS (R2): adopted as a positive decision — CIS Debian L1+L2 (base role) + CIS
  Docker (docker_host + service checklist); app layer via the checklist
- SELinux/AppArmor (R3): AppArmor becomes a baseline control (CIS-enforced);
  register keeps a clean "no SELinux" accept
- IDS (R4): adopt AIDE (baseline via CIS) + Suricata on OPNsense + active alerting

Register shrinks from 4 inherited gaps to 2 deliberate accepts. ADR-002 gains a
Hardening standard section; STATUS + TODO 15 track the (unbuilt) implementation,
including the CIS L2 partition impact on VM provisioning (ADR-006).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-04 15:15:39 +02:00

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 (image digest pinning + prefer official/verified images, ADR-011 / service checklist; 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.