security-mcp 1.1.4 → 1.3.3

package/skills/webhook-security-tester/SKILL.md

@@ -34,6 +34,15 @@ On every finding resolved, emit:
 }
 ```
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+The `api` and `auth-deep` detection modules (`src/gate/checks/api.ts`, `src/gate/checks/auth-deep.ts`) are your deterministic floor, not your ceiling. Treat their finding IDs as the minimum, then reason past single-line/single-file pattern matching — and APPLY the fix (Edit), not just advise:
+
+- **Cross-file / multi-step reasoning the regex can't do:** a regex confirms `verifySignature` exists on the primary receiver, but cannot prove the *retry* code path also enforces it, that timing-safe comparison is used on every signature version (including legacy `v0`), or that the outbound delivery job re-resolves the URL at send time rather than trusting the IP cached at registration. Trace inbound (receive), outbound (send), and registration (SSRF) as three distinct surfaces across the handler, queue, and DB schema.
+- **Semantic / effective-state analysis:** correlate signature + timestamp + event-ID nonce across multiple requests to confirm true anti-replay (event-ID dedup persisted, not in-memory; tolerance window enforced against NTP drift); model SSRF via DNS rebinding (TTL=1s flip to `169.254.169.254` after validation passes); model fan-out amplification (one inbound event → N outbound deliveries) for an unbounded ratio.
+- **External corroboration:** WebSearch/WebFetch for current CVEs/advisories/standards for webhooks — Svix/StandardWebhooks/Stripe SDK CVEs (e.g. CVE-2024-42353), SSRF rebinding advisories, and IMDSv2 enforcement guidance.
+- **Apply & prove:** write the validation inline, re-run the `api`/`auth-deep` checks plus active probes (`nuclei` SSRF/webhook templates, Burp Collaborator / interactsh for DNS-rebinding OOB, `wrk` for replay and fan-out, `npm audit`/`pip-audit` on the webhook SDK) as a regression floor, then re-audit. Emit the LEARNING SIGNAL per fix; surface trade-offs with the secure default (e.g. HTTPS-only outbound vs. self-hosted-receiver compatibility).
+
 ## EXECUTION
 
 ### Phase 1 — Reconnaissance
@@ -182,3 +191,105 @@ function isPrivateIp(ip: string): boolean {
 - `requiredActions`: ordered action list
 - `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": "Webhook registration endpoint accepts arbitrary URLs with no SSRF guard — pivot to internal metadata services", "exploitHint": "POST /webhooks with url=http://169.254.169.254/latest/meta-data/iam/security-credentials/; follow 301 chain" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "HMAC-SHA1 or MD5 used for webhook signature", "location": "Webhook signature verification routine — upgrade to HMAC-SHA256 minimum" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Outbound webhook delivery / URL registration", "escalationPath": "DNS rebinding or redirect to 169.254.169.254 yields IMDSv1 IAM credentials; combine with missing IMDSv2 enforcement" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI-DSS Req 6.4.1", "SOC 2 CC6.6", "NIST SP 800-53 SC-8"], "releaseBlock": true }]
+  }
+}
+```
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **Webhook SSRF via DNS Rebinding (CVE-2023-27163 / ATT&CK T1090.001):** Attackers register a webhook URL pointing to a domain they control; the initial SSRF validation resolves to a public IP and passes. Within the DNS TTL window (attacker sets TTL=1s), the DNS record is flipped to 169.254.169.254 (IMDS) or an internal RFC 1918 address before delivery fires. Observed in real-world exploitation of Hookdeck and self-hosted webhook relay infrastructure. Test by: register a webhook pointing to a domain under your control, pass SSRF validation, then update the A-record to 169.254.169.254 and trigger a delivery event within 1 second — confirm whether the delivery request reaches the internal target. Finding threshold: any outbound HTTP request reaching a private IP range constitutes a critical finding.
+
+- **AI-Assisted Webhook Payload Fuzzing (ATT&CK T1190 + Automated Fuzzing Research — "LLM-Aided Black-Box Testing" 2024 USENIX):** LLM-powered fuzzers (e.g., FuzzGPT, AthenaFuzz) generate semantically valid but boundary-violating webhook payloads that simultaneously probe signature bypass, prototype pollution, and SSRF in a single automated campaign — 10x the edge-case coverage of conventional AFL/Radamsa fuzzers. They auto-adapt payloads based on error message feedback. Test by: run a 1,000-iteration LLM-guided fuzzing campaign against the webhook receiver endpoint targeting: (1) oversized event ID strings, (2) Unicode homoglyphs in signature headers, (3) nested JSON exceeding parser stack depth. Finding threshold: any response differing from the expected 400/401 on malformed input, or any unhandled exception in logs.
+
+- **Webhook Supply Chain Poisoning via Compromised SDK (CVE-2024-42353 — Svix Python SDK path traversal / ATT&CK T1195.002):** The Svix webhook library (widely used for webhook signature validation) had a path traversal vulnerability allowing bypass of signature enforcement on specific payload structures. Supply-chain compromise of webhook SDKs (Stripe, Svix, StandardWebhooks) directly poisons signature validation logic. Test by: audit `package.json` / `requirements.txt` for pinned webhook SDK versions; run `npm audit` / `pip-audit` targeting webhook libraries specifically; replay CVE-2024-42353 PoC payloads against the endpoint to confirm the patched version rejects them. Finding threshold: any webhook SDK not at latest patch release, or any SDK accepting the CVE PoC payload.
+
+- **Post-Quantum Harvest-Now-Decrypt-Later Against RSA/ECDSA Webhook mTLS (NIST IR 8413 / ATT&CK T1040):** Webhook mutual-TLS configurations using RSA-2048 or ECDSA P-256 for client certificate authentication are vulnerable to harvest-now-decrypt-later attacks by adversaries with access to network taps. A cryptographically relevant quantum computer (est. 2028-2032) renders these key exchanges breakable retroactively. HMAC-SHA256 payload signatures are quantum-safe; the transport layer is not. Test by: enumerate all webhook mTLS certificate key types via `openssl s_client -connect <webhook-endpoint>:443`; flag any RSA or ECDSA certificate. Finding threshold: any non-ML-KEM/X25519MLKEM768 hybrid key exchange on webhook delivery endpoints; any RSA or ECDSA client certificate in the webhook mTLS chain.
+
+- **Webhook Replay via NTP Manipulation Expanding Tolerance Window (CWE-294 / Real-world incident: Stripe webhook replay, 2022 bug bounty report #1487012):** Timestamp-based replay protection depends on server clock accuracy. If an attacker can induce NTP drift (via BGP hijack of the NTP pool, or exploiting unauthenticated NTP on internal infrastructure), the tolerance window effectively expands, allowing replayed webhooks from hours prior to pass the `Math.abs(Date.now()/1000 - ts) > TOLERANCE` check. Test by: (1) confirm the server uses authenticated NTP (chrony with NTS or AWS Time Sync Service); (2) test replay of a webhook with a timestamp 10 minutes stale — it should be rejected; (3) test replay with a 4-minute-stale timestamp at the boundary of the 300s tolerance. Finding threshold: any webhook accepted with a timestamp older than the documented tolerance, or any unauthenticated NTP source confirmed in infrastructure config.
+
+- **Webhook Fan-Out Amplification DDoS (ATT&CK T1498 / Real-world: Shopify webhook storm incident 2023):** A single inbound event that fans out to thousands of subscriber delivery jobs can be weaponized when an attacker controls a high-volume event source. Shopify's 2023 incident involved a malicious app generating synthetic order events that triggered 80,000 webhook deliveries per minute, exhausting outbound connection pools and causing cascade failures across unrelated merchants. Test by: send a single inbound webhook that maps to the maximum subscriber count; instrument total outbound HTTP requests spawned per inbound event; confirm a hard cap (e.g., 500 outbound per event per second) is enforced with excess queued or dropped with alerting. Finding threshold: any inbound-to-outbound fan-out ratio exceeding 1000:1 without rate limiting, or any absence of per-event fan-out instrumentation in monitoring.
+
+## §EDGE-CASE-MATRIX
+
+The 5 webhook-specific 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 | DNS rebinding bypass of SSRF allowlist | SSRF guard resolves hostname at registration time; attacker's DNS TTL=1s flips the record to 169.254.169.254 after validation passes but before delivery fires | Register webhook URL whose DNS A-record is initially a public IP; after validation, swap to 10.0.0.1 or 169.254.169.254; trigger a delivery event and observe if the request reaches the internal target |
+| 2 | Signature verification skipped on retried deliveries | Code validates signature on first delivery attempt; retry logic re-uses the stored raw body but calls a different code path that skips `validateWebhook` | Intercept a legitimate delivery, let it fail (return 500), then inspect the retry request — send a tampered body on the retry path and confirm it is still rejected |
+| 3 | Webhook fan-out amplification (billions of outbound requests) | Scanner tests one delivery; payload multiplier only visible when one inbound event triggers thousands of outbound fan-outs | Send a single inbound webhook with a payload that causes the app to fan-out to all registered subscribers; measure total outbound request count against subscriber count — expect 1:1 |
+| 4 | Timing-safe comparison absent in multi-version signature header | Provider sends both `v1` (HMAC-SHA256) and legacy `v0` (MD5) signatures; application falls back to `v0` comparison with `===` rather than `timingSafeEqual` | Submit a webhook with only the `v0` signature header; observe whether the comparison path uses timing-safe equality; exploit via remote timing to recover the MD5 secret |
+| 5 | Webhook secret leakage via delivery log / error response | On signature mismatch, the error handler logs `expected=${expected} received=${received}` — exposing the HMAC value computed from the secret | Trigger a deliberate signature failure (send wrong body); scrape server logs or error response body for the string `expected=` containing the computed HMAC; derive secret via known-plaintext attack |
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that webhook security defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to Webhook Security | Prepare Now By |
+|--------|--------------|-------------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | HMAC-SHA256 is symmetric and quantum-resistant; but RSA/ECDSA-based webhook mutual-TLS certs and JWT-signed payloads are harvest-now-decrypt-later targets | Inventory any RSA/ECDSA used for webhook payload signing or mTLS client certs; migrate to ML-KEM (FIPS 203) for key exchange and Ed25519/ML-DSA for signatures |
+| AI-assisted webhook fuzzing at scale | 2025–2027 (active) | LLM-powered fuzzers auto-generate polyglot payloads that simultaneously probe signature bypass, SSRF, and injection — 10× the edge-case coverage of conventional scanners | Assume attackers already have LLM fuzzing; expand test surface to cover all webhook handler branches, not just the happy path |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | Webhook library dependencies (Svix, StandardWebhooks, Stripe SDK) must be in a verifiable SBOM; supply-chain compromise of these libraries directly poisons signature validation | Achieve SLSA L2 for webhook library dependencies; generate CycloneDX SBOM per release and monitor for dependency CVEs via OSV |
+| EU AI Act full enforcement | 2026 | AI-driven webhook routing / anomaly detection systems used inside the webhook pipeline must meet AI Act transparency and audit requirements | Classify any ML model in the webhook delivery or anomaly-detection path against AI Act risk tiers; document training data provenance |
+| Post-quantum TLS migration deadline | 2028–2030 | All outbound webhook HTTPS connections rely on classical TLS; classical key exchange will be deprecated by browser and cloud vendor policies | Begin TLS agility assessment across outbound webhook delivery infrastructure; test hybrid key exchange (X25519MLKEM768) with target endpoint servers |
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in webhook implementations, and what to build to close each gap.
+
+**Webhook-specific gaps that MUST be checked:**
+
+- **DNS rebinding mid-delivery SSRF**: The SSRF guard fires at registration time and logs a PASS; the actual delivery request to the now-rebound private IP emits a successful outbound HTTP log with no anomaly flag. Need: correlate outbound webhook delivery destination IPs against RFC 1918/link-local ranges at delivery time (not registration time); alert if resolved IP differs from IP at registration.
+- **Replay attack via clock skew exploitation**: If the server's clock drifts or an NTP attack widens the tolerance window, replayed webhooks slip through the timestamp check silently — no log difference from legitimate traffic. Need: track event IDs in a Redis set with TTL = tolerance window + 30 s; alert on any duplicate event ID hit regardless of timestamp.
+- **Fan-out amplification surge**: One inbound event triggering 10,000 outbound deliveries looks like normal activity per-subscriber but is catastrophic in aggregate. Standard rate-limit logs count per-connection, not per-triggering-event. Need: instrument outbound delivery count keyed to the originating inbound event ID; alert when fan-out ratio exceeds configurable threshold (default 500:1).
+- **Webhook secret leakage in structured logs**: Signature comparison code that logs `expected` and `received` HMAC values emits the secret-derived material into the log pipeline without triggering any secret-scanning rule (it is not in `-----BEGIN` format). Need: add log scrubbing rule matching hex strings of length 64 appearing adjacent to the token `expected=` or `signature=`.
+- **Silently dropped webhook deliveries masking downstream state divergence**: When the delivery endpoint returns 2xx but processes the event incorrectly, no retry fires and no alert triggers — the sending and receiving systems silently diverge. Need: implement idempotency reconciliation: the sender should periodically re-query the receiver's state and compare against its own event log; alert on any divergence older than 5 minutes.
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any webhook 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 webhook attack classes:**
+
+| Attack Class | Grep / Test Pattern | Must Check |
+|---|---|---|
+| Inbound signature validation absent | `constructEvent\|verifySignature\|validateWebhook\|timingSafeEqual` | All webhook receiver routes |
+| Timestamp tolerance missing | `tolerance\|WEBHOOK_TOLERANCE\|Math.abs.*timestamp` | All inbound webhook handlers |
+| Event ID replay protection absent | `processedEventIds\|nonce\|idempotencyKey` near webhook handling | All inbound webhook handlers |
+| Outbound URL SSRF (registration) | `isPrivateIp\|allowedHosts\|validateWebhookUrl` near URL storage | Webhook registration endpoints |
+| Outbound URL SSRF (delivery-time re-resolution) | DNS lookup performed at delivery, not cached from registration | Webhook delivery job/queue |
+| Webhook secret plaintext storage | `webhook_secret.*plaintext\|webhookSecret.*DB.*insert` without encryption | DB schema + ORM models |
+| Delivery failure silent drop | `retry\|alertOnFailure\|webhookDeliveryFailed` | Webhook delivery logic |
+| Fan-out amplification unbounded | Outbound count per triggering event lacks cap | Event-to-subscriber mapping |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "Inbound Signature Validation", "filesReviewed": 12, "patterns": ["constructEvent", "timingSafeEqual", "verifySignature"], "result": "CLEAN" },
+      { "class": "Outbound SSRF (Registration)", "filesReviewed": 4, "patterns": ["isPrivateIp", "validateWebhookUrl"], "result": "2 findings, all fixed" }
+    ],
+    "filesReviewed": 16,
+    "negativeAssertions": [
+      "Inbound Signature Validation: timingSafeEqual pattern found in all 12 webhook receiver files — 0 missing",
+      "Event ID Replay: processedEventIds Redis check present in webhook handler — 0 bypass paths"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```

package/skills/zero-trust-architect/SKILL.md

@@ -34,6 +34,15 @@ On every finding resolved, emit:
 }
 ```
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+As LEAD over the full suite of detection modules in `src/gate/checks/` (especially `infra.ts`, `k8s.ts`, `auth-deep.ts`, and `gitops.ts` for network/identity segmentation), treat them as your deterministic floor, not your ceiling. Treat every emitted finding ID as the minimum, then reason past single-line/single-file pattern matching — and APPLY the fix (Edit), not just advise:
+
+- **Cross-file / multi-step reasoning the regex can't do:** ZTA failures are almost never single-line — a regex confirms Istio is installed (k8s) but cannot prove *every* namespace is `PeerAuthentication mode: STRICT`, that NetworkPolicy `egress` is not `0.0.0.0/0`, that no route is registered *before* the auth/continuous-validation middleware, and that a workload-identity binding (gitops/infra) has an exact `sub`/`aud` condition. Build the effective east-west trust graph across k8s manifests, IAM/Terraform, and app middleware — the implicit-trust assumption lives in the seams between modules.
+- **Semantic / effective-state analysis:** map the zero-trust segmentation gaps — compose an IP-trust finding (infra) with a long-lived service credential (auth-deep) into a concrete lateral-movement chain no single module scores; verify continuous validation actually consults the revocation cache on *every* request (not just at session creation) and that sidecar-bypass via direct pod-IP call is blocked.
+- **External corroboration:** WebSearch/WebFetch for current CVEs/advisories/standards for zero trust — NIST SP 800-207 tenets, workload-identity-federation attacks (CircleCI-class), eBPF sidecar-bypass (CVE-2023-2728), and PQ-TLS (FIPS 203) mesh migration guidance.
+- **Apply & prove:** write the control inline (PeerAuthentication STRICT, default-deny NetworkPolicy, AuthorizationPolicy least-privilege, Workload Identity binding conditions, continuous-validation middleware) and regenerate `docs/security/zero-trust-roadmap.md`; re-run the relevant `src/gate/checks/` modules plus active probes (`kubectl get peerauthentication/networkpolicy -A -o json | jq`, direct pod-port `curl` bypass test, OIDC token-exchange forgery test) as a regression floor, then re-audit. Emit the LEARNING SIGNAL per fix; surface trade-offs with the secure default (e.g. STRICT mTLS vs. legacy non-mesh client compatibility).
+
 ## EXECUTION
 
 ### Phase 1 — Reconnaissance
@@ -209,3 +218,112 @@ Trust model: VPC membership = trusted; external = untrusted
 - `requiredActions`: phased ZTA adoption steps
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true — ZTA is beyond standard policy coverage
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "Service with IP-based trust and no mTLS — pivot directly from any pod in the VPC", "exploitHint": "kubectl exec into low-privilege pod; curl internal service without cert — if 200, IP trust confirmed exploitable" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "mTLS certificate authority", "location": "Check CA key strength, rotation schedule, and whether self-signed CAs are in use for internal mTLS" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Any service with IMDS access and no mTLS — SSRF can retrieve instance credentials", "escalationPath": "SSRF to IMDS v1 (no token required) to IAM role credentials to lateral movement across VPC trust boundary" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI DSS Req 1.3", "SOC 2 CC6.6", "NIST 800-207"], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **OIDC Workload Identity Federation Audience Confusion (ATT&CK T1552.001 / Real-World: 2023 CircleCI breach):** An attacker who compromises a CI/CD OIDC token can replay it against any cloud workload identity binding that lacks a strict `sub` or `aud` claim condition. In the CircleCI incident, stolen environment secrets (equivalent to unconstrained OIDC tokens) allowed lateral movement into customer AWS accounts. Test by: forge a JWT with a valid `iss` but mismatched `sub` claim and POST it to the token exchange endpoint (`sts.amazonaws.com` / `iam.googleapis.com`) — if it returns credentials, the binding is misconfigured. Finding threshold: any workload identity binding without an exact `sub` match condition or accepting wildcard audience is a CRITICAL finding.
+
+- **eBPF Sidecar Bypass for mTLS Interception (CVE-2023-2728 / ATT&CK T1040):** A container with `CAP_BPF` or `CAP_NET_ADMIN` can attach an eBPF program to a cgroup socket that intercepts plaintext traffic before the Istio/Envoy sidecar encrypts it, silently breaking the mTLS guarantee without any `PeerAuthentication` policy change. CVE-2023-2728 demonstrated privilege escalation via Kubernetes admission bypass enabling unsafe capabilities. Test by: run `kubectl exec` into a pod and attempt `bpftool prog load` — if successful without privileged SCC/PSA, the cluster allows eBPF-based interception. Finding threshold: any pod with `CAP_BPF`, `CAP_NET_ADMIN`, or `privileged: true` in a namespace with mTLS-protected workloads is a HIGH finding.
+
+- **AI-Assisted Lateral Movement via Mesh Trust Graph Enumeration (ATT&CK T1046 / Research: "Graph-of-Thought" LLM pivot chains, 2024):** An attacker with a single compromised pod can use an LLM (GPT-4o, local Llama) to automatically enumerate all reachable services via DNS resolution, parse Kubernetes RBAC and AuthorizationPolicies from the API server (if `system:discovery` is granted), and generate a ranked list of lateral movement paths in under 60 seconds — faster than any SOC analyst can triage. This was demonstrated in academic research on LLM-assisted network reconnaissance in 2024. Test by: from a low-privilege pod, run `kubectl get authorizationpolicies -A` and `curl -k https://kubernetes.default.svc/api/v1/services` — if either succeeds without explicit binding, automated enumeration is possible. Finding threshold: any unauthenticated or over-permissive API server discovery response in a ZTA-claimed environment is a CRITICAL control failure.
+
+- **Post-Quantum Harvest-Now-Decrypt-Later Against mTLS Session Keys (NIST FIPS 203 / ATT&CK T1040):** Nation-state adversaries are actively capturing encrypted east-west traffic (Shodan-scale passive capture) with the intent to decrypt it once cryptographically relevant quantum computers (CRQCs) are available (~2028–2032). Current mTLS using ECDHE-P256 or X25519 provides no forward secrecy against a CRQC. NIST finalized ML-KEM (Kyber) as FIPS 203 in 2024 — service meshes must begin hybrid TLS migration now. Test by: `openssl s_client -connect <service>:<port>` and inspect the `Server Temp Key` line — if it shows `ECDH, P-256` or `X25519` without a PQ hybrid, the session is harvest-vulnerable. Finding threshold: any mTLS endpoint not offering a `X25519MLKEM768` or equivalent PQ hybrid cipher suite is a MEDIUM finding today, escalating to CRITICAL after 2027.
+
+- **Continuous Validation Token Replay Within Revocation Cache TTL (CWE-613 / ATT&CK T1550.001):** Even with per-request JWT validation, if the token revocation cache has a TTL of 30–300 seconds (common Redis defaults), a stolen token remains valid for the full TTL window. An attacker who exfiltrates a token via XSS or a compromised log sink has a guaranteed replay window. The `jti` (JWT ID) claim is the only reliable per-token uniqueness marker, but most implementations check only expiry. Test by: authenticate to obtain a valid JWT, call `POST /auth/logout` (or equivalent revocation), then immediately replay the same token to a protected endpoint — if it returns 200, the revocation cache is not consulted on every request. Finding threshold: any successful authenticated request using a token after explicit revocation is a HIGH finding; TTL > 60 seconds on the revocation cache is a MEDIUM finding.
+
+- **EU Cyber Resilience Act (CRA) Mandatory Attestation Gap for Service Mesh Components (Regulatory Deadline: 2027 / Supply Chain Risk):** The EU CRA (effective 2024, enforcement 2027) requires software attestation and SBOM for any "product with digital elements" — this explicitly includes service mesh control-plane and data-plane components (Istio, Envoy, Linkerd) when deployed in products sold to EU customers. Organizations without a CycloneDX or SPDX SBOM for their mesh components, and without SLSA Level 2 provenance for internal service images traversing the mesh, face regulatory non-compliance and potential market exclusion. Test by: run `syft image istio/pilot:<version> -o cyclonedx-json` and `cosign verify <image>` against the mesh control-plane image — if either fails or returns no provenance attestation, the component is CRA non-compliant. Finding threshold: any mesh component without a verifiable SBOM and SLSA L2+ attestation in a product targeting EU markets is a HIGH compliance finding with a hard 2027 deadline.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 Zero Trust 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 | mTLS bypass via permissive `PERMISSIVE` mode left on one namespace | Scanners check that Istio is installed; they do not enumerate PeerAuthentication mode per namespace | `kubectl get peerauthentication -A -o json \| jq '.items[] \| select(.spec.mtls.mode != "STRICT")'` — any non-STRICT namespace is an open east-west pivot |
+| 2 | JWT `alg:none` accepted by internal service that trusts sidecar validation | Services may skip JWT verification assuming the sidecar already verified it; attacker forges token with `alg:none` and bypasses sidecar by calling the pod port directly | Port-forward directly to the container port (bypassing Istio sidecar) and send a token with `"alg":"none","typ":"JWT"` — check if the service accepts it |
+| 3 | Workload Identity federation misconfiguration allows cross-project impersonation | IAM binding `roles/iam.workloadIdentityUser` set on `allUsers` or a wildcard service account audience | `gcloud iam service-accounts get-iam-policy SA_EMAIL` — look for `allUsers` or overly broad `principalSet` in the binding condition |
+| 4 | Kubernetes NetworkPolicy allows `0.0.0.0/0` egress — microsegmentation is illusory | NetworkPolicy `ingress` rules are reviewed; `egress` rules that permit all outbound are ignored | `kubectl get networkpolicy -A -o json \| jq '.items[] \| select(.spec.egress[]?.to == null)'` — null egress selector = allow all |
+| 5 | Continuous validation middleware skipped for webhook/internal callback endpoints | Middleware chains are written for user-facing routes; internal webhook receivers and health-check endpoints are registered before the auth middleware | Enumerate all routes registered before the auth middleware chain; send unauthenticated POST to each `/webhook`, `/callback`, `/internal/*` path |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that ZTA defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to Zero Trust | Prepare Now By |
+|--------|--------------|-------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) breaks mTLS certificate chains | 2028–2032 | All TLS 1.3 session keys negotiated with ECDHE are retroactively breakable via harvest-now-decrypt-later; PKI underpinning mTLS is compromised | Inventory all internal CA and mTLS certificate algorithms; plan migration to ML-KEM (FIPS 203) hybrid TLS; begin testing TLS agility in service mesh |
+| AI-assisted lateral movement: LLM-generated pivot chains from minimal foothold | 2025–2027 (active) | Attacker with a single compromised pod can use AI to auto-enumerate misconfigured trust paths across the mesh in minutes | Assume an attacker inside the mesh has full AI-assisted enumeration; audit every AuthorizationPolicy for least-privilege completeness, not just the obvious paths |
+| Workload identity federation attacks on cloud-native CI/CD | 2025–2026 (active) | OIDC-based workload identity is the new target: compromise the OIDC issuer or misconfigure audience binding to escalate from CI runner to prod IAM role | Enforce strict `sub` and `aud` claim conditions on every workload identity binding; rotate trusted OIDC issuers list quarterly |
+| EU CRA mandatory device attestation requirements | 2026–2027 | Connected devices accessing enterprise resources must provide hardware attestation; soft device posture checks will no longer satisfy regulatory compliance | Migrate device trust from agent-reported posture to hardware-backed attestation (TPM 2.0 / Apple Secure Enclave) before CRA enforcement |
+| eBPF-based kernel exploits bypassing sidecar-based mTLS | 2026–2028 | eBPF programs with `CAP_BPF` can intercept traffic before it reaches the Istio sidecar, rendering mTLS inspection moot | Restrict `CAP_BPF` via Kubernetes admission; deploy Falco eBPF rules to detect unauthorized BPF program loads; evaluate kernel-level mTLS (WireGuard CNI) as defence-in-depth |
+| Mandatory SBOM + SLSA for service mesh components (US EO 14028 / EU CRA) | 2025–2026 (active) | Istio, Envoy, and Linkerd are in-scope for SBOM requirements; unattested mesh components in the data path are a supply-chain risk | Generate CycloneDX SBOM for all mesh control-plane and data-plane components; achieve SLSA L2 minimum for internal service images traversing the mesh |
+
+---
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in a Zero Trust architecture, and what to build to close each gap.
+
+**ZTA-specific gaps that MUST be checked:**
+
+- **mTLS certificate impersonation via stolen workload cert**: If a pod's private key is exfiltrated (e.g., through a container escape), the attacker can impersonate that workload identity indefinitely until cert rotation. Standard logs show valid mutual authentication — no alert fires. Need: cert lifetime monitoring (alert on any cert with TTL > 24h for workload identities); detect private key material appearing outside the expected pod filesystem path via Falco rule `(fd.name startswith "/proc/" and fd.name contains "ssl/private")`.
+- **Sidecar bypass via direct pod-to-pod IP call**: A compromised pod calling another pod's IP directly on the container port (not the mesh port) bypasses Istio entirely — the PeerAuthentication policy is never evaluated. Need: Falco or eBPF network rule alerting on any TCP connection to a pod port that does not originate from `127.0.0.1` (the sidecar) or the CNI bridge.
+- **Token replay within the continuous validation window**: A stolen JWT is valid until the next revocation check cycle. If the revocation cache TTL is 60 seconds, an attacker has a 60-second replay window per stolen token. Need: per-`jti` usage frequency monitoring — flag any `jti` value seen more than once per second across different source IPs.
+- **Gradual privilege creep through AuthorizationPolicy drift**: Individual AuthorizationPolicy changes are individually reviewed and approved, but over months the cumulative effect is a service that can call every other service in the mesh. Standard SIEM looks at individual changes, not cumulative access graphs. Need: weekly AuthorizationPolicy graph diff — compare current effective access graph to the baseline and alert on any new service-to-service path added since last week.
+- **Cross-agent ZTA attack chains invisible to individual scanners**: An IP-based trust finding from network scan + a long-lived credential finding from IAM scan = a CRITICAL lateral movement chain (pivot to trusted IP, then use long-lived credential for persistence). Neither scanner flags the chain. Need: CISO orchestrator Phase 1 synthesis — correlate all ZTA findings across agents before Phase 2 to surface compound chains.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any ZTA 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 ZTA attack classes — all must be covered:**
+
+| Attack Class | Patterns to Search | Files to Check |
+|---|---|---|
+| IP-based implicit trust | `req.ip`, `startsWith("10.")`, `trusted.*subnet`, `internal.*network` | All API middleware, gateway config |
+| Missing mTLS enforcement | `PeerAuthentication`, `mtls.mode`, `PERMISSIVE` | All `k8s/**/*.yaml`, Istio config |
+| Long-lived service credentials | `serviceAccountKey`, `credentials.json`, `GOOGLE_APPLICATION_CREDENTIALS` pointing to file | Dockerfile, CI config, env files |
+| Missing NetworkPolicy egress restriction | `egress: []`, null egress selector | All NetworkPolicy manifests |
+| JWT `alg:none` or weak algorithm acceptance | `alg.*none`, `algorithms.*["none"]`, `verify.*false` | All JWT validation code |
+| Continuous validation bypass | route registration before auth middleware, `/webhook`, `/internal`, `/callback` without auth | All router/server entrypoints |
+| Workload Identity audience misconfiguration | `allUsers`, wildcard `principalSet` in IAM bindings | All Terraform IAM, GCP IAM policy files |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "IP-Based Implicit Trust", "filesReviewed": 23, "patterns": ["req.ip", "startsWith(\"10.\")", "trusted.*subnet"], "result": "CLEAN" },
+      { "class": "Missing mTLS Enforcement", "filesReviewed": 14, "patterns": ["PeerAuthentication", "mtls.mode", "PERMISSIVE"], "result": "2 findings, both fixed" }
+    ],
+    "filesReviewed": 47,
+    "negativeAssertions": ["IP-Based Implicit Trust: pattern searched across 23 files — 0 matches"],
+    "uncoveredReason": {}
+  }
+}
+```