Covers the five required components — threat model, risk assessment, security controls, testing results, incident response plan — plus the implemented controls, IAM, network, secrets, compliance mapping, and known risks.

Assets: order data/PII, DB credentials, approval tokens, container images, Terraform state, audit trail, the ECS task identity.

Full STRIDE detail (all categories, per-threat): see docs/decisions/ and the predecessor planning repo.

Risk = Likelihood × Impact (Low/Med/High).

• R1: aiops module — DynamoDB single-use tokens; action_executor Lambda re-validates approval state and refuses prod autonomous actions; S3 Object Lock audit; ECS task role carries zero ecs:Update*/write permissions.
• R2: WAF managed rule groups on the ALB; SQLAlchemy ORM; Pydantic request models; RDS in isolated subnets reachable only from the ECS SG.
• R3: ECR scan-on-push + Trivy in CI and at build; CRITICAL findings triaged (§6 testing results); accepted risks documented with compensating controls.
• R4: aws_s3_account_public_access_block + per-bucket PAB + KMS SSE; Config rule s3-bucket-public-read/write-prohibited continuously checks.
• R5: task-role-based auth for Bedrock/AWS (no static keys); DB password injected at deploy; comprehensive secret patterns in .gitignore; IAM Access Analyzer flags external access.

IAM (least privilege):

• ecs-task-role — CloudWatch put/get, Bedrock InvokeModel, read-only ecs/rds/elb describe, SNS publish, DynamoDB on the approvals table, lambda:InvokeFunction on the executor. No infra-mutate actions.
• action-executor-role — the only role with ecs:UpdateService/StopTask, scoped DynamoDB + S3 audit writes. Decoupled from the agent identity.
• Service roles (Config, RDS monitoring, VPC flow logs, Lambdas) each scoped to their function.

Network: see ARCHITECTURE.md §3 — chained SGs, isolated data tier, flow logs.

Secrets management: no secrets in git or the image. The DB password is generated by Terraform (random_password) into AWS Secrets Manager (aiops-<env>-db-credentials) and injected into the ECS task via the task-def secrets block (never in the task-def environment, never an input variable). All AWS/Bedrock access is via IAM roles. CI/CD authenticates to AWS with GitHub OIDC — no long-lived access keys exist. Roadmap: enable automatic rotation on the Secrets Manager secret.

Per the security requirements: Prowler CIS audit + Trivy container scan + ≥1 manual check.

Real scan of aiops-order-service:latest (Debian 13.5 base, 109 OS packages):

• OS packages: 17 findings (2 CRITICAL, 15 HIGH) — e.g. perl-base CVE-2026-42496 (fix deferred upstream), curl CVE-2026-5773.
• Python deps: chromadb 1.1.1 CRITICAL CVE-2026-45829 (pre-auth code execution) — transitive dependency of CrewAI, not exposed (we run no ChromaDB server); starlette HIGH CVE-2025-62727 (DoS, fixed in 0.49.1).

Triage / accepted risks:

• chromadb — accepted with compensating controls: pulled in transitively by CrewAI, never instantiated or network-exposed in our app; no ChromaDB listener runs. Mitigation roadmap: slim the image / pin CrewAI extras to drop the vector-store dependency.
• starlette DoS — mitigated by WAF rate limiting; upgrade tracked.
• OS CVEs (perl-base, curl) — upstream fixes deferred/unavailable on Debian 13 at scan time; rebuild picks them up automatically.

Scoped assessment across IAM, S3, RDS, EC2, CloudTrail, VPC (198 checks). Command:

prowler aws --services iam s3 rds ec2 cloudtrail vpc --output-formats csv

Result: 607 PASS / 388 FAIL (FAIL by severity: 3 critical, 55 high, 196 medium, 134 low).

Context: this is a shared bootcamp account — Prowler is account-wide, so the majority of findings come from other lab resources, not this project. Our IaC directly implements the controls the relevant CIS checks look for: RDS encryption + SSL, S3 Block Public Access (account + bucket), CloudTrail multi-region with log-file validation, VPC Flow Logs, least-privilege IAM, and restricted-ssh. The 3 critical/55 high are triaged against project-owned resources first; project resources pass the encryption/public-access/logging controls. The CSV is the full evidence.

A repeatable suite that probes each control live and prints an AWS-console pointer; all pass against prod:

DDoS proof (test 4) — while the flood is active, the rate-based rule lists the offending IP:

aws wafv2 get-rate-based-statement-managed-keys --scope REGIONAL --region us-east-1 \
  --web-acl-name aiops-prod-waf --web-acl-id <web-acl-id> \
  --rule-name RateLimit --query 'ManagedKeysIPV4.Addresses' --output json
# → ["<your-ip>/32"]   (rule name is "RateLimit"; metric name is aiops-prod-rate-limit)

1. HTTP→HTTPS redirect — http://…/health returns 301 to HTTPS. ✅
2. AIOps autonomous guardrail — autonomous action against environment=prod returns denied: "autonomous agents may not act on production". ✅
3. AIOps approval lifecycle — propose → pending → approve (executes via the executor Lambda, audited) and reject both behave correctly; an approved token is single-use. ✅

Pre-written, not reactive. Applies to: DDoS, GuardDuty/WAF high finding, AIOps agent runaway, compromised credential, data exposure.

1. Isolate — identify scope; if an agent is implicated, trip the circuit breaker / disable the executor Lambda; tighten the relevant security group; for DDoS, raise WAF rate limits / block offending IPs.
2. Investigate — pull CloudWatch logs (correlation IDs), CloudTrail events, VPC Flow Logs, and the S3 audit trail; confirm blast radius and root cause.
3. Contain — revoke/rotate affected credentials; scale or quarantine affected tasks; freeze deployments (concurrency lock in CI).
4. Notify — SNS alert to the on-call email; record the incident in docs/incident-reports/.
5. Remediate — apply the fix via the GitOps pipeline (PR → review → merge → apply); re-run Trivy/Prowler to confirm; restore service.
6. Post-mortem — blameless RCA in docs/incident-reports/: timeline, root cause, what worked, action items; update controls/runbook.

See RUNBOOK.md for the operational commands behind each step.