@blamejs/exceptd-skills 0.9.1

package/skills/attack-surface-pentest/skill.md

@@ -0,0 +1,381 @@
+---
+name: attack-surface-pentest
+version: "1.0.0"
+description: Modern attack surface management + pen testing methodology for AI-era environments — NIST 800-115, OWASP WSTG, PTES, ATT&CK-driven adversary emulation, TIBER-EU
+triggers:
+  - attack surface
+  - pen test
+  - penetration testing
+  - red team
+  - adversary emulation
+  - threat-led testing
+  - tlpt
+  - tiber-eu
+  - asset inventory
+  - external footprint
+  - asm
+data_deps:
+  - cve-catalog.json
+  - atlas-ttps.json
+  - framework-control-gaps.json
+  - cwe-catalog.json
+  - d3fend-catalog.json
+atlas_refs:
+  - AML.T0043
+  - AML.T0051
+  - AML.T0010
+attack_refs:
+  - T1190
+  - T1133
+  - T1059
+  - T1078
+framework_gaps:
+  - NIST-800-115
+  - OWASP-Pen-Testing-Guide-v5
+  - PTES-Pre-engagement
+  - NIS2-Art21-patch-management
+rfc_refs: []
+cwe_refs:
+  - CWE-1395
+  - CWE-22
+  - CWE-269
+  - CWE-352
+  - CWE-434
+  - CWE-732
+  - CWE-78
+  - CWE-787
+  - CWE-79
+  - CWE-89
+  - CWE-918
+forward_watch:
+  - NIST SP 800-115 successor publication (the 2008 original is the active gap)
+  - TIBER-EU scenario library refresh under DORA Year-2 supervisory cycle
+  - OWASP WSTG v5.x AI/MCP test cases (currently in working-group draft)
+  - PTES revision incorporating AI-surface enumeration
+d3fend_refs:
+  - D3-CSPP
+  - D3-EAL
+  - D3-NTA
+last_threat_review: "2026-05-11"
+---
+
+# Attack Surface Management + Penetration Testing
+
+## Threat Context (mid-2026)
+
+The attack surface is no longer a list of internet-facing IPs and web apps. By mid-2026 the surface a competent adversary maps for a target enterprise includes seven distinct, simultaneously exploitable layers — and the typical pen test scope covers two of them.
+
+### 1. Classical perimeter (still real, no longer primary)
+
+Edge appliances, VPN concentrators, web apps, and exposed RDP/SSH remain in the kill chain (ATT&CK T1190 Exploit Public-Facing Application, T1133 External Remote Services), and edge-device CVEs continue to dominate CISA KEV adds. But initial-access cost on this surface has risen as defenders converge on EDR, WAF, and identity hardening. Adversaries pivot to cheaper surfaces below.
+
+### 2. AI API egress as unmanaged C2 channel
+
+Every enterprise now has outbound HTTPS to one or more LLM providers (OpenAI, Anthropic, Google, Azure OpenAI, Bedrock) plus local model inference endpoints. The SesameOp campaign (ATLAS AML.T0096) demonstrated that prompt/completion fields can carry C2 traffic indistinguishable from legitimate AI usage. Egress filtering policies that allow `api.openai.com` and `api.anthropic.com` as trusted destinations create a covert channel the org explicitly authorized. Pen testers in mid-2026 must emulate this — point-in-time network scanners will not surface it.
+
+### 3. MCP servers as RCE surface
+
+CVE-2026-30615 (Windsurf MCP, CVSS 9.8) is the canonical example: a malicious MCP server executes arbitrary code in the AI assistant's context with zero user interaction. 150M+ affected downloads. Every developer workstation with an MCP-aware client (Cursor, VS Code + Copilot, Windsurf, Claude Code, Gemini CLI) is potentially a network of unsigned-package RCE vectors that no traditional asset inventory enumerates. ATLAS AML.T0010 (ML Supply Chain Compromise).
+
+### 4. Prompt-injection footprint
+
+Any system that feeds external content (PR descriptions, support tickets, web-retrieved docs, calendar events, email bodies, RAG-retrieved chunks) into an LLM prompt is in scope (ATLAS AML.T0051). CVE-2025-53773 (GitHub Copilot, CVSS 9.6) showed prompt injection achieving RCE via a developer tool. 2026 meta-analysis: adaptive prompt injection succeeds against SOTA defenses at >85%. Pen testers must enumerate the prompt-injection footprint as a first-class asset class.
+
+### 5. RAG corpora and embedding stores
+
+Vector databases are exfil targets and poisoning targets. ATLAS AML.T0043 (Craft Adversarial Data) covers vector manipulation that forces retrieval to surface proprietary chunks or to retrieve attacker-controlled poisoned chunks. A pen test that ignores the vector store does not test the actual data-exfil path.
+
+### 6. Ephemeral runtimes invisible to point-in-time CMDBs
+
+Serverless functions, K8s pods scaled to zero between invocations, ephemeral build runners, sandbox VMs — these exist for seconds to minutes and never appear in a quarterly asset inventory snapshot. A traditional ASM tool that scans on a 24-hour cycle has zero visibility. Adversaries who land in a build pipeline get code execution against the supply chain (ATT&CK T1059) inside ephemeral runners that the blue team's SIEM has no log feed from.
+
+### 7. Supply chain manifests
+
+`package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, MCP server manifests, model registries (Hugging Face, internal MLflow), and SBOMs (CycloneDX, SPDX) define a transitive dependency graph that is the actual attack surface for software supply chain compromise. 41% of 2025 zero-days were AI-discovered, compressing the window between dependency publication and reliable exploitation to hours. ATT&CK T1078 (Valid Accounts) is increasingly preceded by a supply chain compromise that plants the valid account.
+
+### What this means for pen testing
+
+A pen test scoped to layers 1 and (partly) 7 — i.e. "web app + network + nominal SBOM review" — is structurally inadequate against a mid-2026 adversary. Red teams now have to emulate AI-API-as-C2 (SesameOp) and prompt-injection-as-RCE (CVE-2025-53773) alongside classical web/network surfaces. Threat-led penetration testing programs (TIBER-EU under DORA, CBEST under PRA/FCA) require adversary emulation grounded in current threat intelligence — but their published scenario libraries lag mid-2026 TTPs by 12–18 months and tester certifications do not require demonstrated competence in AI-surface attacks.
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control / Document | Why It Fails for Mid-2026 Pen Testing |
+|---|---|---|
+| NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) | Whole document | Published September 2008. Predates cloud-native architectures, the AI surface, MCP, RAG, and ephemeral runtimes entirely. The methodology section assumes a network-centric perimeter and gives zero guidance on AI APIs, prompt-injection enumeration, vector store assessment, or supply-chain manifest review. No revision has been issued in 18 years. |
+| OWASP Web Security Testing Guide (WSTG) v5 | Sections 4.x (Web App Testing) | Covers web app testing surface (auth, session, input validation, business logic). Does not cover AI API testing, MCP server trust, prompt injection as a webapp-equivalent input vector, or RAG corpus integrity. v5.x AI/MCP test cases are in working-group draft and not yet a stable reference. |
+| PTES (Penetration Testing Execution Standard) | Pre-engagement, Intelligence Gathering, Vulnerability Analysis, Exploitation, Post-Exploitation | The phase structure remains useful, but every phase's asset taxonomy is network-centric: hosts, services, web apps. PTES does not require the tester to enumerate AI APIs, MCP servers, RAG corpora, embedding stores, model registries, or ephemeral runtime telemetry as scoped assets. PTES Pre-engagement scoping templates ship without an AI-surface checklist. |
+| NIS2 (EU Directive 2022/2555) | Article 21 (cybersecurity risk-management measures, including patch management) | Article 21(2)(e) requires policies and procedures for testing and assessing the effectiveness of cybersecurity measures. The directive does not specify methodology, leaving "testing" to be operationalized by national CSIRTs. Patch-management language in Art. 21 assumes human-speed exploit development; AI-discovered zero-days (Copy Fail class, ~1 hour from disclosure to working PoC) make the typical 30-day patch SLA structurally inadequate. |
+| TIBER-EU (ECB, 2018, refreshed under DORA) | Whole framework | TIBER-EU mandates Threat-Led Penetration Testing for significant financial entities under DORA Article 26. The framework requires a Threat Intelligence Provider report and adversary emulation by a Red Team Provider. As implemented in 2025–2026, the published scenario libraries and accepted TTPs lag current adversary tradecraft by 12–18 months. TLPT engagements that did not include AI-API-as-C2 or prompt-injection-as-RCE scenarios in 2025 missed the dominant new tradecraft. |
+| CBEST (Bank of England / PRA / FCA) | Whole framework | UK equivalent to TIBER-EU for systemically important financial firms. Same lag pattern as TIBER-EU. CBEST-certified providers are not required to demonstrate competence in AI-surface attack emulation as of mid-2026. |
+| Australian ISM (Information Security Manual) + ACSC Essential 8 | ISM controls on penetration testing; Essential 8 Maturity Level 3 testing requirements | Essential 8 mandates regular testing of mitigation strategies (patching, app control, MFA, etc.). The testing requirements do not extend to AI-API egress as C2, MCP trust, or RAG poisoning. ISM control set is network/endpoint centric. |
+| ISO/IEC 27001:2022 | A.5.34 (Privacy and protection of PII) — note: the actually relevant clause for independent review is **A.5.35 (Independent review of information security)** and **A.8.29 (Security testing in development and acceptance)** | A.5.35 requires independent review of the information security approach at planned intervals or when significant changes occur. The clause is methodology-agnostic — auditors accept a network/web pen test as evidence even when AI surfaces are in production. A.8.29 mandates security testing of new and changed information systems, but does not define what an adequate test of an AI system looks like. |
+| MITRE ATT&CK Enterprise (v17) | Whole matrix | The enterprise matrix does not contain prompt-injection as a technique. AI-as-C2 (SesameOp pattern) is absent from ATT&CK as of mid-2026. Adversary emulation programs that are ATT&CK-only and not ATLAS-extended will not include the mid-2026 dominant new tradecraft in their playbooks. ATLAS v5.1.0 covers it — but ATLAS is not yet a standard requirement for pen testing certification or scoping. |
+
+> Global coverage note (AGENTS.md rule #5): the above table spans US (NIST 800-115, ATT&CK), EU (NIS2, TIBER-EU under DORA), UK (CBEST), AU (ISM/Essential 8), and ISO 27001:2022. US-only pen test scoping is incomplete.
+
+---
+
+## TTP Mapping (MITRE ATLAS v5.1.0 + MITRE ATT&CK v17)
+
+Pen testers must emulate both classical and AI-class chains. The table below maps the kill-chain phases a mid-2026 adversary emulation engagement must cover.
+
+| Phase | Classical TTP (ATT&CK v17) | AI-Class TTP (ATLAS v5.1.0) | Framework Gap Flag |
+|---|---|---|---|
+| Reconnaissance | T1595 (Active Scanning) — implied by T1190 setup | AML.T0000 (Search Open Technical Databases) — model card / dataset / API endpoint discovery | NIST 800-115 §3.x recon guidance is network-only |
+| Initial Access | T1190 (Exploit Public-Facing Application) | AML.T0051 (LLM Prompt Injection) — entered via PR description, support ticket, retrieved doc | OWASP WSTG covers webapp; not prompt-injection as entry vector |
+| Initial Access | T1133 (External Remote Services) | AML.T0010 (ML Supply Chain Compromise) — malicious MCP server installed by developer | PTES scoping templates do not require MCP server enumeration |
+| Execution | T1059 (Command and Scripting Interpreter) | AML.T0051 → tool-use call invoking shell/code execution in agent context | NIS2 Art.21 patch-mgmt language assumes binary exploit; semantic-input exploit lives outside |
+| Persistence | T1078 (Valid Accounts) | AML.T0018 / AML.T0010 — poisoned dependency planting valid creds | TIBER-EU scenario libraries lag this by 12–18 months |
+| Command and Control | T1071 (Application Layer Protocol) | AML.T0096 (LLM Integration Abuse — AI API as C2, SesameOp pattern) | No major framework defines a control for AI-API egress as C2 |
+| Exfiltration | T1041 (Exfil Over C2 Channel) | AML.T0043 (Craft Adversarial Data) → vector-store retrieval forced to surface proprietary chunks | RAG corpus is not enumerated in classical ASM |
+| Defense Evasion | T1027 (Obfuscated Files or Information) | AML.T0051 with adaptive payload generation per attempt | Pen test reports that show "no anomalies" against AI-generated payloads understate evasion |
+
+Gap flag legend: every row above maps to at least one framework gap declared in `framework_gaps` frontmatter, ensuring AGENTS.md rule #4 (no orphaned controls) holds in reverse — every TTP we emulate has a framework gap it exposes.
+
+---
+
+## Exploit Availability Matrix
+
+Pen testers select tooling based on real exploit availability. The matrix below pulls from `data/exploit-availability.json` and `data/cve-catalog.json`; `last_verified` dates are tracked in the data files, not duplicated here.
+
+| Vulnerability | CVSS | RWEP | CISA KEV | Public PoC | AI-Discovered/Accelerated | Live-Patchable | Pen Tester Use |
+|---|---|---|---|---|---|---|---|
+| CVE-2026-31431 (Copy Fail Linux kernel LPE) | 7.8 | 90 | Yes | Yes — 732-byte deterministic exploit | Yes (AI-discovered in ~1 hour) | Yes (kpatch / livepatch) | Post-exploit privilege escalation in unpatched Linux hosts; reliable, no race condition |
+| CVE-2025-53773 (GitHub Copilot prompt-injection RCE) | 9.6 | 91 | No (not enterprise infra in KEV sense) | Yes — demonstrated PoC | Yes (AI tooling generates injection payloads) | No (requires Copilot update + prompt hardening) | Initial access via PR descriptions, support tickets, retrieved docs; emulate AML.T0051 |
+| CVE-2026-30615 (Windsurf MCP RCE) | 9.8 | 94 | No | Partial — concept demonstrated | No | No (requires Windsurf patch) | Lateral movement to developer workstations via malicious MCP server; emulate AML.T0010 |
+| CVE-2026-43284 (covered in fuzz/memory-safety skill) | see `data/cve-catalog.json` | see `data/cve-catalog.json` | see `data/exploit-availability.json` | see `data/exploit-availability.json` | see `data/cve-catalog.json` | see `data/cve-catalog.json` | Memory-corruption chain context — refer to that skill for exploitation detail |
+| CVE-2026-43500 (covered in supply-chain skill) | see `data/cve-catalog.json` | see `data/cve-catalog.json` | see `data/exploit-availability.json` | see `data/exploit-availability.json` | see `data/cve-catalog.json` | see `data/cve-catalog.json` | Supply chain compromise context — refer to that skill for exploitation detail |
+| SesameOp (AI-as-C2 technique, no CVE — adversary tradecraft) | N/A (technique, not vulnerability) | N/A | N/A | Yes — ATLAS-documented adversary pattern (AML.T0096) | Yes | N/A | Emulate covert AI-API C2 during adversary emulation; verifies whether egress monitoring catches AML.T0096 |
+
+For any CVE referenced here, the canonical record (with `last_verified` date, exploit URL provenance, KEV add date) lives in `data/exploit-availability.json`. The pen tester pulls fresh values from there at engagement start — these rows are an orientation cross-walk, not the source of truth.
+
+---
+
+## Analysis Procedure
+
+The procedure threads three foundational security principles through every phase. A pen test that does not produce explicit findings against all three has not done the work — it has done compliance theater (see Compliance Theater Check below).
+
+### Foundational principle #1 — Defense in depth assessment
+
+At each architectural layer the test asks: if this layer fails, does the next layer catch it? A finding is generated whenever a single-layer failure produces complete compromise.
+
+The layers under test (mid-2026 inventory):
+
+| Layer | Control class | Test question |
+|---|---|---|
+| Perimeter | WAF, edge firewall, VPN, DDoS scrubbing | Does perimeter bypass (T1190) reach the application layer with no further check? |
+| Application | Input validation, auth, session, business logic | Does prompt injection (AML.T0051) reach tool-use without semantic sanitization? |
+| Identity | IAM, MFA, OIDC, role-based access | Does a compromised service account (T1078) cross trust boundaries without re-auth? |
+| Data | Encryption at rest, DLP, RAG corpus access control | Does retrieval (AML.T0043) surface chunks the requesting principal should not see? |
+| Runtime | EDR, seccomp, namespace isolation, container sandbox | Does a kernel LPE (Copy Fail class) escape container isolation? |
+| Supply chain | SBOM, signed manifests, dependency pinning, MCP allowlist | Does an unsigned MCP server (AML.T0010) install with no manifest verification? |
+| Egress | Network egress filtering, AI-API monitoring, DNS RPZ | Does AI-API egress (AML.T0096) carry C2 without behavioral detection? |
+
+For each layer the tester records: which control(s) are present, which were probed, which caught the test, which did not. The defense-in-depth heatmap in the output format is built directly from this record.
+
+### Foundational principle #2 — Least privilege validation
+
+Every identified principal — human, service, AI agent, MCP server, build pipeline runner, model inference endpoint — gets a privilege audit. The procedure:
+
+1. Enumerate the principal's actual permissions (IAM policy, Linux capabilities, K8s RBAC, MCP tool allowlist, AI agent function-calling spec).
+2. Enumerate the principal's required permissions for its real workload.
+3. Compute the delta. Every permission in (1) not in (2) is an excess-privilege finding.
+4. Map each excess permission to a TTP it enables (e.g. excess `s3:DeleteObject` enables T1485 Data Destruction; excess MCP `shell_exec` tool enables AML.T0051 → T1059 chain).
+
+Excess privilege is itself a finding regardless of whether the test exercised it — least privilege is a posture metric, not an event metric.
+
+### Foundational principle #3 — Zero trust assumption inversion
+
+The tester assumes every network position is hostile, every identity is untrusted until proven, every egress is suspect. The procedure inverts the implicit-trust assumptions the org operates under:
+
+1. From every network segment the test reaches, attempt to reach the next segment. Implicit-trust between segments is a zero-trust failure.
+2. For every identity the test assumes, attempt to invoke privileged APIs without step-up authentication. Implicit re-auth-not-required is a zero-trust failure.
+3. For every authorized egress (including the trusted AI-API endpoints), inject anomalous traffic (high-entropy payloads, base64-encoded blobs in prompt fields, oversized completions). Egress that authorizes destination without inspecting content is a zero-trust failure.
+
+A pen test that "achieves access" by abusing implicit trust between segments is a zero-trust failure, not just a network finding. It is reported as such in the output format.
+
+### Concrete procedure steps
+
+**Step 1 — Scoping and rules of engagement (PTES Pre-engagement + TIBER-EU TI-Provider report)**
+
+Define: in-scope systems (must include AI surface, MCP installations, RAG corpora, ephemeral runtimes, supply chain manifests — not just IPs and URLs), out-of-scope systems, test windows, escalation contacts, legal authorisation (CFAA/Computer Misuse Act / Australian Cybercrime Act / equivalent jurisdiction). For TLPT engagements under DORA/CBEST, the TI-Provider Threat Intelligence report defines the adversary scenario; verify the scenario reflects mid-2026 tradecraft (AI-API-as-C2, prompt-injection-as-RCE) and is not a copy-forward of 2024 scenarios.
+
+**Step 2 — Asset inventory (extended for the mid-2026 surface)**
+
+Enumerate, at minimum:
+
+- External IPs, domains, certificates (Censys/Shodan/crt.sh, RDAP).
+- Web apps and APIs (with OpenAPI/GraphQL schemas where exposed).
+- VPN/SSO/identity providers.
+- AI APIs in use (LLM providers, local inference endpoints, AI agent frameworks).
+- MCP servers installed across developer fleet (enumerate via IDE config files: `~/.cursor/mcp.json`, `~/.vscode/mcp.json`, equivalents).
+- RAG corpora and embedding stores (vector DBs, document indexes).
+- Model registries (Hugging Face orgs, internal MLflow / model registries).
+- Ephemeral runtime fabrics (Lambda/CloudRun/Functions, K8s namespaces with HPA scale-to-zero, ephemeral build runners).
+- Supply chain manifests (`package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, MCP manifests, CycloneDX/SPDX SBOMs).
+
+If any of the AI-surface categories are reported as "none in scope" by the customer, capture that as a scope-limitation finding — most organisations are wrong about this in 2026.
+
+**Step 3 — OSINT and recon**
+
+- DNS, subdomain enumeration, certificate transparency.
+- Code-host recon: public GitHub orgs for leaked tokens, exposed `.env`, branch-protection lapses.
+- CVE / advisory cross-walk: pull current `data/cve-catalog.json` entries, cross-reference each in-scope component against CSAF advisories and OSV.dev for OSS components.
+- EPSS-anchored prioritisation: rank candidate vulnerabilities by EPSS percentile and CISA KEV status; CVSS alone is not the ranker (AGENTS.md rule #3).
+
+**Step 4 — Vulnerability identification (classical surface)**
+
+- Authenticated and unauthenticated scans where authorised (Nessus / Nuclei / Burp / equivalent).
+- Manual webapp testing per OWASP WSTG v5 sections 4.1–4.12.
+- CWE coverage from `data/cwe-catalog.json` cross-walked to findings — CWE-79 (XSS), CWE-89 (SQLi), CWE-78 (OS command injection), CWE-787 (out-of-bounds write) are the load-bearing classical categories for the chains tested here; AGENTS.md rule #4 (no orphaned controls) requires every finding be CWE-mapped.
+
+**Step 5 — AI-surface enumeration and probing**
+
+For each system identified in Step 2 as feeding external content into an LLM prompt:
+
+- Prompt-injection probes: a battery of indirect-injection payloads delivered via the system's normal input channels (PR descriptions, support tickets, retrieved docs, calendar/email if integrated). Record bypass rate.
+- MCP tool-allowlist abuse: for each installed MCP server, verify (a) signed manifest enforced, (b) tool allowlist enforced, (c) bearer auth required, (d) outputs sanitized before model receives them. Test by introducing a controlled non-malicious MCP server with a permissive manifest and observing whether the client installs it without prompt.
+- AI-C2 simulation: from a host the test has reached, generate AI-API traffic encoding a synthetic C2 protocol in prompt and completion fields. Observe whether SIEM / DLP / egress monitoring fires any alert. If the AI-API destination is treated as trusted internal traffic with no behavioural baseline, this is a controlled emulation of AML.T0096.
+- RAG corpus assessment: where authorised, attempt vector-store retrieval that surfaces chunks outside the requesting principal's access boundary; attempt to inject a poisoned chunk via the documented ingestion path and verify whether content integrity checks fire.
+
+**Step 6 — Exploitation (only as scoped)**
+
+For each candidate vulnerability with high RWEP and authorised exploitation scope:
+
+- Confirm exploitability against a non-production replica where available, then against production within RoE.
+- Document blast radius before each exploitation step.
+- For Copy Fail class kernel LPEs in scope, refer to the `kernel-lpe-triage` skill — exploitation methodology and live-patch verification belong there.
+
+**Step 7 — Defense-in-depth probing**
+
+Run the layer-by-layer test from foundational principle #1 above. The output of this step is the heatmap, not a list of bugs. For each row in the heatmap the tester records: was the next layer engaged? did it catch the test? what telemetry fired?
+
+**Step 8 — Privilege chain analysis**
+
+Apply foundational principle #2 to every principal the test enumerated or compromised. Produce the excess-privilege ledger directly as output.
+
+**Step 9 — Zero-trust violation inventory**
+
+Apply foundational principle #3. Record every implicit-trust crossing the test exploited — segment-to-segment, identity-to-identity, egress without inspection.
+
+**Step 10 — Reporting and remediation roadmap**
+
+Map each finding to:
+
+- RWEP score (from `lib/scoring.js`, never CVSS alone — AGENTS.md rule #3).
+- EPSS percentile and CISA KEV status (from `data/exploit-availability.json`).
+- CWE category (from `data/cwe-catalog.json`).
+- D3FEND defensive countermeasure (from `data/d3fend-catalog.json`) — see section 8 below.
+- Framework gap exposed (from `data/framework-control-gaps.json`).
+
+Sequence remediation by RWEP descending, with live-patchable items inside RWEP tier scheduled first when their patch SLA can realistically be met. For supply chain manifests, the remediation requires not just patching the called-out version but tightening the dependency-resolution policy that allowed it in.
+
+---
+
+## Output Format
+
+```
+## Penetration Test Report — [Engagement Name]
+
+**Engagement window:** [start] – [end]
+**Tester(s) / firm:** [names + certifications]
+**Authorising party:** [client representative]
+**Scope reference:** [PTES Pre-engagement document / TIBER-EU TI-Provider report / equivalent]
+
+### 1. Executive summary
+- Top 5 findings by RWEP, one sentence each.
+- Defense-in-depth verdict: which layers held, which failed.
+- Zero-trust verdict: were implicit-trust crossings reachable?
+- Overall posture characterisation against the mid-2026 attack surface.
+
+### 2. Scope and rules of engagement
+[Verbatim or referenced from the agreed RoE document. Includes legal authorisation reference per jurisdiction.]
+
+### 3. Asset inventory (mid-2026 extended)
+| Category | Asset | Notes |
+|---|---|---|
+| External IP/domain | ... | ... |
+| Web app/API | ... | ... |
+| Identity provider | ... | ... |
+| AI API | ... | provider, endpoint, principal |
+| MCP server | ... | client, signed?, allowlisted? |
+| RAG corpus | ... | store type, access boundary |
+| Model registry | ... | location, signing posture |
+| Ephemeral runtime | ... | platform, observability coverage |
+| Supply chain manifest | ... | path, lockfile present? |
+
+Scope-limitation findings (categories the client said had "none in scope" that the tester confirmed otherwise) listed separately.
+
+### 4. Findings (prioritised by RWEP)
+For each finding:
+- ID, title, affected asset(s).
+- TTP mapping (ATT&CK and/or ATLAS).
+- CWE category.
+- RWEP score + components (CVSS / EPSS / KEV / PoC availability / AI-acceleration / blast radius).
+- Reproduction evidence.
+- Defense-in-depth context: which layers did and did not catch this.
+- Recommended D3FEND countermeasure (see section 8 below).
+- Framework gap exposed.
+
+### 5. Defense-in-depth heatmap
+| Layer | Control(s) probed | Caught? | Telemetry fired? | Notes |
+|---|---|---|---|---|
+| Perimeter | ... | Y/N/Partial | Y/N | ... |
+| Application | ... | ... | ... | ... |
+| Identity | ... | ... | ... | ... |
+| Data | ... | ... | ... | ... |
+| Runtime | ... | ... | ... | ... |
+| Supply chain | ... | ... | ... | ... |
+| Egress (incl. AI-API) | ... | ... | ... | ... |
+
+### 6. Least-privilege excess-privilege ledger
+| Principal | Type | Excess permission(s) | TTP enabled | Recommendation |
+|---|---|---|---|---|
+| ... | human / service / AI agent / MCP server / pipeline | ... | T#### / AML.T#### | revoke / scope to specific resource / re-auth required |
+
+### 7. Zero-trust assumption violations
+| # | Implicit-trust crossing exploited | Where to insert verification | Recommendation |
+|---|---|---|---|
+| 1 | segment A → segment B without identity check | east-west boundary | mutual mTLS + per-call authorisation |
+| 2 | service account assumed trusted across cluster | API gateway | step-up auth on privileged operations |
+| 3 | egress to api.openai.com authorised by destination only | egress inspection | behavioural baseline + content inspection per AML.T0096 |
+
+### 8. Remediation roadmap
+| Priority | Finding | RWEP | Recommended D3FEND counter | Owner | Target date |
+|---|---|---|---|---|---|
+
+### 9. Appendices
+- Tooling and versions used.
+- Raw evidence (logs, captures, payloads) — separately classified.
+- References: PTES section IDs, OWASP WSTG IDs, NIST 800-115 section IDs, ATLAS/ATT&CK IDs cited.
+```
+
+---
+
+## Compliance Theater Check
+
+Apply each of the following tests to a candidate "we have a pen test" assertion. Any one of them returning a theater verdict invalidates the engagement as evidence of real posture.
+
+**Test 1 — Scope theater.** Ask the org for their most recent pen test report and inspect the scope statement. If the scope is only network + web app + nominal SBOM review, and the org operates AI APIs, MCP servers in developer workflow, RAG, or ephemeral runtimes, the engagement did not test the mid-2026 attack surface. A 2026 pen test that did not enumerate AI APIs, MCP servers, RAG corpora, embedding stores, model registries, or ephemeral runtime telemetry as scoped assets is theater for the current threat model regardless of how thorough it was within its declared scope.
+
+**Test 2 — Defense-in-depth-finding theater.** Read the findings section. If a pen test of a 10,000+ employee organisation found zero defense-in-depth gaps — i.e. every reported finding either did not chain past a single control, or no chains were attempted — the engagement either had its scope artificially constrained or the tester did not run multi-stage emulation. Real organisations of that size have defense-in-depth gaps; their absence in a report is itself the finding.
+
+**Test 3 — Pre-disclosed-scope theater.** Ask: was the pen tester told in advance which specific systems, payloads, or techniques were out of scope to "not surprise" the operations team or "avoid noise in detection systems"? If yes, that is a compliance pen test (a checkbox engagement to satisfy an auditor that "testing occurred"), not an adversary emulation. TIBER-EU and CBEST explicitly require the opposite: the Red Team Provider operates against a Blue Team that is unaware of the engagement specifics, precisely because pre-disclosure invalidates the result. A "pen test" that pre-disclosed the test plan to the SOC has measured the SOC's cooperation, not the organisation's actual resistance to a real adversary.
+
+**Test 4 — Currency theater.** Open the report's TTP references. If the engagement is dated 2025–2026 and the TTP coverage is ATT&CK-only with no ATLAS references, the tester did not emulate the dominant new tradecraft. The pen test cannot evidence resistance to attack patterns it did not attempt.
+
+---
+
+## Defensive Countermeasure Mapping (D3FEND)
+
+The findings the pen test typically produces map to D3FEND v0.10+ defensive countermeasures from `data/d3fend-catalog.json`. The table below is the recommended-counter cross-walk used in section 8 of the output format.
+
+| Typical finding | D3FEND ID | What the counter actually does |
+|---|---|---|
+| Missing egress inspection / AI-API treated as trusted destination (AML.T0096) | D3-NTA (Network Traffic Analysis) | Baseline + anomaly detect on egress flows including authorised AI API endpoints; surfaces SesameOp-class C2 in prompt/completion fields |
+| Excess service-account / AI-agent / MCP-tool privilege (least-privilege failure) | D3-EAL (Execution Activity Logging) | Logs principal actions with context so excess-privilege exercise is detectable post-hoc and reviewable against a least-privilege baseline |
+| Unsigned MCP server installed by developer client (AML.T0010) | D3-CSPP (Credentialed Scan / Software Provenance Policy — per `data/d3fend-catalog.json`) | Enforces signed-manifest and provenance verification before MCP server load; rejects unsigned tool surfaces at install time |
+
+Pen test findings outside this short table map to D3FEND countermeasures present in `data/d3fend-catalog.json` (D3-EHB, D3-MFA, D3-NI, D3-PHRA, D3-PA, D3-IOPR, etc.); the tester selects the counter whose technique-coverage description in the catalog matches the chain the finding exploited. AGENTS.md rule #4 (no orphaned controls) is satisfied because every recommended counter maps to a TTP the test actually emulated and a CWE category the finding exposed.