Section 13 — Security Monitoring and Auditability

Companion to musehub-production-readiness-checklist.md.

Update (2026-08-29) — re-verified with full account access

The broader read-access grant this section was blocked on has landed (IAM Identity Center + AdministratorAccess on both accounts via SSO). Re-ran every blocked check directly.

Already true — the original pass just couldn't see it

• [x] CloudTrail — enabled on both accounts, multi-region, log-file validation on (musehub-nonproduction-trail / musehub-production-trail)
• [x] GuardDuty — enabled on both accounts (detector IDs confirmed)
• [x] ECR image vulnerability scanning — actually enabled and working (scanOnPush: true on both accounts' musehub/musehub repo). The original pass's claim that this "is not enabled" was wrong — the specific image it checked simply hadn't been scanned yet at that point in time.

Enabled today

• [x] Security Hub — enabled on both accounts with default standards (AWS Foundational Security Best Practices), 2026-08-29
• [x] IAM Access Analyzer — enabled on both accounts (musehub-account-analyzer), 2026-08-29

Still open — deliberately not done in this pass

• [ ] AWS Config — not enabled. Has real ongoing per-resource recording cost and needs actual setup decisions (which resource types, recorder IAM role) — a "flip it on" toggle isn't appropriate here the way it was for Security Hub/Access Analyzer. Revisit as its own task.
• [ ] S3 account-level Block Public Access — not enabled. Do not enable naively: account- level Block Public Access applies as 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 (see sign-off below). Turning on account-level BPA without an explicit bucket-level exception would break that. Needs a deliberate design pass, not a quick toggle.
• [ ] Monitor changes to IAM/KMS/CloudTrail/DNS/security-groups — no alerting wired up yet; would build on the now-available CloudTrail + GuardDuty + Security Hub findings
• [ ] Alert on root-account activity / failed console logins — same, no alerting wired up yet
• [ ] Define a vulnerability-remediation SLA — can now be meaningfully defined, since scanning is confirmed working and producing real findings (see below). Not yet done.
• [ ] Record and assign every security finding — no findings-tracking process exists yet

musehub-releases bucket — signed off

musehub-releases' disabled Block Public Access settings are confirmed intentional (Gabriel, 2026-08-29) — this bucket serves the public CLI installer and release tarballs by design. Documented here as the explicit, permanent exception to "enable S3 Block Public Access" rather than something to silently leave unresolved. Nothing sensitive should ever be placed in this bucket.

Real vulnerability findings — worth understanding, not urgent to act on

The running musehub/musehub:latest image has real CVEs, found via the now-confirmed-working ECR scanning:

All 7 CRITICAL findings (CVE-2026-5450 glibc, CVE-2026-57433/CVE-2026-12087/CVE-2026-13221 perl, CVE-2026-34182 openssl, CVE-2026-56000 xorg-server, CVE-2026-58016 glib2.0) currently have no vendor fix available — nothing to remediate via package upgrade right now. Not something to lose sleep over, but worth tracking for whenever fixes land upstream.

xorg-server showing up in a headless backend service's dependency tree looks alarming at first, but is explained: the Dockerfile runs playwright install --with-deps chromium for OG card rendering (#129), and Chromium — even run headless — links against X11 libraries, pulling in a much larger package surface (and larger CVE count) than the rest of the app needs. This is a legitimate architectural tradeoff for that one feature, not sloppy dependency management. Worth considering longer-term whether isolating Chromium into a separate sidecar/service (keeping the main API image minimal) would meaningfully reduce the primary web-facing container's attack surface — not urgent, since none of the current CRITICAL findings are fixable regardless of base image choice.