security-mcp 1.1.4 → 1.3.3

package/skills/aws-penetration-tester/SKILL.md

@@ -20,6 +20,15 @@ a compromised Lambda to full account takeover. You know every `iam:PassRole` abu
 Find every AWS misconfiguration that could allow privilege escalation, data exfiltration,
 or account compromise. Write the Terraform fix or IAM policy correction inline.
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+The `infra.ts` and `iac.ts` detection modules (`src/gate/checks/infra.ts`, `src/gate/checks/iac.ts`) are your deterministic floor, not your ceiling. Treat their finding IDs as the minimum, then reason past what single-line/single-file pattern matching can see — and APPLY the fix (Edit the Terraform/IAM policy), not just advise:
+
+- **Cross-file / data-flow reasoning the regex can't do:** `iam:PassRole` granted in one policy file + `lambda:CreateFunction` (or `ec2:RunInstances`) in a role it can assume in another = a full privilege-escalation chain no single-line grep flags.
+- **Semantic / effective-state analysis:** compute the *effective* permissions and blast radius of each role across its full assume-role/trust-policy graph — an `Owner`-equivalent reachable from a Lambda with a public Function URL is the real finding, not the wildcard in isolation.
+- **External corroboration:** use WebSearch/WebFetch for current AWS Security Bulletins, HackTricks Cloud escalation techniques, and CVEs for detected service versions (e.g. runc/EKS).
+- **Apply & prove:** write the fix inline (scope `PassRole` with `iam:PassedToService`, enforce IMDSv2 `http_tokens=required` + hop limit 1, add `ExternalId`), re-run the `infra.ts`/`iac.ts` checks plus tfsec/checkov as a regression floor, then re-audit the escalation graph semantically. Emit the LEARNING SIGNAL per fix; surface any fix that changes intended behavior as an explicit trade-off with the secure default.
+
 ## EXECUTION
 
 1. Scan all Terraform, CloudFormation, CDK, and serverless.yml files for AWS resources
@@ -58,3 +67,504 @@ If internet permitted:
 - Blast radius: exactly what is accessible if this is exploited
 - Privilege escalation chain (if applicable)
 - Fixed Terraform/IAM policy written inline
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "...", "exploitHint": "..." }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "...", "location": "..." }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "...", "escalationPath": "..." }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["..."], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+### 1. IAM Privilege Escalation via `iam:PassRole` + Service Chaining (Rhino Security Labs Technique)
+
+**Technique:** An attacker with `iam:PassRole` and `ec2:RunInstances` (or `lambda:CreateFunction`,
+`glue:CreateJob`, `sagemaker:CreateTrainingJob`, etc.) can pass a more-privileged role to a new
+service resource, then execute code under that role — bypassing policy boundaries entirely.
+
+**Test:** Search all IAM policies for the combination of `iam:PassRole` co-existing with any
+service creation action. Run:
+```bash
+grep -r "iam:PassRole" . --include="*.tf" --include="*.json" -l
+```
+Then for each hit, check whether the same policy or any role it can assume also grants
+`ec2:RunInstances`, `lambda:CreateFunction`, `glue:CreateJob`, `ecs:RunTask`, or
+`sagemaker:CreateTrainingJob`.
+
+**Finding:** Any policy where `iam:PassRole` scope is `"Resource": "*"` with no condition
+keys (`aws:RequestedRegion`, `iam:PassedToService`) is an automatic HIGH. If a service creation
+action is co-located, escalate to CRITICAL.
+
+**Fix:** Restrict `iam:PassRole` to specific role ARNs and add condition:
+```json
+"Condition": { "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" } }
+```
+
+---
+
+### 2. EKS Pod Identity / IRSA Token Audience Confusion (CVE-2024-21626 Class)
+
+**Technique:** EKS IRSA (IAM Roles for Service Accounts) tokens include an `aud` claim. If the
+OIDC provider trust policy does not pin `sts.amazonaws.com` as the sole audience AND the service
+account annotation is overly broad, a malicious pod in a lower-privilege namespace can forge
+requests to STS using ambient IRSA tokens. Additionally, container escape via `runc` path
+traversal (CVE-2024-21626) can reach the host IRSA token file before it is rotated.
+
+**Test:**
+```bash
+# Check OIDC trust policy audience restriction
+grep -r "oidc.eks" . --include="*.tf" -A10 | grep -E '"aud"|Audience'
+# Verify hop limit enforced (mitigates SSRF → IMDS token theft)
+grep -r "http_tokens" . --include="*.tf" | grep -v "required"
+```
+
+**Finding:** Any IRSA trust policy missing `StringEquals` on `token.actions.githubusercontent.com:aud`
+or without `sub` condition pinned to the specific service account is CRITICAL.
+
+---
+
+### 3. S3 Server-Side Request Forgery to IMDS Credential Theft Chain
+
+**Technique:** An application-level SSRF vulnerability that can reach `169.254.169.254` bypasses
+IMDSv1 controls entirely if the EC2 metadata hop limit is set to 2 (default before December 2019).
+The attacker retrieves temporary IAM credentials for the instance profile, then calls STS to
+confirm the role, and escalates.
+
+**Test:**
+```bash
+# Confirm IMDSv2 hop-limit is 1 (mandatory)
+grep -r "http_put_response_hop_limit" . --include="*.tf" | grep -v "= 1"
+grep -r "metadata_options" . --include="*.tf" -A5
+# Grep for missing metadata_options block entirely
+grep -rL "metadata_options" . --include="*.tf" | xargs grep -l "aws_instance"
+```
+
+**Finding:** Any `aws_instance` or `aws_launch_template` without `metadata_options { http_tokens = "required" http_put_response_hop_limit = 1 }` is CRITICAL if the application has any HTTP fetch capability.
+
+---
+
+### 4. AWS CodeBuild / CodePipeline Supply Chain Injection
+
+**Technique (Supply Chain / Emerging Threat):** An attacker with write access to a dependency
+source (npm, pip, Maven) that CodeBuild fetches during `buildspec.yml` execution can inject
+malicious code that runs in the CodeBuild environment — which typically holds credentials for
+S3, ECR, and deployment roles. This is the AWS-native form of the SolarWinds / XZ Utils
+supply-chain attack pattern.
+
+**Test:**
+```bash
+# Check buildspec.yml for unpinned dependencies
+find . -name "buildspec.yml" -o -name "buildspec.yaml" | xargs grep -E "npm install|pip install|gem install" | grep -v "@[0-9]"
+# Check CodeBuild role scope
+grep -r "codebuild" . --include="*.tf" -A30 | grep -E "AdministratorAccess|PowerUserAccess|\*"
+```
+
+**Finding:** Any CodeBuild `buildspec.yml` that installs packages without pinned versions AND
+the CodeBuild execution role has IAM write, S3 write, or ECR push permissions is a CRITICAL
+supply-chain risk.
+
+**Emerging Threat Context:** AI-generated package names hallucinated by LLM coding assistants
+create phantom package names that attackers register ("AI-assisted dependency confusion"). Check
+all `package.json`, `requirements.txt`, and `pom.xml` for packages with zero download history.
+
+---
+
+### 5. Secrets Manager / Parameter Store Plaintext Logging via CloudWatch
+
+**Technique:** When application code retrieves a secret via `GetSecretValue` or `GetParameter`,
+some logging frameworks (especially structured loggers that serialize the entire SDK response
+object) will log the `SecretString` field to CloudWatch Logs. This creates a secondary plaintext
+secret store with longer retention and broader IAM read access than the original secret.
+
+**Test:**
+```bash
+# Find CloudWatch log groups with long or infinite retention
+grep -r "retention_in_days" . --include="*.tf" | grep -v "retention_in_days"
+# Find log group missing encryption
+grep -rL "kms_key_id" . --include="*.tf" | xargs grep -l "aws_cloudwatch_log_group"
+# Find application code that may log full SDK response
+grep -rn "GetSecretValue\|get_secret_value" . --include="*.ts" --include="*.py" --include="*.js" -A3 | grep -i "log\|console\|print"
+```
+
+**Finding:** Any CloudWatch log group without KMS encryption AND retention > 90 days that is
+accessible by a log group with loose IAM read policy is HIGH. Add `kms_key_id` and set
+`retention_in_days = 30` minimum.
+
+---
+
+### 6. Post-Quantum Threat: AWS KMS RSA Key Usage in Long-Lived Signed Artifacts
+
+**Technique (Post-Quantum / Emerging Threat):** AWS KMS RSA_2048 and RSA_4096 keys used for
+signing (S3 object signatures, CloudFront signed URLs, JWT RS256 tokens) are vulnerable to
+harvest-now-decrypt-later attacks. An adversary collecting signed tokens today can break the
+signatures when a cryptographically relevant quantum computer (CRQC) is available (estimated
+2028–2032 per NIST). AWS KMS does not yet offer ML-DSA (FIPS 204) signing keys natively, but
+hybrid approaches using application-layer ML-DSA signatures alongside KMS are available.
+
+**Test:**
+```bash
+# Find all KMS keys configured for SIGN_VERIFY with RSA
+grep -rn "key_usage.*SIGN_VERIFY\|customer_master_key_spec.*RSA" . --include="*.tf"
+# Find CloudFront signed URL configurations
+grep -rn "trusted_key_groups\|trusted_signers" . --include="*.tf"
+# Find JWT libraries using RS256
+grep -rn "RS256\|RS384\|RS512" . --include="*.ts" --include="*.py" --include="*.js"
+```
+
+**Finding:** Any KMS RSA signing key used for tokens or artifacts with validity > 1 year is HIGH
+with a post-quantum risk note. Recommend migration plan to ML-DSA when AWS KMS supports it and
+interim mitigation of shortening token lifetimes to < 24 hours.
+
+---
+
+### 7. GuardDuty Suppression Rules Creating Detection Blind Spots
+
+**Technique:** GuardDuty suppression rules (filter rules with auto-archive action) are commonly
+created to suppress noisy findings from trusted CI/CD IP ranges or pentest suites. An attacker
+who discovers a suppressed CIDR block (via leaked Terraform state or CloudFormation outputs) can
+route their attacks through a VPN endpoint in that CIDR to evade GuardDuty detection entirely.
+
+**Test:**
+```bash
+# Find GuardDuty filter/suppression rules in Terraform
+grep -rn "aws_guardduty_filter\|aws_guardduty_publishing_destination" . --include="*.tf" -A20
+# Check for overly broad suppression (entire RFC 1918 ranges)
+grep -rn "criterion\|equal_to\|gte\|lte" . --include="*.tf" | grep -E "10\.|172\.16|192\.168" -A3
+```
+
+**Finding:** Any GuardDuty suppression rule that archives findings by CIDR block broader than /28
+or by `ipAddressV4` containing a public IP range is HIGH. Each suppression rule must be documented
+with a business justification and reviewed quarterly.
+
+---
+
+### 8. AI-Assisted Attack Surface: Bedrock / SageMaker IAM Over-Privilege
+
+**Technique (AI-Assisted / Emerging Threat):** AWS Bedrock and SageMaker endpoints are increasingly
+used in production. Their execution roles commonly receive `s3:GetObject` on training data buckets
+or `s3:PutObject` on output buckets. An attacker who achieves prompt injection via a Bedrock Agent
+invocation can exfiltrate the model's execution role credentials via the agent's code interpreter
+tool — a novel SSRF-via-LLM attack class documented in AWS threat research (2024).
+
+**Test:**
+```bash
+# Find Bedrock agent and model execution roles
+grep -rn "bedrock\|sagemaker" . --include="*.tf" -A30 | grep -E "iam_role_arn|role_arn|execution_role"
+# Check if Bedrock agent action groups include code execution
+grep -rn "AMAZON.CodeInterpreter\|action_group_executor" . --include="*.tf" --include="*.json"
+# Verify Bedrock Guardrails configured
+grep -rn "aws_bedrock_guardrail" . --include="*.tf"
+```
+
+**Finding:** Any Bedrock Agent with `AMAZON.CodeInterpreter` action group enabled AND an execution
+role that has `s3:GetObject` or `sts:AssumeRole` on scopes beyond the agent's dedicated bucket is
+CRITICAL — this is an exploitable AI prompt-injection-to-credential-theft chain.
+
+---
+
+## §AWS_PENETRATION_TESTER-CHECKLIST
+
+1. **IAM Wildcard Actions in Customer-Managed Policies**
+   Mechanism: `"Action": "*"` or `"Action": "iam:*"` in any non-AWS-managed policy grants full
+   admin equivalent. Grep: `grep -rn '"Action": "\*"' . --include="*.tf" --include="*.json"`.
+   Finding: Any hit outside `AdministratorAccess` managed policy is CRITICAL.
+
+2. **S3 Block Public Access Disabled at Account Level**
+   Mechanism: Account-level Block Public Access can be disabled separately from bucket-level,
+   allowing bucket ACLs or policies to re-enable public access. Grep:
+   `grep -rn "aws_s3_account_public_access_block" . --include="*.tf"` — absence of this resource
+   in the account Terraform is a HIGH finding. All four `block_*` attributes must be `true`.
+
+3. **Lambda Function URLs with AuthType NONE**
+   Mechanism: `aws_lambda_function_url` with `authorization_type = "NONE"` exposes the Lambda
+   directly to the internet with no IAM authentication. Grep:
+   `grep -rn "authorization_type" . --include="*.tf" | grep -i "none"`.
+   Finding: Any match is CRITICAL unless the Lambda explicitly implements its own auth layer
+   with documented evidence.
+
+4. **EC2 Instance Metadata Service v1 (IMDSv1) Still Accessible**
+   Mechanism: IMDSv1 requires no session token, making it trivially reachable from any SSRF.
+   Grep: `grep -rn "http_tokens" . --include="*.tf" | grep -v "required"` plus check for
+   `aws_instance` resources missing `metadata_options` entirely.
+   Finding: Any instance without `http_tokens = "required"` and `http_put_response_hop_limit = 1`
+   is CRITICAL.
+
+5. **Cross-Account AssumeRole Without ExternalId Condition**
+   Mechanism: A trust policy allowing `sts:AssumeRole` from a foreign account principal without
+   `sts:ExternalId` condition enables the confused deputy attack — any AWS service in the trusting
+   account can assume the role. Grep:
+   `grep -rn "sts:AssumeRole" . --include="*.tf" --include="*.json" -A10 | grep -v ExternalId`.
+   Finding: Any cross-account trust without `ExternalId` condition is HIGH.
+
+6. **CloudTrail Multi-Region Trail Disabled or Trail Deleted**
+   Mechanism: A single-region CloudTrail misses global service events (IAM, STS, CloudFront).
+   An attacker deleting the trail has a 15-minute window of unlogged activity.
+   Grep: `grep -rn "is_multi_region_trail" . --include="*.tf" | grep "false"`.
+   Finding: `is_multi_region_trail = false` or absence of `enable_log_file_validation = true` is HIGH.
+
+7. **Security Group Ingress from 0.0.0.0/0 on Non-80/443 Ports**
+   Mechanism: SSH (22), RDP (3389), database ports (3306, 5432, 1433, 27017, 6379) open to the
+   internet provide direct attack surface. Grep:
+   `grep -rn "cidr_blocks.*0.0.0.0/0" . --include="*.tf" -B5 | grep -E "from_port|to_port"`.
+   Finding: Any non-HTTP/S port open to `0.0.0.0/0` is CRITICAL.
+
+8. **RDS Snapshot Publicly Restorable**
+   Mechanism: `aws_db_snapshot` with `shared_accounts = ["all"]` or `publicly_accessible = true`
+   on the RDS instance allows any AWS account to restore a full copy of the database.
+   Grep: `grep -rn "publicly_accessible" . --include="*.tf" | grep "true"`.
+   Finding: Any RDS instance or snapshot with `publicly_accessible = true` is CRITICAL.
+
+9. **KMS Key Rotation Disabled on Customer-Managed Keys**
+   Mechanism: Without annual key rotation, a compromised KMS key or HSM breach exposes all
+   historical ciphertext. Grep:
+   `grep -rn "enable_key_rotation" . --include="*.tf" | grep "false"` plus absence check.
+   Finding: Any CMK without `enable_key_rotation = true` is HIGH.
+
+10. **CodeBuild Environment Variable Secrets (Plaintext)**
+    Mechanism: Secrets in CodeBuild `environment_variable` blocks with `type = "PLAINTEXT"` appear
+    in CloudWatch Logs, build outputs, and AWS Console in cleartext. Grep:
+    `grep -rn "PLAINTEXT" . --include="*.tf" -B2 | grep -i "secret\|password\|token\|key\|api"`.
+    Finding: Any secret-like environment variable with `type = "PLAINTEXT"` is HIGH; use
+    `PARAMETER_STORE` or `SECRETS_MANAGER` type instead.
+
+11. **EKS Cluster Public API Endpoint Without CIDR Restriction**
+    Mechanism: `endpoint_public_access = true` with `public_access_cidrs = ["0.0.0.0/0"]` exposes
+    the Kubernetes API server to brute force, credential stuffing, and CVE exploitation from anywhere.
+    Grep: `grep -rn "endpoint_public_access\|public_access_cidrs" . --include="*.tf"`.
+    Finding: Public endpoint without explicit CIDR allowlist (not `0.0.0.0/0`) is HIGH.
+
+12. **SNS / SQS Resource Policy Allowing Any Principal**
+    Mechanism: `"Principal": "*"` in an SNS topic or SQS queue resource policy with no
+    `aws:SourceAccount` or `aws:SourceArn` condition allows any AWS account to publish/subscribe.
+    Grep: `grep -rn '"Principal": "\*"' . --include="*.tf" --include="*.json" -A5 | grep -v Condition`.
+    Finding: Any match on SNS/SQS/Secrets Manager resource policy is HIGH.
+
+---
+
+## §POC-REQUIREMENT
+
+For every CRITICAL or HIGH finding in this domain:
+
+1. **Write the working PoC FIRST** — exact payload, exact CLI command, observed impact.
+   Example for IMDSv1 credential theft:
+   ```bash
+   # Step 1: Confirm IMDSv1 accessible (from SSRF-vulnerable app or compromised instance)
+   curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
+   # Expected output: role-name printed
+
+   # Step 2: Retrieve credentials
+   curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>
+   # Expected output: {"AccessKeyId":"...","SecretAccessKey":"...","Token":"...","Expiration":"..."}
+
+   # Step 3: Confirm scope of compromise
+   AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=... \
+     aws sts get-caller-identity
+   # Observed impact: full identity of instance role revealed; attacker can now call any API
+   # permitted by that role's attached policies
+   ```
+
+2. **Confirm the PoC reproduces the issue** — document the actual API response received.
+
+3. **Write the fix** — e.g., set `http_tokens = "required"` and `http_put_response_hop_limit = 1`
+   in the `metadata_options` block of the `aws_instance` resource.
+
+4. **Verify the PoC fails against the fix:**
+   ```bash
+   # After fix applied and instance refreshed:
+   curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
+   # Expected: 401 Unauthorized — confirms IMDSv2 enforcement working
+   ```
+
+5. **Record in findings JSON:**
+   ```json
+   {
+     "findingId": "AWS-IMDS-001",
+     "severity": "CRITICAL",
+     "exploitPoC": "curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE> returns live credentials",
+     "fixApplied": "http_tokens = required, hop_limit = 1",
+     "pocFailsPostFix": true
+   }
+   ```
+
+**PoC skipping = finding severity downgraded to MEDIUM automatically.**
+This is enforced by the orchestrator at findings merge time.
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately call `orchestration.update_agent_status` with `"CRITICAL_ESCALATION"` flag and
+halt normal scan progression when ANY of the following are discovered:
+
+1. **Live AWS credentials present in source code or git history** — any `AKIA`, `ASIA`, or
+   `AROA` prefixed string found in `.tf`, `.env`, `.json`, `.ts`, `.py`, or git log output.
+   The full run must pause; credentials must be rotated before analysis continues.
+
+2. **IAM policy granting `AdministratorAccess` to a public-facing service role** — e.g., a
+   Lambda function URL with `AuthType = NONE` whose execution role has `AdministratorAccess`.
+   This is a complete account takeover vector requiring immediate remediation.
+
+3. **S3 bucket containing production data confirmed publicly readable** — any `aws_s3_bucket`
+   where Block Public Access is disabled AND a `GetObject` action is permissible by `Principal: *`
+   in the bucket policy. Stop and escalate; data may already be exfiltrated.
+
+4. **CloudTrail logging disabled or deleted in all regions** — if the multi-region trail
+   is absent or `enable_logging = false`, the account has no forensic record of recent API calls.
+   Escalate immediately; this may indicate an active attacker covering tracks.
+
+5. **EKS cluster with `cluster-admin` ClusterRoleBinding to a service account in a non-system namespace** —
+   this grants full Kubernetes API access to any pod in that namespace, which combined with any
+   container escape CVE is a full cluster compromise path.
+
+6. **AWS SSO / IAM Identity Center permission set with `AdministratorAccess` assigned to more
+   than 5 users or a group containing external identities** — over-broad SSO permissions combined
+   with identity provider compromise (e.g., Okta breach) gives attackers admin access to every
+   account in the AWS Organization.
+
+7. **KMS key deletion scheduled with a pending window of less than 7 days** — active key deletion
+   may render encrypted production data permanently inaccessible; confirm this is authorized
+   and not an attacker performing destructive ransomware-style action.
+
+8. **AWS Organizations SCP absence** — if no Service Control Policies are attached to any OU,
+   individual account IAM policies are the only guardrail. Any account-level IAM misconfiguration
+   then has no organizational backstop. Escalate as an architectural CRITICAL.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in this domain that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Second-order / stored payload executed in different context | Scanner checks input context, not execution context | Store payload safely; trigger in separate request/session |
+| 2 | Unicode normalisation bypass | Regex filters run before normalisation; attacker uses homoglyphs or composed forms | Submit Ⅰ (U+2160) or ＜ (U+FF1C) variants of known-bad strings |
+| 3 | Polyglot payload active in multiple sinks simultaneously | Scanners test one injection class per payload | `'"><script>{{7*7}}</script><!--` — SQL + XSS + SSTI in one request |
+| 4 | Out-of-band exfiltration (DNS/HTTP callback) | Scanner looks for inline response difference; OOB leaves no visible trace | Use Burp Collaborator / interactsh; inject DNS lookup payload |
+| 5 | Race condition between check and use (TOCTOU) | Sequential scanners don't model concurrency | Send two simultaneous requests to the same state-changing endpoint |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to This Domain | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | Harvest-now-decrypt-later attacks active today; RSA/ECDSA keys signed today will be broken | Inventory all RSA/ECDSA usage; migrate long-lived data to ML-KEM (FIPS 203) |
+| AI-assisted adversaries at scale | 2025–2027 (active) | LLM-powered fuzzing finds 10× more edge cases; automated PoC generation | Assume attackers have LLM help; expand test surface to match |
+| EU AI Act full enforcement | 2026 | High-risk AI systems require mandatory conformity assessments | Classify all AI features against AI Act tiers now |
+| Post-quantum TLS migration deadline | 2028–2030 | Browser vendors will drop classical-only TLS connections | Begin TLS agility assessment; test hybrid key exchange |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | SBOM and SLSA attestation are becoming legally required | Achieve SLSA L2 minimum; generate CycloneDX SBOM per release |
+
+---
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in this domain, and what to build to close each gap.
+
+**Standard gaps that MUST be checked:**
+
+- **Second-order attack execution**: The storage request looks safe; only the retrieval+execution step is dangerous. Need: correlate write events with downstream read+execute events in the same SIEM query window.
+- **Timing-side-channel leakage**: No log event emitted; only observable as microsecond response-time variance. Need: per-endpoint p99 latency tracking with statistical anomaly detection.
+- **Low-and-slow credential stuffing**: Individually, each request is under rate limits. Need: behavioural baseline — flag accounts with geographically impossible velocity or device-fingerprint mismatch across authentication attempts.
+- **Insider exfiltration via legitimate process**: Authorised exports, reports, and data downloads that individually are permitted but collectively constitute data exfiltration. Need: data-volume anomaly detection — alert when a single user's data access volume exceeds 3× their 30-day baseline within 24 hours.
+- **Cross-agent attack chains**: Phase 1 finding A + Phase 1 finding B = CRITICAL chain invisible to either agent alone. Need: CISO orchestrator Phase 1 synthesis step — correlate all agent findings before Phase 2.
+
+**AWS-specific detection gaps:**
+
+- **CloudTrail `eventSource: s3.amazonaws.com` with `eventName: GetObject` at high volume**: CloudTrail data events for S3 are disabled by default and cost extra. Without them, bulk S3 exfiltration via `GetObject` is completely invisible. Enable S3 data events on all buckets containing sensitive data and alert on > 1000 `GetObject` calls in 5 minutes from a single principal.
+- **AssumeRole chains crossing account boundaries**: A single CloudTrail event shows the AssumeRole call but not what the assumed role does in the target account. Need: CloudTrail aggregation across all accounts in the AWS Organization via CloudTrail Lake or a centralised S3 trail to correlate multi-account lateral movement.
+- **Lambda cold-start exfiltration**: An attacker who has injected code into a Lambda dependency (supply chain) can exfiltrate credentials during the cold-start init phase before the function handler runs. This does not generate application-layer logs. Need: Lambda extension-level telemetry or eBPF-based network monitoring at the Lambda execution environment level.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any attack class clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [N files] | [patterns used] | CLEAN`
+- `CHECKED: [N files] | [patterns used] | [N findings, all fixed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [{ "class": "IAM Privilege Escalation", "filesReviewed": 23, "patterns": ["iam:PassRole", "iam:CreatePolicy", "iam:AttachRolePolicy"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["IMDSv1 Access: http_tokens pattern searched across 23 .tf files — 0 non-required instances"],
+    "uncoveredReason": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "aws-penetration-tester",
+  "resolved": true,
+  "remediationTemplate": "one-line description of what was done",
+  "falsePositive": false
+}
+```
+Call `security.record_outcome` with this payload so the routing engine learns which agent resolves each finding class most successfully. If a finding is a false positive, set `falsePositive: true` — this prevents the false-positive pattern from being routed here again.
+
+---
+
+## §AUTOHARDEN-RULESET
+
+Your authoritative threat-rule set for AWS config drift is the registry at
+`defaults/cloud-controls/aws.json`. It enumerates AWS FSBP + CIS AWS Foundations rules as
+detections paired with auto-remediations. Treat each rule as an attack surface, not a compliance
+checkbox: if a resource matches the insecure pattern it is exploitable — detect it, then fix it.
+
+### Execution
+
+1. Run the detect-and-remediate engine over the working tree:
+   `npx -y security-mcp@latest autoharden` (add `--dry-run` to preview). It rewrites Terraform in
+   place with the hardened config for every `set-attr`, `insert-block`, and `companion-resource`
+   rule, and reports `[MANUAL]` rules it could not safely auto-apply.
+2. Every auto-applied fix is verified by re-running that rule's own detector against the mutated
+   file before being kept; an edit that does not clear the finding is reverted and reported manual.
+3. For `[MANUAL]` rules (runtime-state like GuardDuty/root-MFA, or a 0.0.0.0/0 CIDR replacement that
+   needs a human-chosen allowlist), apply the emitted snippet via your existing inline-fix workflow.
+4. The read-only PR gate (`security.run_pr_gate` → the `cloud-controls` check) emits the same rules
+   as findings without mutating files — use it to confirm a clean tree post-fix.
+
+### Rule record contract (each entry in aws.json)
+
+- `ruleId` — also the gate Finding id
+- `threat` — the attack the misconfig enables (the "why")
+- `frameworks` — e.g. ["AWS FSBP EC2.8", "CIS AWS Foundations Benchmark 5.6"] — context labels
+- `detect` — { target, resourceType, forbid?, require?, requireCompanionType? }
+- `remediate` — { strategy, ensure? | companion? | snippet? }
+
+### Worked example (auto-applied)
+
+`AWS_EC2_IMDSV2_REQUIRED` — threat: SSRF → IMDSv1 → instance-profile credential theft. A bare
+`aws_instance` with no `metadata_options` is rewritten to add
+`metadata_options { http_tokens = "required", http_put_response_hop_limit = 1 }`; the detector then
+re-scans the block and finds it clean.
+
+### Coverage discipline (ties into §ZERO-MISS-MANDATE)
+
+You CANNOT declare AWS clean without running the full ruleset. For each rule output one of:
+`APPLIED: <ruleId> | <file> | re-scan CLEAN`, `MANUAL: <ruleId> | snippet emitted | <reason>`,
+`CLEAN: <ruleId> | 0 violations`, or `N/A: <ruleId> | not applicable: <evidence>`. Silent skip =
+FAILED COVERAGE. To extend coverage, add a record to `defaults/cloud-controls/aws.json` — no code
+change required; the engine consumes it on next run.