security-mcp 1.1.4 → 1.3.1

package/skills/anti-replay-tester/SKILL.md

@@ -193,3 +193,109 @@ const paymentIntent = await stripe.paymentIntents.create(
 - `requiredActions`: ordered action list
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true if finding goes beyond the SKILL.md mandate
+- `intelligenceForOtherAgents`: structured hints for downstream agents (see schema below)
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "JWT with no jti and 24h expiry — stolen token has full replay window", "exploitHint": "Capture token from network log; replay raw Authorization header until expiry" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "HMAC-SHA256 webhook signature without timestamp binding", "location": "src/webhooks/handler.ts" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Replay of signed S3 presigned URL beyond expiry window via missing server-side nonce check", "escalationPath": "Replayed presigned URL → S3 read of other-tenant objects if bucket policy is broad" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI-DSS Req 8.3.9", "SOC2 CC6.1"], "releaseBlock": true }]
+  }
+}
+```
+
+## §EDGE-CASE-MATRIX
+
+The 5 anti-replay 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 | JWT replay after logout via a second session | Revocation check is scoped to the session that issued the token; a token captured before logout on device A remains valid on device B until natural expiry | Issue JWT on session A; log out session A; replay raw `Authorization: Bearer <token>` from a fresh client — should reject with 401 |
+| 2 | Webhook event ID collision across environments | Dev and staging share the same event-ID namespace; seen-nonce table is not environment-scoped, so a prod event ID replayed in staging is silently dropped (or vice-versa) | Send a webhook with `id=evt_prod_123` to the staging endpoint; verify the nonce store is keyed as `env:eventId`, not bare `eventId` |
+| 3 | OAuth authorization code reuse on clock-skew boundary | Code was issued at T; validator uses server clock T+6s; 5-minute code window has expired but the off-by-one in `<=` vs `<` accepts it; a second use 1 ms later also succeeds | Replay the same authorization code twice in rapid succession from different IPs — both should succeed if the comparison is `exp >= now` instead of `exp > now` |
+| 4 | SAML assertion replay via XML signature wrapping | The signature is valid on the outer element; a scanner checks signature validity, not that the signed element and the processed element are the same node | Use a signature-wrapping tool (e.g., saml-raider) to duplicate the assertion node; submit; verify the IdP or SP rejects a duplicate `InResponseTo` or missing `jti`/`ID` tracking |
+| 5 | Idempotency key fixation by attacker-controlled client | Attacker knows the key pattern (`userId_orderId_timestamp`); they pre-send a request with the same predicted key and a lower amount; the legitimate retry is deduplicated against the fraudulent first request | Generate the idempotency key server-side using a cryptographically random component the client cannot predict; confirm client-supplied keys are rejected or ignored |
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that anti-replay defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to Anti-Replay | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | HMAC-SHA256 webhook signatures and JWT HMAC-HS256 are not broken by Shor's algorithm, but RSA/ECDSA-signed JWTs (RS256, ES256) will be; captured tokens signed today can be forged in the post-CRQC window | Inventory all RS256/ES256 JWTs; migrate long-lived signing keys to ML-DSA (FIPS 204); prefer short-expiry tokens to minimise the harvest-now-replay-later window |
+| AI-assisted token capture and replay at scale | 2025–2027 (active) | LLM-assisted attack tooling automates intercepting tokens from mobile app traffic, browser storage, and log files at scale — then bulk-replays them | Enforce jti tracking in Redis with per-token revocation; rotate signing keys on a 90-day schedule; alert on >3 concurrent sessions per user |
+| WebAuthn / Passkey widespread adoption | 2025–2026 | As passkeys replace passwords, the replay attack surface shifts to the challenge-response nonce in the WebAuthn assertion; implementations that reuse challenges are trivially exploited | Validate `challenge` in every WebAuthn assertion against a server-side nonce store with 60-second TTL; never accept a challenge not issued by your server |
+| EU AI Act full enforcement | 2026 | Auth systems powering high-risk AI features must demonstrate replay protection as part of conformity assessment | Document anti-replay controls in system-security plan; map to AI Act Article 9 risk management requirements |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | Replay protection libraries (jose, jsonwebtoken) must appear in SBOM with pinned versions; outdated versions with CVEs become compliance blockers | Generate CycloneDX SBOM per release; track CVE status for all JWT/crypto dependencies; auto-alert on new CVEs in jose, jsonwebtoken, passport-jwt |
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in anti-replay attacks, and what to build to close each gap.
+
+**Gaps that MUST be checked:**
+
+- **jti reuse across microservices with separate Redis clusters**: Each service validates the JWT signature but checks jti in its own local cache; a token can be replayed once per service. Standard SIEM only sees individual service auth events, not cross-service jti fan-out. Need: centralised jti revocation store (shared Redis Sentinel or distributed cache) with a cross-service read; SIEM query correlating the same `jti` value appearing in auth logs for more than one distinct service within the token's validity window.
+
+- **Webhook replay within the timestamp tolerance window**: A 5-minute tolerance window is standard (Stripe uses 300 s). An attacker who captures a signed webhook can replay it up to 299 seconds later and pass all checks if the event-ID nonce store is not consulted. Standard WAF and signature-validation logs show "signature valid" — they do not log nonce-store hits. Need: explicit log event `webhook.nonce_check` (pass/fail) emitted after the nonce lookup, separate from the signature-validation log event; alert on any `nonce_check=fail` that is not preceded by a `signature=fail`.
+
+- **OAuth PKCE code_verifier brute-force**: The authorization code is captured (e.g., via redirect-URI mismatch); the attacker then brute-forces short `code_verifier` values. No rate limiting exists on the token endpoint in many implementations. Standard auth logs show token endpoint 400s but not the pattern of repeated attempts per `code`. Need: rate limit the token endpoint per `code` value (max 3 attempts); alert on >1 failed token exchange for the same `code`.
+
+- **Idempotency key exhaustion / collision DoS**: Attacker sends many requests with the same idempotency key but varying payloads to fill the deduplication store and force legitimate retries to be silently dropped. No log event emitted for dropped-as-duplicate requests in most payment libraries. Need: log every idempotency deduplication event with original request hash vs current request hash; alert when a key is reused with a *different* payload (indicates either a bug or an attack).
+
+- **Cross-agent finding chains invisible to single-agent review**: A missing `jti` finding (anti-replay-tester) combined with a SSRF finding (ssrf-scanner) could allow an attacker to obtain a valid JWT from an internal metadata service and replay it externally. Neither agent alone sees this chain. Need: CISO orchestrator Phase 1 synthesis step — correlate anti-replay findings with credential-exposure findings before Phase 2 penetration testing.
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any anti-replay 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.
+
+Attack classes that MUST be covered:
+
+| Class | Grep Patterns | Expected Finding ID if Vulnerable |
+|-------|--------------|-----------------------------------|
+| JWT jti tracking | `jti`, `jwt:jti:`, `seenTokens`, `usedJtis` | `ANTI_REPLAY_JWT_NO_JTI` |
+| JWT logout revocation | `revokeToken`, `blacklist`, `redis.*jti`, `signOut` | `ANTI_REPLAY_JWT_NO_REVOCATION` |
+| Webhook timestamp window | `WEBHOOK_TOLERANCE`, `timestamp.*300`, `t=.*,v1=` | `ANTI_REPLAY_WEBHOOK_NO_TIMESTAMP` |
+| Webhook event-ID nonce | `seenNonces`, `processedEvents`, `eventId.*exists` | `ANTI_REPLAY_WEBHOOK_NO_NONCE` |
+| OAuth nonce / PKCE | `nonce`, `code_verifier`, `code_challenge`, `PKCE` | `ANTI_REPLAY_OAUTH_NO_NONCE` |
+| Payment idempotency key | `idempotencyKey`, `Idempotency-Key`, `idem` | `ANTI_REPLAY_PAYMENT_NO_IDEMPOTENCY` |
+| SAML assertion ID tracking | `InResponseTo`, `assertionId`, `saml.*replay` | `ANTI_REPLAY_SAML_NO_ASSERTION_TRACKING` |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "JWT jti tracking", "filesReviewed": 12, "patterns": ["jti", "jwt:jti:", "seenTokens"], "result": "CLEAN" },
+      { "class": "Webhook timestamp window", "filesReviewed": 4, "patterns": ["WEBHOOK_TOLERANCE", "t=.*,v1="], "result": "1 finding, fixed" }
+    ],
+    "filesReviewed": 47,
+    "negativeAssertions": [
+      "JWT jti tracking: pattern 'jti' searched across 12 auth files — present in all token-issuance paths",
+      "Payment idempotency: 'idempotencyKey' found in all 3 payment creation call sites"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **JWT Replay via Leaked Refresh Tokens in CI Logs (CVE-2023-49803 / ATT&CK T1552.001):** Long-lived refresh tokens for OAuth2 flows (e.g., GitHub Actions OIDC tokens) are inadvertently printed to CI stdout and harvested from public build logs. The refresh token is replayed hours or days later to mint new access tokens. Test by: grep CI pipeline logs for `refresh_token=`, `Bearer ey`, and `authorization_code=` patterns using `truffleHog` or `gitleaks`; then attempt to exchange a captured refresh token against the token endpoint — a finding is confirmed if the exchange succeeds after the issuing job has completed and the token has not been revoked.
+
+- **AI-Assisted Mass JWT Replay via LLM-Powered Traffic Analysis (ATT&CK T1550.001):** Attacker uses an LLM (e.g., via the Burp AI assistant or a custom GPT-4 script) to parse gigabytes of captured HAR files, extract every `Authorization: Bearer` header, deduplicate by expiry, and queue valid tokens for parallel replay across target endpoints. The attack requires no MITM — only access to exported browser traffic or CDN access logs. Test by: export a browser HAR file containing 50+ authenticated requests; run `python jwt_harvester.py <file.har>` (open-source tool); confirm that at least one replayed token returns HTTP 200 on a state-changing endpoint rather than 401. Finding threshold: any token accepted more than once on a non-idempotent endpoint.
+
+- **SAML Assertion Replay via XML Signature Wrapping (CVE-2017-11427 / ATT&CK T1606.002):** The SP validates the HMAC/RSA signature on the outer `<samlp:Response>` element but processes a cloned `<saml:Assertion>` node injected as a sibling. The signed element and the evaluated element are different DOM nodes — signature is valid, assertion is attacker-controlled. Affects SimpleSAMLphp, OneLogin, and custom SP implementations. Test by: use `saml-raider` (Burp extension) to perform a signature-wrapping mutation on a captured SAML response; inject a second `<saml:Assertion>` with elevated `<saml:Attribute>` values; replay to the SP's ACS endpoint — finding confirmed if the SP accepts the wrapped response and grants elevated privileges. Also verify the SP tracks `InResponseTo` and assertion `ID` attributes against a nonce store.
+
+- **Post-Quantum Harvest-Now-Replay-Later on RS256/ES256 JWTs (NIST IR 8413 / ATT&CK T1040):** Adversaries with access to encrypted traffic archives (nation-state interceptors, long-term PCAP storage) are collecting RS256/ES256-signed JWTs today with intent to forge signatures once a Cryptographically Relevant Quantum Computer (CRQC) breaks RSA/ECDSA (~2028–2032 per NIST). A forged JWT bearing a valid-looking signature can be replayed long after the original user session — especially against services that do not enforce `jti` revocation or tight expiry windows. Test by: audit all JWT-issuing code for `algorithm: RS256` or `algorithm: ES256`; inventory key lengths (`openssl rsa -text -noout -in jwt.pem`); confirm no JWT has expiry >15 minutes. Finding threshold: any RS256/ES256 JWT with `exp - iat > 900` seconds or any service without per-token `jti` revocation is a confirmed post-quantum harvest risk.
+
+- **WebAuthn Challenge Reuse Enabling Credential Replay (CVE-2021-41183 pattern / ATT&CK T1550.002):** Implementations that generate the WebAuthn `challenge` once per user (stored in a persistent session) rather than per-authentication ceremony allow an intercepted `authenticatorAssertionResponse` to be replayed in a new session. The server accepts the response because the stored challenge matches, even though the response was captured from a different browser context. Affects custom WebAuthn RP implementations that skip per-ceremony nonce rotation. Test by: capture a valid `authenticatorAssertionResponse` JSON blob using a MITM proxy; open a second incognito browser session; replay the captured response to the `/api/auth/webauthn/authenticate` endpoint — if the server stores the challenge in a database row (not a one-time Redis key with 60 s TTL), the replay succeeds. Finding threshold: server accepts a replayed `authenticatorAssertionResponse` more than once, or challenge TTL exceeds 120 seconds.
+
+- **Supply Chain Replay via Compromised Idempotency Key Generation in Stripe SDK Fork (CVE-2022-24434 pattern / ATT&CK T1195.001):** A malicious or backdoored fork of `stripe-node` (or `stripe-php`) generates predictable idempotency keys based on `userId + orderId + Math.floor(Date.now() / 1000)` — a pattern that an insider or supply-chain attacker can pre-compute and pre-register with a lower payment amount. When the legitimate payment fires, Stripe deduplicates it against the attacker's pre-registered fraudulent request. Test by: run `npm audit signatures` and `npm ls stripe` to verify the installed package matches the published registry checksum; inspect the idempotency key generation function for entropy — keys must include `crypto.randomBytes(16).toString('hex')`; attempt to pre-register a Stripe `PaymentIntent` with a predicted key and then trigger the legitimate checkout flow — finding confirmed if Stripe returns the fraudulent pre-registered intent.

package/skills/appsec-code-auditor/SKILL.md

@@ -119,3 +119,88 @@ You cannot call `orchestration.update_agent_status("completed")` while any HIGH/
 Write `.mcp/agent-runs/{agentRunId}/appsec-findings.json` following the AgentFindingsFile schema.
 Each finding MUST include `exploitChain[]` showing step-by-step reproduction.
 Each remediated finding MUST reference the exact file + line number changed.
+
+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": "SQL Injection", "filesReviewed": 47, "patterns": ["queryRaw", "string concat"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["SQL Injection: queryRaw pattern searched across 47 files — 0 matches"],
+    "uncoveredReason": {}
+  }
+}
+```

package/skills/artifact-integrity-analyst/SKILL.md

@@ -66,3 +66,444 @@ and provenance. Covers §5 Supply Chain Security fully.
 - Missing signing, provenance, or SBOM controls
 - CI workflow additions to implement the missing control
 - §5 SLSA control reference per finding
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "...", "exploitHint": "..." }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "...", "location": "..." }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "...", "escalationPath": "..." }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["..."], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+### 1. Typosquatting & Dependency Confusion (CVE-class: supply chain namespace collision)
+
+**Attack:** An attacker publishes a malicious package to a public registry (npm, PyPI) with a
+name that matches an internal private package. When the build system resolves dependencies, it
+preferentially pulls the public (malicious) version if the public version number exceeds the
+private registry's version — the dependency confusion attack (Alex Birsan, 2021, HackerOne).
+
+**Detection method:**
+```bash
+# List all package names in package.json / requirements.txt
+# Check whether each name exists in the public registry
+npm info <internal-package-name> --json 2>/dev/null | jq '.name'
+# If a result is returned for an internal-only name, this is a confirmed dependency confusion risk
+# Also check: .npmrc / pip.conf — is `--index-url` or `registry` scoped to private registry ONLY?
+grep -r "registry" .npmrc .yarnrc .yarnrc.yml pip.conf pyproject.toml 2>/dev/null
+```
+
+**Finding:** Any internal package name resolvable from the public registry without explicit
+`@scope` namespace enforcement or a registry-precedence lock constitutes a HIGH finding.
+
+---
+
+### 2. Build-Time Code Injection via Malicious CI Action (SLSA Build Integrity)
+
+**Attack:** A referenced GitHub Actions action (`uses: org/action@v2`) resolves to a mutable
+tag. If the action maintainer's account is compromised, a malicious commit can be pushed to
+the same `v2` tag, causing every downstream build to execute attacker-controlled code inside
+the trusted CI environment — identical to the SolarWinds build-time injection pattern.
+
+**Detection method:**
+```bash
+# Find all GitHub Actions workflow files
+find . -path "./.github/workflows/*.yml" -o -path "./.github/workflows/*.yaml" | \
+  xargs grep -n "uses:" | grep -v "@[0-9a-f]\{40\}"
+# Any 'uses:' line not pinned to a full 40-character SHA is a finding
+# Example of finding: uses: actions/checkout@v4  (mutable)
+# Expected: uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  (pinned)
+```
+
+**Finding:** Any `uses:` reference not pinned to a full commit SHA is HIGH.
+Reference: SLSA L2+ requires pinned, versioned action references.
+
+---
+
+### 3. Rekor Transparency Log Tampering Detection
+
+**Attack:** An adversary with access to a CI signing key signs a backdoored artifact and
+publishes the signature to Sigstore's Rekor transparency log. Because the artifact is signed,
+admission controllers approve it. The key compromise may go undetected if the log is not
+monitored for unexpected entries against a known-good policy.
+
+**Detection method:**
+```bash
+# Verify a container image's Rekor log entry matches expected workflow
+cosign verify \
+  --certificate-identity-regexp="https://github.com/<org>/<repo>/.github/workflows/release.yml" \
+  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
+  <image>@<digest>
+
+# Enumerate all Rekor entries for a given artifact hash
+rekor-cli search --sha "$(sha256sum artifact.tar.gz | cut -d' ' -f1)"
+# Unexpected entries from a non-CI identity = compromised signing key
+```
+
+**Finding:** Cosign identity mismatch between expected workflow URL and actual certificate
+subject is a CRITICAL finding. Trigger §PROJECT-ESCALATION immediately.
+
+---
+
+### 4. AI-Assisted Malicious Package Detection (Emerging Threat — 2025+)
+
+**Attack:** LLM-assisted adversaries generate syntactically legitimate but semantically
+malicious packages that evade keyword-based scanners. Packages contain delayed-execution
+payloads (e.g., triggered after 30 days or after N installs), encrypted C2 channels inside
+seemingly benign HTTP requests, or steganographic payloads in bundled assets. This technique
+was observed in the `xz-utils` backdoor (CVE-2024-3094) — a years-long social-engineering
+and code-poisoning campaign.
+
+**Detection method:**
+```bash
+# Static entropy analysis of bundled files — high entropy = potential encrypted payload
+python3 -c "
+import math, sys
+data = open(sys.argv[1],'rb').read()
+freq = {}
+for b in data: freq[b] = freq.get(b,0)+1
+entropy = -sum((c/len(data))*math.log2(c/len(data)) for c in freq.values())
+print(f'Entropy: {entropy:.3f}')
+" <file>
+# Entropy > 7.5 bits/byte on a non-compressed file is suspicious
+
+# Behavioral analysis: install in isolated sandbox, trace syscalls
+strace -e trace=network,file npm install <suspicious-package> 2>&1 | grep -E "(connect|open)"
+```
+
+**Finding:** Packages with unexplained high-entropy bundled assets, network syscalls during
+install scripts, or `postinstall` hooks that download external resources are HIGH findings.
+
+---
+
+### 5. Post-Quantum Signature Downgrade (Emerging Threat — FIPS 204/205 transition)
+
+**Attack:** As NIST finalises ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for code signing,
+systems that advertise support for hybrid classical/post-quantum signatures but fall back to
+ECDSA-only when the PQ algorithm is unavailable are vulnerable to active downgrade attacks.
+An adversary performing a MitM on artifact delivery can strip the PQ signature layer,
+leaving only the classical ECDSA signature — which will be breakable by a CRQC.
+
+**Detection method:**
+```bash
+# Check if Cosign or in-house signing supports ML-DSA or hybrid PQ schemes
+cosign version  # Look for PQ-capable release >= 2.4 (experimental)
+# Check signing policy for downgrade enforcement
+grep -r "algorithm\|key-type\|signing-algorithm" cosign.yaml policy.yaml 2>/dev/null
+# If no policy enforces PQ-only or hybrid-minimum, flag as MEDIUM (escalates to HIGH by 2027)
+```
+
+**Finding:** No post-quantum signing capability, no PQ migration roadmap, or policies that
+allow silent downgrade to classical-only signing is a MEDIUM finding today, escalating
+timeline to HIGH by 2027 per NIST PQC migration guidance.
+
+---
+
+### 6. SBOM Completeness Evasion via Indirect Dependency Omission
+
+**Attack:** SBOMs generated by shallow tools (e.g., `npm ls --depth=0`) omit transitive
+dependencies. A compromised transitive dependency (e.g., the `event-stream` npm incident,
+2018) is invisible to the SBOM consumer, who believes the SBOM is complete. The US Executive
+Order 14028 and the EU Cyber Resilience Act both require *complete* SBOMs including all
+transitive dependencies.
+
+**Detection method:**
+```bash
+# Generate full-depth SBOM and compare node count against shallow SBOM
+syft <image> -o cyclonedx-json > sbom-full.json
+jq '.components | length' sbom-full.json
+
+# Compare against any checked-in SBOM
+jq '.components | length' sbom-checked-in.json
+
+# Diff: if full SBOM has significantly more components, shallow SBOM is incomplete
+# Also verify: every component in the full SBOM has a valid PURL
+jq '[.components[] | select(.purl == null or .purl == "")] | length' sbom-full.json
+# Non-zero = components without PURL = SBOM non-compliant with CycloneDX spec
+```
+
+**Finding:** SBOM missing transitive dependencies, or components lacking valid PURLs, is a
+HIGH finding under US EO 14028 §4(e) and EU CRA Article 13.
+
+---
+
+### 7. Immutable Tag Bypass via Registry API (Container Supply Chain)
+
+**Attack:** Even when a container registry is configured with `imageTagMutability: IMMUTABLE`
+(ECR) or equivalent, some registry APIs expose administrative endpoints that allow tag
+reassignment under specific IAM conditions. An over-permissioned CI role or a compromised
+registry admin credential can silently reassign an immutable tag to a different digest without
+triggering standard audit logs, breaking the deployment assumption that the tag points to a
+known-good image.
+
+**Detection method:**
+```bash
+# ECR: verify current tag -> digest mapping and compare to build-time expected digest
+aws ecr describe-images --repository-name <repo> \
+  --image-ids imageTag=latest \
+  --query 'imageDetails[0].imageDigest' --output text
+
+# Cross-reference against the digest recorded in the deployment manifest or SBOM
+grep "sha256:" deployment.yaml | head -5
+
+# Also: check ECR repository policy for any principal with ecr:PutImage on production repos
+aws ecr get-repository-policy --repository-name <repo> | \
+  jq '.policyText | fromjson | .Statement[] | select(.Effect=="Allow") | .Action'
+```
+
+**Finding:** Any IAM principal other than the designated CI role with `ecr:PutImage` or
+`ecr:BatchDeleteImage` on a production repository is a HIGH finding. Tag digest mismatch
+between deployment manifest and live registry is a CRITICAL finding.
+
+---
+
+## §ARTIFACT_INTEGRITY_ANALYST-CHECKLIST
+
+1. **Mutable action references in CI:** Scan all `.github/workflows/*.yml` for `uses:` lines
+   not pinned to a 40-character commit SHA. Grep: `uses:.*@` then filter out 40-char hashes.
+   Finding: any mutable tag reference (`@v1`, `@main`, `@latest`).
+
+2. **SLSA level determination:** Read CI pipeline definitions; identify whether a hosted build
+   service is used (L2) and whether the build platform is hardened + isolated (L3). Grep for
+   `slsa-framework/slsa-github-generator` or equivalent. Finding: L1 or L2 for production
+   release artifacts.
+
+3. **Cosign signing step present:** Grep CI files for `cosign sign`. Verify signing occurs
+   *after* build, *before* push. Finding: no signing step, or signing occurs after push
+   (signature may not be associated with the correct digest).
+
+4. **Admission controller enforcement:** Check Kubernetes policy files for Kyverno
+   `ImageVerification` or Gatekeeper constraints. Grep: `imageVerification`, `cosign.dev`.
+   Finding: no admission policy enforcing signature verification at deploy time.
+
+5. **SBOM generation and publication:** Verify a `syft` or `cdxgen` step in CI that outputs
+   CycloneDX JSON. Verify SBOM is signed (`cosign attest --type cyclonedx`). Verify SBOM is
+   uploaded to Dependency-Track or equivalent. Finding: missing generation, missing signature,
+   or missing publication.
+
+6. **Base image digest pinning:** Grep all Dockerfiles for `FROM` lines. Any `FROM` without
+   `@sha256:` is a finding. Grep: `^FROM` then check for `@sha256:`.
+   Finding: any base image pinned only by tag.
+
+7. **Transitive SBOM completeness:** Run `syft` at full depth and compare component count to
+   any checked-in SBOM. Grep generated SBOM for components with null PURLs.
+   Finding: component count mismatch > 10% or any null PURL.
+
+8. **Registry tag mutability:** For ECR, run `aws ecr describe-repositories` and check
+   `imageTagMutability`. For GCR/GAR, check IAM for `artifactregistry.tags.update`.
+   Finding: `imageTagMutability: MUTABLE` on any production registry.
+
+9. **Provenance attestation in Rekor:** Run `cosign verify-attestation --type slsaprovenance`
+   against the production artifact. Verify the certificate subject matches the expected
+   GitHub Actions workflow URL. Finding: no attestation, or subject mismatch.
+
+10. **Dependency confusion namespace collision:** For each internal package name, query the
+    public registry. Grep `.npmrc` / `pip.conf` for scoped private-registry-only enforcement.
+    Finding: internal package name resolvable from public registry without scope enforcement.
+
+11. **Build reproducibility:** Attempt to reproduce the build from source using the recorded
+    provenance. Compare resulting artifact digest to the published digest.
+    Finding: digest mismatch = non-reproducible build = provenance cannot be trusted.
+
+12. **Over-permissioned CI IAM role:** Review the IAM role or service account used by CI.
+    Check for write permissions beyond the designated artifact repository. Grep Terraform/IaC
+    for `ecr:*`, `artifactregistry.repositories.*`, `storage.objects.*` with wildcard actions.
+    Finding: CI role with write access to registries, buckets, or repos beyond its build scope.
+
+---
+
+## §POC-REQUIREMENT
+
+For every CRITICAL or HIGH finding in the artifact integrity domain, the following sequence is
+MANDATORY before the finding is recorded:
+
+1. **Write the working PoC FIRST.** For each finding class, examples include:
+
+   - *Mutable action reference exploit:*
+     ```bash
+     # Simulate tag reassignment: verify that changing the action tag resolves different code
+     git ls-remote https://github.com/actions/checkout refs/tags/v4
+     # Record the current SHA, then show what a malicious reassignment would look like
+     # (do not execute against real repos — document the mechanism and reference real incidents)
+     ```
+
+   - *Dependency confusion exploit:*
+     ```bash
+     # Create a dummy package with a higher version number than the internal package
+     mkdir /tmp/confusion-poc && cd /tmp/confusion-poc
+     echo '{"name":"<internal-pkg-name>","version":"9999.0.0","main":"index.js"}' > package.json
+     echo 'console.log("DEPENDENCY CONFUSION EXECUTED");' > index.js
+     # Install in a test environment without registry scoping — confirm the public package wins
+     npm install <internal-pkg-name> --registry https://registry.npmjs.org
+     ```
+
+   - *Mutable tag image substitution:*
+     ```bash
+     # Record current digest for a mutable tag
+     docker pull <registry>/<image>:latest
+     docker inspect <registry>/<image>:latest --format='{{.Id}}'
+     # Demonstrate that a re-push with a different payload under the same tag is undetected
+     # by deployments that reference the tag rather than the digest
+     ```
+
+2. **Confirm the PoC reproduces the issue** in an isolated test environment. Record observed
+   impact (code execution, artifact substitution, build poisoning).
+
+3. **Write the fix** (digest pinning, scope enforcement, registry policy, etc.).
+
+4. **Verify the PoC fails against the fix.** Re-run the PoC steps and confirm the attack path
+   is closed.
+
+5. **Record in findings JSON:**
+   ```json
+   {
+     "findingId": "AIA-001",
+     "severity": "HIGH",
+     "exploitPoC": {
+       "steps": ["step 1 command", "step 2 command"],
+       "observedImpact": "description of what happened",
+       "pocVerified": true,
+       "fixVerified": true
+     }
+   }
+   ```
+
+**PoC skipping = finding severity automatically downgraded to MEDIUM.**
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately call `orchestration.update_agent_status` with `"CRITICAL_ESCALATION"` and halt
+normal execution flow when ANY of the following conditions are detected:
+
+1. **Active signing key compromise:** Rekor log contains a valid signature for a production
+   artifact from a certificate identity that does not match any known CI workflow URL. This
+   indicates either a key leak or an unauthorized signing event — the entire artifact fleet
+   may be compromised.
+
+2. **Backdoored dependency already deployed to production:** A dependency in the production
+   SBOM matches a known-malicious package hash (e.g., cross-referenced against OSS-Fuzz or
+   the OSV database) and the artifact is currently running in production. Immediate incident
+   response, not a scheduled fix.
+
+3. **Non-reproducible build with provenance mismatch:** The signed provenance claims a
+   specific source commit and build configuration, but a reproducibility attempt produces a
+   different artifact digest. This indicates the build was tampered between source and
+   publish — a SolarWinds-class event.
+
+4. **Registry tag reassignment detected:** The digest currently pointed to by a production
+   tag differs from the digest recorded at deployment time in the deployment manifest or
+   GitOps repo. An image has been silently swapped in production.
+
+5. **CI pipeline exfiltrating secrets to external endpoint:** Build logs or CI network traces
+   show outbound connections to non-whitelisted external IPs or domains during the signing or
+   build step. This indicates a compromised action or poisoned build environment.
+
+6. **Transitive dependency with RCE vulnerability (CVSS >= 9.0) in production SBOM:** The
+   SBOM cross-reference against OSV/NVD returns a critical RCE CVE for a component that is
+   loaded in the production artifact's runtime execution path (not dev-only).
+
+7. **SLSA provenance for a production release is entirely absent:** A production artifact
+   that customers receive has no provenance attestation of any kind. In regulated environments
+   (FedRAMP, PCI DSS 4.0), this alone is a compliance blocker that may require a release
+   recall or emergency patch.
+
+8. **Over-permissioned CI role with production write access AND recent credential rotation
+   failure:** The CI service account has not rotated credentials in over 90 days AND has write
+   access to production registries. Combined with any other finding, this represents an
+   unacceptably wide blast radius for a single compromised CI run.
+
+---
+
+## §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.
+
+**Artifact-integrity-specific gaps:**
+
+- **Silent tag reassignment in registries**: Standard CloudTrail/Audit Logs capture `PutImage` events but do not diff tag-to-digest mappings. Need: a scheduled Lambda/Cloud Function that polls each production tag's digest and alerts on any change not initiated by a known CI run.
+- **SBOM drift between release and runtime**: The signed SBOM reflects the artifact at build time; packages installed post-deployment (e.g., via entrypoint scripts) are invisible. Need: runtime SBOM diffing using Falco or Tetragon to detect new file writes to dependency directories after container start.
+- **Compromised transparency log entry**: Rekor is append-only but its consistency proof requires active monitoring. A client that never checks the inclusion proof can be served a forged log by a MitM. Need: automated `rekor-monitor` deployment that continuously verifies the log's consistency tree.
+
+---
+
+## §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": "Mutable Action Reference", "filesReviewed": 12, "patterns": ["uses:.*@(?![0-9a-f]{40})"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["Mutable action references: searched 12 workflow files — 0 unpinned references"],
+    "uncoveredReason": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "artifact-integrity-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.