security-mcp 1.1.4 → 1.3.3

package/skills/capec-code-mapper/SKILL.md

@@ -35,6 +35,15 @@ On every finding resolved, emit:
 }
 ```
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+The full suite of detection modules in `src/gate/checks/` — especially `injection-deep.ts`, `auth-deep.ts`, `api.ts`, and `secrets.ts` — are the deterministic floor you correlate CAPEC→CWE→ATT&CK chains across, not your ceiling. Treat their finding IDs as the minimum surface evidence, then reason past what single-line/single-file pattern matching can see — and APPLY the fix (Edit the vulnerable code), not just advise:
+
+- **Cross-file / data-flow reasoning the regex can't do:** a `req.query` value (CAPEC-88 input surface) flowing through a util module into `$queryRaw` (CAPEC-66) is a taint chain neither the input-side nor sink-side grep resolves alone — trace source→sink across files to confirm the CAPEC mapping is live, not theoretical.
+- **Semantic / effective-state analysis:** for each CAPEC mapping, determine whether the mitigating control is *effective* (parameterized query actually used on the tainted path, `algorithms` pinned on the reached `jwt.verify`, authz enforced on the IDOR'd object) and build the compound CAPEC→CWE→CVE exploit chain.
+- **External corroboration:** use WebSearch/WebFetch for the current CAPEC catalog, CWE→CVE mappings on NVD, and D3FEND countermeasures for each mapped pattern.
+- **Apply & prove:** write the fix inline for each OPEN CAPEC finding, re-run the relevant `src/gate/checks/` modules plus semgrep as a regression floor, then re-audit the taint chain semantically. Emit the LEARNING SIGNAL per fix; surface any fix that changes intended behavior as an explicit trade-off with the secure default.
+
 ## EXECUTION
 
 ### Phase 1 — Reconnaissance
@@ -161,3 +170,87 @@ If internet permitted:
 - `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": "...", "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
+
+Domain-specific intelligence that extends beyond the base CAPEC mapping mandate:
+
+- **CAPEC-194 + CVE-2023-29374 (Spring Framework mass assignment)**: Auto-binding frameworks silently map attacker-controlled HTTP parameters to model fields. Grep for `@ModelAttribute`, `@RequestBody` without `@JsonIgnoreProperties` — one field difference between "safe" and "full account takeover."
+- **CAPEC-460 (HTTP Response Splitting) via CRLF injection** — still present in raw header-write code even in 2025; CVE-2023-24998 (Apache Commons FileUpload) demonstrates the chain. Search for `res.setHeader` with unsanitized user input.
+- **CAPEC-666 (Exploitation of Permissions via Confused Deputy) — AI/LLM era**: When an LLM agent can call tools on behalf of users, prompt injection (CAPEC-114) becomes a confused-deputy attack. Attacker-controlled document content tricks the LLM into invoking privileged tools with the user's credentials. No CVE yet, but PortSwigger Research 2024 demonstrated full account takeover via indirect prompt injection in a GenAI assistant.
+- **CAPEC-116 (Excavation via Differential Analysis) + post-quantum timing**: Classical constant-time code guarantees break under quantum simulation environments. Harvest-now-decrypt-later (HNDL) attacks mean RSA-2048 ciphertext captured today is already at risk. CVE-2024-28882 illustrates OpenSSH timing leakage. Inventory all `crypto.createDiffieHellman` and `crypto.generateKeyPairSync` calls for algorithm agility.
+- **CAPEC-153 (Input Data Manipulation) via GraphQL batching abuse** — CVE-2023-28425 (Redis) and analogous patterns in Apollo Server: attackers batch thousands of mutations in a single HTTP request, bypassing per-request rate limits. Check for `apollo-server` without `@graphql-armor/max-directives` or query-cost analysis.
+- **CAPEC-1 (Accessing Functionality Not Properly Constrained) in server-side AI tool calls**: LLM function-calling surfaces expose internal APIs to model-controlled dispatch. Without a capability allowlist, an attacker who controls the prompt controls which functions are called. Map every `tools: [...]` array in Anthropic/OpenAI SDK calls to a permission boundary check.
+- **CAPEC-56 (Removing/Adding Data Stores) via prototype pollution** — CVE-2022-37601 (webpack loader-utils), CVE-2023-26136 (tough-cookie): `__proto__` mutation still appears in lodash `_.merge` and `JSON.parse` + dynamic key assignment patterns. Grep for `Object.assign(target, userInput)` and `[userKey] =` with untrusted keys.
+- **CAPEC-549 (Local Execution of Code) via supply-chain compromised package** — post-quantum threat vector: adversaries use AI-generated lookalike packages (typosquatting at scale) to inject CAPEC-549 payloads. CVE-2024-21501 (sanitize-html bypass) illustrates how a "security" package itself became the attack vector. Verify every `package.json` dependency against npm provenance attestations (`npm audit signatures`).
+
+---
+
+## §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/cert-pin-rotation-specialist/SKILL.md

@@ -34,6 +34,15 @@ On every finding resolved, emit:
 }
 ```
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+The `crypto.ts` detection module (`src/gate/checks/crypto.ts`) — supported by `mobile-android.ts` and `mobile-ios.ts` for the pinning configs — is your deterministic floor, not your ceiling. Treat its finding IDs as the minimum, then reason past what single-line/single-file pattern matching can see — and APPLY the fix (Edit the pinning config / rotation runbook), not just advise:
+
+- **Cross-file / data-flow reasoning the regex can't do:** a `fetchPinUpdate()` that returns `null` on error in one file, wired to a pin-enforcement path in another, is a fail-open MitM window — the regex sees "safe error handling," not "pinning disabled."
+- **Semantic / effective-state analysis:** verify each pinned hash is a *SPKI* hash (not a leaf-cert fingerprint that breaks on renewal), that the backup pin value is genuinely distinct from the primary, that the OTA config is signature-verified before acceptance, and that the `expiration` date leaves real rotation headroom.
+- **External corroboration:** use WebSearch/WebFetch for the CA/B Forum 90-day-cert ballot, CT-log monitoring APIs (crt.sh), and FIPS 203/204 post-quantum migration guidance for pinned key algorithms.
+- **Apply & prove:** write the fix inline (add a distinct SPKI backup pin, make the OTA path fail-closed, add signature verification, wire a CI expiration-check gate), re-run the `crypto.ts` checks plus an `openssl` SPKI-extraction + duplicate-pin diff as a regression floor, then re-audit the rotation lifecycle semantically. Emit the LEARNING SIGNAL per fix; surface any fix that changes intended behavior as an explicit trade-off with the secure default.
+
 ## EXECUTION
 
 ### Phase 1 — Reconnaissance
@@ -198,3 +207,115 @@ export async function fetchPinUpdate(): Promise<string[] | null> {
 - `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": "App falls back to no pinning on pin-fetch failure — MitM window open during remote-config fetch", "exploitHint": "Block config.yourdomain.com at network layer; client reverts to no-pin mode" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "SHA-1 certificate fingerprint used as pin (not SPKI SHA-256)", "location": "android/res/xml/network_security_config.xml" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Remote pin-config fetch URL is user-controllable", "escalationPath": "Attacker supplies internal metadata endpoint as config URL; server fetches and returns cloud credentials" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI-DSS 4.2.1", "NIST SP 800-53 SC-17"], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **AI-Assisted Pin-Bypass Script Generation (ATT&CK T1557.002 — AiTM Phishing):** LLM-powered tools (e.g., Frida-AI wrappers seen in 2024 red-team toolkits) analyze an APK's OkHttp or TrustKit configuration at runtime and auto-generate a Frida hook script tailored to that app's specific pin-check method signature, bypassing pinning without touching network traffic. Test by: run `objection -g <package> explore --startup-command "android sslpinning disable"` on a debug build and verify the app refuses the MITM certificate anyway; then attempt the AI-generated hook against the release build and confirm certificate pinning still blocks the connection. Finding threshold: any release build where a generic objection script or auto-generated Frida hook bypasses pinning without requiring app-specific reverse engineering.
+
+- **90-Day Certificate Lifetime Ballot (CA/B Forum SC-081, effective 2026):** The CA/Browser Forum ballot SC-081 mandates maximum 90-day TLS certificate lifetimes by 2026, shattering rotation runbooks designed around 1–2-year certs. Apps that pin leaf SPKI hashes and rely on a 60-day pre-release update cycle will break quarterly. Test by: simulate a 90-day rotation in staging — revoke the pinned cert, issue a new one, measure the time from "backup pin shipped in app" to ">80% user adoption" via store analytics; if that window exceeds 30 days, the rotation model is broken. Finding threshold: any mobile app with an OTA pin-update path whose end-to-end propagation time exceeds 30 days, or any app without OTA rotation at all.
+
+- **Post-Quantum Harvest-Now-Decrypt-Later Against Pinned SPKI (NIST PQC FIPS 203/204):** Nation-state adversaries are capturing encrypted TLS sessions today with intent to decrypt when a cryptographically relevant quantum computer (CRQC) arrives (~2028–2032). SPKI pins based on RSA-2048 or P-256 public keys do not prevent harvest; they only authenticate the endpoint. Sessions pinned to a P-256 endpoint are captured and queued for CRQC decryption. Test by: inventory every pinned domain's current key algorithm via `openssl s_client -connect <host>:443 2>/dev/null | openssl x509 -noout -text | grep "Public Key Algorithm"` — flag all RSA and ECDSA (P-256/P-384) endpoints; confirm no ML-KEM (FIPS 203) hybrid is negotiated in the TLS handshake. Finding threshold: any pinned production endpoint using RSA or classical ECDSA without a hybrid post-quantum key exchange scheduled for deployment before 2027.
+
+- **CT Log Rogue Certificate Issuance for Pinned Domains (CVE-2022-26923 — AD CS ESC1 variant / ATT&CK T1588.004):** An attacker who compromises an intermediate CA (or exploits a misconfigured Active Directory Certificate Services ESC1 template) can issue a certificate for a pinned domain. The pin rejects it at connection time on already-deployed clients, but newly installed app versions that shipped before the pin was added are silently vulnerable, and no server-side alert fires. Test by: set up a crt.sh webhook (via `https://crt.sh/atom?q=%.yourdomain.com`) or use the Google Certificate Transparency API to alert on newly logged certificates for all pinned domains; verify the alert fires within 1 hour of a test issuance. Finding threshold: any pinned domain with no CT log monitoring configured where unauthorized issuance would go undetected for more than 24 hours.
+
+- **Supply Chain Attack on Pin-Config Signing Key via Compromised CI/CD (ATT&CK T1195.002 — Compromise Software Supply Chain):** The OTA pin-config signing key is typically stored as a CI/CD secret (GitHub Actions, CircleCI). A supply-chain compromise of the CI environment (e.g., a malicious dependency in the build pipeline — see the 2024 `xz-utils` backdoor pattern, CVE-2024-3094) allows an attacker to exfiltrate the signing key and issue a fraudulent pin-config payload that pushes attacker-controlled pins to all live app clients. Test by: audit the signing key's storage location; verify it is stored in a hardware-backed secret store (AWS KMS, GCP KMS, or HashiCorp Vault with HSM backend) and that the CI pipeline never writes the raw private key to disk or logs; confirm key rotation has occurred at least once. Finding threshold: any OTA pin-config signing key stored as a plaintext CI secret or file on disk rather than in a KMS-backed store.
+
+- **SBOM/Compliance Gap — Undeclared CA Root and Config Signing Key Material (US EO 14028 / EU Cyber Resilience Act):** US Executive Order 14028 and the EU Cyber Resilience Act (CRA, effective 2027) require a Software Bill of Materials that includes all cryptographic key material and trust anchors used in a product. CA root SPKI hashes pinned in `network_security_config.xml` and OTA config signing key fingerprints are cryptographic trust anchors that must appear in the CycloneDX SBOM; their absence is a compliance blocker for US federal customers and EU market access. Test by: parse the app's CycloneDX SBOM (`cdxgen -o sbom.json .`) and verify that every SPKI hash present in pinning configs and every public key fingerprint used for config signature verification appears as a `cryptoMaterial` component in the SBOM; cross-reference against `network_security_config.xml` and `TrustKit` config entries. Finding threshold: any SPKI pin hash or signing key fingerprint present in source code that does not appear in the project's CycloneDX SBOM.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in certificate pinning and rotation that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | OTA pin-config fetch fails open — no pinning enforced | Static analysis sees `return null` and marks it as safe error handling; it does not model that `null` disables all pin checks | Block the remote config URL at the network layer; confirm the app still connects (should fail closed, not succeed) |
+| 2 | Leaf-certificate hash pinned instead of SPKI hash | Both look like SHA-256 base64 strings; scanners check presence of a hash, not which hash type it is | Re-run `openssl s_client` extraction using the certificate-fingerprint command (`-fingerprint -sha256`) vs. the SPKI path; compare — if they match there is no bug, if they differ and the code uses the fingerprint path, it will break on cert renewal |
+| 3 | Backup pin is a duplicate of the primary pin | Static analysis confirms two `<pin>` entries exist and marks the backup-pin requirement satisfied; it does not check value equality | Hash-compare all pin values in `network_security_config.xml` and TrustKit config; duplicate pins provide zero rotation headroom |
+| 4 | Root CA pin bypassed by intermediate CA cross-signed under attacker-controlled trust anchor | Pinning tools verify the chain against the device trust store; an attacker who controls a trust anchor on the device can issue a chain that passes the OS check before the pin is evaluated on older OkHttp versions | Test on a device with a custom CA installed; verify the app rejects the connection even when OS chain validation succeeds |
+| 5 | Pin expiration date is set but rotation runbook is never triggered — expiry silently passes in production | CI/CD pipelines do not parse `expiration` from XML and no calendar alert was created | Write a CI step or cron job that parses the `expiration` attribute and fails the build if it is within 60 days; confirm the alert fires in staging |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that pinning and PKI lifecycle defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to Cert-Pin Rotation | Prepare Now By |
+|--------|--------------|-------------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) breaks RSA/ECDSA | 2028–2032 | SPKI pins are hashes of RSA/EC public keys; harvest-now-decrypt-later adversaries capture pinned TLS sessions today to decrypt when CRQC arrives | Inventory all pinned keys; flag RSA-2048 and P-256 endpoints for post-quantum migration; plan ML-KEM (FIPS 203) hybrid TLS rollout |
+| 90-day maximum TLS certificate lifetimes (CA/B Forum ballot) | 2025–2026 (active) | Planned rotation cycles designed around 1–2-year certs break immediately; OTA rotation becomes mandatory, not optional | Shorten rotation runbook to a 60-day cycle; validate OTA pin-update path can complete a full rotation within 30 days end-to-end |
+| AI-assisted MitM tooling (LLM-generated per-target payloads) | 2025–2027 (active) | Attackers generate per-app bypass scripts that target the specific OTA config fetch pattern used; generic defences fail | Require HMAC-signed pin-config payloads with a server-side nonce; reject unsigned or replayed config responses |
+| Browser/OS removal of SHA-1 and SHA-256 leaf cert trust | 2026 | Apps still pinning SHA-1 fingerprints (not SPKI) will start failing as intermediates are re-issued with stronger algorithms, changing fingerprints | Audit every pinned hash for algorithm type; migrate all to SPKI SHA-256 |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | Pin-config signing keys and CA root certificates must appear in SBOM; undocumented key material is a compliance gap | Include CA root SPKI hashes and config signing key fingerprints in CycloneDX SBOM |
+
+---
+
+## §DETECTION-GAP
+
+What current monitoring CANNOT detect in certificate-pinning and rotation, and what to build to close each gap.
+
+**Domain-specific gaps that MUST be checked:**
+
+- **Silent pin expiration in production**: The `expiration` attribute in Android `network_security_config.xml` is parsed only at app startup on the device; no server-side event is emitted when a pin set expires. Need: a CI/CD step and an out-of-band cron job that parse expiration dates and page on-call at 90, 60, and 30 days before expiry.
+- **OTA config fetch returning stale or attacker-substituted pins**: The fetch succeeds with HTTP 200 and the app logs no error, but the returned pin set was served from a CDN cache poisoned days earlier. Need: pin the OTA config endpoint itself (meta-pinning) and include a `issuedAt` timestamp in the signed payload; reject responses older than 24 hours.
+- **Duplicate-pin false positive in backup-pin audit**: Automated pin-count checks report "2 pins present — compliant." They do not compare values. Need: a lint rule or pre-commit hook that asserts all pin values in a config file are unique.
+- **Certificate Transparency log divergence**: An unauthorized certificate for a pinned domain is issued by a rogue CA. The app's pin would reject it, but no alert fires because the attack is detected only at connection time on the device, not centrally. Need: CT log monitoring (e.g., crt.sh webhook or Google Certificate Transparency API) alerting on any newly issued certificate for pinned domains.
+- **Cross-agent chain — OTA fetch SSRF + pin bypass**: The OTA config URL is partially user-controlled (SSRF) and the fetch-fail-open path is active. Phase 1 SSRF agent flags the SSRF; Phase 1 cert-pin agent flags the fail-open. Neither agent alone sees the critical chain. Need: CISO orchestrator Phase 1 synthesis to correlate both findings into a single CRITICAL escalation.
+
+---
+
+## §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.
+
+**Mandatory attack classes for cert-pin-rotation-specialist:**
+
+| Class | Patterns to Search | Acceptable Skip Condition |
+|-------|--------------------|--------------------------|
+| Single pin (no backup) | Count of `<pin>` / `PublicKeyHashes` entries per domain | Not applicable only if project has zero network calls |
+| Leaf-cert hash vs. SPKI hash | Compare `openssl -fingerprint` output vs. SPKI extraction output for each pinned value | Not applicable only if no TLS pinning code exists |
+| OTA fetch fail-open | Search for `return null` / `return []` / empty-catch in pin-fetch function | Not applicable only if no OTA rotation mechanism exists |
+| Expired or near-expiry pin set | Parse `expiration` from XML / `kTSKExpirationDate` from Swift config | Not applicable only if no expiration date field exists in config |
+| Unsigned or unverified OTA pin config | Look for missing `verifyConfigSignature` or equivalent before accepting fetched pins | Not applicable only if pins are never fetched remotely |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "Single pin no backup", "filesReviewed": 3, "patterns": ["<pin>", "PublicKeyHashes"], "result": "CLEAN" },
+      { "class": "Leaf-cert hash vs. SPKI", "filesReviewed": 3, "patterns": ["openssl fingerprint vs spki extraction"], "result": "1 finding, fixed" },
+      { "class": "OTA fetch fail-open", "filesReviewed": 5, "patterns": ["return null", "catch {}"], "result": "CLEAN" },
+      { "class": "Expired or near-expiry pin set", "filesReviewed": 3, "patterns": ["expiration", "kTSKExpirationDate"], "result": "CLEAN" },
+      { "class": "Unsigned OTA pin config", "filesReviewed": 5, "patterns": ["verifyConfigSignature", "signature"], "result": "CLEAN" }
+    ],
+    "filesReviewed": 11,
+    "negativeAssertions": [
+      "OTA fetch fail-open: return-null and empty-catch patterns searched across 5 files — 0 unguarded paths",
+      "Unsigned OTA config: signature verification present in all remote-fetch paths"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```