feat: AWS Security & Compliance — finding-to-code mapping with AI remediation @aknysh (#2282)

## what

Add atmos aws security analyze — fetch security findings from AWS Security Hub, map them to Atmos components and stacks via resource tags, and generate structured remediation reports
Add atmos aws compliance report — generate compliance posture reports against industry frameworks (CIS AWS, PCI-DSS, SOC2, HIPAA, NIST) with pass/fail scoring
Add finding-to-code mapping pipeline with 7 strategies: finding-tag (exact), tag-api (exact), context-tags (high), account-map (low), ecr-repo (low), naming-convention (low), resource-type (low)
Add optional AI-powered remediation via --ai flag — multi-turn tool analysis reads component source and stack config, generates root cause analysis, specific code changes, stack YAML changes, deploy commands, risk assessment
Add AI finding deduplication (same title+component+stack analyzed once) and retry with exponential backoff for transient API errors
Add 4 output formats: Markdown (terminal), JSON (CI/CD), YAML, CSV
Add Atmos Auth integration via identity config field for targeting Security Hub delegated admin accounts
Add --stack, --component, --severity, --source, --framework, --format, --file, --max-findings, --no-group, --region, --identity flags
Add AI tools: atmos_list_findings, atmos_describe_finding, atmos_analyze_finding, atmos_compliance_report
Add example: examples/aws-security-compliance/
Add Docusaurus docs for all commands and configuration
Add blog post with production testing results

why

Reviewing AWS security findings today requires navigating multiple AWS console pages, cross-referencing resources with Terraform code, and manually figuring out which configuration caused the issue. This is slow, error-prone, and requires deep AWS + Terraform expertise.

Atmos owns the component-to-stack relationship, so it can trace a security finding on an AWS resource all the way back to the exact Terraform code and stack configuration that created it — and generate a targeted fix.

The key differentiator vs AWS MCP security servers: MCP servers return raw findings but have no concept of Atmos stacks, components, or Terraform source code. Our implementation maps findings to IaC and generates specific remediation with deploy commands.

See It in Action

Tested against a multi-account AWS organization (11 accounts, Security Hub delegated admin, 500 findings, 97.2% mapped to Atmos components).

1. Security findings mapped to components

$ atmos aws security analyze --stack plat-use2-dev --component rds/example

ℹ Fetching security findings...
ℹ Mapping 500 findings to Atmos components...
ℹ Filtered to 4 findings matching stack="plat-use2-dev" component="rds/example"

# Security Report: plat-use2-dev / rds/example

Findings: 4 (1 CRITICAL, 3 HIGH)

## CRITICAL Findings (1)

### 1. Security groups should not allow unrestricted access to ports with high risk

| Field          | Value                                                        |
|----------------|--------------------------------------------------------------|
| **Severity**   | CRITICAL                                                     |
| **Source**     | security-hub (aws-foundational-security-best-practices/1.0)  |
| **Resource**   | arn:aws:ec2:us-east-2:***:security-group/sg-***              |
| **Component**  | rds/example                                                  |
| **Stack**      | plat-use2-dev                                                |
| **Confidence** | exact                                                        |
| **Mapped By**  | finding-tag                                                  |

Resource Tags:
• atmos_stack = plat-use2-dev
• atmos_component = rds/example
• terraform_component = rds
• Name = acme-plat-use2-dev-example-postgres-db
• Namespace = acme, Tenant = plat, Environment = use2, Stage = dev

## Summary
| Severity  | Count | Mapped | Unmapped |
|-----------|-------|--------|----------|
| CRITICAL  | 1     | 1      | 0        |
| HIGH      | 3     | 3      | 0        |
| **Total** | **4** | **4**  | **0**    |

2. AI-powered remediation (`--ai`)

$ atmos aws security analyze --stack plat-use2-dev --component rds/example --ai

ℹ Analyzing findings with AI...

✓ AI analysis complete — Security Analysis: rds/example in plat-use2-dev

## Findings Breakdown

### EC2.18: Unrestricted Ingress on Unauthorized Port (HIGH)
Port 5432 (PostgreSQL) is open to 0.0.0.0/0. The likely cause is
allowed_cidr_blocks being set to an overly permissive value.

### EC2.13: Unrestricted Ingress on Port 22/SSH (HIGH)
⚠️ Port 22 has no business being on an RDS security group. This strongly
suggests an out-of-band manual change in the AWS Console — drift from IaC.

## Root Cause (Common Thread)
Both findings stem from var.allowed_cidr_blocks being set too permissively,
compounded by possible out-of-band drift.

## Priority Actions
1. Remove the port-22 inbound rule manually (out-of-band drift)
2. Update catalog/rds/example.yaml:
     allowed_cidr_blocks: []
     publicly_accessible: false
     use_private_subnets: true
3. Add Terraform validation guards:
     validation {
       condition     = !contains(var.allowed_cidr_blocks, "0.0.0.0/0")
       error_message = "allowed_cidr_blocks must not contain 0.0.0.0/0."
     }
4. Plan and apply:
     atmos terraform plan rds/example -s plat-use2-dev
     atmos terraform apply rds/example -s plat-use2-dev

## Risk Assessment
| Finding              | Risk   | Note                                       |
|----------------------|--------|--------------------------------------------|
| EC2.18 (port 5432)   | Medium | Removing rule breaks direct DB connections |
| EC2.13 (port 22/SSH) | Low    | No RDS traffic should depend on SSH        |

3. Compliance report

$ atmos aws compliance report

# Compliance Report: CIS AWS Foundations Benchmark

## Score: 35/42 Controls Passing (83%)

### Failing Controls
| Control      | Title                                                                 | Severity |
|--------------|-----------------------------------------------------------------------|----------|
| Config.1     | AWS Config should be enabled with service-linked role                 | CRITICAL |
| EC2.14       | Security groups should not allow ingress from 0.0.0.0/0 to port 3389  | HIGH     |
| EC2.13       | Security groups should not allow ingress from 0.0.0.0/0 to port 22    | HIGH     |
| S3.1         | S3 buckets should have block public access settings enabled           | MEDIUM   |
| EC2.6        | VPC flow logging should be enabled in all VPCs                        | MEDIUM   |
| IAM.17       | Ensure IAM password policy expires passwords within 90 days           | LOW      |
| CloudTrail.7 | Ensure S3 access logging on CloudTrail S3 bucket                      | LOW      |

4. Compliance report with AI (`--ai`)

$ atmos aws compliance report --ai

✓ AI analysis complete — CIS Foundations Benchmark

## Overall Status: 🟡 83% Compliant (35/42 controls passing)

## 🚨 Priority Issues (Fix First)

### CRITICAL
| Control  | Issue                                  | Action                             |
|----------|----------------------------------------|------------------------------------|
| Config.1 | AWS Config not enabled or missing role | Enable in all regions, attach role |

### HIGH
| Control | Issue                              | Action                                  |
|---------|------------------------------------|-----------------------------------------|
| EC2.14  | RDP (port 3389) open to 0.0.0.0/0 | Restrict to known IP ranges or VPN       |
| EC2.13  | SSH (port 22) open to 0.0.0.0/0   | Use SSM Session Manager instead of SSH   |

## 🟠 Medium: S3.1 (Block Public Access), EC2.6 (VPC Flow Logs)
## 🟢 Low: IAM.17 (Password policy), CloudTrail.7 (S3 access logging)

## Next Steps
1. Lock down security groups for ports 22/3389
2. Enable AWS Config — also detects future drift
3. Run `atmos terraform apply` on security-groups, vpc, config components
4. Re-run this report to verify score improves

New CLI Commands

`atmos aws security analyze`

Fetches findings from Security Hub, maps them to Atmos components via resource tags (7 mapping strategies with confidence levels), and renders reports in 4 formats. Post-mapping --stack and --component filters narrow results after mapping. With --ai, the AI reads component source code and stack config via multi-turn tools to generate specific remediation.

`atmos aws compliance report`

Queries Security Hub enabled standards, counts total controls via ListSecurityControlDefinitions, and computes pass/fail scores. Supports --framework filter for CIS AWS, PCI-DSS, SOC2, HIPAA, NIST. With --ai, generates prioritized remediation for each failing control.

Configuration

aws:
  security:
    enabled: true
    identity: "security-readonly"  # Atmos Auth → Security Hub account
    region: "us-east-2"            # Aggregation region
    max_findings: 500
    tag_mapping:
      stack_tag: "atmos:stack"
      component_tag: "atmos:component"

Example

See examples/aws-security-compliance/ for a complete configuration with auth, tag mapping, AI provider, and all commands.

references

PRD: docs/prd/atmos-aws-security-compliance.md
Blog: website/blog/2026-04-03-aws-security-compliance.mdx
Example: examples/aws-security-compliance/
Docs: website/docs/cli/commands/aws/security/, website/docs/cli/commands/aws/compliance/
Config: website/docs/cli/configuration/aws/security.mdx

Summary by CodeRabbit

Release Notes

New Features
- AWS Security Hub integration with automatic mapping of findings to Atmos components and stacks
- Compliance reporting with support for CIS-AWS, PCI-DSS, SOC2, HIPAA, and NIST frameworks
- AI-powered remediation analysis using --ai flag for structured guidance
- Multiple output formats (Markdown, JSON, YAML, CSV) for security and compliance reports
- Configuration schema for AWS security settings, tag mapping, and frameworks
Documentation
- Added comprehensive guides for atmos aws security analyze and atmos aws compliance report commands
- Added AWS configuration documentation for security settings and tag-based component mapping
- Added blog post and examples demonstrating end-to-end AWS security workflows

cloudposse/atmos v1.215.0-rc.3 on GitHub

why