security-mcp 1.1.4 → 1.3.3

package/skills/cloud-infra-specialist/SKILL.md

@@ -23,6 +23,15 @@ SKILL.md §3, §4, and §7 are the minimum. You go beyond them.
 90% fixing — you write the Terraform/Kubernetes/Helm fixes directly.
 Every finding maps to a blast radius: what can an attacker reach if this misconfiguration is exploited?
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+As LEAD over the cloud/infra suite, the `infra.ts`, `iac.ts`, `k8s.ts`, `gitops.ts`, and `data-platform.ts` detection modules (`src/gate/checks/infra.ts` et al.) 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/Helm/K8s manifest/policy), not just advise:
+
+- **Cross-file / cross-finding reasoning the regex can't do:** walk the privilege-escalation graph across files — an `iam:PassRole` in one `.tf` + a permissive trust policy in another + an `automountServiceAccountToken: true` pod spec compose a node-credential-theft chain no single `infra.ts`/`k8s.ts` match sees. Map the full blast radius, not the one-line flag.
+- **Semantic / effective-state analysis:** a `0.0.0.0/0` SG rule may be neutered by a NACL, or an "encrypted" bucket may be readable cross-account via a confused-deputy resource policy; adjudicate the *effective* reachability across IaC + GitOps drift, not the declared intent.
+- **External corroboration:** WebSearch/WebFetch for current cloud-provider advisories, Kubernetes/CRI-O CVEs, CIS Benchmark updates, and HackTricks-Cloud privesc techniques relevant to the detected provider and cluster version.
+- **Apply & prove:** write the hardened Terraform/Rego/manifest inline, re-run the relevant `src/gate/checks/` module as a regression floor, then re-audit semantically; emit the LEARNING SIGNAL per fix and surface trade-offs (e.g. tighter egress vs. operational reachability) with the secure default.
+
 ## ACTIVATION PROTOCOL
 
 1. Call `orchestration.update_agent_status(agentRunId, "cloud-infra-specialist", "running")`
@@ -61,6 +70,17 @@ Every finding maps to a blast radius: what can an attacker reach if this misconf
 - **Terraform state security:** State file location, encryption, access controls — who can read
   the state file can reconstruct all secrets and resource configurations.
 
+## BEYOND SKILL.MD — DOMAIN-SPECIFIC THREAT INTELLIGENCE
+
+- **CVE-2022-0811 (CRI-O "cr8escape"):** A single `\n` in a pod spec annotation allows container escape to host root. Any cluster running CRI-O < 1.19.6 is fully compromised. Check `kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.containerRuntimeVersion}'` and cross-reference against CRI-O release history.
+- **CVE-2022-3172 (kube-apiserver SSRF):** The aggregated API server accepts redirects to internal endpoints. Attackers can pivot from the API server to EC2 instance metadata (169.254.169.254) or GCP metadata (metadata.google.internal), stealing node IAM credentials. Test with a custom APIService that redirects to IMDS.
+- **CVE-2023-44487 (HTTP/2 Rapid Reset — cloud load balancers):** All major cloud ALBs/NLBs are exposed until the provider patches the underlying Envoy/nghttp2 layer. Application-layer mitigations (request rate limits) do not substitute for infrastructure-layer patches. Verify provider advisory dates against cluster creation/update timestamps.
+- **Confused Deputy via AWS Resource-Based Policies (technique, no single CVE):** Cross-account S3 bucket policies or SNS topic policies that trust `*` with a condition on `aws:SourceAccount` can be bypassed if the trusted account has a confused deputy chain. Map every `Principal: "*"` with conditions using Cloudsplaining or Parlament.
+- **GCP Workload Identity Federation token theft (technique):** If a GCP service account is bound to a Kubernetes service account and the pod runs with `automountServiceAccountToken: true`, the projected OIDC token can be exchanged for a GCP access token by any process in the pod. The token lives in a well-known path (`/var/run/secrets/kubernetes.io/serviceaccount/token`) and is valid for 1 hour. Enumerate with `kubectl get pods -o yaml | grep automountServiceAccountToken`.
+- **AI-era threat — LLM-assisted IAM privilege escalation graph traversal:** Tools like PMapper and Cloudfox now have LLM back-ends that auto-generate multi-hop escalation chains (e.g., `iam:PassRole` → `ec2:RunInstances` → assume admin role) at scale. Assume attackers enumerate your IAM graph in minutes. Every `iam:PassRole` or `iam:CreatePolicyVersion` without a condition must be treated as a critical finding.
+- **Post-quantum threat — Harvest-Now-Decrypt-Later against cloud KMS-wrapped secrets:** AWS KMS, GCP Cloud KMS, and Azure Key Vault all use RSA or ECDH under the hood for key wrapping. Secrets encrypted today with classical key wrapping algorithms will be decryptable once CRQCs arrive (est. 2028-2032). Any secret with a classification lifetime exceeding 5 years must migrate to hybrid ML-KEM (FIPS 203) wrapping now. Inventory long-lived secrets with `aws kms list-keys` + `describe-key` and flag RSA-wrapped data keys.
+- **Supply chain attack via Terraform provider registry (technique):** Malicious or typo-squatted Terraform providers on registry.terraform.io have full access to the runner's environment variables — including cloud credentials injected by CI. Any provider source not on the `hashicorp/` or known-vendor namespace must be reviewed. Pin provider versions with `required_providers` version constraints and verify checksums in `.terraform.lock.hcl`.
+
 ## PROJECT-AWARE EDGE CASES
 
 Derived from detected IaC and cloud configuration:
@@ -83,3 +103,110 @@ If internet permitted:
 Write `.mcp/agent-runs/{agentRunId}/infra-findings.json`
 Each finding includes the affected Terraform resource or Kubernetes object, the blast radius,
 the exploit chain, and the fixed code.
+
+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 }]
+  }
+}
+```
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "AGENT_NAME",
+  "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": "IAM Privilege Escalation", "filesReviewed": 23, "patterns": ["iam:PassRole", "iam:CreatePolicyVersion", "iam:AttachRolePolicy"], "result": "CLEAN" }],
+    "filesReviewed": 23,
+    "negativeAssertions": ["IAM PassRole without condition searched across 23 Terraform files — 0 matches"],
+    "uncoveredReason": {}
+  }
+}
+```
+
+## §EDGE-CASE-MATRIX-CLOUD-SUPPLEMENT
+
+Cloud-infra-specific attack cases that automated cloud security scanners (Prowler, ScoutSuite, Checkov) universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Cloud Scanners Miss It | Concrete Test |
+|---|-----------|---------------------------|---------------|
+| 1 | Multi-hop IAM privilege escalation via `iam:PassRole` + `ec2:RunInstances` | Scanners flag individual overpermissive policies; they do not walk the full graph across role boundaries | Run PMapper or Cloudfox against the account; look for any path from a dev/CI principal to `AdministratorAccess` with ≤3 hops |
+| 2 | IMDS v1 exposure inside a container running on EC2/EKS node | Container scanners check the image; network-layer IMDSv1 access from any pod on the node is invisible to them | From a busybox pod, `curl http://169.254.169.254/latest/meta-data/iam/security-credentials/`; if it returns credentials, IMDSv2 is not enforced at the node level |
+| 3 | Terraform state file in an S3 bucket with `versioning=disabled` and `acl=private` but no bucket policy denying cross-account access | Checkov checks encryption and versioning separately; cross-account confused-deputy access via resource policies is not modelled | Enumerate the state bucket's resource policy and check for `Principal: "*"` or any cross-account principal; attempt `s3:GetObject` from a different account with a condition mismatch |
+| 4 | Ephemeral cloud credential exfiltration via environment variable injection into CI runners | SAST tools scan application code, not CI pipeline YAML; injected environment variables leave no artefact in the application repo | Search `.github/workflows/`, `.gitlab-ci.yml`, `buildspec.yml` for `env:` blocks that print or log `AWS_*` / `GOOGLE_*` / `AZURE_*` variable names; check runner logs for credential echo |
+| 5 | VPC security group "last-writer-wins" race during auto-scaling group launch | Static IaC scanners see the intended rules; a race between the ASG launch hook and a separate automation job can temporarily open 0.0.0.0/0 on a newly launched instance before the hook completes | Review ASG launch lifecycle hooks; check CloudTrail for `AuthorizeSecurityGroupIngress` events within 60 seconds of `EC2 Instance Launch` events on the same instance ID |
+
+## §DETECTION-GAP-CLOUD-SUPPLEMENT
+
+Cloud-infra-specific monitoring gaps that CloudTrail / AWS Security Hub / GCP Security Command Center / Azure Defender CANNOT detect by default, and what to build to close each gap.
+
+- **Cross-account assume-role chaining**: CloudTrail logs each `AssumeRole` call in the account where it originates, but does not automatically correlate a chain of three accounts (A → B → C). An attacker pivoting across accounts appears as three separate, low-signal events. Need: cross-account CloudTrail aggregation in a security lake (S3 + Athena), with a query that joins `AssumeRole` events on `responseElements.credentials.accessKeyId` across accounts within a 5-minute window.
+- **Terraform state reads by non-CI principals**: S3 `GetObject` on state bucket paths is a legitimate CI operation; reads by human IAM principals or non-pipeline roles are invisible without a bucket-level data event filter. Need: enable S3 data event logging for the state bucket and alert on `GetObject` events where the `userIdentity.type` is not `AssumedRole` with the expected CI role ARN.
+- **GKE/EKS node instance metadata abuse from within a pod**: The kubelet network policy blocks pod-to-API-server direct access, but not pod-to-node-IMDS unless a `NetworkPolicy` or IMDSv2 hop-limit of 1 is enforced. No pod-level log event is emitted when the metadata endpoint is reached. Need: enforce `HttpPutResponseHopLimit: 1` on all EC2 launch templates; on GKE, enable `--metadata-concealment` and alert on `metadata.google.internal` DNS queries from the pod CIDR in VPC Flow Logs.
+- **Long-lived IAM access keys never rotated**: IAM access key age is visible via `iam:ListAccessKeys`, but Security Hub's finding for keys older than 90 days fires only once and is not re-fired if the finding is suppressed. Need: a scheduled Lambda or Step Function that re-evaluates key age daily and creates a new CRITICAL finding (not just updates) if the key crosses 180 days, bypassing suppression logic.
+- **Workload Identity / IRSA token replay across pod restarts**: The projected OIDC token for a Kubernetes service account bound to a cloud IAM role is valid for up to 1 hour. If a pod is compromised and the token is exfiltrated, the cloud provider cannot distinguish legitimate from replayed token exchanges — both look like valid OIDC federation events. No alert fires. Need: monitor cloud IAM token exchange events (`sts:AssumeRoleWithWebIdentity` on AWS, `generateIdToken` on GCP) for the same Kubernetes service account appearing from more than one source IP within the token validity window.

package/skills/compliance-gap-analyst/SKILL.md

@@ -24,6 +24,15 @@ Produce a complete risk register with SLA deadlines per §20.
 Identify any finding that blocks release.
 Covers §20, §22C-E, and §24 fully.
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+The full suite of detection modules in `src/gate/checks/` (especially `secrets.ts`, `auth-deep.ts`, `dependencies.ts`, and `crypto.ts`) is the evidence source you map controls onto — your deterministic floor, not your ceiling. Treat their finding IDs as the raw material for the risk register, then reason past what single-line/single-file pattern matching can see to produce audit-grade evidence and catch control gaps no single check encodes — and APPLY the fix (Edit the policy/logging/control), not just advise:
+
+- **Cross-file / cross-finding reasoning the regex can't do:** turn raw findings into multi-framework gaps — a `dependencies.ts` unpatched-CVE finding becomes a simultaneous PCI 6.3.3 + SOC 2 CC7.1 failure; a `secrets.ts` long-lived compliance API token becomes the CC6.1 over-privilege gap that destroys the audit trail when abused.
+- **Semantic / effective-state analysis:** verify *operating* effectiveness, not just *design* — trace whether every PHI-touching path from the appsec findings actually writes an audit log (§164.312(b)), whether consent/audit tables are append-only, and whether retention is enforced in code, not just policy.
+- **External corroboration:** WebSearch/WebFetch for EPSS/CVE currency, CISA KEV, FIPS 203/204/205 PQC migration, and EU AI Act / EO 14028 SBOM mandates relevant to the in-scope frameworks.
+- **Apply & prove:** write the control/PoC/evidence inline (per §POC-REQUIREMENT), re-run the relevant `src/gate/checks/` modules as a regression floor, then re-audit semantically; emit the LEARNING SIGNAL per fix and surface trade-offs (e.g. release-block vs. compensating control + SLA) with the secure default.
+
 ## EXECUTION
 
 1. Read ALL findings files: appsec, infra, supply-chain, ai, mobile, crypto, pentest
@@ -68,6 +77,36 @@ Covers §20, §22C-E, and §24 fully.
 - CC8 series: Change Management
 - CC9 series: Risk Mitigation
 
+**ISO 27001:2022 Annex A (selected):**
+- A.5.23: Information security for use of cloud services
+- A.8.8: Management of technical vulnerabilities
+- A.8.24: Use of cryptography
+- A.8.26: Application security requirements
+- A.8.28: Secure coding
+- A.8.29: Security testing in development and acceptance
+
+**NIST 800-53 Rev 5 (selected control families):**
+- AC: Access Control (AC-2 through AC-25)
+- AU: Audit and Accountability
+- CA: Assessment, Authorization, and Monitoring
+- CM: Configuration Management
+- IA: Identification and Authentication
+- IR: Incident Response
+- SC: System and Communications Protection
+- SI: System and Information Integrity
+
+**GDPR Articles relevant to security findings:**
+- Art. 25: Data protection by design and by default
+- Art. 32: Security of processing (pseudonymisation, encryption, resilience)
+- Art. 33: Notification of personal data breach to supervisory authority (72h)
+- Art. 35: Data protection impact assessment (DPIA) for high-risk processing
+
+**HIPAA Security Rule safeguards:**
+- §164.312(a)(1): Access control — unique user identification, emergency access, automatic logoff
+- §164.312(b): Audit controls — hardware, software, and procedural mechanisms
+- §164.312(c)(1): Integrity controls — authenticate or verify PHI has not been altered
+- §164.312(e)(1): Transmission security — guard against unauthorized access during transmission
+
 ## OUTPUT
 
 `AgentFinding[]` array enriched with compliance mappings. Also produces:
@@ -75,3 +114,395 @@ Covers §20, §22C-E, and §24 fully.
 - `complianceMappingTable`: finding ID → all framework controls
 - `releaseBlocked`: boolean
 - `deliverableChecklist`: status of all §24 required outputs
+
+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
+
+The following checks are REQUIRED in addition to the core framework mapping above.
+Each targets a known blind spot in standard compliance tooling.
+
+### 1. PCI DSS 4.0 Req 6.3.3 — Patch Freshness Gap (CVE Correlation Required)
+Standard compliance tools check that a patching *process* exists but do not verify actual patch currency.
+**Attack technique**: Exploitation of known unpatched vulnerabilities within the CDE.
+**Specific check**: For every dependency in `package.json`, `pom.xml`, `go.mod`, and OS package lists,
+cross-reference CVE publication dates against the last applied patch date.
+Any CVE published more than 7 days ago with EPSS ≥ 0.4 and CVSS ≥ 7.0 that remains unpatched = PCI DSS
+Req 6.3.3 failure AND SOC 2 CC7.1 failure simultaneously.
+**Detection**: `npm audit --json | jq '.vulnerabilities | to_entries[] | select(.value.severity=="high" or .value.severity=="critical")'`
+**Finding**: Any result here is a CRITICAL compliance gap with a 24-hour SLA.
+
+### 2. GDPR Art. 32 — Pseudonymisation Bypass via Re-identification (AI-Assisted)
+Modern adversaries use LLM-assisted re-identification attacks on "anonymised" datasets.
+A dataset that passes classical k-anonymity checks can be de-anonymised by an LLM correlating
+quasi-identifiers (zip code + age + gender + diagnosis) against public datasets.
+**Attack technique**: LLM-assisted probabilistic re-identification — not covered by any existing GDPR scanner.
+**Specific check**: Identify all data export endpoints and analytics pipelines. For each, determine whether
+the quasi-identifier set (any combination of fields that together narrow population below k=5) is present
+in exported records. Test by constructing a synthetic 5-row dataset with the real schema and running it
+through an open-source re-identification tool (e.g., ARX, sdcMicro).
+**Detection**: `grep -rE "(zip|postal|dob|age|gender|diagnosis|ethnicity)" --include="*.ts" --include="*.py" src/`
+Any endpoint returning 3+ quasi-identifiers without noise injection or suppression = GDPR Art. 32 gap.
+**Finding**: Document as HIGH with GDPR Art. 32 + ISO 27001:2022 A.8.11 citation.
+
+### 3. SOC 2 CC6.1 — Broken Access Control via Compliance-Adjacent API Tokens (CWE-284)
+Compliance reporting endpoints (audit log exports, evidence downloaders, SIEM integrations) are often
+granted broad read access and then forgotten. Attackers target these as lateral-movement pivot points.
+**Attack technique**: Abuse of long-lived, over-privileged compliance API tokens to exfiltrate all audit
+logs and evidence packages — a data breach that simultaneously destroys the evidence trail.
+**Specific check**: Enumerate all service accounts, API keys, and OAuth clients used by compliance tooling.
+Verify: (a) scope is least-privilege, (b) tokens rotate within 90 days, (c) tokens are stored in secrets manager
+not in `.env` files or CI environment variables in plaintext.
+**Detection**: `grep -rE "(COMPLIANCE|AUDIT|SIEM|SPLUNK|DATADOG)_TOKEN|_API_KEY" .env* .github/workflows/ --include="*.yml"`
+Any plaintext token = CRITICAL. Any token with >90-day rotation = HIGH (SOC 2 CC6.1, PCI DSS Req 8.3.9).
+
+### 4. NIST 800-53 CA-7 — Continuous Monitoring Gaps Exposed by Supply Chain Compromise
+The SolarWinds/XZ-utils class of attacks exploits a gap between what compliance frameworks require
+("perform continuous monitoring") and what organisations actually monitor (build artefacts at rest, not
+the build *process* itself).
+**Specific technique**: A malicious contributor modifies a build script or test helper that is never scanned
+because it is not in the "production code" scope defined by compliance tools.
+**Specific check**: Extend the monitoring scope to ALL files that influence the build output, including
+`.github/workflows/`, `Makefile`, `scripts/`, `jest.config.js`, `vite.config.ts`, and any pre/post-install
+hooks in `package.json`. Compute SHA-256 of every such file and compare against the last known-good commit.
+**Detection**: `git log --all --format="%H %ae %s" -- .github/workflows/ scripts/ Makefile | head -50`
+Any commit by an author not in CODEOWNERS for that path = HIGH (NIST CA-7, ISO 27001 A.8.8).
+**Supply chain emerging threat**: This class of attack is accelerating — CISA AA24-166A (2024) documents
+7 confirmed campaigns targeting CI/CD pipelines. Treat any unexplained workflow change as CRITICAL until proven safe.
+
+### 5. HIPAA §164.312(b) — Audit Log Completeness Verification (Often Attestation-Faked)
+Many organisations attest to audit logging but have silent gaps: database direct-access paths,
+admin panels that bypass the ORM, and async job runners that share a service account.
+**Specific check**: For every PHI-touching code path identified by appsec-agent, confirm a corresponding
+audit log write exists. Use code coverage tracing: instrument the audit-write function and run the test suite.
+Any PHI read/write that does not trigger the audit log = HIPAA §164.312(b) violation.
+**Detection**: `grep -rn "PHI\|patientId\|mrn\|ssn\|dob" --include="*.ts" --include="*.py" src/ | grep -v "audit\|log\|emit"`
+Any match where the surrounding function lacks an explicit audit call = CRITICAL compliance finding.
+**Test**: Write a synthetic integration test that reads a PHI record and then asserts the audit log table has a
+new entry with the correct userId, resourceType, resourceId, and timestamp. Failure = HIPAA gap.
+
+### 6. Post-Quantum Readiness — NIST FIPS 203/204/205 Migration Gap Assessment
+The NIST post-quantum cryptography standards were finalised in August 2024 (FIPS 203 ML-KEM,
+FIPS 204 ML-DSA, FIPS 205 SLH-DSA). Compliance frameworks have not yet mandated migration,
+but harvest-now-decrypt-later attacks are active today against long-lived regulated data (health records,
+financial transaction histories, government records).
+**Specific check**: Inventory every RSA and ECDSA key in use. Classify by data sensitivity and retention period.
+Any key protecting data with a retention period beyond 2030 must have a documented PQC migration plan.
+**Detection**: `grep -rE "(RSA|ECDSA|secp256|P-256|rsa2048|rsa4096)" --include="*.ts" --include="*.tf" --include="*.yaml" .`
+Also check TLS configurations: `grep -rE "ssl_protocols|TLSv1\.[012]|cipher_suite" nginx.conf* .`
+**Finding**: Document under emerging threat category. Map to NIST SP 800-131A Rev 2 (transitioning to stronger
+cryptographic algorithms), ISO 27001 A.8.24, and ENISA's 2024 post-quantum readiness guidance.
+Any long-lived regulated data protected only by classical crypto = HIGH (escalating to CRITICAL after 2027).
+
+### 7. EU AI Act Compliance Gap — High-Risk AI System Classification (Effective 2026)
+The EU AI Act full enforcement begins in 2026. Any AI system used in employment, credit scoring, biometric
+identification, critical infrastructure, or access to essential services falls under "high-risk" obligations
+requiring mandatory conformity assessments, logging, and human oversight mechanisms.
+**Specific check**: Enumerate all AI/ML inference endpoints in the codebase. For each, determine:
+(a) what decision it influences, (b) whether a human can override it, (c) whether all inputs and outputs are
+logged for at least 6 months (Art. 12 logging obligation), (d) whether an accuracy/bias evaluation was performed.
+**Detection**: `grep -rE "(openai|anthropic|bedrock|sagemaker|vertexai|replicate|huggingface)" --include="*.ts" --include="*.py" src/`
+Any LLM inference call that influences a regulated decision without human override capability = HIGH (EU AI Act Art. 9, 12, 14).
+**Emerging threat**: AI-assisted automated compliance attestation — adversaries are using LLMs to generate
+convincing but fraudulent compliance evidence packages. Cross-verify all automatically generated evidence
+against authoritative system-of-record logs.
+
+### 8. SBOM Completeness and Integrity — US EO 14028 / EU Cyber Resilience Act
+US Executive Order 14028 and the EU Cyber Resilience Act (CRA, effective 2027 for most products)
+mandate Software Bills of Materials (SBOM) for software sold to or used by regulated entities.
+A missing or incomplete SBOM is itself a compliance violation in the US federal supply chain context.
+**Specific check**: Verify that a CycloneDX or SPDX SBOM exists and is generated automatically in CI/CD.
+The SBOM must include: all direct and transitive dependencies, component hashes, supplier information,
+and licence identifiers. Verify it is signed (SLSA L2+) and published as a release artefact.
+**Detection**: Check `.github/workflows/` for SBOM generation step. Check releases for `sbom.cyclonedx.json` or `sbom.spdx.json`.
+`cat .github/workflows/*.yml | grep -i "sbom\|cyclonedx\|syft\|trivy\|grype"`
+**Finding**: Absent or unsigned SBOM = HIGH for US federal supply chain context; MEDIUM for commercial products
+planning EU CRA compliance. Map to NIST SP 800-161 (C-SCRM), EO 14028 Section 4.
+
+---
+
+## §COMPLIANCE_GAP_ANALYST-CHECKLIST
+
+Numbered attack checklist specific to compliance gap analysis. For each item: exact mechanism,
+what to grep/test, and what constitutes a finding.
+
+1. **Scope Creep in CDE Definition (PCI DSS Req 12.5.2)**
+   Mechanism: Systems added to the network after the last PCI scoping exercise are not included in
+   the CDE boundary, leaving them unaudited and uncontrolled.
+   Test: Compare current infrastructure inventory (`terraform state list`, `kubectl get nodes --all-namespaces`,
+   AWS `ec2 describe-instances`) against the last documented CDE boundary diagram.
+   Finding: Any system processing, storing, or transmitting CHD that is absent from the CDE diagram.
+
+2. **Audit Log Tampering — Missing Integrity Protection (SOC 2 CC7.2 / NIST AU-9)**
+   Mechanism: Audit logs stored in the same data store as application data can be modified or deleted
+   by an attacker who achieves application-level access, eliminating evidence of the breach.
+   Test: `grep -rn "DELETE FROM.*audit\|TRUNCATE.*audit\|drop.*log" --include="*.sql" --include="*.ts" src/`
+   Also verify logs are written to an immutable destination (CloudTrail with Object Lock, Worm-mode S3, Splunk with lockdown).
+   Finding: Any code path that can modify audit logs, or any log destination without integrity protection.
+
+3. **Orphaned Service Accounts with Elevated Privileges (SOC 2 CC6.2 / ISO 27001 A.8.2)**
+   Mechanism: Service accounts created for a feature or integration are not deprovisioned when the feature is removed.
+   They accumulate in IAM with their original broad permissions and no active owner.
+   Test: `aws iam list-users | jq '.Users[] | select(.PasswordLastUsed == null or (.PasswordLastUsed < "2025-01-01"))'`
+   Also cross-reference all service accounts against CODEOWNERS and active application configuration.
+   Finding: Any service account unused for >90 days with privileges beyond read-only.
+
+4. **Data Retention Policy Not Enforced in Code (GDPR Art. 5(1)(e) / HIPAA §164.530(j))**
+   Mechanism: Privacy policies and compliance documents state a retention period (e.g., 7 years for financial,
+   6 years for HIPAA), but no automated deletion job or TTL mechanism exists in the codebase.
+   Test: `grep -rn "TTL\|expires_at\|deletedAt\|purge\|retention" --include="*.ts" --include="*.py" src/`
+   Then confirm a scheduled job exists that enforces the retention window.
+   Finding: Any regulated data store (PHI, CHD, PII) without a corresponding automated deletion or archival mechanism.
+
+5. **Consent Records Without Tamper-Evident Storage (GDPR Art. 7 / CCPA)**
+   Mechanism: Consent is recorded in the same mutable database as application data. If the database is
+   compromised or corrupted, consent records can be altered, leaving the organisation unable to prove lawful basis.
+   Test: `grep -rn "consent\|gdpr\|opt.?in\|opt.?out" --include="*.ts" --include="*.sql" src/`
+   Verify the consent record table has: immutable append-only design, cryptographic hash chain, or external audit log.
+   Finding: Any consent table that allows UPDATE or DELETE on existing rows.
+
+6. **Cryptographic Algorithm Downgrade in TLS Configuration (PCI DSS Req 4.2.1 / NIST SP 800-52r2)**
+   Mechanism: TLS configurations that permit TLS 1.0/1.1 or weak cipher suites (RC4, 3DES, export ciphers)
+   remain after a security hardening pass because they are set in infrastructure code not covered by app scans.
+   Test: `grep -rE "TLSv1\b|TLSv1\.1|ssl_ciphers.*RC4|ssl_ciphers.*DES|ssl_ciphers.*NULL" nginx.conf* haproxy.cfg* .`
+   Also: `nmap --script ssl-enum-ciphers -p 443 <target>` or `testssl.sh <target>`.
+   Finding: Any TLS configuration permitting < TLS 1.2 or a NIST-deprecated cipher suite.
+
+7. **Missing Business Associate Agreement Coverage (HIPAA §164.308(b))**
+   Mechanism: A third-party SaaS vendor receives PHI via API integration, but no Business Associate Agreement
+   (BAA) is in place. The organisation believes the vendor's general terms cover this, which they do not.
+   Test: Enumerate all outbound API calls from PHI-touching code paths.
+   `grep -rn "fetch\|axios\|httpClient\|got(" --include="*.ts" src/ | grep -v test`
+   Cross-reference each external domain against the vendor BAA registry.
+   Finding: Any external endpoint receiving PHI without a documented, signed BAA on file.
+
+8. **Change Management Bypass — Unapproved Production Deployments (SOC 2 CC8.1 / ISO 27001 A.8.32)**
+   Mechanism: CI/CD pipeline allows direct push to the main/production branch without a PR approval,
+   bypassing the change management controls that auditors rely on to evidence CC8.1.
+   Test: `gh api repos/{owner}/{repo}/branches/main/protection` — verify `required_pull_request_reviews.required_approving_review_count >= 1`.
+   Also check for admin override bypass: `"enforce_admins": { "enabled": true }`.
+   Finding: Any production branch configuration permitting direct push or admin bypass of review requirements.
+
+9. **Incomplete Incident Response Documentation (NIST IR-8 / SOC 2 CC7.5)**
+   Mechanism: The incident response plan exists as a static document but has never been tested.
+   Tabletop exercise records, post-mortems, and escalation contact lists are absent or stale.
+   Compliance auditors will ask for evidence of IRP execution, not just the plan.
+   Test: `find . -name "incident*" -o -name "postmortem*" -o -name "runbook*" | head -20`
+   Verify the most recent incident response exercise was within the past 12 months.
+   Finding: Any organisation without documented IRP test within 365 days = SOC 2 CC7.5 gap.
+
+10. **Vulnerability Disclosure Policy Absence (ISO 27001:2022 A.8.8 / PCI DSS Req 6.3.1)**
+    Mechanism: External researchers who discover vulnerabilities have no responsible disclosure channel.
+    Without a VDP, the organisation cannot demonstrate it has a mechanism to receive and act on external
+    vulnerability reports — a requirement under ISO 27001:2022 A.8.8 and strongly implied by PCI DSS 6.3.1.
+    Test: Check for `/.well-known/security.txt`, `SECURITY.md` in repo root, and a HackerOne/Bugcrowd programme.
+    `curl -sI https://<domain>/.well-known/security.txt`
+    Finding: Missing security.txt or SECURITY.md = LOW (escalates to MEDIUM if PCI or ISO 27001 certified/in-scope).
+
+11. **DPIA Not Conducted for High-Risk Processing (GDPR Art. 35)**
+    Mechanism: New product features involving systematic profiling, large-scale processing of special-category
+    data, or automated decision-making are shipped without a DPIA, which is a legal requirement under GDPR Art. 35.
+    Test: Identify all AI/ML features, profiling pipelines, and large-scale PII processing in the current codebase.
+    Cross-reference against the DPIA register in the organisation's privacy management system.
+    Finding: Any feature processing special-category data at scale without a documented, approved DPIA.
+
+12. **Access Reviews Not Evidenced (SOC 2 CC6.3 / ISO 27001 A.5.18)**
+    Mechanism: User access rights are granted but never reviewed. Former employees or role-changed employees
+    retain access to sensitive systems. Auditors require periodic access review evidence.
+    Test: Pull IAM user list with last-activity date. Cross-reference against HR offboarding records.
+    `aws iam generate-credential-report && aws iam get-credential-report | base64 -d | grep -v ",true,"`
+    Finding: Any active credentials for accounts inactive >90 days, or no documented quarterly access review.
+
+---
+
+## §POC-REQUIREMENT
+
+For every CRITICAL or HIGH finding in the compliance gap analyst domain:
+
+1. **Write the working PoC FIRST** — exact payload, exact request, observed impact.
+   Do not write the remediation until the PoC is confirmed to reproduce the issue.
+
+2. **Confirm the PoC reproduces the issue** — run it, capture the output, record the exact error or
+   data exposure observed.
+
+3. **THEN write the fix** — the fix must be specific and implementable, not a generic recommendation.
+
+4. **THEN verify the PoC fails against the fix** — re-run the exact same PoC after applying the fix.
+   If it still succeeds, the fix is incomplete. Iterate.
+
+5. **Record the PoC in findings JSON under `exploitPoC`:**
+```json
+{
+  "exploitPoC": {
+    "payload": "exact command or request",
+    "reproduced": true,
+    "impact": "what was observed",
+    "fixApplied": "one-line description of the fix",
+    "fixVerified": true
+  }
+}
+```
+
+**PoC skipping = finding severity downgraded to MEDIUM automatically.**
+
+No exceptions. Compliance findings without a PoC are treated as hypothetical. Auditors and attackers
+alike need evidence of exploitability to prioritise remediation correctly.
+
+Example PoC for audit log deletion bypass (CRITICAL):
+```bash
+# PoC: Direct database DELETE bypasses application-layer audit controls
+psql $DATABASE_URL -c "DELETE FROM audit_logs WHERE user_id = 'attacker-id';"
+# Expected if vulnerable: rows deleted, no counter-entry in audit_logs
+# Expected after fix: permission denied (row-level security) OR compensating log entry created
+```
+
+---
+
+## §PROJECT-ESCALATION
+
+The following conditions require an IMMEDIATE call to `orchestration.update_agent_status` with
+`"status": "CRITICAL_ESCALATION"` before this agent completes. Do not finish the compliance report
+and then escalate — escalate first, then continue.
+
+1. **Active data breach indicators**: Any finding that suggests PHI, CHD, or PII has already been
+   exfiltrated (e.g., evidence of bulk export from a regulated data store in audit logs, unexpected
+   large outbound transfers, credential in public git history with access to production).
+   Action: CRITICAL_ESCALATION + alert orchestrator + set `releaseBlocked: true` + flag for IR team.
+
+2. **PCI DSS Req 6.4.2 total absence**: No application security assessment of any kind (SAST, DAST,
+   manual pentest) has been performed before production for a system in the CDE.
+   Action: CRITICAL_ESCALATION — this is a mandatory PCI DSS requirement and its absence means the
+   organisation cannot complete a QSA assessment. Block all further deployments to the CDE.
+
+3. **HIPAA breach notification trigger**: Any finding that constitutes an "impermissible use or disclosure"
+   of PHI under 45 CFR §164.410, including a misconfigured S3 bucket, publicly accessible PHI endpoint,
+   or PHI in application logs. HIPAA mandates notification within 60 days; the clock starts at discovery.
+   Action: CRITICAL_ESCALATION + immediate legal/compliance team notification + document discovery timestamp.
+
+4. **Compliance evidence tampering**: Discovery that audit logs, compliance evidence packages, or SOC 2
+   report artefacts have been modified, deleted, or fabricated.
+   Action: CRITICAL_ESCALATION — this may constitute fraud. Preserve all evidence in immutable storage
+   immediately. Do not modify any files. Notify orchestrator and await human decision.
+
+5. **Critical CVE with active exploitation in CDE-adjacent system (EPSS ≥ 0.7, CVSS ≥ 9.0)**:
+   A vulnerability matching this profile in a system that touches the CDE creates an imminent breach risk
+   that supersedes all other compliance work.
+   Action: CRITICAL_ESCALATION + supply CVE ID, affected system, and EPSS score to orchestrator.
+   The full agent run must be reprioritised around emergency patching.
+
+6. **Post-quantum harvest-now attack evidence**: Discovery that long-lived regulated data (>2030 retention)
+   is protected only by RSA or ECDSA, AND there is evidence in network logs of unusual bulk data access
+   patterns (potential harvest-now-decrypt-later exfiltration).
+   Action: CRITICAL_ESCALATION — while not yet decryptable, the data may already be in adversary hands.
+   Flag for immediate key rotation and data re-encryption planning.
+
+7. **AI Act high-risk system deployed without conformity assessment (EU operations)**:
+   Any AI system making automated decisions in employment, credit, or law enforcement contexts that is
+   deployed in the EU without a mandatory conformity assessment completed.
+   Action: CRITICAL_ESCALATION — this is a regulatory deployment violation, not just a gap. May require
+   immediate suspension of the AI feature to avoid enforcement action.
+
+8. **SBOM integrity failure — tampered dependency hash**:
+   A dependency hash in the SBOM does not match the hash of the installed package in `node_modules`
+   or the equivalent. This is the signature of a supply chain compromise (XZ-utils class).
+   Action: CRITICAL_ESCALATION + quarantine affected build environment + do not deploy.
+   Treat as active supply chain incident until proven otherwise.
+
+---
+
+## §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.
+
+**Compliance-domain-specific detection gaps:**
+
+- **Regulatory scope drift**: New infrastructure deployed outside the original compliance scope is not automatically added to monitoring. Need: automated asset discovery reconciled against compliance scope definitions on every deployment.
+- **BAA/DPA coverage lapses**: A third-party vendor updates their terms, invalidating the existing BAA or DPA, without notifying the customer. Need: scheduled legal review trigger + vendor change notification monitoring.
+- **Access review evidence gaps**: Access reviews are performed but not documented in the format auditors require. Need: automated evidence collection that captures reviewer identity, review date, and disposition for every account reviewed.
+
+---
+
+## §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": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "compliance-gap-analyst",
+  "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.