sjat/boma

sjat 3b029352b6 Add per-service SECURITY.md convention; one role per service

Revise ADR-004 to a service-role standard: every service is its own
self-contained role with a required file set including SECURITY.md, uniform
deploy mechanics, and a deferred shared-engine option (with revisit trigger)
recorded in the ADR.

Add the per-service security record:
- docs/security/service-security-template.md — canonical SECURITY.md template
  (exposure, checklist status, service-specific hardening, residual risks)
- roles/<service>/SECURITY.md is where each service records how it meets the bar;
  /security-review aggregates roles/*/SECURITY.md and cross-checks against config
- service-checklist.md noted as the generic bar the record answers

Wire-up: new-role runbook step writes SECURITY.md from the template; ADR-002
governance bullet points at it; CLAUDE.md role conventions require it and mandate
one-role-per-service; STATUS records the convention as defined-not-yet-applied.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-04 16:09:33 +02:00

2.4 KiB

Raw Permalink Blame History

Per-service security record — template

Copy this file to roles/<service>/SECURITY.md and fill it in when building a service role (ADR-004). It is the per-service security record: the generic bar lives in docs/security/service-checklist.md (the questions); this file is this service's answers, plus service-specific measures. Filling the Checklist status section is how a service clears the bar (docs/runbooks/new-role.md).

The planned /security-review aggregates every roles/*/SECURITY.md and cross-checks the claims here against the role's actual config (Compose template, declared firewall ports), so keep this honest and current.

Delete this preamble in the copy and start from the heading below.

Security — <service>

Exposure

Published ports: <ports> — and which are declared in the group_vars firewall vars
Auth surface: <how it authenticates — e.g. behind reverse proxy + SSO, or app-native login>
Reachability: <which VLANs / sources can reach it; internal-only vs LAN vs public>
Data sensitivity: <what data it holds; backup/restore pointer>

Checklist status

Each item from docs/security/service-checklist.md, with this service's status: ✅ met · ⚠️ deviation (link to docs/security/accepted-risks.md) · n/a.

Secrets in vault; no default creds; nothing secret in git/images
Non-root; no privileged/host-network unless justified; minimal mounts; caps dropped
Ports declared in group_vars; behind reverse proxy + auth if exposed; least-privilege inter-service reach
Image pinned (tag/digest), update path known
Logs reviewable; backup/restore covered if stateful

Service-specific hardening

Measures beyond the generic bar — the application's own relevant settings. Examples of the kind of thing that belongs here (replace with this service's actual measures):

App-level brute-force / rate-limiting protection enabled
Trusted-domains / allowed-hosts restricted
Unused features or remote-access modes disabled
Server-side encryption / secure cookie / security-header settings

Residual / accepted risks

Anything not done for this service — each with rationale and a revisit trigger. Link global trade-offs to docs/security/accepted-risks.md; note service-local ones here.

<none yet, or: risk · rationale · revisit trigger>

2.4 KiB Raw Permalink Blame History