Security FAQ
Security questions, answered from the code and the design decisions. The security posture summary gives the reviewer's overview; the concept pages on least privilege and defense in depth give the reasoning.
Which compliance frameworks does the Baseline support?
The offerings note lists out-of-the-box compliance readiness for SOC 2, HIPAA, PCI DSS 4.0, CMMC, NIST CSF and the CIS AWS Foundations Benchmark. In the code this is AWS Config with a BuiltForProd-soc2-baseline conformance pack on by default and 28 further packs (HIPAA, PCI DSS v4, NIST CSF, CMMC 2.0, CIS Critical Security Controls v8 and service packs) switched on per requirement, plus Security Hub standards (CIS v5, Foundational Security Best Practices, PCI DSS v4, tagging) as switches. Readiness means the controls and evidence sources exist; certification is your auditor's decision.
Are there any IAM users or long-lived access keys?
No. A service control policy denies creating IAM users, login profiles and access keys in every member account. People sign in through IAM Identity Center with twelve-hour sessions; pipelines authenticate through GitHub OIDC and assume a deployer role; workloads use EKS Pod Identity. The only exception to the user rule is the root user of each account, whose email is a plus-addressed alias on a team mailbox.
Who can change production?
Only the ACME_PlatformLeads and ACME_DevOpsLeads groups hold administrative permission sets in plat-prod; every other group is read-only there. In the pipelines, production applies wait for the prod GitHub Environment's required reviewers, and the production deploy pull request for the web application is merged by a person and then synced manually in ArgoCD.
How are secrets handled?
Application secrets live in acme-aws-blueprint-secrets, one YAML file per application per stage, encrypted with SOPS using one KMS key per stage (acme-sops-dev, acme-sops-staging, acme-sops-prod, acme-sops-sandbox). The key policy, not GitHub, decides who can decrypt: all engineer groups for sandbox and dev, only the lead groups for staging and prod. A sync workflow pushes decrypted values into SSM Parameter Store as SecureString parameters in the target account, and the External Secrets Operator delivers them to Kubernetes. Plaintext is never committed; the validation script rejects placeholder values. Infrastructure-generated secrets such as the DocumentDB master password are created by the module with write-only arguments, so they appear in neither plan nor state. Rotation of application secrets is manual: edit, review, merge.
Is everything encrypted?
At rest: default EBS encryption in every account, SSE-KMS on the state bucket, the audit bucket and the data lake, encryption on DocumentDB and ElastiCache, customer-managed KMS keys with annual rotation for the audit trail and the per-stage secrets. In transit: bucket policies deny non-TLS and TLS below 1.2 on the state and audit buckets, CloudFront uses TLSv1.2_2021, load balancers listen on HTTPS only, and DocumentDB and ElastiCache use in-transit encryption.
What detects a threat or a misconfiguration?
GuardDuty, Security Hub and IAM Access Analyzer are on by default, administered from core-security as delegated administrator for the whole organization. Inspector, Macie and Shield Advanced are switches in environments/core/security/security.hcl, each with its price beside it. AWS Config records every supported resource type in every account and aggregates in core-audit. High-severity GuardDuty findings, selected Config non-compliance and CIS CloudWatch alarms go to an SNS topic whose email you set; a public S3 bucket is remediated automatically outside core-public.
Can a compromised account delete its own logs?
No. One organization CloudTrail delivers every account's events, with log file validation, to a KMS-encrypted, versioned, TLS-only bucket in core-audit, alongside Config history and every VPC's flow logs. The acme-audit-protection policy denies stopping or deleting CloudTrail and Config in every member account.
How are prod and non-prod routed?
Transit Gateway route tables are split into isolation domains, prod and nonprod by default. Two domain tables never learn each other's routes, and each carries a blackhole route for the address range of every stage outside it, so cross-domain traffic is dropped at the Transit Gateway rather than reaching the other side through the hub. Every domain table sends 0.0.0.0/0 to the hub, and every spoke reaches the hub (egress, VPN, DNS) and the CI runners.
Is egress inspected?
It can be. AWS Network Firewall inspection in the hub is built and switched off by default because of its cost (about $865 per month for three AZ endpoints plus $0.065 per GB). When on, every spoke's egress passes through a stateful policy with alert and flow logs.
How do engineers reach private resources?
Through a single AWS Client VPN endpoint in the network account, federated with IAM Identity Center, with per-group, per-environment authorization derived from one access matrix. It is off by default, single-AZ and split-tunnel when on.
Does BuiltForProd keep access to my accounts?
Not after handover, unless you engage Managed. The deployment is executed by BuiltForProd's team into your accounts; the repositories and the accounts are yours. Under Managed, the access you grant and its scope are set out in your agreement; see the shared responsibility model.
How is the supply chain protected?
Every GitHub Action is pinned to a commit SHA, every registry module and provider to an exact version. Pre-commit and CI run Checkov, Trivy, tflint and secret-key detection on infrastructure; code repositories run Trivy image scans that fail on fixable critical and high vulnerabilities. Container images run as a fixed non-root user, and ECR tags are immutable; see policy as code.