@blamejs/exceptd-skills 0.9.1

package/skills/threat-modeling-methodology/skill.md

@@ -0,0 +1,312 @@
+---
+name: threat-modeling-methodology
+version: "1.0.0"
+description: Threat modeling methodologies for mid-2026 — STRIDE, PASTA, LINDDUN (privacy), Cyber Kill Chain, Diamond Model, MITRE Unified Kill Chain, AI-system threat modeling, agent-based threat modeling
+triggers:
+  - threat model
+  - threat modeling
+  - stride
+  - pasta
+  - linddun
+  - kill chain
+  - diamond model
+  - unified kill chain
+  - attack tree
+  - threat modeling methodology
+  - data flow diagram
+  - dfd
+  - trust boundary
+data_deps:
+  - atlas-ttps.json
+  - framework-control-gaps.json
+  - cve-catalog.json
+  - cwe-catalog.json
+  - d3fend-catalog.json
+atlas_refs: []
+attack_refs: []
+framework_gaps:
+  - ISO-27001-2022-A.8.28
+  - ISO-IEC-23894-2023-clause-7
+  - ISO-IEC-42001-2023-clause-6.1.2
+  - NIST-800-218-SSDF
+rfc_refs: []
+cwe_refs: []
+d3fend_refs: []
+forward_watch:
+  - ISO/IEC 27005 revision integrating AI-system threats
+  - OWASP Threat Modeling Manifesto v2 (post-2020)
+  - MITRE ATLAS v6 publication and any methodology guidance attached
+  - Unified Kill Chain successor revision (Pols, post-v3.0)
+  - LINDDUN-GO and LINDDUN-PRO updates incorporating LLM privacy threats
+  - PASTA v2 updates incorporating AI/ML application threats
+last_threat_review: "2026-05-11"
+---
+
+# Threat Modeling Methodology
+
+## Purpose
+
+The companion skill `threat-model-currency` measures *when* a threat model is stale. This skill governs *how* a threat model is built. Currency without methodology yields opinion; methodology without currency yields a current-looking 2022 artefact. Both are required.
+
+This skill is opinionated about methodology selection. There is no single methodology that covers technical threats, privacy threats, intrusion-analysis scenarios, full-lifecycle attack chains, and AI/agent-system threats simultaneously. Practitioners who try to force one methodology to do all five jobs produce thin coverage. The procedure below selects and combines methodologies deliberately.
+
+---
+
+## Threat Context
+
+Most "threat models" in circulation in mid-2026 are STRIDE diagrams of 2018–2022 vintage. Their failure modes are concrete and current:
+
+- **No AI agents as actors.** The actor inventory lists humans, services, and external systems. AI coding assistants, MCP servers, RAG retrievers, autonomous agents executing tool calls — none appear with their own trust boundaries. The Windsurf MCP RCE (CVE-2026-30615) and the Copilot prompt-injection RCE (CVE-2025-53773) are not representable in a model whose actor schema predates the threat.
+- **No MCP supply-chain RCE class.** Trust boundaries between developer workstations and "tool plugins" do not exist in pre-2024 threat models. The supply-chain chapter lists npm, Docker, and OS packages — not AI tool plugins, which now have an equal or greater attack surface across 150M+ assistant installs.
+- **No AI-API as C2 channel.** The C2 chapter enumerates DGAs, beaconing, protocol anomalies. ATLAS AML.T0096 (LLM Integration Abuse — covert C2, SesameOp pattern) is not on the diagram. The model cannot reason about a documented technique that is operationally indistinguishable from legitimate AI usage at the network layer.
+- **Prompt injection mis-classified.** Pre-2024 STRIDE assigns prompt injection to "Tampering" or omits it entirely. Operationally it is an access-control bypass that achieves what spoofing achieves via the model's context window, with measured success rates above 85% against state-of-the-art defences.
+- **Embedding store missing from crown jewels.** Data-classification work predates RAG. Vector embeddings of proprietary documents are treated as "metadata" rather than as a semantic projection of the underlying sensitive corpus.
+
+Methodology choice is not cosmetic — it determines what is representable in the model:
+
+- **STRIDE** (Microsoft, formalised 1999; SDL adoption 2002) under-represents privacy threats. LINDDUN exists because Spoof/Tamper/Repudiate/InfoDisclose/DoS/EoP cannot cleanly express linkability, identifiability, non-repudiation-of-data-subjects, detectability, disclosure-of-information-with-purpose-mismatch, unawareness, and non-compliance.
+- **PASTA** (Process for Attack Simulation and Threat Analysis, Tony UcedaVélez, 2012; book 2015) over-represents app-layer threats. It is excellent for a single application's threat surface and weak for systemic AI risks crossing multiple AI services, agents, and pipelines.
+- **LINDDUN** (KU Leuven, original 2010; LINDDUN-GO 2020; LINDDUN-PRO 2022) is the canonical privacy methodology and the appropriate input to a GDPR / LGPD / PIPL / DPDPA DPIA workflow.
+- **Trike** (Saitta, Larcom, Eddington, 2005) is requirements-driven and asset-centric; it survives in regulated environments but has had limited public revision.
+- **OCTAVE** / **OCTAVE Allegro** (SEI / Carnegie Mellon, OCTAVE 2001, Allegro 2007) is enterprise-risk shaped, useful for organisation-wide asset prioritisation, and ill-suited to component-level technical modelling.
+- **Cyber Kill Chain** (Lockheed Martin, Hutchins/Cloppert/Amin, 2011) is linear, intrusion-stage shaped, biased toward APT-style attacks, and weak for cloud-native and ephemeral compute.
+- **Diamond Model of Intrusion Analysis** (Caltagirone, Pendergast, Betz, 2013) gives IR / SOC analysts an adversary–capability–infrastructure–victim frame that ATT&CK alone does not, and pivots naturally to attribution and campaign tracking.
+- **MITRE Unified Kill Chain** (Pols, 2017; v3.0 published 2024) integrates Lockheed Kill Chain with MITRE ATT&CK across 18 stages, extending coverage to cover initial access through impact in cloud-native and AI-augmented environments.
+- **AI-system threat modeling** (Microsoft AI/ML STRIDE-ML, MITRE ATLAS methodology guidance, OWASP ML Top 10) and **agent-based threat modeling** are not unified into a single accepted framework as of mid-2026. The procedure below treats them as a composite of STRIDE-ML + ATLAS TTPs + an explicit actor-inventory amendment.
+
+Skipping methodology selection is itself a methodology. The most common pattern in industry is "we talked about threats in a sprint planning meeting" — which produces no artefact, no review trail, and no input to currency assessment. The pre-ship test for this skill: an artefact exists, lives next to the system it models, and is versioned.
+
+---
+
+## Framework Lag Declaration
+
+No major risk-assessment, secure-development, or AI-management framework prescribes a specific threat-modeling methodology. The gap is global, not US-specific.
+
+| Jurisdiction | Framework | Control | What it misses |
+|---|---|---|---|
+| US | NIST SP 800-53 Rev. 5 | RA-3 (Risk Assessment) | Process-only — mentions threat sources and threat events; specifies no methodology, no DFD/attack-tree requirement, no actor inventory standard. A STRIDE-from-2018 model is RA-3-compliant in 2026. |
+| US | NIST SP 800-218 SSDF v1.1 | PW.1 (Design Software to Meet Security Requirements), PW.4 (Reuse Existing, Well-Secured Software) | PW.1 calls for "threat modelling and risk assessment" without specifying methodology. PW.4 has no representation for AI-assistant-generated code as a distinct supply-chain class. Listed in `data/framework-control-gaps.json` as `NIST-800-218-SSDF`. |
+| US | NIST AI RMF 1.0 | MAP-2.1, MAP-3.1 | Requires categorising AI-system risks; does not require a specific threat model methodology, does not require trust-boundary articulation for AI agents, does not cross-walk to ATLAS. |
+| EU | EU AI Act | Art. 9 (Risk Management System for high-risk AI) | "Continuous iterative" risk management; provides no methodology, no required cross-walk to ATLAS, no requirement that AI agents be modelled as actors with trust boundaries. |
+| EU | NIS2 Directive (2022/2555) | Art. 21(2)(a) — Risk analysis policies | Mandates risk analysis as a measure; silent on threat-model methodology. National competent authority guidance (mid-2026) has not bound any methodology. |
+| EU | DORA (Regulation 2022/2554) | Art. 6 — ICT risk management framework | "Ongoing" risk identification; undefined methodology. |
+| EU | EU Cyber Resilience Act (Regulation 2024/2847) | Annex I, Part I — Essential cybersecurity requirements | Requires risk assessment over the product lifecycle; does not specify methodology, does not name AI components or agent supply chain as a required model element. |
+| UK | NCSC | Cyber Assessment Framework Principle A2 (Risk Management); NCSC Threat Modelling guidance (2024 update) | Principle-based. NCSC's 2024 threat-modelling guidance recommends STRIDE-like decomposition but does not mandate AI-agent actor representation. |
+| AU | ASD | ISM control ISM-0042 (security risk management framework); ISM AI annex (2025) | ISM updates monthly but does not bind a threat-modeling methodology. The 2025 AI annex names ATLAS but does not require methodology-level integration. |
+| JP | NISC / IPA | Cybersecurity Management Guidelines v3.0 (2023) | Requires risk identification process; methodology-neutral; no AI-actor requirement. |
+| IL | INCD | Cyber Defence Methodology 2.0 (2024) | Risk-based but methodology-neutral; AI-system threat modelling not yet integrated as of mid-2026. |
+| SG | CSA Singapore | Cybersecurity Code of Practice (CCoP 2.0, 2022); Model AI Governance Framework v2 (2024) | CCoP requires risk assessment; AI governance framework is principle-based; neither binds a methodology. |
+| Global | ISO | ISO/IEC 27001:2022 A.5.7 (Threat Intelligence), A.8.28 (Secure Coding) | Listed in `data/framework-control-gaps.json` as `ISO-27001-2022-A.8.28`. Silent on methodology; prompt-injection-as-RCE is outside the scope of "secure coding". |
+| Global | ISO | ISO/IEC 27005:2022 (Information security risk management) | Process guidance; methodology-neutral; predates current AI threat catalogue. |
+| Global | ISO | ISO/IEC 42001:2023 (AI Management System), clause 6.1.2 | Listed as `ISO-IEC-42001-2023-clause-6.1.2`. AI risk assessment as periodic activity; no runtime threat-surface methodology; cross-jurisdiction obligations not enumerated. |
+| Global | ISO | ISO/IEC 23894:2023 (AI Risk Management Guidance) clause 7 | Process-level lifecycle guidance; no specific methodology binding. |
+| Global | ISO | ISO 31000:2018 (Risk management) | Enterprise-risk umbrella; no operational methodology. |
+| Global | COSO | ERM Framework | Enterprise risk; no operational threat-modelling methodology. |
+| Privacy | EU / global | GDPR Art. 35 (DPIA); LGPD Art. 38 (RIPD); PIPL Art. 55; India DPDPA 2023 | Require impact assessments but bind no methodology. LINDDUN is the de facto privacy threat-modeling methodology; none of these regulations name it. |
+
+The recurring failure across all of the above: every framework treats threat modelling as a process to perform, not as a methodology to select on the basis of what is representable. This skill is the missing methodology selector.
+
+---
+
+## TTP Mapping
+
+Threat-modelling methodologies are *consumers* of the TTP catalog, not contributors. The mapping below shows what each methodology pulls from `data/atlas-ttps.json`, `data/cve-catalog.json`, and the ATT&CK references inside `data/cve-catalog.json` entries.
+
+| Methodology | Native input | TTP pull pattern | Gap if methodology used alone |
+|---|---|---|---|
+| STRIDE / STRIDE-per-element | Trust boundaries on a DFD | Per boundary: enumerate Spoof / Tamper / Repudiate / InfoDisclose / DoS / EoP; map each to ATT&CK or ATLAS TTPs from `data/atlas-ttps.json` | Privacy threats (linkability, identifiability) compressed into "InfoDisclose" lose specificity; LINDDUN required to surface them. |
+| STRIDE-ML (Microsoft, 2020) | DFD with ML training/inference/feedback elements | Per ML element: adversarial ML threats from ATLAS (AML.T0010 ML Supply Chain, AML.T0020 Poison Training Data, AML.T0043 Craft Adversarial Data, AML.T0051 LLM Prompt Injection, AML.T0054 NLP Craft Adversarial Data, AML.T0096 LLM Integration Abuse) | Agent-as-actor still missing; needs the actor-inventory amendment described in the Analysis Procedure. |
+| PASTA | App-centric attack trees with business-impact rooting | Per app component: pull CVE-level threats from `data/cve-catalog.json` (e.g. CVE-2025-53773 prompt-injection RCE in app-integrated AI assistants) and ATLAS TTPs at the app boundary | Systemic AI risks crossing services (cross-agent prompt injection, shared embedding contamination) sit outside any one app. |
+| LINDDUN / LINDDUN-PRO | DFD plus privacy threat tree | Per data flow: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure-of-Information, Unawareness/Unintervenability, Non-compliance; cross-walk to GDPR Art. 5 / Art. 32 obligations | Technical threats (memory corruption, kernel LPE) not represented. |
+| Trike | Requirements model + implementation model | Per actor-action pair: authorised vs. unauthorised actions; pull ATT&CK TTPs that bridge the gap | Limited recent revision; weaker fit for AI-agent actors. |
+| OCTAVE Allegro | Asset profiles | Per critical asset: areas-of-concern; cross-walk to ATLAS/ATT&CK | Component-level technical threats missing. |
+| Cyber Kill Chain | Linear 7-stage intrusion timeline | Per stage: ATT&CK TTPs | Cloud-native / serverless / AI-pipeline scenarios fit the timeline poorly; lateral movement assumptions break in ephemeral compute. |
+| Diamond Model | Adversary–capability–infrastructure–victim diamond | Per intrusion event: TTPs become adversary capabilities; pivot to other diamonds | Built for IR / SOC, not for design-phase threat modelling — pair with STRIDE/PASTA during design and Diamond during operate phase. |
+| MITRE Unified Kill Chain (v3.0, 2024) | 18 phases spanning initial access through objectives | Per phase: ATLAS and ATT&CK TTPs assigned to phases that cover both classical and AI-augmented attacks | Most comprehensive single methodology, but weak on privacy threats — pair with LINDDUN. |
+| AI-system threat modeling (composite) | Augmented DFD with AI actors and AI trust boundaries | Full ATLAS v5.1.0 catalogue (every `AML.T*` key in `data/atlas-ttps.json`) | Methodology not yet standardised — this skill operationalises it. |
+| Agent-based threat modeling | Actor graph with autonomous agents, MCP plugins, tool-call boundaries | CVE-2026-30615 (MCP RCE), CVE-2025-53773 (prompt-injection RCE), AML.T0051, AML.T0096 | Methodology not yet standardised — this skill operationalises it. |
+
+The truth set for any composite model is: every `AML.T*` key in `data/atlas-ttps.json`, plus every `attack_refs` entry across every CVE in `data/cve-catalog.json`, plus the CWE root-cause classes in `data/cwe-catalog.json`. A model that does not address each, or document a reasoned exclusion for each, is non-current by construction (and should be re-run through `threat-model-currency`).
+
+---
+
+## Exploit Availability Matrix
+
+Methodologies are catalog consumers, not catalog producers. The matrix shows the catalog dependency for each.
+
+| Methodology | Consumes | KEV-bound? | PoC-bound? | AI-accelerated input? | Live-patch decisions in scope? |
+|---|---|---|---|---|---|
+| STRIDE | Generic threat categories per boundary | No — threat categories are pre-CVE | No | No | No (model is design-time) |
+| STRIDE-ML | STRIDE categories + ATLAS TTPs | Indirectly via CVEs mapped to TTPs | Yes (when a TTP has a public PoC, that strengthens the threat) | Yes (AML.T0017 Develop Capabilities — AI on attacker side) | No |
+| PASTA | App-centric attack trees consuming CVE-level primitives from `data/cve-catalog.json` | Yes (KEV entries elevate tree-branch priority) | Yes | Yes | Possible — PASTA stage VI (Vulnerability and Weakness Analysis) names live-patch as a control class |
+| LINDDUN | Privacy threat tree | No — privacy threats are policy-bound, not exploit-bound | No | No | No |
+| Trike | Authorised/unauthorised action gaps | Indirectly | Indirectly | No | No |
+| OCTAVE Allegro | Asset areas-of-concern | Indirectly | No | No | No |
+| Cyber Kill Chain | Intrusion phases | Yes (KEV common in initial-access phase) | Yes | Yes | No |
+| Diamond Model | Adversary–capability–infrastructure–victim | Yes (capabilities include live CVEs) | Yes | Yes (campaigns increasingly use AI-developed capabilities per Hard Rule AGENTS.md #1 / DR-5) | Yes (Diamond pivots into IR and IR drives live-patch decisions) |
+| MITRE Unified Kill Chain v3.0 | Full ATLAS + ATT&CK across 18 phases | Yes | Yes | Yes | Yes (phases 14–18 include impact stages where live-patch SLAs are decisive) |
+| AI-system composite | Full ATLAS catalogue | Yes (CVE-2025-53773 prompt-injection RCE, CVE-2026-30615 MCP RCE, both in `data/cve-catalog.json`) | Yes | Yes | Yes (CVE-2025-53773 is SaaS live-patchable; CVE-2026-30615 is IDE-update live-patchable) |
+| Agent-based composite | ATLAS subset (AML.T0010, AML.T0051, AML.T0096) + MCP-class CVEs | Yes | Yes | Yes | Yes |
+
+None of these methodologies directly consume the CVE catalog as a primary input. All of them must be *informed* by `data/cve-catalog.json` for currency — which is what makes `threat-model-currency` the natural companion skill.
+
+---
+
+## Analysis Procedure
+
+Every threat-modelling exercise must explicitly thread three foundational principles. None is optional.
+
+- **Defense in depth.** Methodology selection itself is a defense-in-depth question. Use STRIDE-ML for technical threats *plus* LINDDUN for privacy *plus* Diamond Model for operate-phase IR scenarios *plus* MITRE Unified Kill Chain v3.0 for end-to-end lifecycle coverage. No single methodology is sufficient. The model must show, per threat, at least two control layers (prevent + detect, or prevent + contain).
+- **Least privilege.** Every actor in the model — human, service, AI agent, MCP plugin, RAG retriever, tool-call target — must be documented with a trust boundary and a minimum-scope authorisation statement. The model surfaces excess privilege as a finding, not as an implicit assumption.
+- **Zero trust.** Trust boundaries are explicit. Every boundary crossing requires verification (mutual auth, signed input, capability-scoped token, prompt-injection-resistant context boundary). The model must answer, for each boundary, *what is verified and how* — not "the network is internal".
+
+For ephemeral / serverless / AI-pipeline contexts (Hard Rule AGENTS.md #9), classical STRIDE-per-element applies poorly: there is no persistent attack surface to decompose. Use the modified procedure: model the *invocation lifecycle* (cold-start → execution → state externalisation → teardown) as the unit of analysis, attach trust boundaries to invocation-context inputs (event payload, IAM-scoped role, retrieved secrets, AI model context window), and treat the absence of persistent state as a control to be verified, not assumed.
+
+### Step 1 — Scope the system and inventory actors (including AI agents)
+
+List every actor with a trust boundary and an authorisation scope:
+
+- Human actors (end users, operators, developers, admins, contractors).
+- Service actors (microservices, batch jobs, cron tasks, queues).
+- External-system actors (third-party APIs, identity providers, SaaS).
+- **AI actors** — AI coding assistants, MCP servers, LLM endpoints, agent runtimes, autonomous workflows. Per AGENTS.md every AI actor is named, with trust boundary, with minimum-scope authorisation, with an explicit answer to "what does this agent decide on its own and what does it escalate?"
+- Data actors — vector embedding stores, RAG corpora, training data manifests, model weight artefacts. Treated as crown-jewel data even when they appear as "metadata" elsewhere.
+
+### Step 2 — Choose methodology or methodology mix
+
+Apply the selection rule:
+
+- Technical threats only, single app, design phase → STRIDE-per-element (or STRIDE-ML if any AI/ML element exists).
+- Privacy / DPIA in scope (GDPR / LGPD / PIPL / DPDPA) → add LINDDUN-PRO.
+- Multi-service / app-centric with business-impact rooting → PASTA, with STRIDE-ML inside each app-component decomposition.
+- Operate-phase / SOC / IR scenarios → Diamond Model, fed by ATLAS+ATT&CK.
+- End-to-end lifecycle, cloud-native, AI-augmented → MITRE Unified Kill Chain v3.0 as the spine, with STRIDE-ML and LINDDUN as per-phase decomposition tools.
+- AI agents present → composite AI-system + agent-based amendments to whichever spine is chosen.
+
+Document the methodology choice and rationale at the top of the artefact. Methodology choice is reviewable.
+
+### Step 3 — Draw the model
+
+Per chosen methodology:
+
+- STRIDE / STRIDE-ML / LINDDUN / PASTA → Data Flow Diagram with explicit trust boundaries and explicit AI actors. Where ephemeral compute is in scope, the DFD models invocation lifecycle, not server topology.
+- Trike → requirements model and implementation model side by side.
+- OCTAVE Allegro → asset profile sheets.
+- Cyber Kill Chain → linear stage diagram.
+- Diamond Model → adversary–capability–infrastructure–victim diamonds per intrusion event.
+- MITRE Unified Kill Chain v3.0 → 18-phase grid with applicable TTPs at each phase.
+- Agent-based → actor graph with directed edges representing tool-call authorisations.
+
+### Step 4 — Enumerate threats per methodology
+
+For STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. For STRIDE-ML add: Model Stealing, Model Poisoning, Adversarial Input, Prompt Injection, Membership Inference. For LINDDUN: Linkability, Identifiability, Non-repudiation (of data subjects), Detectability, Disclosure of Information, Unawareness/Unintervenability, Non-compliance. For PASTA: complete the seven stages (Define Objectives → Define Technical Scope → App Decomposition → Threat Analysis → Vulnerability & Weakness Analysis → Attack Modelling → Risk & Impact Analysis).
+
+### Step 5 — Map threats to ATLAS + ATT&CK
+
+For each enumerated threat, attach at least one `AML.T*` ID from `data/atlas-ttps.json` or one ATT&CK `T*` ID. Threats with no TTP attachment are either (a) novel — and require an entry into the zero-day learning loop via `zeroday-gap-learn` — or (b) over-broad and need decomposition.
+
+### Step 6 — Cross-walk to CWE root causes
+
+For each technical threat, attach the relevant CWE class from `data/cwe-catalog.json`. CWE is the design-defect view that complements ATT&CK's behavioural view. A model whose threats cross-walk only to TTPs is operationally complete but architecturally thin.
+
+### Step 7 — Score known CVEs per RWEP
+
+For each threat that maps to a known CVE in `data/cve-catalog.json`, score per RWEP (`lib/scoring.js`) — not CVSS alone (Hard Rule AGENTS.md #3, DR-2). RWEP outputs feed prioritisation in step 8.
+
+### Step 8 — Produce mitigations (hand off to defensive-countermeasure-mapping)
+
+Mitigations are out of scope for this skill. Every enumerated threat is handed to `defensive-countermeasure-mapping`, which produces D3FEND IDs from `data/d3fend-catalog.json`. The cross-walk handoff is described in section "Defensive Countermeasure Mapping" below.
+
+### Step 9 — Integrate findings to threat-model-currency
+
+The output of this skill feeds `threat-model-currency` as the model under test. Currency assessment runs against this artefact, not against a separately-maintained PDF.
+
+### Step 10 — Re-run on cadence
+
+Per Hard Rule AGENTS.md #12 (external data version pinning): when ATLAS, ATT&CK, NIST 800-218 SSDF, ISO/IEC 42001, or any data-dep version pin advances, re-run the model. Currency triggers also include: any new CVE in scope (`data/cve-catalog.json` change), any new zero-day lesson (`data/zeroday-lessons.json` change), any change to actor inventory (new agent, new MCP server, new RAG corpus).
+
+---
+
+## Output Format
+
+```
+## Threat Model — <system name>
+**Date:** YYYY-MM-DD
+**Methodology:** <STRIDE-ML + LINDDUN + Diamond | Unified Kill Chain v3.0 | composite ...>
+**Methodology rationale:** <why this combination, not others>
+**Currency triggers:** <list of upstream changes that will require re-run>
+
+### 1. Scope and Actor Inventory
+| Actor | Type (human/service/AI/data) | Trust boundary | Minimum-scope authorisation | Notes |
+|---|---|---|---|---|
+
+### 2. AI / Agent Inventory (required if any AI actor present)
+| Agent | Runtime | Tool-call surface | Plugins / MCP servers | Decides on its own | Escalates to |
+|---|---|---|---|---|---|
+
+### 3. Data Flow Diagram / Attack Tree / Kill Chain Grid
+<diagram or structured representation per methodology choice>
+
+### 4. Threat Enumeration
+| # | Methodology | Element / Phase | Threat | ATLAS / ATT&CK TTP | CWE | CVE (if any) | RWEP |
+|---|---|---|---|---|---|---|---|
+
+### 5. ATLAS / ATT&CK Cross-Walk
+<aggregated TTP list against atlas-ttps.json and ATT&CK; flag uncovered TTPs>
+
+### 6. CWE Root-Cause Cross-Walk
+<aggregated CWE list against cwe-catalog.json>
+
+### 7. Mitigation Roadmap (hand-off)
+<refer each threat to defensive-countermeasure-mapping output; do not enumerate D3FEND here>
+
+### 8. Currency Triggers
+<list specific external events that invalidate this model and require re-run via threat-model-currency>
+
+### 9. Methodology Limitations
+<explicit per-methodology gap statement; e.g., "STRIDE-ML does not surface privacy threats; LINDDUN-PRO addendum at section 4b">
+```
+
+---
+
+## Compliance Theater Check
+
+Apply each test. A "no" on any of (a)–(e) means the threat-model is paper.
+
+(a) **Currency.** "Show me your current threat model." If the response is "we did one two years ago" or "let me find it in SharePoint", theater — the model is not an operational artefact.
+
+(b) **Co-location with the system.** "Is your threat model checked into the same Git repository as the system it models, with a `CODEOWNERS` rule that requires security review on changes?" If it lives in a SharePoint, Confluence wiki, or shared drive disconnected from the codebase, theater — there is no enforced review on system changes that invalidate the model.
+
+(c) **AI agents as actors.** "Did your latest threat model include AI agents as actors with their own trust boundaries and minimum-scope authorisation statements? Name them." If the actor inventory does not name AI coding assistants, MCP servers, agent runtimes, or RAG retrievers, the model is 2022-vintage regardless of its date stamp.
+
+(d) **Right methodology for privacy.** "For your privacy threats, did you use STRIDE or LINDDUN?" STRIDE for privacy is the wrong methodology — InfoDisclose compresses seven LINDDUN categories into one. If the DPIA / RIPD / PIPIA referenced this model and it used STRIDE alone for privacy, the privacy assessment is theater.
+
+(e) **Cross-jurisdiction.** "Did your model include cross-jurisdiction threats — EU AI Act high-risk categorisation, NIS2 incident-reporting timelines, DORA ICT third-party register, UK CAF B4, AU ISM AI annex, IL INCD methodology, JP NISC, SG CCoP 2.0?" Hard Rule AGENTS.md #5: a model citing only US frameworks does not meet the bar.
+
+(f) **Methodology rationale.** "Why did you choose this methodology mix?" If the answer is "because that's what we always do" or "because STRIDE is the standard", the methodology choice was not reviewed. Document the rationale or it is theater.
+
+---
+
+## Defensive Countermeasure Mapping
+
+Threat modelling produces an enumerated threat set; mitigations come from the `defensive-countermeasure-mapping` skill. Every threat in the Threat Enumeration table (section 4 of Output Format) is handed off as an input to that skill, which produces D3FEND IDs from `data/d3fend-catalog.json` along with the explicit four-axis annotation:
+
+- **Defense-in-depth layer position.** Each D3FEND mapping is annotated with its layer (network, host, identity, application, data, agent context). Threats that map to only one layer are flagged for additional layering.
+- **Least-privilege scope.** Each mapping is annotated with the principal whose privilege is being scoped (human user, service identity, agent, plugin). Mappings that do not narrow privilege are flagged as monitoring-only.
+- **Zero-trust posture.** Each mapping declares the verification primitive at the boundary it covers (mutual auth, signed input, prompt-injection-resistant context boundary, capability-scoped token).
+- **AI-pipeline applicability (Hard Rule AGENTS.md #9).** Each mapping declares whether it is architecturally feasible for serverless / containerised / AI-pipeline targets. Mappings that are infeasible are paired with an explicitly scoped alternative or marked "no compensating control available — accept residual or redesign".
+
+For each threat enumerated in this skill's output, the receiving `defensive-countermeasure-mapping` invocation must produce at least one D3FEND ID at two distinct defense-in-depth layers (per "Defense in depth" in Analysis Procedure step 0). Threats with only one layer of D3FEND coverage are flagged as defense-shallow and routed back to design.
+
+---
+
+## Hand-Off / Related Skills
+
+- **`threat-model-currency`** — runs after this skill to score the produced model against 14 currency classes. The two skills are companion artefacts: methodology builds the model, currency keeps it fresh.
+- **`defensive-countermeasure-mapping`** — receives the threat enumeration from section 4 of Output Format and produces D3FEND mitigations. Mandatory hand-off for any shipped threat model.
+- **`researcher`** — dispatcher for "what skill addresses this specific threat I just enumerated?" Use when a threat in section 4 does not have an obvious skill home.
+- **`zeroday-gap-learn`** — receives any threat enumerated in section 4 that has no ATLAS or ATT&CK TTP attachment. New threats feed back into the learning loop per Hard Rule AGENTS.md #6.
+- **`framework-gap-analysis`** — receives any threat enumerated in section 4 that is not addressed by an existing framework control. The model exposes framework gaps as a natural by-product of cross-walk; framework-gap-analysis then runs the global EU+UK+AU+ISO+IL+JP+SG comparison.
+- **`ai-attack-surface`** — runs alongside this skill when the actor inventory includes any AI agent. Produces the AI-specific TTP set that feeds the threat enumeration.
+- **`mcp-agent-trust`** — runs alongside this skill when the actor inventory includes any MCP server or agent plugin. Produces the trust-boundary specification for MCP edges.
+- **`rag-pipeline-security`** — runs alongside this skill when the data inventory includes any RAG corpus or vector embedding store.

package/skills/webapp-security/skill.md

@@ -0,0 +1,281 @@
+---
+name: webapp-security
+version: "1.0.0"
+description: Web application security for mid-2026 — OWASP Top 10 2025, OWASP ASVS v5, CWE root-cause coverage, AI-generated code weakness drift, server-rendered vs SPA tradeoffs, defense-in-depth across the request lifecycle
+triggers:
+  - webapp security
+  - web application security
+  - owasp top 10
+  - owasp asvs
+  - xss
+  - csrf
+  - sqli
+  - sql injection
+  - path traversal
+  - ssrf
+  - file upload
+  - command injection
+  - unsafe deserialization
+  - broken access control
+  - ai generated code
+data_deps:
+  - cve-catalog.json
+  - atlas-ttps.json
+  - framework-control-gaps.json
+  - cwe-catalog.json
+  - d3fend-catalog.json
+  - rfc-references.json
+atlas_refs:
+  - AML.T0051
+attack_refs:
+  - T1190
+  - T1059
+  - T1505
+framework_gaps:
+  - OWASP-ASVS-v5.0-V14
+  - OWASP-LLM-Top-10-2025-LLM01
+  - NIST-800-218-SSDF
+  - ISO-27001-2022-A.8.28
+rfc_refs:
+  - RFC-8446
+  - RFC-9114
+  - RFC-7519
+  - RFC-8725
+cwe_refs:
+  - CWE-22
+  - CWE-77
+  - CWE-78
+  - CWE-79
+  - CWE-89
+  - CWE-94
+  - CWE-200
+  - CWE-269
+  - CWE-287
+  - CWE-352
+  - CWE-434
+  - CWE-502
+  - CWE-732
+  - CWE-862
+  - CWE-863
+  - CWE-918
+  - CWE-1188
+d3fend_refs:
+  - D3-IOPR
+  - D3-NTA
+  - D3-CSPP
+  - D3-EAL
+  - D3-MFA
+last_threat_review: "2026-05-11"
+---
+
+# Web Application Security Assessment
+
+## Threat Context (mid-2026)
+
+Webapps still ship CWE-79 (Cross-Site Scripting), CWE-89 (SQL Injection), and CWE-22 (Path Traversal) at rates the industry was supposed to have engineered out of existence by 2018. The reason is not mystery — it is AI codegen drift. Coding assistants (GitHub Copilot, Cursor, Windsurf, Claude Code, Codex, Gemini Code Assist) reintroduce OWASP-Top-10-class weaknesses into new code at roughly the rate human review removed them during the 2010s. Industry analysis published in early 2026 across several large-codebase studies converges on the same order of magnitude: approximately **30% of AI-suggested webapp code contains at least one Top-10-class weakness**, and approximately **60% of those weaknesses reach production unmodified** because the human developer treats the assistant's output as reviewed-by-default.
+
+**CVE-2025-53773 (GitHub Copilot prompt-injection RCE, CVSS 9.6)** is the canonical mid-2026 case: the weakness propagated *through* the coding assistant rather than from a human developer. The attack vector is a hidden adversarial instruction in a PR description; when a developer asks Copilot to summarise the PR, the injected instruction runs in the developer's session context. This collapses the boundary between code review and code execution — the AI is both the reviewer and the executor, and the prompt is the payload. OWASP Top 10 2025 added **LLM01 (Prompt Injection)** as a top-tier risk for any AI-fronted webapp; ASVS v5 does not yet operationalise prompt injection as a verification surface.
+
+**Architectural reaction: server-rendered apps regained share.** Through 2023–2025 the SPA-everything trend pushed business logic, auth state, and access decisions into the client. With AI codegen now producing client-side TypeScript at industrial volume, the per-route client attack surface compounded — every route became a potential CWE-200 (Information Exposure) and CWE-862 (Missing Authorization) carrier because client-side checks are advisory, not authoritative. Mid-2026 architectures favour **server-rendered-by-default with interactive islands**: React Server Components, Next.js App Router, Remix, Phoenix LiveView, HTMX, Rails Hotwire. Auth lives on the server. State changes traverse server actions. SPAs survive where a true client-side data model exists (collaborative editing, offline-first), and they pay for it with explicit zero-trust auth on every endpoint.
+
+**Exploit acceleration is current operational reality, not a forecast.** Agentic exploitation frameworks emerging through 2025–2026 (PentestGPT lineage, autonomous-recon-and-exploit toolchains) compress the time from CVE disclosure to mass exploitation for known webapp weakness classes. The defender's working assumption must be: any CVE-2025/2026 RCE in a public webapp framework is being scanned for within hours of disclosure, not days (per DR-5: AI acceleration is current operational reality).
+
+**Transport is no longer a choice.** RFC 8446 (TLS 1.3) is baseline; RFC 9114 (HTTP/3 over QUIC) is the production transport for any public webapp serving a global audience. Skills citing TLS 1.2 as adequate in 2026 are citing a deprecated threat model. JWT-based session tokens must be issued and validated per RFC 7519 with RFC 8725 (JWT BCP) — the BCP is non-optional because the original RFC 7519 threat model under-specified algorithm pinning, audience checks, and key confusion.
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control | Why It Fails in mid-2026 |
+|---|---|---|
+| OWASP Top 10 2025 | LLM01 (Prompt Injection) added as #1 for AI-fronted apps | The list now names prompt injection as a webapp risk class, but most ASVS-driven verification programmes have not yet incorporated it as a tested surface. Tracked in `data/framework-control-gaps.json` as OWASP-LLM-Top-10-2025-LLM01. |
+| OWASP ASVS v5.0 | V14 (Configuration) | V14 covers configuration hardening for the deployed app. It does not yet operationalise **AI-generated code as a verification surface**: there is no V14 requirement to mark AI-generated handlers, no separate verification level for AI-introduced weakness drift, no provenance attestation. Tracked as OWASP-ASVS-v5.0-V14. |
+| OWASP ASVS v5.0 | V5 (Validation, Sanitization & Encoding) | Comprehensive for human-authored validation logic; assumes the developer chose the encoding. AI-suggested handlers frequently bypass the project's canonical validation library and inline ad-hoc string handling — V5 has no requirement to detect *which* validation path is used per route. |
+| NIST SSDF (SP 800-218) | PW.4 / PW.7 (secure coding practices, code review) | SSDF mentions secure coding and review without naming AI-codegen as a special case. The "review" assumed in PW.7 is a human reading code; it does not require re-review when the next AI-codegen-CVE wave reveals a new weakness class in previously-shipped AI-suggested code. Tracked as NIST-800-218-SSDF. |
+| ISO 27001:2022 | A.8.28 (Secure coding) | Method-agnostic — applies equally to hand-written and AI-generated code, which means it has no AI-codegen-specific control surface. Tracked as ISO-27001-2022-A.8.28. |
+| EU NIS2 (2022/2555) | Art. 21(2)(e) effectiveness of cybersecurity measures | Requires policies for assessing effectiveness but does not mandate webapp pen testing, ASVS verification, or AI-codegen review cadence. An organisation can claim Art. 21(2)(e) compliance with a yearly checklist and no offensive test. |
+| EU DORA (2022/2554) | Art. 24–25 ICT testing, Art. 26 TLPT | TLPT is mandatory only for in-scope financial entities and only periodically. Day-to-day webapp testing is left to the entity's "ICT risk management framework" — no specific minimum. |
+| UK NCSC CAF | B4 (Vulnerability management) | Method-neutral and outcome-based — does not specify webapp testing depth, ASVS level, or AI-codegen audit. A B4-compliant org may still ship CWE-79 in AI-generated handlers. |
+| AU ISM | Control 1235 (secure programming practices) | Names secure programming but predates the AI-codegen weakness-drift problem. No control distinguishing AI-suggested code from human-authored code. |
+| JP FISC v9 | Secure-coding baseline | Sector-specific (banking/financial) baseline for secure development. Does not address AI-generated code provenance or re-review obligations. |
+| IL INCD | Secure-coding directives (gov + critical infra) | Mandates secure-coding training and SAST/DAST in the SDLC. Does not mandate AI-codegen provenance markers or differential review. |
+| SG MAS TRM | §7 software development | Sector-specific (regulated financial entities). Names secure coding lifecycle but does not address AI-codegen as a distinct risk class. |
+| NYDFS 23 NYCRR 500 | §500.5 penetration testing & vulnerability assessment | Annual pen test + bi-annual vulnerability assessment is the floor. For AI-fronted apps with prompt-injection surface, "annual" is structurally inadequate against agentic-exploit timelines. |
+
+---
+
+## TTP Mapping (MITRE ATT&CK Enterprise + ATLAS v5.1.0)
+
+| TTP ID | Technique | Webapp Manifestation | CWE Root-Causes | Framework Coverage |
+|---|---|---|---|---|
+| T1190 | Exploit Public-Facing Application | Direct exploitation of an internet-exposed webapp endpoint | CWE-22, CWE-78, CWE-79, CWE-89, CWE-94, CWE-434, CWE-502, CWE-918 | Partial — ASVS V5/V7/V12 cover; framework gap for AI-codegen weakness reintroduction |
+| T1059 | Command and Scripting Interpreter | Server-side RCE via webapp handler invoking a shell/interpreter | CWE-77, CWE-78, CWE-94, CWE-502 | Partial — secure coding standards address; no AI-codegen-specific control |
+| T1505 | Server Software Component (web shell) | Post-exploitation web shell uploaded via dangerous file upload or path traversal | CWE-22, CWE-434, CWE-732 | Partial — D3-EAL (executable allowlisting) and write-once webroot mitigate; no framework mandates either |
+| T1078 | Valid Accounts (used after credential capture / IDOR) | Authenticated-context abuse following CWE-863 / CWE-352 / CWE-1188 weaknesses | CWE-269, CWE-287, CWE-352, CWE-862, CWE-863, CWE-1188 | Partial — ASVS V3/V4 cover session/access; no control for AI-suggested authorisation logic |
+| AML.T0051 | LLM Prompt Injection (for AI-fronted webapps) | Adversarial instructions in user input reaching an LLM with tool/action capability | CWE-94 (interpreted-instruction injection class) | Missing in NIST/ISO/SOC 2; OWASP LLM Top 10 2025 LLM01 names it; ASVS v5 does not yet test it |
+
+---
+
+## Exploit Availability Matrix
+
+| CWE Class | Tooling Maturity (offensive) | Tooling Maturity (defensive SAST/DAST/IAST) | AI-Augmented Exploitation | Bug Bounty Market Signal (mid-2026, order-of-magnitude) | Patch Availability |
+|---|---|---|---|---|---|
+| CWE-89 (SQLi) | Burp Suite Pro, sqlmap, ZAP — fully mature | Semgrep, CodeQL, GitHub Advanced Security, Snyk Code — high coverage | Yes — agentic frameworks chain recon + payload generation | Critical SQLi → RCE typically tens-of-thousands USD on enterprise programmes | Instant for framework CVEs; cultural-fix lag for AI-codegen reintroduction |
+| CWE-79 (XSS) | Burp, ZAP, XSStrike — mature; DOM XSS still finds in SPAs | SAST high for reflected; weaker for DOM/mutation XSS | Yes — automated payload mutation against context-aware filters | Stored XSS on auth surface mid-single-digit thousands USD | Framework patches instant; AI-codegen reintroduction recurs |
+| CWE-22 (Path Traversal) | Mature (Burp, ZAP, ffuf) | SAST high coverage for direct sinks | Moderate — agentic recon enumerates upload+download pairs | Lower-mid thousands USD typical | Instant for framework; reintroduced by AI-suggested file-handler code |
+| CWE-78 / CWE-77 (Command Injection) | Mature (Burp, commix) | SAST high coverage; IAST excellent | Yes — straightforward for agentic toolchains | Critical RCE order-of-magnitude tens-of-thousands USD | Patchable but reintroduced when AI suggests shell-exec helpers |
+| CWE-434 (Dangerous File Upload) | Mature; chains with T1505 web shell installation | SAST moderate; DAST high; IAST excellent | Yes | Critical RCE tier when chains to webshell | Patchable per-route; reintroduced by AI-suggested upload handlers |
+| CWE-918 (SSRF) | Mature (Burp Collaborator, cloud metadata endpoints) | SAST moderate; needs allow-list intent annotation | Yes — agentic frameworks chain SSRF → cloud IMDS → credential theft | High mid-tier (cloud credential theft chains push toward Critical) | Patchable; commonly reintroduced when AI suggests "fetch URL" handlers |
+| CWE-502 (Unsafe Deserialization) | Mature (ysoserial, marshalsec) | SAST high in Java/.NET; weaker in dynamic-language native-format deserialisers | Yes | Critical RCE tier | Patchable but reintroduced when AI suggests "deserialise the request body" handlers without an allow-list |
+| CWE-352 (CSRF) | Mature; SameSite weakens but does not eliminate | SAST low (intent-dependent); DAST moderate | Limited — defence is structural | Lower-mid thousands USD typical | Defence is architectural (CSRF tokens + SameSite + origin checks) |
+| CWE-862 / CWE-863 (Missing/Incorrect Authorisation, IDOR class) | Mature (Burp Autorize) | SAST low — intent-dependent; requires per-route auth model | Yes — agentic frameworks enumerate route + token combinations | IDOR mid-tier; privilege-escalation IDOR high mid-tier | Per-route fix; reintroduced when AI suggests handlers without auth check |
+| CWE-1188 (Insecure Default Initialization) | Manual review heavy | SAST moderate (config-aware) | Limited | Variable | Architectural |
+| AML.T0051 (Prompt Injection, AI-fronted webapps) | Manual + emerging Garak / Promptfoo / adaptive frameworks | Prompt-injection classifiers, output guardrails — partial only | Yes — adaptive attacks succeed >85% against SOTA defences per 2026 meta-analysis | Variable — emerging programme category | No reliable patch; defence-in-depth only |
+
+---
+
+## Analysis Procedure
+
+The procedure threads three foundational design principles end-to-end. They are not optional and they are not interchangeable.
+
+**Defense in depth** — the request lifecycle is layered, no single control is trusted to fail closed:
+
+1. **Perimeter** — WAF / CDN bot management is a signal layer, not a control layer. WAF rules detect known payload shapes (Burp default, sqlmap default) but do not catch AI-mutated payloads reliably. Treat WAF output as a tripwire feeding SIEM, never as a substitute for input validation.
+2. **Transport** — TLS 1.3 (RFC 8446) baseline; HTTP/3 over QUIC (RFC 9114) for public global apps. HSTS preload. Certificate pinning where the client is a controlled mobile app, not a browser.
+3. **Input validation (canonical control)** — every route declares its input schema (JSON Schema, Pydantic, Zod, ASP.NET model binding). Validation happens server-side at handler entry. Schemas pinned to project canonical types — no ad-hoc inline parsing in AI-suggested handlers.
+4. **Output encoding (XSS counter)** — context-aware encoding per sink (HTML body, attribute, JS, URL, CSS). Server-rendered templates default to escape; SPA frameworks default to escape but interpolate raw HTML on developer opt-in (raw-HTML interpolation APIs and analogues are reviewed surfaces).
+5. **Auth at every endpoint (no implicit trust between handlers)** — every route declares its required role/scope. There is no "internal" handler that skips auth because it is "only called by other handlers".
+6. **CSRF tokens + SameSite cookies + origin checks (state-change defence)** — defence is layered because each component fails in known scenarios: SameSite=Lax permits top-level navigation; tokens fail if leaked via XSS; origin checks fail behind some proxies. Use all three.
+7. **DB parameterisation (SQLi counter)** — every query parameterised. ORMs default to parameterised; raw SQL is a reviewed surface. AI-suggested handlers that build SQL strings via interpolation are blocked at PR.
+8. **Server-rendered with interactive islands** — reduces the client attack surface. State changes traverse server actions. Auth decisions are server-authoritative. SPAs only where a real client-side data model exists.
+9. **SAST + DAST + IAST in CI** — SAST (Semgrep, CodeQL, GitHub Advanced Security) at every PR; DAST (ZAP, Burp Enterprise) on staging; IAST in staging integration tests. Findings have an explicit fix-or-document SLA, not an indefinite backlog.
+10. **Fuzz parser surfaces** — every binary/text parser exposed to user input is fuzzed (hand-off to `fuzz-testing-strategy`).
+
+**Least privilege** — every endpoint, every service-account, every deployment principal:
+
+- Every endpoint declares the minimum role/scope; no super-handler that "does everything".
+- Service-account-style API tokens scoped per route, per action, not blanket-admin.
+- AI-generated handlers default to **least privilege per ASVS V14** — no implicit elevation, no shared credential pool.
+- Database principals scoped per service (no app-wide DBA credential); row-level security where the framework supports it.
+- File-handler processes run with a write-once webroot and no shell.
+
+**Zero trust** — every request is hostile until proven otherwise:
+
+- Sessions short-lived. Refresh tokens rotated and sender-constrained (DPoP / mTLS) per RFC 9700 BCP.
+- JWTs validated per RFC 7519 + RFC 8725: algorithm pinned, audience checked, expiry enforced, key resolved via JWKS with key-ID match — no algorithm-none acceptance, no algorithm confusion.
+- Every state change requires explicit auth + CSRF + origin.
+- Never trust client-provided role / identity / tenant; the server resolves identity from the session and authorisation from the server-side policy.
+- Internal-network position grants nothing — SSRF assumes the attacker is already inside.
+
+### The 10-step assessment
+
+1. **Inventory routes + auth requirements + data sensitivity.** Enumerate every HTTP route (or GraphQL operation, gRPC method). For each: required role, request schema, response schema, data classification, AI-codegen provenance flag (was this handler suggested by an assistant?).
+2. **Map each route to CWE-Top-25-class risk.** Score by CWE class × data sensitivity × external reachability. Apply the RWEP model — CVSS alone fails per AGENTS.md Hard Rule #3.
+3. **Audit AI-generated code separately from human-written code.** Require commit-time provenance markers (git trailer, commit-message tag, or co-author metadata) identifying AI-assisted commits. Re-review AI-suggested handlers on every AI-codegen-CVE wave (e.g. CVE-2025-53773 → re-review every Copilot-suggested handler in the affected window). If provenance is not captured, the org cannot answer "what code do we need to re-review?" — this is a compliance-theater indicator.
+4. **SAST + DAST coverage measurement.** Report: % of routes covered by SAST sinks, % covered by DAST in staging, findings-to-fix ratio over trailing 90 days. A SAST programme that finds and does not fix is theater (AGENTS.md DR-1 / Hard Rule #8).
+5. **IAST in staging.** Instrumented runtime testing covers what SAST cannot (intent-dependent authorisation, runtime config). Required for any app handling regulated data (PII, PCI, PHI).
+6. **Fuzz parser surfaces.** Hand off to `fuzz-testing-strategy` for any parser, deserialiser, or media-handler reachable from a public route. Fuzz corpus seeded from production traffic samples (sanitised).
+7. **Server-rendered-by-default decision.** Justify any SPA-only route against the AI-codegen blast radius. SPAs allowed where a true client-side data model exists; not allowed by default for CRUD with auth checks.
+8. **CSRF + origin + SameSite policy.** Document the per-route stance. Cookie-based session auth without SameSite=Lax or Strict + CSRF tokens is a finding. Bearer-token auth on the Authorization header is not CSRF-exempt for mixed cookie/bearer apps — verify.
+9. **Output encoding policy.** Per-template-engine default-escape verification. Audit every raw-HTML opt-out (raw-interpolation APIs, `|safe`, `html_safe`, `raw()`). Each opt-out is a reviewed and documented surface.
+10. **Deployment with least-privilege service identity.** Database creds scoped per service. Outbound network policy denies by default (mitigates CWE-918 SSRF → cloud metadata exfiltration chain). Filesystem writes scoped to a single ephemeral path. No shared service account across microservices.
+
+---
+
+## Output Format
+
+```
+## Web Application Security Assessment
+
+**Assessment Date:** YYYY-MM-DD
+**Scope:** [app/repo names, route count, in-scope environments]
+**ASVS Target Level:** [L1 / L2 / L3, with justification by data sensitivity]
+
+### Per-Route Risk Matrix
+| Route | Auth Required | Data Class | CWE Root-Cause Risks | Current Controls | AI-Codegen Blast Radius | RWEP | Remediation |
+|-------|---------------|------------|----------------------|------------------|-------------------------|------|-------------|
+| POST /api/upload | role:editor | regulated | CWE-434, CWE-22, CWE-78 | content-type allowlist; magic-byte check; UUID rename | Suggested by Copilot 2025-11; not re-reviewed | [score] | [action + SLA] |
+
+### AI-Codegen Audit Summary
+- Total routes: [N]
+- Routes with AI-suggested handlers (provenance-marked): [N] ([%])
+- Routes with AI-suggested handlers (provenance unknown): [N] ([%]) — compliance-theater indicator if >10%
+- Routes re-reviewed after most recent AI-codegen CVE wave: [N] ([%])
+- AI-suggested handlers bypassing canonical validation library: [N]
+- AI-suggested handlers without auth check: [N]
+
+### ASVS Coverage Report
+| ASVS Section | L1 / L2 / L3 Verified | Gaps |
+|--------------|----------------------|------|
+| V2 Authentication | [status] | [items] |
+| V3 Session Management | [status] | [items] |
+| V4 Access Control | [status] | [items] |
+| V5 Validation, Sanitization & Encoding | [status] | [items] |
+| V7 Error Handling & Logging | [status] | [items] |
+| V8 Data Protection | [status] | [items] |
+| V12 Files & Resources | [status] | [items] |
+| V13 API & Web Service | [status] | [items] |
+| V14 Configuration (incl. AI-codegen gap per OWASP-ASVS-v5.0-V14) | [status] | [items] |
+
+### OWASP Top 10 2025 Coverage Card
+| Rank | Category | Coverage | Notes |
+|------|----------|----------|-------|
+| A01 | Broken Access Control | [status] | CWE-862/863/1188 audit per route |
+| A02 | Cryptographic Failures | [status] | TLS 1.3 baseline, JWT per RFC 8725 |
+| A03 | Injection | [status] | CWE-79/89/77/78/94 — DB parameterisation, output encoding |
+| A04 | Insecure Design | [status] | Threat-model currency (hand-off) |
+| A05 | Security Misconfiguration | [status] | ASVS V14 |
+| A06 | Vulnerable & Outdated Components | [status] | Hand-off to supply-chain-integrity |
+| A07 | Identification & Authentication Failures | [status] | Hand-off to identity-assurance |
+| A08 | Software & Data Integrity Failures | [status] | CWE-502; SLSA provenance for build outputs |
+| A09 | Security Logging & Monitoring Failures | [status] | Auth-failure logging, anomaly detection |
+| A10 | Server-Side Request Forgery | [status] | CWE-918; outbound network policy |
+| LLM01 | Prompt Injection (for AI-fronted routes) | [status] | Per OWASP-LLM-Top-10-2025-LLM01; hand-off to ai-attack-surface |
+
+### Framework Gaps (Global)
+[Per framework in scope from the Framework Lag Declaration: specific controls that fail for AI-codegen weakness drift and prompt-injection surface.]
+
+### Prioritised Recommendations
+[Ordered by RWEP impact, with SLA. AI-codegen re-review actions called out explicitly.]
+```
+
+---
+
+## Compliance Theater Check
+
+Each test below distinguishes paper compliance from real posture. A "no" answer to any of (a)–(d) means the corresponding control claim is theater.
+
+**(a) SAST findings-to-fix ratio.** "Show me the most recent SAST report for this codebase. What was the findings-to-fix ratio over the last 90 days?" If SAST runs but findings sit in a backlog with no SLA — or if the team's first response is "we have a SAST tool" without producing the ratio — the SAST control is theater (AGENTS.md DR-1).
+
+**(b) Auth-failure test coverage.** "What percentage of routes have unit or integration tests that assert auth failure modes — 401 when unauthenticated, 403 when authenticated as a non-authorised role, 404-or-403 (depending on policy) when the resource exists but the caller has no access?" If the answer is qualitative ("we test auth") rather than a number, the auth-control claim is paper (CWE-862 / CWE-863 / CWE-1188 are not tested into existence by the framework alone).
+
+**(c) AI-codegen provenance.** "Is AI-generated code marked at commit time — git trailer, commit message tag, or co-author metadata — so it can be re-reviewed at the next AI-codegen-CVE wave?" If there is no provenance signal, the org cannot answer "what code do we need to re-review when the next CVE-2025-53773-class issue lands?" — and the re-review claim is theater.
+
+**(d) Bug-bounty time-to-fix for Critical.** "For your last 10 bug-bounty payouts (or your last 10 internal security findings classified Critical), what was the time-to-fix? Provide the dates." If the median time-to-fix for Critical exceeds 30 days, the vulnerability-management claim is theater regardless of what the policy document says. For Critical RCE in an AI-codegen reintroduction class (CWE-89, CWE-78, CWE-502, CWE-918), the operational target should be measured in hours-to-days, not weeks (AGENTS.md DR-3 — control existence requires operational SLA, not policy language).
+
+---
+
+## Defensive Countermeasure Mapping
+
+Each D3FEND technique below maps an offensive finding from the assessment to a defensive control, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability per AGENTS.md Hard Rule #9.
+
+| D3FEND ID | Technique | Layer (defense in depth) | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
+|---|---|--------------------------|-----------------------|--------------------|---------------------------|
+| D3-IOPR | Input / Output Profiling (Message Analysis) | Perimeter + handler entry — request shape and content profiling against a route's declared schema | Per-route schema; no shared "generic input filter" | Every request inspected; absence of WAF alert is not absence of attack — feeds SIEM, not a fail-closed control | Applies to AI-fronted routes — anomalous prompt shape (high-entropy, instruction-pattern) is a profile signal |
+| D3-NTA | Network Traffic Analysis | Network egress — webapp outbound connections profiled against intent | Per-service egress allowlist; no shared default-allow | Outbound denied by default; SSRF (CWE-918) cannot reach cloud metadata or internal-only services | Critical for AI-fronted apps — model API calls profiled for SesameOp-style covert C2 (hand-off to ai-c2-detection) |
+| D3-CSPP | Client-Server Payload Profiling | Handler entry — request payload shape, header order, TLS fingerprint anomalies | Per-route baseline; no app-wide model | Anomalous request shape is suspicious even if syntactically valid | Applies to AI-fronted routes — adversarial payload shapes (long context, repeated instruction tokens) flagged |
+| D3-EAL | Executable Allowlisting | Server filesystem — block T1505 web-shell installation post-CWE-22 / CWE-434 exploitation | Write-once webroot; service principal cannot execute scripts in upload directory | Even on successful upload exploit, the uploaded file cannot execute as a handler | Applies — protects AI-assistant-suggested file-upload handlers that miss the executable-extension check |
+| D3-MFA | Multi-Factor Authentication (Auth Hardening) | Identity layer — phishing-resistant FIDO2 / WebAuthn passkeys | Per-principal; no shared MFA enrolment | Every authentication challenge resistant to AiTM proxy phishing; passkey-only for privileged routes | Critical — AI-assisted phishing kit development compresses time-to-weaponise; TOTP / SMS are insufficient (hand-off to identity-assurance) |
+
+---
+
+## Hand-Off / Related Skills
+
+- **`attack-surface-pentest`** — operate this skill's per-route risk matrix as scoping input for offensive testing (TIBER-EU / CBEST style).
+- **`fuzz-testing-strategy`** — hand off every parser, deserialiser, and media-handler surface identified in step 6 of the procedure.
+- **`defensive-countermeasure-mapping`** — extend the D3FEND mapping above into a full multi-layer defensive architecture review.
+- **`identity-assurance`** — operationalise D3-MFA and the auth-at-every-endpoint requirement (FIDO2 / passkey / OIDC / RFC 9700 OAuth BCP).
+- **`supply-chain-integrity`** — extend OWASP Top 10 2025 A06 (Vulnerable & Outdated Components) and A08 (Software & Data Integrity Failures) into SBOM, SLSA, VEX, and Sigstore coverage.
+- **`ai-attack-surface`** — for AI-fronted routes, hand off the LLM01 prompt-injection surface and MCP trust posture analysis.
+- **`ai-c2-detection`** — for AI-fronted apps, integrate D3-NTA egress baselining for SesameOp-class covert C2 detection.
+- **`threat-modeling-methodology`** — apply STRIDE / PASTA / LINDDUN to the per-route risk matrix for design-time coverage of OWASP Top 10 2025 A04 (Insecure Design).