boma/docs
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
..
decisions Re-challenge accepted risks; adopt CIS hardening + IDS 2026-06-04 15:15:39 +02:00
hardware Add hardware reference doc skeleton + reviews dir 2026-06-01 10:14:53 +02:00
reviews review-repo: harden scanner, apply safe fixes, record first review 2026-05-30 19:10:58 +02:00
runbooks Expand ADR-002 into a security baseline + strategy 2026-06-04 14:39:51 +02:00
security Re-challenge accepted risks; adopt CIS hardening + IDS 2026-06-04 15:15:39 +02:00
superpowers Add implementation plan for hardware capacity tooling 2026-06-01 10:04:59 +02:00
FRICTION.md Log Forgejo no-PR-workflow friction in FRICTION.md 2026-06-01 11:22:26 +02:00
README.md Add architecture decision records and runbooks 2026-05-30 14:10:01 +02:00
TODO.md Re-challenge accepted risks; adopt CIS hardening + IDS 2026-06-04 15:15:39 +02:00

docs/

Project documentation.

  • decisions/ — Architecture Decision Records (ADRs): the "why" behind the design. Numbered from 001; each records context, the decision, and what was ruled out.
  • runbooks/ — step-by-step operational procedures (add a host, add a role, rotate secrets).

For what is actually built vs only designed, see STATUS.md at the repo root — the ADRs describe intent, not necessarily current reality.