Security monitoring follow-up: AWS Config, S3 account-level BPA, alerting, findings-tracking

Context

Split out from #161, which is now closed. #161 covered re-verifying and enabling what could be safely "flipped on" with full account access: CloudTrail and GuardDuty were already enabled, Security Hub and IAM Access Analyzer were newly enabled, and ECR scanning was confirmed already working. What's left needs actual design work, not a quick toggle.

Remaining items

• AWS Config — has real ongoing per-resource recording cost and requires setup decisions (which resource types to record, recorder IAM role). Needs its own cost/scope pass before enabling on either account.
• S3 account-level Block Public Access — not enabled on either account. Cannot be enabled naively: account-level BPA is a ceiling that combines with bucket-level settings (most restrictive wins), and musehub-releases has its own bucket-level public access intentionally disabled to serve the public /install.sh installer and release tarballs (signed off as intentional, 2026-08-29). Enabling account-level BPA without an explicit bucket-level exception for musehub-releases would break the public installer. Needs a deliberate design: likely an explicit per-bucket exception/allowlist alongside the account-level block.
• Alerting on sensitive changes — no alerting wired up for IAM/KMS/CloudTrail/DNS/security- group changes, or for root-account activity / failed console logins. CloudTrail, GuardDuty, and Security Hub are all now live and producing events/findings — this would build on top of those rather than needing new data sources.
• Findings-tracking process — no process exists for recording and assigning ownership of security findings (from GuardDuty, Security Hub, or ECR scan results). Worth deciding whether this lives in MuseHub's own issue tracker or a dedicated tool.

Also worth a look eventually (not urgent)

The running musehub/musehub image has 7 CRITICAL CVEs (glibc, perl, openssl, xorg-server, glib2.0), all currently unfixable (no vendor patch available). Traced to playwright install --with-deps chromium (OG cards, #129) pulling in X11/xorg-server. Worth considering whether isolating Chromium into a separate sidecar/service would reduce the main API image's attack surface long-term — not urgent since none of the current CRITICAL findings are fixable regardless of base image choice. See docs/production-readiness/13-security-monitoring.md for the full findings table.