security-mcp 1.1.3 → 1.3.1

package/skills/git-history-secret-scanner/SKILL.md

@@ -180,3 +180,109 @@ service-account*.json
 - `requiredActions`: ordered rotation steps
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true if finding goes beyond the SKILL.md mandate
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "Active credential found in git history; may still be valid for lateral movement", "exploitHint": "Test credential against provider API before rotation completes; enumerate what resources it grants access to" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "RSA-2048 private key", "location": "commit abc1234, file keys/deploy.pem" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Cloud provider key found in history; check CloudTrail/audit logs for usage since commit date", "escalationPath": "Key may grant IAM privilege escalation if attached policy is overly broad" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI DSS Req 8.3.2", "SOC 2 CC6.1", "NIST IA-5"], "releaseBlock": true }]
+  }
+}
+```
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **AI-Assisted Mass Credential Harvesting via LLM-Powered Repo Mining (ATT&CK T1552.001 + T1213.003):** Threat actors deploy fine-tuned LLMs (e.g., models trained on leaked GitHub data) to scan millions of public repositories in hours, extracting secrets from deleted commits, squash merges, and binary blobs that regex-only tools miss. Active tooling includes `trufflehog`-derivatives augmented with GPT-4 for contextual secret classification. Test by: run `trufflehog git --concurrency=10 --json file:///path/to/repo` with `--only-verified` flag disabled — compare LLM-classified findings against regex-only baseline; any delta represents secrets AI finds that your CI gate misses. Finding threshold: any credential classified as "likely valid" by entropy + context analysis that was not flagged by gitleaks constitutes a detection gap requiring rule addition.
+
+- **Harvest-Now-Decrypt-Later Attack on Historical RSA/ECDSA Keys (NIST IR 8413, CNSA 2.0 transition):** Nation-state actors are archiving full git object databases from public and semi-public repos today, targeting committed RSA ≤2048-bit and ECDSA P-256 private keys for retroactive decryption once a Cryptographically Relevant Quantum Computer (CRQC) is available (est. 2028–2033 per ODNI). Keys used for TLS, SSH deploy access, or code signing are highest risk. Test by: run `git log --all -p | grep -E "BEGIN (RSA|EC|DSA|OPENSSH) PRIVATE KEY" | wc -l` — any non-zero result is a CRQC-harvest finding. Cross-reference key bit length via `openssl rsa -text -noout < key.pem | grep "bit"`. Finding threshold: any RSA key ≤3072-bit or ECDSA key on P-256/P-384 ever committed to history requires immediate revocation and migration to ML-KEM-768 or Ed25519.
+
+- **Supply Chain Secret Injection via Dependency Commit History (ATT&CK T1195.001, incident: event-stream 2018):** Malicious maintainer takeovers result in secrets (npm tokens, PyPI credentials, CI webhook URLs) being briefly committed to a transitive dependency's git history — visible to anyone who clones with full history before the remediation commit. The event-stream incident exposed that millions of projects inherited a compromised package; a similar attack today would target GitHub Actions token leaks in `.github/workflows/` commit history. Test by: for each direct dependency, run `git -C $(npm pack --dry-run 2>/dev/null | grep "directory:" | awk '{print $2}') log --all -p -- "**/.env" "**/*.token" 2>/dev/null | head -50`; also check the dependency's GitHub commit history via API for any commit containing `GITHUB_TOKEN` or `NPM_TOKEN` in the past 90 days. Finding threshold: any secret pattern found in a transitive dependency's commit history warrants a vendor security advisory and dependency replacement evaluation.
+
+- **Git Reflog and Dangling Object Persistence After `--force` Push and History Rewrite (CVE-2024-32002 context, ATT&CK T1070.004):** Organizations that attempt to remediate a leaked secret via `git filter-repo` or `BFG Repo Cleaner` often leave the secret accessible for 30–90 days in reflogs and dangling objects on every developer machine that cloned before the rewrite. GitHub and GitLab also retain deleted content in their object storage for varying periods. The CVE-2024-32002 class of git hook injection vulnerabilities demonstrates that git's object store is a persistent attack surface. Test by: `git fsck --unreachable --no-reflogs 2>/dev/null | grep blob | awk '{print $3}' | xargs -I{} sh -c 'git cat-file -p {} 2>/dev/null | grep -Ei "(password|api.?key|secret|token|AKIA)"'` — also check `git reflog --all --format="%H %gd %gs" | head -200` for refs pointing to commits removed from branch tips. Finding threshold: any secret found in unreachable objects means the history rewrite was incomplete and the secret must still be rotated.
+
+- **CI/CD Secret Leakage via GitHub Actions Debug Logging and Audit Log API (ATT&CK T1552.004, regulatory: EU CRA Article 13):** GitHub Actions `ACTIONS_STEP_DEBUG=true` logs and the GitHub Audit Log API (`/orgs/{org}/audit-log`) can expose secrets printed during workflow runs — these are stored separately from the git object model and not scanned by standard git history scanners. The EU Cyber Resilience Act (CRA, effective 2027) mandates that manufacturers of digital products demonstrate secret hygiene across the full software supply chain including CI artifacts. Test by: query `gh api /repos/{owner}/{repo}/actions/runs --jq '.[].id' | head -20 | xargs -I{} gh api /repos/{owner}/{repo}/actions/runs/{}/logs` and pipe through `grep -Ei "(AKIA|password|secret|token)"` on the downloaded ZIP; separately run `gh api /orgs/{org}/audit-log?phrase=secret&include=all` to check for audit events referencing secret exposure. Finding threshold: any secret value appearing in CI logs requires immediate rotation and constitutes a CRA Article 13 compliance finding if the product is EU-market software.
+
+- **Semantic Secret Obfuscation Bypassing Regex Scanners — Split Secrets and Variable Concatenation (Research: "How Bad Can It Git?" USENIX Security 2019):** The USENIX 2019 study found that 4.8% of GitHub secrets used obfuscation techniques including string splitting across variables, base64 encoding, and hex encoding to evade automated detection. A secret stored as `KEY_PART1 = "AKIA4S3CUR"` + `KEY_PART2 = "ITY_EXAMPLE"` with runtime concatenation is invisible to all regex-based scanners. AI-assisted obfuscation is accelerating this pattern. Test by: run Shannon entropy analysis across all string literals in git history using `trufflehog git --json file:///path/to/repo | jq '.SourceMetadata.Data | select(.entropy > 4.2)'`; also apply custom heuristics: `git log --all -p | grep -E '(concat|join|\.join|format|sprintf|f").*[A-Z0-9]{8,}'` to find assembled string patterns. Supplement with `semgrep --config=p/secrets` which has dataflow-aware rules that follow variable assignments across lines. Finding threshold: any string with Shannon entropy > 4.2 that assembles into a 20+ character value matching a known credential format (AWS, GCP, Stripe, GitHub) is a confirmed finding regardless of whether it appears as a single literal.
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in git history secret scanning that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Secret committed inside a binary blob (compiled artifact, PDF, image EXIF) checked into git | Regex scanners operate on text diff output; binary blobs show as `Binary files differ` | Run `git log --all --diff-filter=A -- "*.pdf" "*.png" "*.jar" "*.zip"` and extract with `git show <hash>:<path>` piped through `strings` then grep |
+| 2 | Secret present only in a merge commit or orphan ref (PR head refs, CI internal refs) | `git log --all -p` may miss squash-merge parents and orphan branches like `refs/pull/*/head` | Run `git log --all --merges -p` separately; also scan `git for-each-ref --format="%(refname)" refs/` and fetch all remote refs including PR heads |
+| 3 | Secret embedded in a git note or commit message body, not in file content | Scanners scan file diffs; git notes and commit message bodies are separate objects not shown in `git log -p` | Run `git log --all --format="%B" | grep -Ei "(password|api.?key|secret|token)"` and `git notes list | xargs -I{} git notes show {}` |
+| 4 | Credential in a stash or dangling object unreachable from any ref | `git log --all` only walks reachable objects; stashes and dangling blobs survive `git gc` until explicit expiry | Run `git fsck --unreachable --no-reflogs 2>/dev/null | grep blob` then `git cat-file -p <hash>` on each unreachable blob; also check `git stash list` |
+| 5 | Short-lived branch deleted before scanner runs — commit still reachable via reflog for 30–90 days | Deleted branches remove the ref but the commits remain in reflog until expiry | Run `git reflog --all` to enumerate all reflog entries; scan commits reachable only via reflog with `git log $(git reflog --all --format="%H")` |
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that defences designed today must account for in the context of git history secrets.
+
+| Threat | Est. Timeline | Relevance to Git History Secrets | Prepare Now By |
+|--------|--------------|----------------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | RSA/ECDSA private keys committed to git history are harvestable today; a CRQC will break them retroactively — harvest-now-decrypt-later is active | Inventory all RSA/ECDSA private keys ever committed; revoke and replace with ML-KEM / Ed25519 minimum; treat any historical RSA key as already compromised by 2030 |
+| AI-assisted credential harvesting at scale | 2025–2027 (active) | LLM-powered scanners trawl public repos and extract secrets from history 10x faster than grep; attackers already use this | Assume any public repo with historical secrets is already harvested; rotation is urgent, not eventual |
+| GitHub / GitLab API caching of deleted content | 2025+ (active) | Provider APIs may cache blob content even after `git filter-repo` rewrites; some cached views persist | Never rely on history rewrite alone; always rotate; request provider-side cache purge for critical secrets |
+| Mandatory SBOM + build provenance traceability (US EO 14028 / EU CRA) | 2025–2026 (active) | Auditors will request git provenance; secrets in history become discoverable during SBOM audits and supply-chain due diligence | Achieve clean git history before SBOM audits begin; run this scanner in CI on every PR |
+| Federated identity replacing long-lived tokens | 2026–2028 | OIDC / workload identity federation eliminates static API keys; repos still holding historical static keys become compliance debt | Migrate to short-lived OIDC tokens now; historical static keys in git become SOC 2 CC6.1 and PCI DSS 4.0 Req 8.6 findings |
+
+## §DETECTION-GAP
+
+What current git history scanning CANNOT detect, and what to build to close each gap.
+
+**Standard gaps that MUST be checked:**
+
+- **Encrypted or base64-encoded secrets**: A secret encoded as base64 or AES-encrypted before commit looks like random noise to regex scanners. Need: entropy analysis (Shannon entropy > 4.5 on a 40+ character string is a strong signal) — run `trufflehog git --entropy` or implement a custom high-entropy detector alongside pattern matching.
+- **Secrets committed as part of test fixtures that were later promoted to production**: Scanner marks them low-severity because of `test_` / `fake_` prefix. Need: cross-reference all test-labelled credentials against the live secrets manager; if any match, escalate to CRITICAL regardless of naming convention.
+- **Secrets that were committed, rotated, and the rotation itself committed back**: Scanner finds the old value but not whether a new value is equally weak or also in history. Need: track the full lifecycle — flag any credential that appears in more than one distinct commit value as a rotation-audit finding.
+- **Binary and LFS-tracked files containing secrets**: `git-lfs` objects are stored externally; `git log -p` never shows their content. Need: enumerate all LFS pointers (`git lfs ls-files --all`), download each object, and run regex + entropy scan on the raw content.
+- **Orphan commits reachable only through CI/CD system's internal ref store**: CI systems clone repos with additional refs (`refs/remotes/pull/*/merge`) not mirrored in local clones. Need: clone with `--mirror` or use the provider API to enumerate all refs, including internal CI refs, before scanning.
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any secret class clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [N commits] | [patterns used] | CLEAN`
+- `CHECKED: [N commits] | [patterns used] | [N findings, all actioned]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+**Mandatory secret classes to attest:**
+
+| Class | Canonical Pattern / Tool |
+|-------|--------------------------|
+| AWS credentials (AKIA*, secret access key) | gitleaks built-in + `AKIA[0-9A-Z]{16}` |
+| Private keys (RSA / EC / DSA / OpenSSH) | `BEGIN .* PRIVATE KEY` |
+| Environment files (.env, .env.*) | `git log --all -- "**/.env" "**/.env.*"` |
+| Database connection strings | `(postgres\|mysql\|mongodb\|redis)://[^:]+:[^@]+@` |
+| API keys / tokens (generic high-entropy) | trufflehog entropy scan, Shannon > 4.5 on 40+ chars |
+| Binary blobs and LFS objects | `git fsck` + `strings` on unreachable blobs |
+| Git notes and commit message bodies | `git log --all --format="%B"` |
+| Dangling / unreachable objects | `git fsck --unreachable` |
+| Orphan refs (PR heads, reflog) | `git for-each-ref refs/` + `git reflog --all` |
+| Stashed changes | `git stash list` |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "AWS Credentials", "commitsReviewed": 1247, "patterns": ["AKIA[0-9A-Z]{16}", "gitleaks aws-access-key-id"], "result": "CLEAN" },
+      { "class": "Private Keys", "commitsReviewed": 1247, "patterns": ["BEGIN .* PRIVATE KEY"], "result": "2 findings — both keys revoked, rotation checklist generated" }
+    ],
+    "commitsReviewed": 1247,
+    "refsScanned": ["refs/heads/*", "refs/remotes/*", "refs/stash", "reflog"],
+    "blobsChecked": 34,
+    "negativeAssertions": [
+      "AWS Credentials: gitleaks + regex across 1247 commits — 0 matches",
+      "Database connection strings: regex across 1247 commits — 0 matches"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```

package/skills/iam-privesc-graph-builder/SKILL.md

@@ -214,3 +214,155 @@ If internet permitted:
 - `requiredActions`: ordered action list
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true if finding goes beyond the SKILL.md mandate
+- `intelligenceForOtherAgents`: cross-agent intelligence block (see schema below)
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [
+      {
+        "type": "HIGH_VALUE_TARGET",
+        "description": "Role with iam:PassRole + ec2:RunInstances reachable by app identity",
+        "exploitHint": "Launch EC2 with admin instance profile via RunInstances API, retrieve credentials from instance metadata service"
+      }
+    ],
+    "forCryptoSpecialist": [
+      {
+        "type": "CRYPTO_WEAKNESS_REFERENCE",
+        "algorithm": "KMS key policy with Principal:* allows unauthenticated decrypt",
+        "location": "infra/kms.tf"
+      }
+    ],
+    "forCloudSpecialist": [
+      {
+        "type": "SSRF_TO_CLOUD_CHAIN",
+        "ssrfLocation": "Any SSRF surface in the app layer",
+        "escalationPath": "SSRF → IMDSv1 at 169.254.169.254 → instance profile credentials → iam:PassRole → AdministratorAccess"
+      }
+    ],
+    "forComplianceGrc": [
+      {
+        "type": "COMPLIANCE_BLOCKER",
+        "frameworks": ["PCI DSS Req 7.2", "SOC 2 CC6.3", "NIST AC-6"],
+        "releaseBlock": true
+      }
+    ]
+  }
+}
+```
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **AI-Assisted IAM Policy Fuzzing via LLM Enumeration (ATT&CK T1069.003 — Cloud Groups):** LLM-powered tools such as PMapper-AI and custom GPT-4-based harnesses now enumerate all permutations of dangerous IAM action combinations (e.g., any two-action path reaching `iam:CreatePolicyVersion` + `iam:SetDefaultPolicyVersion`) faster than any human auditor. Test by: run `python3 -m pmapper graph create && python3 -m pmapper analysis --privesc` against a live AWS account or mocked policy set; flag any path reachable by a non-admin identity in under 3 hops. Finding threshold: any escalation path with probability > 0 is a finding — PMapper outputs this as `True` in the `is_admin` column.
+
+- **Harvest-Now-Decrypt-Later Against KMS-Wrapped IAM Credentials (Post-Quantum / NIST SP 800-208):** Secrets encrypted today under RSA-2048-wrapped KMS data keys (the default for many SSM Parameter Store and Secrets Manager entries) will be decryptable by a Cryptographically Relevant Quantum Computer (CRQC) estimated 2028–2032. An attacker with current `kms:Decrypt` or `secretsmanager:GetSecretValue` access can exfiltrate ciphertext now for future decryption. Test by: enumerate all KMS CMKs with `aws kms list-keys`; for each, run `aws kms describe-key` and flag any key using `RSA_2048` or `ECC_NIST_P256` key spec instead of `SYMMETRIC_DEFAULT` (AES-256-GCM) or ML-KEM-backed HSM. Finding threshold: any asymmetric CMK used for data-at-rest encryption of long-lived secrets is a finding.
+
+- **OIDC Wildcard Sub-Claim Exploitation in CI/CD Role Assumption (ATT&CK T1552.001, GitHub Security Advisory GHSA-2j6j-wq87-g8vm):** GitHub Actions OIDC trust policies using glob patterns such as `repo:myorg/*:*` on the `sub` condition key allow any repository fork or any branch within the org to assume the cloud role. This was demonstrated in the 2023 Reviewdog supply-chain incident where a compromised GitHub Action could satisfy a wildcard org-level OIDC claim. Test by: grep all IAM trust policies for `token.actions.githubusercontent.com:sub` conditions containing `*`; attempt `AssumeRoleWithWebIdentity` with a synthesized JWT whose `sub` is `repo:myorg/attacker-fork:ref:refs/heads/main`. Finding threshold: any OIDC trust policy where a fork or non-protected branch satisfies the condition is a CRITICAL finding.
+
+- **Confused Deputy Attack via AWS Service-Linked Roles (CVE-2023-35165 — AWS CDK Bootstrap Role Escalation):** AWS CDK bootstrap creates a `cdk-hnb659fds-cfn-exec-role` with `AdministratorAccess`. Any identity with `cloudformation:CreateStack` + `iam:PassRole` referencing this role gains full admin access — the service (CloudFormation) acts as a confused deputy executing on behalf of the low-privilege caller. This exact vector was the root of CVE-2023-35165. Test by: grep for `cfn-exec-role` or `cdk-*-cfn-exec-role` ARNs in Terraform and CDK outputs; verify whether any non-admin identity has both `cloudformation:CreateStack` and `iam:PassRole` to that ARN. Finding threshold: any reachable path from a developer/CI role to `cfn-exec-role` with AdministratorAccess is CRITICAL.
+
+- **Supply-Chain IAM Escalation via Unsigned Terraform Module Sources (SLSA L0 — ATT&CK T1195.001):** Terraform IAM modules sourced from public registries (`registry.terraform.io`) or unpinned GitHub refs (`github.com/org/module?ref=main`) have no cryptographic integrity guarantee. A compromised module can inject an additional `aws_iam_policy_attachment` resource that grants attacker-controlled principals elevated permissions — undetected until `terraform plan` output is carefully reviewed. Test by: grep all `module` blocks in `*.tf` for sources not pinned to a full commit SHA (e.g., `?ref=v1.2.3` is insufficient — only a 40-char SHA is pinless-safe); run `terraform plan -out=plan.bin && terraform show -json plan.bin | jq '.resource_changes[] | select(.type | startswith("aws_iam"))'` and diff against expected IAM resources. Finding threshold: any IAM-creating module sourced without a pinned SHA is a HIGH supply-chain finding.
+
+- **Cross-Cloud Workload Identity Federation Privilege Escalation (ATT&CK T1550.001 — Use Alternate Authentication Material):** AWS↔GCP Workload Identity Federation and Azure↔AWS federation chains create IAM escalation paths that single-cloud scanners miss entirely. A GCP service account with `roles/iam.workloadIdentityUser` on an AWS role pool can assume an AWS role; if that AWS role has `iam:PassRole`, the attacker crosses cloud boundaries to reach AWS admin. This pattern was highlighted in the 2024 Wiz research "Cross-Cloud Attacks." Test by: enumerate all `google_iam_workload_identity_pool_provider` resources and map their `aws` attribute `account_id` + `role_arn`; cross-reference the target AWS role's permissions for dangerous IAM actions. Finding threshold: any GCP-to-AWS or Azure-to-AWS federation path where the AWS target role holds privilege-escalation-capable actions (`iam:PassRole`, `iam:CreatePolicyVersion`, etc.) is a CRITICAL cross-cloud finding.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 IAM privilege escalation attack cases that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | **Multi-hop cross-account role chaining** | Scanners inspect each account's IAM in isolation; the escalation only completes when role A in account 1 assumes role B in account 2 which has `AdministratorAccess` in account 3 | Map all `sts:AssumeRole` targets in trust policies; follow chains across account boundaries; flag any path that reaches an admin role in any account within 3 hops |
+| 2 | **Service-linked role confused deputy** | The service-linked role itself is AWS-managed and appears "safe"; scanners don't model the service's own API as an attacker-controlled code-execution surface | Check if any service (e.g. Lambda, Glue, SageMaker) can be invoked by a low-privilege identity AND has a service-linked role with cross-resource permissions; enumerate service API calls that trigger privileged backend actions |
+| 3 | **`iam:SetDefaultPolicyVersion` on existing policy** | Scanners flag `iam:CreatePolicyVersion` but miss `iam:SetDefaultPolicyVersion` — an attacker creates a dormant `*` version earlier, then flips it active | Grep for `iam:SetDefaultPolicyVersion` in any Allow statement without a resource constraint; check existing policies for non-default versions with broader permissions |
+| 4 | **Condition key bypass via wildcarded `aws:RequestedRegion`** | IAM condition-based restrictions appear locked to a region or VPC; scanner evaluates the stated condition as effective; attacker calls the same API from the unconstrained global endpoint | For every `Condition` block using `aws:RequestedRegion` or `aws:SourceVpc`, verify the corresponding service actually enforces that condition; Services like IAM and STS ignore `aws:RequestedRegion` |
+| 5 | **OIDC / Workload Identity federation overmatch** | CI/CD OIDC trust policies use glob patterns on `sub` claim (e.g., `repo:myorg/*:*`) allowing any branch/repo in the org to assume the role | Grep all OIDC trust policies for wildcard `sub` or `aud` claim conditions; flag any trust policy where a fork, branch, or third-party workflow could satisfy the claim condition |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that IAM privilege escalation defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to IAM/Cloud | Prepare Now By |
+|--------|--------------|------------------------|----------------|
+| **AI-assisted IAM policy fuzzing** | 2025–2027 (active) | LLM-powered tools enumerate all permutation combinations of dangerous IAM actions automatically — manual review cadence is too slow | Implement automated least-privilege analysis in CI (e.g., iamlive, Cloudsplaining) as a merge gate; don't rely on periodic manual audits |
+| **Cryptographically Relevant Quantum Computer (CRQC) — KMS key exposure** | 2028–2032 | Harvest-now-decrypt-later: secrets encrypted today under RSA-wrapped KMS data keys will be decryptable; attacker who can call `kms:Decrypt` now stores ciphertext for future decryption | Inventory all KMS key usage; migrate CMKs to ML-KEM-backed HSM; enforce `kms:Decrypt` on specific resources only |
+| **Cross-cloud identity federation attacks** | 2025–2026 (active) | Workload Identity Federation (AWS↔GCP, Azure↔AWS) creates new privilege escalation paths between cloud boundaries that single-cloud IAM scanners miss | Treat all OIDC/WIF trust policies as critical attack surface; graph IAM edges across cloud providers |
+| **Mandatory SBOM + SLSA for cloud infrastructure code** | 2025–2026 (active) | US EO 14028 and EU CRA require provenance for infrastructure-as-code artefacts; unsigned Terraform modules or CDK packages used in IAM definitions become a supply-chain escalation vector | Pin all Terraform module sources to verified SHAs; generate SLSA L2 provenance for IaC pipelines; reject unsigned CDK constructs |
+| **AWS IAM Condition key expansion** | Ongoing | AWS continuously adds new global condition keys (e.g., `aws:PrincipalOrgID`, `aws:PrincipalTag`); policies written without these controls will be bypassed by new principal types that didn't exist at policy-write time | Monitor AWS IAM release notes; re-evaluate all `Deny` policies quarterly against new condition key additions |
+
+---
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in IAM privilege escalation, and what to build to close each gap.
+
+**Standard gaps that MUST be checked:**
+
+- **Dormant policy version activation**: CloudTrail logs `SetDefaultPolicyVersion` as a low-noise IAM event mixed with routine policy management. SIEM rules rarely correlate "version set to non-latest" with a pre-existing `*` permissions version. Need: alert on `SetDefaultPolicyVersion` where the activated version's `Action` array contains `*` or includes any item from the dangerous-action list.
+
+- **Cross-account role chain traversal**: CloudTrail in account A logs `AssumeRole` for role B in account B. Account B's CloudTrail logs account A's principal assuming role B. Neither account alone sees the full chain. Need: aggregate CloudTrail across all accounts into a central SIEM; build a graph query correlating `AssumeRole` events by source principal across account boundaries within a 15-minute window.
+
+- **OIDC federation token issuance from unexpected branches**: GitHub Actions OIDC tokens are short-lived and leave minimal trace in the cloud control plane. A workflow running on a fork or an unexpected branch satisfying a wildcard `sub` claim will generate a valid `AssumeRoleWithWebIdentity` call indistinguishable from a legitimate CI job. Need: alert on `AssumeRoleWithWebIdentity` where the `sub` claim contains a branch/ref not in an approved allowlist.
+
+- **Service-linked role lateral movement via service API**: When an attacker calls `lambda:InvokeFunction` or `glue:StartJobRun`, the resulting execution uses the service-linked or execution role — the attacker's own identity is only in the initial API call. CloudTrail shows the attacker's `InvokeFunction` but subsequent S3/DynamoDB calls appear under the Lambda execution role. Need: correlate invocation events with downstream resource-access events within the same invocation ID using CloudTrail `requestParameters.logStreamName` or X-Ray trace IDs.
+
+- **Permission boundary absence on dynamically created roles**: `iam:CreateRole` calls without `PermissionsBoundary` in the request are individually valid API calls. No AWS Config rule fires by default. Need: AWS Config rule `iam-no-inline-policy` is insufficient; deploy a custom Config rule or SCP that denies `iam:CreateRole` where `PermissionsBoundary` is absent.
+
+- **Cross-agent attack chains (IAM + SSRF)**: IAM agent finds a role with broad EC2 access; SSRF agent finds an SSRF in the app layer — neither flags the combined chain where SSRF reaches IMDSv1 to steal EC2 instance profile credentials that then use that broad EC2 role. Need: CISO orchestrator Phase 2 synthesis — correlate all agent findings before declaring the environment clean.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any IAM 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.
+
+**Mandatory IAM attack classes that must each produce a coverage line:**
+
+| Attack Class | Grep Patterns | Files to Search |
+|---|---|---|
+| Wildcard Action + Resource | `"Action":\s*"\*"`, `actions\s*=\s*\[.*\*` | All `*.tf`, `*.json`, `*.yaml` |
+| PublicPrincipal in resource policy | `"Principal":\s*"\*"`, `allUsers`, `AllUsers` | All IAM/bucket/key policy files |
+| Dangerous IAM actions (unconstrained) | `iam:PassRole`, `iam:CreateRole`, `iam:AttachRolePolicy`, `iam:SetDefaultPolicyVersion` | All policy files |
+| Cross-account trust without ExternalId | `sts:AssumeRole` in trust policies where Condition block is absent or lacks `sts:ExternalId` | Trust policy JSON/HCL |
+| OIDC wildcard sub claim | `"\*"` in OIDC trust policy Condition on `token.actions.githubusercontent.com:sub` | OIDC trust policies |
+| Missing permission boundary on created roles | `resource "aws_iam_role"` blocks without `permissions_boundary` attribute | Terraform `*.tf` |
+| IMDSv1 enabled (SSRF-to-credentials path) | `http_tokens\s*=\s*"optional"` or absence of `metadata_options` block | EC2 instance Terraform |
+| GCP primitive roles | `roles/owner`, `roles/editor` on service accounts | GCP IAM Terraform |
+| Kubernetes cluster-admin binding | `cluster-admin` in `ClusterRoleBinding` subjects | `*.yaml` K8s manifests |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      {
+        "class": "Wildcard Action + Resource",
+        "filesReviewed": 34,
+        "patterns": ["\"Action\": \"*\"", "actions = [\"*\"]"],
+        "result": "CLEAN"
+      },
+      {
+        "class": "iam:PassRole unconstrained",
+        "filesReviewed": 34,
+        "patterns": ["iam:PassRole"],
+        "result": "2 findings, both remediated — resource scoped to non-admin role ARNs"
+      }
+    ],
+    "filesReviewed": 34,
+    "negativeAssertions": [
+      "Wildcard Action+Resource: pattern searched across 34 policy files — 0 matches",
+      "PublicPrincipal: allUsers/Principal:* searched across 34 files — 0 matches"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```

package/skills/incident-responder/SKILL.md

@@ -190,3 +190,114 @@ Every finding must include:
 - `requiredActions`: ordered action list if not auto-remediated
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true if finding goes beyond the SKILL.md mandate
+
+Every findings JSON MUST also include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "Active attacker foothold or unpatched vector discovered during IR", "exploitHint": "Lateral movement path still open; pivot point identified in auth service" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "RSA-2048 signing key exposed in breach", "location": "config/signing-keys/" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Internal metadata endpoint accessed during incident", "escalationPath": "IMDSv1 → IAM role credential theft → S3 bucket exfiltration" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["GDPR Art.33", "HIPAA §164.408", "PCI DSS 12.10.5"], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **AI-Driven C2 Beaconing via LLM APIs (ATT&CK T1071.001 / T1102):** Threat actors in 2024–2025 (e.g., SCATTERED SPIDER, FIN7 derivatives) have used legitimate LLM API endpoints (OpenAI, Anthropic) as covert C2 channels — instructions embedded in prompts, exfiltration in completions — bypassing DLP tools that whitelist AI provider domains. Test by: run `grep -r "openai.com\|api.anthropic.com\|generativelanguage.googleapis.com" /var/log/proxy* /var/log/dns*` and flag any process not in the approved AI-consumer list making outbound calls to these endpoints; correlate with unexpected data volumes. Finding threshold: any non-approved process beaconing to LLM APIs at intervals consistent with C2 (60–300s).
+
+- **Harvest-Now-Decrypt-Later against TLS Sessions (NIST PQC / CRQC Timeline):** Intercepted TLS 1.2/1.3 sessions using RSA or ECDHE key exchange are being archived by nation-state actors for future decryption once a Cryptographically Relevant Quantum Computer arrives (estimated 2028–2032). Long-retention data (PII, financial records, health data) exfiltrated today becomes plaintext then. Test by: audit TLS cipher suite negotiation in production — `openssl s_client -connect host:443 2>/dev/null | grep "Cipher is"` — and flag any non-PQC-hybrid suite for data classified as sensitive beyond 2030. Finding threshold: any service transmitting regulated data using only classical key exchange without a hybrid ML-KEM (FIPS 203) wrapper.
+
+- **SolarWinds-Style Build Pipeline Injection (ATT&CK T1195.002 / SLSA Level 0):** The SolarWinds SUNBURST incident (CVE-2020-10148) demonstrated that unsigned build artifacts and compromised CI runners allow attackers to inject malicious code that survives eradication of the application layer. During IR, analysts focus on app servers and miss the CI/CD plane entirely. Test by: compare SHA-256 hashes of deployed binaries against the artifact registry's signed provenance (`cosign verify-blob --bundle <bundle> <artifact>`); enumerate all GitHub Actions runners and self-hosted agents for unexpected processes (`ps aux` snapshot vs. baseline). Finding threshold: any deployed artifact whose hash cannot be verified against a signed SLSA provenance attestation.
+
+- **OAuth Consent Grant Persistence Post-Credential-Rotation (ATT&CK T1550.001):** Documented in the Lapsus$ compromise of Microsoft (2022) and Okta (2022) — after password rotation and MFA reset, attacker-created OAuth app consent grants remained active, giving persistent read/write access to email, files, and calendar. Test by: during eradication, run `az ad app list --filter "startswith(displayName,'<unknown>')"` (Azure), `gcloud auth application-default print-access-token` scope audit (GCP), or GitHub `GET /user/installations` to enumerate all OAuth app grants on affected accounts; revoke any grant not in the approved app inventory. Finding threshold: any OAuth app grant to an account involved in the incident that is not in the approved third-party app registry.
+
+- **EU AI Act Art. 73 Mandatory Incident Reporting for High-Risk AI (Regulatory — enforcement 2026):** Under the EU AI Act (Regulation 2024/1689), providers of high-risk AI systems (credit scoring, HR, critical infrastructure, biometrics) must report serious incidents to national supervisory authorities within defined timelines analogous to GDPR Art. 33. IR playbooks built today that lack an AI-system-failure scenario will miss this obligation when enforcement begins. Test by: check whether the IR severity matrix contains an entry for "AI system output causing harm or fundamental rights violation"; verify the playbook names the applicable national market surveillance authority for AI. Finding threshold: any product classified as a high-risk AI system whose IR playbook contains no AI-Act-specific notification step.
+
+- **Memory-Only Ransomware Evading EDR (CVE-2024-21412 / ATT&CK T1620, T1486):** Akira, Black Basta, and LockBit 3.0 affiliates have deployed fileless ransomware variants that load entirely into memory via process hollowing or DLL injection, bypassing file-based EDR detection (documented in CISA AA24-131A). Traditional eradication (remove malicious files, reimaging) leaves no artefact to remove if encryption has already completed. Test by: during containment, capture a full memory dump of affected hosts before any shutdown (`winpmem_mini_x64.exe <output.raw>` on Windows, `LiME` on Linux) — scan the dump with Volatility3 `vol -f dump.raw windows.malfind` to identify injected regions; do not reboot before dump capture or forensic evidence is lost. Finding threshold: any P0 ransomware incident where a memory dump was not captured before system shutdown, constituting an evidence preservation gap.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 incident-response scenarios that automated detection and naive triage universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners/Analysts Miss It | Concrete Test |
+|---|-----------|-------------------------------|---------------|
+| 1 | Attacker-planted persistence surviving eradication | Eradication checklist targets known IOCs; novel persistence (cloud function, scheduled Lambda, OAuth app grant, cron injected via supply chain) is left behind | After "eradication complete", enumerate ALL: cron jobs, cloud scheduled tasks, OAuth app authorisations, startup scripts, and container entry points — compare against pre-incident baseline |
+| 2 | Credential re-use across services after rotation | Rotation remediates the compromised service but the same credential was reused elsewhere; attacker pivots to unrotated service | After any credential rotation, grep all secrets stores and CI/CD env vars for the rotated value; run `grep -r "<rotated-secret-prefix>" .env* .github/ infra/` across the full monorepo |
+| 3 | Log tampering / gap during dwell period | Attacker cleared or rate-limited logs; analyst sees a clean window and concludes no activity occurred | Verify log continuity — check for gaps in sequence numbers or timestamp skips >30s in authentication and audit logs; absence of logs during an active session IS evidence |
+| 4 | Insider-assisted incident where the "responder" is the threat actor | Standard IR assumes the responder is trusted; if an insider is involved, they may observe the investigation and destroy remaining evidence | Restrict IR war-room access to a need-to-know list verified by HR; treat all digital evidence as potentially tampered until chain-of-custody is established externally |
+| 5 | Notification clock triggered by discovery, not by breach date | GDPR Art.33 (72h) and most US state laws clock from when the organisation "becomes aware" — not when the breach occurred; delayed triage can inadvertently blow the legal deadline | Document the exact timestamp of first awareness (alert, ticket, internal report) at the start of triage; this timestamp is the legal T₀ regardless of when the breach actually happened |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that IR programmes designed today must account for.
+
+| Threat | Est. Timeline | Relevance to IR | Prepare Now By |
+|--------|--------------|-----------------|----------------|
+| AI-automated adversary post-exploitation | 2025–2027 (active) | LLM-driven C2 can enumerate, pivot, and exfiltrate faster than human responders can triage; dwell time measured in minutes, not days | Reduce MTTD target to <5 min via UEBA; pre-authorise automated network isolation for P0 severity without human approval gate |
+| Cryptographically Relevant Quantum Computer (CRQC) — harvest-now attacks | 2028–2032 (harvest active now) | Encrypted exfiltration captured today will be decrypted when CRQC arrives; long-lived PII, IP, and state secrets are at risk | Inventory all RSA/ECDSA-encrypted data at rest and in transit; prioritise migration of long-retention data to ML-KEM (FIPS 203) |
+| EU AI Act mandatory incident reporting for high-risk AI | 2026 (enforcement) | AI system failures causing harm become reportable incidents with their own 72h-style notification obligations | Classify all AI features against AI Act tiers; add AI-system-failure scenarios to the IR severity matrix and escalation chain |
+| Mandatory SBOM + SLSA provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | Supply chain compromise incidents will require SBOM-based blast-radius analysis; without SBOM, determining affected dependencies during an incident is days of manual work | Generate CycloneDX SBOM per release; include SBOM-diff step in the incident triage playbook to immediately scope supply chain exposure |
+| Ransomware-as-a-Service with data auction (double extortion) | 2025+ (escalating) | Threat actors exfiltrate before encrypting; containment alone is insufficient — data is already staged for auction | Add pre-encryption exfiltration detection to the P0 playbook: monitor for large outbound data transfers (>1GB in 10 min) and DNS exfiltration patterns alongside ransomware IOCs |
+
+---
+
+## §DETECTION-GAP
+
+What current IR monitoring and tooling CANNOT detect in this domain, and what to build to close each gap.
+
+**Gaps that MUST be checked in every IR engagement:**
+
+- **Attacker persistence in cloud control-plane**: CloudTrail/Audit Log shows API calls but not all persistence vectors (e.g., Service Account key generation, Lambda layer injection, ECR image replacement). Need: dedicated control-plane drift detection — baseline all IAM bindings, service account keys, and function configurations; alert on any delta not matching a recent deployment.
+- **Credential theft via memory scraping**: No file-system or network event is generated when credentials are read from process memory (e.g., LSASS dump, Kubernetes secret mounted in pod memory). Need: kernel-level process injection detection (eBPF-based); flag any process reading memory of another process outside known debug relationships.
+- **Log integrity during incident**: Logs may have been tampered with before IR begins; standard SIEM analysis assumes log fidelity. Need: cryptographic log signing (AWS CloudTrail log file validation, GCP CMEK-signed audit logs); during triage, verify log signatures before treating any log evidence as authoritative.
+- **OAuth app persistence post-account compromise**: An attacker who obtains OAuth consent grants retains access even after password rotation. Need: OAuth app audit as a standard eradication checklist item — enumerate and revoke all third-party OAuth grants for affected accounts, not just credentials.
+- **Cross-agent attack chains invisible to single-agent triage**: A P2 misconfiguration finding (Phase 1) plus a P2 anomalous access finding (Phase 2) may combine into a P0 chain invisible to either finding alone. Need: CISO orchestrator Phase 1 synthesis step — correlate all agent findings before Phase 2 to surface multi-hop chains.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any IR domain area clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [artifact or log source] | [method used] | CLEAN`
+- `CHECKED: [artifact or log source] | [method used] | [N findings, all addressed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+IR domains that MUST be attested:
+
+| Domain | Minimum Check |
+|--------|--------------|
+| Playbook existence | Glob for `runbook*`, `playbook*`, `incident*` in docs and repo root |
+| Kill-switch mechanism | Grep for `killSwitch`, `featureFlag`, `circuit.*breaker` across src |
+| Evidence preservation procedure | Check playbook for log-snapshot and chain-of-custody steps |
+| SIEM/alerting integration | Grep for monitoring provider SDKs and webhook configs |
+| Regulatory notification SLAs | Confirm playbook includes GDPR 72h, HIPAA 60d, state-law timelines |
+| Post-incident review template | Confirm 5 Whys / root-cause template exists |
+| Eradication persistence checklist | Confirm checklist covers cron, cloud functions, OAuth grants, startup scripts |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "IR Playbook Gap", "filesReviewed": 12, "patterns": ["runbook*", "playbook*", "incident*"], "result": "CLEAN" },
+      { "class": "Kill-Switch Absence", "filesReviewed": 84, "patterns": ["killSwitch", "featureFlag", "circuit.?breaker"], "result": "1 finding, remediated" }
+    ],
+    "filesReviewed": 84,
+    "negativeAssertions": [
+      "Evidence preservation: playbook contains log-snapshot step — confirmed present",
+      "Regulatory SLAs: GDPR 72h and HIPAA 60d both present in playbook Phase 5"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```

package/skills/injection-specialist/SKILL.md

@@ -60,3 +60,134 @@ Cover §13 input validation and §17 file handling completely.
 - Working exploit payload
 - Fixed code written inline
 - §13/§17 section covered
+
+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 }]
+  }
+}
+```
+
+---
+
+## §POLYGLOT — Single Payload, Multiple Sinks
+
+For every input that reaches multiple contexts, use a polyglot payload to detect multiple vulnerabilities simultaneously:
+
+- `'"><script>{{7*7}}</script><!--` — detects SQL injection + XSS + SSTI in one request
+- `; ls /tmp #` — detects OS command injection + SQL injection (comment-based)
+- `../../../etc/passwd` — detects path traversal in any file context
+
+For each input: run ALL injection classes, not just the obvious one. A form field that looks like it's only for names can be an SSTI sink in the email template renderer.
+
+## §HTTP-SMUGGLING
+
+1. Detect the proxy chain: identify nginx/HAProxy/ELB/Cloudflare versions from response headers and error pages
+2. Test CL.TE: send request with `Content-Length: 6` and `Transfer-Encoding: chunked` with body `0\r\n\r\nX` — observe if backend processes the prefix
+3. Test TE.CL: chunked body that overflows into the next request parsed by the backend
+4. Test H2.CL: HTTP/2 request with `content-length` header mismatching actual body size — downgraded to HTTP/1.1
+5. **Impact**: request queue poisoning lets attacker prepend arbitrary headers/body to the next user's request — steal cookies, hijack session, poison cache
+
+## §PROTO-CHAIN — Prototype Pollution to Privilege Escalation
+
+1. Identify every endpoint that merges user-controlled data into a plain JS object (_.merge, Object.assign, spread)
+2. Send payload: `POST /settings` with body `{"__proto__": {"isAdmin": true}}`
+3. Identify downstream authorization check that reads `options.isAdmin` or `user.role`
+4. Confirm: does a subsequent `GET /admin` return 200 instead of 403?
+5. **Client-side variant**: URL hash → `JSON.parse` → unsafe assign → `if (config.admin)` → privilege escalation in SPA
+6. **Required fix**: use `Object.create(null)` + Zod schema parse before every merge
+
+---
+
+## BEYOND SKILL.MD
+
+Domain-specific threats, techniques, and research that go beyond the standard injection checklist:
+
+- **CVE-2023-32731 (gRPC metadata injection)**: Attacker-controlled gRPC metadata headers are passed unsanitised to backend services, enabling header injection and SSRF via internal routing metadata — scanners only check HTTP/1.1 headers.
+- **CVE-2024-23897 (Jenkins arbitrary file read via CLI)**: The Jenkins CLI argument parser allows `@file` syntax in command arguments; combined with a crafted injection payload, attackers can read `/etc/passwd` or SSH private keys from the controller — path traversal disguised as CLI argument parsing.
+- **GraphQL batch query amplification + injection chain**: Batching `{"query":"..."}` arrays is rarely rate-limited; combine with SSTI payloads in fragment names or variable values to achieve RCE at GraphQL resolvers that call `eval()` or template-render user-supplied strings.
+- **Second-order SQL injection via ORM audit logs**: Many ORMs write SQL error messages (including malformed user input) to an audit table; if that table is later queried and displayed without sanitisation, the injection executes in a privileged admin context invisible to the original scanner.
+- **AI-generated code introducing `eval()` injection**: LLM-assisted development (Copilot, Cursor) frequently suggests `eval(userInput)` or `new Function(userInput)` patterns when building dynamic rule engines or formula parsers — audit every file touched by AI pair-programming tools for dynamic code execution sinks.
+- **LLM prompt injection via database content (indirect injection)**: An attacker stores a crafted prompt in a database field (e.g., user bio, product description); the application's AI assistant later retrieves and injects that field directly into a system prompt, causing the LLM to exfiltrate data or take unauthorised tool actions — the injection never touches HTTP input validation.
+- **Post-quantum harvest-now-decrypt-later targeting injection payloads**: Injection payloads in encrypted TLS sessions are being archived by nation-state adversaries for future decryption once CRQCs arrive (est. 2028–2032); injection findings in high-sensitivity contexts (auth tokens, PII fields) should be treated as already-compromised if RSA/ECDH is in use without hybrid ML-KEM.
+- **CRLF injection in HTTP/2 pseudo-headers**: HTTP/2 forbids CRLF in header values, but some reverse proxies (nginx < 1.25.3, HAProxy < 2.8) incorrectly forward CR-only (`\r`) sequences when downgrading to HTTP/1.1, enabling response splitting in contexts that appear safe under HTTP/2-only testing.
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "injection-specialist",
+  "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.
+
+---
+
+## §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.
+
+## §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": "SQL Injection", "filesReviewed": 47, "patterns": ["queryRaw", "string concat"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["SQL Injection: queryRaw pattern searched across 47 files — 0 matches"],
+    "uncoveredReason": {}
+  }
+}
+```