boma/docs/security/service-checklist.md

Per-service security checklist

The bar every service (a per-service role — ADR-004) must clear before deploy, especially anything reachable beyond its own host. Established by ADR-002 (Security baseline and strategy); referenced from docs/runbooks/new-role.md. Enforced manually in review today; the planned /security-review skill (see docs/TODO.md) will automate the check.

Treat each item as must-pass unless a deviation is recorded in docs/security/accepted-risks.md with a rationale and a revisit trigger.

This checklist is the generic bar. Each service answers it in its own roles/<service>/SECURITY.md (the "Checklist status" section), created from docs/security/service-security-template.md — see ADR-004.

Secrets & credentials

• All secrets live in an encrypted vault.yml (vault.<service>.<key>); none in plaintext files, templates, or Compose env literals
• No default or vendor-shipped credentials remain — admin passwords/tokens are generated and stored in vault
• Nothing secret is baked into an image or committed to git (gitleaks must pass)

Least privilege

• Container runs as a non-root user where the image supports it
• No privileged: true and no host network mode unless explicitly justified
• Only the volumes/paths the service needs are mounted; read-only where possible
• Linux capabilities dropped to what's required (no blanket grants)

Network & exposure

• Every listening port is declared in group_vars firewall definitions — never opened ad-hoc on a host
• The service is not published directly to a LAN/WAN port if it can sit behind the reverse proxy instead
• Anything reachable beyond the srv VLAN is behind the reverse proxy with authentication (and TLS)
• Inter-service reach follows least privilege — no broad srv→srv access where a single declared dependency suffices

Updates & provenance

• Image pinned per ADR-011's tiered rule — stateful: tag@digest; stateless: rolling tag (latest/stable) acceptable
• The update path is known — how this service gets patched

Operability (security-adjacent)

• Logs go somewhere reviewable (central aggregation when available)
• Backup/restore recorded and verifiable (ADR-022): a stateful service carries backup__* data, roles/<service>/BACKUP.md is rendered, and /check-backup reports the declared paths/dumps captured in the latest snapshot — or the service sets backup__state: false with a reason. Deviations → docs/security/accepted-risks.md.
• Passed Level 4 service-UI verification (/verify-service) against staging — the service has a populated roles/<service>/VERIFY.md and its critical journeys verified (ADR-008 Level 4 / ADR-017)
• Operational access recorded and verifiable (ADR-021): the role carries access__* data, roles/<service>/ACCESS.md is rendered, and /check-access reports the documented paths green — or a deviation is recorded in docs/security/accepted-risks.md

Deviations are allowed but must be conscious: record them in docs/security/accepted-risks.md, don't leave them implicit.