@blamejs/exceptd-skills 0.15.0 → 0.15.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (49) hide show
  1. package/CHANGELOG.md +12 -0
  2. package/data/_indexes/_meta.json +44 -44
  3. package/data/_indexes/section-offsets.json +804 -795
  4. package/data/_indexes/summary-cards.json +3 -3
  5. package/data/_indexes/token-budget.json +506 -501
  6. package/data/cve-catalog.json +629 -51
  7. package/manifest.json +84 -84
  8. package/package.json +1 -1
  9. package/sbom.cdx.json +94 -94
  10. package/skills/age-gates-child-safety/skill.md +7 -7
  11. package/skills/ai-attack-surface/skill.md +1 -1
  12. package/skills/ai-c2-detection/skill.md +3 -3
  13. package/skills/ai-risk-management/skill.md +9 -9
  14. package/skills/api-security/skill.md +4 -4
  15. package/skills/cloud-security/skill.md +7 -7
  16. package/skills/compliance-theater/skill.md +4 -4
  17. package/skills/container-runtime-security/skill.md +6 -6
  18. package/skills/coordinated-vuln-disclosure/skill.md +12 -12
  19. package/skills/defensive-countermeasure-mapping/skill.md +14 -10
  20. package/skills/dlp-gap-analysis/skill.md +3 -3
  21. package/skills/email-security-anti-phishing/skill.md +6 -6
  22. package/skills/exploit-scoring/skill.md +2 -2
  23. package/skills/framework-gap-analysis/skill.md +6 -6
  24. package/skills/fuzz-testing-strategy/skill.md +1 -1
  25. package/skills/global-grc/skill.md +2 -2
  26. package/skills/identity-assurance/skill.md +5 -5
  27. package/skills/idp-incident-response/skill.md +5 -5
  28. package/skills/incident-response-playbook/skill.md +8 -8
  29. package/skills/kernel-lpe-triage/skill.md +4 -4
  30. package/skills/mcp-agent-trust/skill.md +3 -3
  31. package/skills/mlops-security/skill.md +5 -5
  32. package/skills/ot-ics-security/skill.md +7 -7
  33. package/skills/policy-exception-gen/skill.md +2 -2
  34. package/skills/pqc-first/skill.md +2 -2
  35. package/skills/rag-pipeline-security/skill.md +2 -2
  36. package/skills/ransomware-response/skill.md +9 -9
  37. package/skills/researcher/skill.md +11 -11
  38. package/skills/sector-energy/skill.md +6 -6
  39. package/skills/sector-federal-government/skill.md +2 -2
  40. package/skills/sector-financial/skill.md +4 -4
  41. package/skills/sector-healthcare/skill.md +6 -6
  42. package/skills/sector-telecom/skill.md +1 -1
  43. package/skills/security-maturity-tiers/skill.md +4 -4
  44. package/skills/skill-update-loop/skill.md +6 -6
  45. package/skills/supply-chain-integrity/skill.md +1 -1
  46. package/skills/threat-model-currency/skill.md +3 -3
  47. package/skills/threat-modeling-methodology/skill.md +9 -9
  48. package/skills/webapp-security/skill.md +7 -7
  49. package/skills/zeroday-gap-learn/skill.md +8 -8
@@ -48,13 +48,17 @@ d3fend_refs:
48
48
  - D3-RPA
49
49
  - D3-SCP
50
50
  last_threat_review: "2026-05-11"
51
- discovery_mode: "standalone" # v0.13.2: operator-reached via `exceptd brief defensive-countermeasure-mapping` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
51
+ discovery_mode: "standalone" # operator-reached via `exceptd brief defensive-countermeasure-mapping` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
52
52
  ---
53
53
 
54
54
  # Defensive Countermeasure Mapping — D3FEND as the Blue-Team Counterpart to ATT&CK / ATLAS
55
55
 
56
56
  ATT&CK and ATLAS catalog what attackers do. D3FEND catalogs what defenders do, in the same technique-grain taxonomy. Most SOCs in mid-2026 maintain an ATT&CK heatmap of detection coverage; far fewer maintain a D3FEND coverage map of the controls that actually counter those techniques. Operators can articulate attacker behavior with technique-level precision but can only articulate their own defenses at framework-control granularity ("we have SI-2"), which is a category mismatch. This skill closes that mismatch. Inputs are offensive findings — a CVE, an ATT&CK or ATLAS technique, a framework control gap. Outputs are layered defensive-countermeasure maps grounded in `data/d3fend-catalog.json` and explicitly threaded through defense-in-depth, least-privilege, and zero-trust principles.
57
57
 
58
+ ## Frontmatter Scope
59
+
60
+ The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. This skill maps defensive countermeasures (MITRE D3FEND) rather than owning a native set of offensive techniques — its subject is the blue-team control taxonomy, not adversary TTPs. The offensive techniques it counters come from whatever finding the operator supplies at invocation time; that input domain is the union of every ATLAS/ATT&CK technique in the catalog, so pinning a fixed subset here would falsely narrow it. The authoritative technique attachment lives in the offensive skill that produced the finding.
61
+
58
62
  ---
59
63
 
60
64
  ## Threat Context (mid-2026)
@@ -100,13 +104,13 @@ No major compliance framework requires technique-grained defensive mapping. Each
100
104
  | Industry | PCI DSS v4.0 | Twelve requirements for cardholder data environments | Control-level. The closest technique-grain language is in 5.x (malware protection) — does not require D3FEND mapping. |
101
105
  | Industry | SOC 2 TSC | Trust Services Criteria outcome categories | Outcome-level. Auditor discretion on implementation. |
102
106
 
103
- The cross-framework pattern is uniform: every framework operates at control or outcome grain. D3FEND operates at technique grain. The translation layer — which technique counters which attack technique, in which D3FEND tactic, at which trust posture, at which privilege scope — is the gap this skill fills. The framework controls themselves are not wrong; they are coarser than the threat. Per AGENTS.md hard rule #2, the framework lag is structural: no framework yet operationalizes the defensive technique taxonomy.
107
+ The cross-framework pattern is uniform: every framework operates at control or outcome grain. D3FEND operates at technique grain. The translation layer — which technique counters which attack technique, in which D3FEND tactic, at which trust posture, at which privilege scope — is the gap this skill fills. The framework controls themselves are not wrong; they are coarser than the threat. The framework lag is structural and first-class: no framework yet operationalizes the defensive technique taxonomy.
104
108
 
105
109
  ---
106
110
 
107
111
  ## TTP Mapping
108
112
 
109
- This is a meta-mapping skill. Its TTP coverage equals the union of: every ATLAS technique in `data/atlas-ttps.json`, every ATT&CK technique appearing in any `attack_refs` field across the skill library, and every offensive technique referenced in any `counters_attack_techniques` array inside `data/d3fend-catalog.json`. Per AGENTS.md hard rule #4, every D3FEND ID in the catalog is mapped to at least one offensive technique — there are no orphan defensive entries.
113
+ This is a meta-mapping skill. Its TTP coverage equals the union of: every ATLAS technique in `data/atlas-ttps.json`, every ATT&CK technique appearing in any `attack_refs` field across the skill library, and every offensive technique referenced in any `counters_attack_techniques` array inside `data/d3fend-catalog.json`. Every D3FEND ID in the catalog is mapped to at least one offensive technique — there are no orphan defensive entries (no orphaned controls).
110
114
 
111
115
  The skill consumes offensive findings from these inputs and produces defensive mappings. It does not author new offensive technique entries; that is the job of the catalogs upstream and the `zeroday-gap-learn` and `threat-model-currency` skills. The cross-walk surfaces:
112
116
 
@@ -133,14 +137,14 @@ For each D3FEND ID surfaced by Analysis Procedure Step 3, the matrix records:
133
137
  |---|---|---|
134
138
  | Deployed in the org's stack? | operator input, verified against asset inventory | Is the control actually running, or only purchased / specified? |
135
139
  | Tunable per environment? | `data/d3fend-catalog.json` `implementation_examples` | Can the control be tuned for serverless vs. monolith vs. ephemeral container, or is it host-only? |
136
- | AI-pipeline applicable? | `data/d3fend-catalog.json` `ai_pipeline_applicability` (mandatory per AGENTS.md rule #9) | Per rule #9, if the control is architecturally impossible in serverless / container / AI pipeline contexts, the catalog declares an explicit alternative (e.g., admission-controller signature verification as the D3-EAL surrogate for serverless). The matrix surfaces that alternative. |
140
+ | AI-pipeline applicable? | `data/d3fend-catalog.json` `ai_pipeline_applicability` (mandatory field) | If the control is architecturally impossible in serverless / container / AI pipeline contexts, the catalog declares an explicit alternative (e.g., admission-controller signature verification as the D3-EAL surrogate for serverless). The matrix surfaces that alternative. |
137
141
  | Defense-in-depth layer | computed from `data/d3fend-catalog.json` `tactic` (Model / Harden / Detect / Isolate / Deceive / Evict / Restore) | Which DiD layer the control occupies for this finding. A finding defended only in one layer is under-defended. |
138
142
  | Privilege scope | computed from `data/d3fend-catalog.json` description and from the operator's deployment context | Per-process (D3-EAL, D3-EHB), per-segment (D3-NTA, D3-NI), per-request (D3-CBAN, D3-MFA when continuously verified), or blanket (D3-PSEP / D3-ASLR — kernel-wide). |
139
143
  | Zero-trust posture | computed from D3FEND description; verifies-per-request vs. trusts-after-perimeter | A control that verifies on every request (D3-MFA continuous reauth, D3-CBAN per-call) is zero-trust. A control that authenticates once and trusts thereafter (vanilla session cookies, perimeter-only D3-NI) is implicit-trust. |
140
144
  | Framework controls partially mapped | `data/d3fend-catalog.json` `framework_controls_partially_mapped` | The framework controls that nominally cover this technique but, per `lag_notes`, fail to operationalize it at D3FEND grain. |
141
145
  | Live-tunable vs. requires deploy | operator input, joined with `implementation_examples` | Can the control be tuned without a rolling deploy (e.g., updating a Kyverno policy) or does it require image rebuilds and reboots? |
142
146
 
143
- If the operator cannot supply deployment-status data, the matrix surfaces "unknown deployment status — must verify against asset inventory before claiming coverage" and the skill flags the finding as undefended for reporting purposes. Per AGENTS.md hard rule #10, no fabricated deployment data.
147
+ If the operator cannot supply deployment-status data, the matrix surfaces "unknown deployment status — must verify against asset inventory before claiming coverage" and the skill flags the finding as undefended for reporting purposes. No fabricated deployment data.
144
148
 
145
149
  ---
146
150
 
@@ -171,7 +175,7 @@ Every D3FEND mapping must carry a **trust-posture classification**:
171
175
  - **Verifies on session establishment, trusts thereafter.** Examples: vanilla TLS session resumption, perimeter D3-NI without internal traffic analysis.
172
176
  - **Assumes implicit trust on a segment.** Examples: bare D3-NI without D3-NTA inside the segment.
173
177
 
174
- Zero-trust-compliant defense maps to controls that verify per request. Implicit-trust controls are not invalid — they are layer-1 — but the output must label them so the operator can see the trust assumption a given control is making. Per AGENTS.md DR-1, never imply a framework control is adequate when current TTPs bypass it; the trust-posture column is the explicit corrective.
178
+ Zero-trust-compliant defense maps to controls that verify per request. Implicit-trust controls are not invalid — they are layer-1 — but the output must label them so the operator can see the trust assumption a given control is making. Never imply a framework control is adequate when current TTPs bypass it; the trust-posture column is the explicit corrective.
175
179
 
176
180
  ### Steps
177
181
 
@@ -183,7 +187,7 @@ Zero-trust-compliant defense maps to controls that verify per request. Implicit-
183
187
 
184
188
  **Step 4 — Score each candidate countermeasure.** For each D3FEND ID surfaced in Step 3, record:
185
189
  (a) Deployment status. Operator answers: deployed / partially deployed / not deployed / unknown.
186
- (b) AI-pipeline applicability per AGENTS.md rule #9. Read `ai_pipeline_applicability` directly from `data/d3fend-catalog.json`. If the catalog states the control is architecturally impossible in the operator's environment, capture the explicit alternative the catalog provides.
190
+ (b) AI-pipeline applicability. Read `ai_pipeline_applicability` directly from `data/d3fend-catalog.json`. If the catalog states the control is architecturally impossible in the operator's environment, capture the explicit alternative the catalog provides.
187
191
  (c) Defense-in-depth layer position — the D3FEND tactic the technique belongs to.
188
192
  (d) Least-privilege scope — per-process / per-segment / per-request / blanket, per the principle 2 classification.
189
193
  (e) Zero-trust posture — verifies-per-request / verifies-on-session / implicit-trust-on-segment, per the principle 3 classification.
@@ -274,9 +278,9 @@ The theater test for this skill is direct: the operator's defensive program is i
274
278
 
275
279
  A second, complementary test:
276
280
 
277
- > "Show your D3FEND coverage heatmap alongside your ATT&CK heatmap. If you have an ATT&CK heatmap (offensive coverage) but no D3FEND heatmap (defensive coverage at the same grain), your blue-team articulation is one-sided. The most common shape: ATT&CK heatmap exists, populated by EDR alerts; D3FEND heatmap does not exist; Harden, Isolate, Evict, and Restore tactics have no operator-known content. The org has bought defensive products and deployed framework controls, but cannot list which D3FEND technique each product implements. Per AGENTS.md DR-1, the framework controls are being treated as truth at a grain they do not address."
281
+ > "Show your D3FEND coverage heatmap alongside your ATT&CK heatmap. If you have an ATT&CK heatmap (offensive coverage) but no D3FEND heatmap (defensive coverage at the same grain), your blue-team articulation is one-sided. The most common shape: ATT&CK heatmap exists, populated by EDR alerts; D3FEND heatmap does not exist; Harden, Isolate, Evict, and Restore tactics have no operator-known content. The org has bought defensive products and deployed framework controls, but cannot list which D3FEND technique each product implements. The framework controls are being treated as truth at a grain they do not address."
278
282
 
279
- A third test, specific to AI-pipeline environments per AGENTS.md hard rule #9:
283
+ A third test, specific to AI-pipeline environments:
280
284
 
281
285
  > "Pick any AI / LLM / RAG / MCP workload in your environment. List the D3FEND controls you would deploy on an on-prem monolith for the equivalent attack surface. Now, for each, state whether the control is architecturally possible in your ephemeral/serverless/AI pipeline runtime, and if not, what the explicit alternative is per `data/d3fend-catalog.json`'s `ai_pipeline_applicability` field. If the answer is 'the framework control exists, so we are covered', the program is in theater — the framework control is architecturally impossible in the workload's runtime and the alternative was never scoped. The audit passes; the workload is undefended."
282
286
 
@@ -300,4 +304,4 @@ The cross-walks the skill maintains:
300
304
 
301
305
  - **DLP / exfil → D3FEND.** Sourced from `data/dlp-controls.json`, whose entries carry a `d3fend_refs` field linking each DLP technique to the D3FEND countermeasures that detect or isolate the corresponding exfil pattern. The DLP catalog is the dedicated link for the Detect and Isolate tactics in data-loss scenarios.
302
306
 
303
- When a new offensive technique is added to `data/atlas-ttps.json` or referenced in a new CVE in `data/cve-catalog.json`, the catalog steward must ensure at least one D3FEND entry covers it via `counters_attack_techniques`, or open a gap entry in `data/d3fend-catalog.json` per AGENTS.md hard rule #4 (no orphaned controls — by inversion, no orphaned attack techniques). This skill is the consumer that surfaces the inversion failure if the catalog drifts.
307
+ When a new offensive technique is added to `data/atlas-ttps.json` or referenced in a new CVE in `data/cve-catalog.json`, the catalog steward must ensure at least one D3FEND entry covers it via `counters_attack_techniques`, or open a gap entry in `data/d3fend-catalog.json` (no orphaned controls — by inversion, no orphaned attack techniques). This skill is the consumer that surfaces the inversion failure if the catalog drifts.
@@ -86,7 +86,7 @@ The dominant real-world exfil pattern: an engineer pastes proprietary code, cust
86
86
  | NIST AI RMF MAP-4.1 / MEASURE-2.10 (referenced from `DLP-CHAN-LLM-PROMPT`, `DLP-CHAN-LLM-CONTEXT`) | AI risk identification and measurement | Identifies AI system risks and measurement criteria. | Voluntary, not auditable. Does not operationalise DLP at the prompt or retrieval boundary. |
87
87
  | ISO 27001:2022 A.8.16 | Monitoring Activities | Monitoring of networks, systems, and applications. | Channel-agnostic in language; every implementation guide cites email/web/endpoint. No guidance for SDK-level prompt logging, MCP tool-call argument capture, or RAG retrieval audit. |
88
88
  | ISO 27001:2022 A.5.34 (referenced from `DLP-CHAN-LLM-CONTEXT`, `DLP-CHAN-IDE-TELEMETRY`) | Privacy and Protection of PII | PII handling. | Does not address retrieval-time classification of PII in RAG corpora. |
89
- | ISO/IEC 42001:2023 clause 6.1.2 | AI Risk Treatment Planning | Requires the org to plan treatments for AI risks. | Non-prescriptive on prompt-egress DLP. Auditors accept policy documents in lieu of control evidence — DR-1 risk. The real_requirement is recorded under `ISO-IEC-42001-2023-clause-6.1.2` in `data/framework-control-gaps.json`. |
89
+ | ISO/IEC 42001:2023 clause 6.1.2 | AI Risk Treatment Planning | Requires the org to plan treatments for AI risks. | Non-prescriptive on prompt-egress DLP. Auditors accept policy documents in lieu of control evidence — a compliance-theater risk. The real_requirement is recorded under `ISO-IEC-42001-2023-clause-6.1.2` in `data/framework-control-gaps.json`. |
90
90
  | EU AI Act (Reg. 2024/1689) Art 10 / Art 15 | Data governance and accuracy/robustness/cybersecurity for high-risk AI | Training data governance, robustness, and cybersecurity for high-risk AI systems. | Inference-time prompt data flows are not enumerated. Cross-border transfer of prompt content interacting with EU-resident personal data is governed by GDPR Art 44, not by AI Act technical controls. |
91
91
  | EU GDPR Art 44 | International transfers | Cross-border personal-data transfers require adequacy, SCCs, or BCRs. | Operationalised in DPIAs as "transfers to processors" — engineer-pastes-into-LLM is treated as an unsanctioned use, not as a measurable DLP event. Without prompt-egress evidence the org cannot answer a Subject Access Request asking "has my data been processed by AI." |
92
92
  | UK Data Protection Act 2018 / UK GDPR + ICO AI guidance (Oct 2023, updated 2025) | UK transfers and AI accountability | Equivalent to EU GDPR; ICO has issued AI-specific guidance. | Same blind spot as GDPR Art 44; ICO guidance is non-statutory. |
@@ -101,7 +101,7 @@ The dominant real-world exfil pattern: an engineer pastes proprietary code, cust
101
101
  | PCI-DSS 4.0 §3.4 | Cardholder-data rendering | PAN must be rendered unreadable. | Silent on PAN appearing in LLM prompts; payment org operational reality is that engineers paste prod queries containing PAN-shaped data into AI tools for debugging. |
102
102
  | US DTSA / EU Trade Secrets Directive 2016/943 | Trade secret protection | Misappropriation remedies. | "Reasonable measures to keep secret" is the eligibility test. Pasting trade secrets into a third-party LLM that retains them for abuse monitoring can disqualify trade-secret status in subsequent litigation. No technical control named — purely a downstream legal-eligibility risk. |
103
103
 
104
- **Bottom line:** no compliance framework operationalises LLM-prompt, MCP-tool-arg, RAG-retrieval, embedding-store, or code-completion-context DLP as a required, auditable, technically prescriptive control. Compliance evidence based purely on legacy SC-7, AC-2, A.8.16, or §164.312 for AI-era DLP is theater (DR-1).
104
+ **Bottom line:** no compliance framework operationalises LLM-prompt, MCP-tool-arg, RAG-retrieval, embedding-store, or code-completion-context DLP as a required, auditable, technically prescriptive control. Compliance evidence based purely on legacy SC-7, AC-2, A.8.16, or §164.312 for AI-era DLP is theater.
105
105
 
106
106
  ### Expanded jurisdictional coverage (per `data/global-frameworks.json`)
107
107
 
@@ -210,7 +210,7 @@ A gap exists where:
210
210
  - A control depends on SDK-level prompt logging that is not enabled (cascading dependency failure).
211
211
  - A control depends on retrieval-time classification on a RAG corpus where labels have not propagated (cascading dependency failure).
212
212
 
213
- Score each gap using the RWEP model in `lib/scoring.js`. Inputs: KEV / known-exploitation evidence (use the Exploit Availability Matrix above), AI-acceleration flag (yes for every modern channel), blast radius (per-identity vs. enterprise-wide), patch availability (architectural — not patchable, only mitigable). Output RWEP per gap. Never report a gap with CVSS alone (DR-2).
213
+ Score each gap using the RWEP model in `lib/scoring.js`. Inputs: KEV / known-exploitation evidence (use the Exploit Availability Matrix above), AI-acceleration flag (yes for every modern channel), blast radius (per-identity vs. enterprise-wide), patch availability (architectural — not patchable, only mitigable). Output RWEP per gap. Never report a gap with CVSS alone — RWEP is the prioritization signal, with CVSS reported alongside but never as the sole input.
214
214
 
215
215
  **Step 6 — Propose layered controls per the defense-in-depth ladder.**
216
216
 
@@ -54,7 +54,7 @@ d3fend_refs:
54
54
  - D3-IOPR
55
55
  - D3-MFA
56
56
  last_threat_review: "2026-05-18"
57
- discovery_mode: "standalone" # v0.13.2: operator-reached via `exceptd brief email-security-anti-phishing` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
57
+ discovery_mode: "standalone" # operator-reached via `exceptd brief email-security-anti-phishing` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
58
58
  ---
59
59
 
60
60
  # Email Security and Anti-Phishing Assessment
@@ -95,7 +95,7 @@ Phishing remained the #1 initial-access vector through 2025 (Verizon DBIR 2025)
95
95
  | IN CERT-In | Phishing guidance and 6-hour incident reporting rule | Reporting requirement is firm; control specifications lag. |
96
96
  | NYDFS | 23 NYCRR 500.14 (training and monitoring) | Annual phishing-aware training required; does not specify FIDO2, DMARC `p=reject`, or deepfake-aware procedures. |
97
97
 
98
- Per AGENTS.md Rule #5, this analysis spans EU + UK + AU + JP + IL + SG + IN + NYDFS alongside NIST and ISO. Each framework-gap ID in `framework_gaps` (`NIST-800-53-SI-3`, `ISO-27001-2022-A.8.16`, `SOC2-CC7-anomaly-detection`, `NIS2-Art21-incident-handling`, `UK-CAF-C1`, `AU-Essential-8-App-Hardening`) resolves against `data/framework-control-gaps.json` — operators producing a per-control evidence pack should pull the canonical lag rationale from that catalog rather than transcribing the table above.
98
+ This analysis spans EU + UK + AU + JP + IL + SG + IN + NYDFS alongside NIST and ISO, because a US-only email-security posture is incomplete for any multi-jurisdiction sender. Each framework-gap ID in `framework_gaps` (`NIST-800-53-SI-3`, `ISO-27001-2022-A.8.16`, `SOC2-CC7-anomaly-detection`, `NIS2-Art21-incident-handling`, `UK-CAF-C1`, `AU-Essential-8-App-Hardening`) resolves against `data/framework-control-gaps.json` — operators producing a per-control evidence pack should pull the canonical lag rationale from that catalog rather than transcribing the table above.
99
99
 
100
100
  ---
101
101
 
@@ -122,7 +122,7 @@ Note: `atlas_refs` is intentionally empty — these are ATT&CK Enterprise TTPs a
122
122
  | Voice cloning | Commodity | ElevenLabs and similar have anti-abuse, but underground forks and self-hosted open-weights models remove the guardrails. ~3 seconds of audio suffices. |
123
123
  | Real-time deepfake video | Live | DeepFaceLab plus real-time variants; single-GPU; demonstrated at scale by the Arup 2024 incident. |
124
124
  | LLM-generated hyperpersonalized email | Live | All major LLM providers run abuse-detection on the email-generation surface; jailbreak-augmented intermediaries route around it. |
125
- | AI-discovered novel evasion | Active | Per DR-5: AI acceleration of attacker tooling is current operational reality, not future-watch. |
125
+ | AI-discovered novel evasion | Active | AI acceleration of attacker tooling is current operational reality, not future-watch. |
126
126
  | Phishing-resistant defense | Available now | FIDO2 / WebAuthn synced passkeys = the only authenticator class that survives 2026 phishing kits. CISA Phishing-Resistant MFA guidance + NIST 800-63B rev 4 codify this. |
127
127
  | DMARC `p=reject` adoption | Universal at large senders, ~60% enforced | Adoption metric is misleading; enforcement metric is the real KPI. |
128
128
  | ARC for forwarders | Maturing across major providers | Closes the mailing-list-breaks-DMARC objection that kept many domains at `p=none`. |
@@ -134,7 +134,7 @@ No CVE entries are claimed for this skill — email-channel social engineering i
134
134
 
135
135
  ## Analysis Procedure
136
136
 
137
- The procedure threads three foundational principles per AGENTS.md:
137
+ The procedure threads three foundational principles:
138
138
 
139
139
  **Defense in depth** — inbound: DMARC enforcement (`p=reject`) + ARC for forwarders + secure email gateway (Proofpoint, Mimecast, Microsoft Defender for Office 365, Google Workspace Gmail Advanced Protection) + URL rewriting + sandbox detonation + DLP egress. Outbound: DKIM signing on all sending sources + BIMI registration + SPF maintenance with SPF-record-flattening discipline (10-DNS-lookup ceiling). User layer: phishing-resistant MFA (passkeys), simulated phishing program including AI-augmented lures, deepfake-aware policies for video and voice. Vendor layer: fourth-party email risk — supplier DMARC posture monitored as a vendor-risk attribute. Incident layer: BEC IR playbook with explicit hand-off to `incident-response-playbook`.
140
140
 
@@ -142,7 +142,7 @@ The procedure threads three foundational principles per AGENTS.md:
142
142
 
143
143
  **Zero trust** — every email is hostile until verified (DMARC pass + sender reputation + intent classification at gateway). Every video call requesting a financial action requires a live verification challenge (callback to a known number; pre-arranged challenge phrase; in-person or known-good-channel confirmation for high-value transactions). Every voice call from a "known" executive requesting an out-of-policy action gets multi-channel verification before action.
144
144
 
145
- **Cloud-email canonical, on-prem exception** (Rule #9): default scoping assumes Microsoft 365 Exchange Online or Google Workspace Gmail. On-prem Exchange (legacy, regulated enclave, air-gapped) gets an explicit exception path noting which controls (cloud-native sandbox detonation, Microsoft Defender XDR signals, Google Workspace Security Sandbox) have on-prem equivalents and which require compensating controls.
145
+ **Cloud-email canonical, on-prem exception:** default scoping assumes Microsoft 365 Exchange Online or Google Workspace Gmail. On-prem Exchange (legacy, regulated enclave, air-gapped) gets an explicit exception path noting which controls (cloud-native sandbox detonation, Microsoft Defender XDR signals, Google Workspace Security Sandbox) have on-prem equivalents and which require compensating controls.
146
146
 
147
147
  Email-authentication RFCs cited throughout the procedure (`RFC-7489` DMARC, `RFC-6376` DKIM, `RFC-7208` SPF, `RFC-8616` BIMI/AuthIndicators DNS encoding, `RFC-8461` MTA-STS, `RFC-8617` ARC, `RFC-8460` TLSRPT) resolve against `data/rfc-references.json`. The DLP exfil-channel mappings invoked by the gateway-and-egress sub-procedures (`DLP-CHAN-EMAIL-OUT` for outbound message exfil, `DLP-CHAN-LLM-PROMPT` for LLM-prompt-as-egress when users paste mailbox content into AI assistants, `DLP-ENFORCE-BLOCK` for hard-block enforcement on confirmed PHI/PCI patterns) resolve against `data/dlp-controls.json` — these are the canonical IDs to cite when handing off to `dlp-gap-analysis`.
148
148
 
@@ -191,7 +191,7 @@ Four concrete tests distinguish paper compliance from real anti-phishing posture
191
191
 
192
192
  ## Defensive Countermeasure Mapping
193
193
 
194
- Per AGENTS.md, this skill ships on 2026-05-11 and includes the optional 8th section, mapping offensive findings to MITRE D3FEND defensive techniques.
194
+ This section maps offensive findings to MITRE D3FEND defensive techniques.
195
195
 
196
196
  | D3FEND ID | Defense | Defense-in-Depth Layer | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
197
197
  |---|---|---|---|---|---|
@@ -42,7 +42,7 @@ The `atlas_refs` and `attack_refs` arrays are intentionally empty. This skill is
42
42
 
43
43
  RWEP exists because the exploit development cycle has compressed. The factors that CVSS does not model are now the dominant signal in real-world prioritization.
44
44
 
45
- - **AI-accelerated exploit development is current operational reality, not emerging.** 41% of 2025 zero-days were discovered or weaponized with AI-assisted tooling (AGENTS.md DR-5 / GTIG 2025). Copy Fail (CVE-2026-31431) was discovered by an AI system in approximately one hour; Fragnesia (CVE-2026-46300, 2026-05-13) is the 2026 anchor case for autonomous agentic-AI discovery — Zellic's agentic auditor surfaced an 18-year-old Linux kernel primitive. The first documented AI-built in-the-wild zero-day landed 2026-05-11 (GTIG AI 2FA-bypass). CVSS scoring assumes a human-speed gap between disclosure and reliable exploitation — that gap is gone for AI-capable threat actors. RWEP's `ai_factor` weight is calibrated to this reality; align downstream scoring narratives to CTID Secure AI v2 (2026-05-06, replaces v1).
45
+ - **AI-accelerated exploit development is current operational reality, not emerging.** 41% of 2025 zero-days were discovered or weaponized with AI-assisted tooling (GTIG 2025). Copy Fail (CVE-2026-31431) was discovered by an AI system in approximately one hour; Fragnesia (CVE-2026-46300, 2026-05-13) is the 2026 anchor case for autonomous agentic-AI discovery — Zellic's agentic auditor surfaced an 18-year-old Linux kernel primitive. The first documented AI-built in-the-wild zero-day landed 2026-05-11 (GTIG AI 2FA-bypass). CVSS scoring assumes a human-speed gap between disclosure and reliable exploitation — that gap is gone for AI-capable threat actors. RWEP's `ai_factor` weight is calibrated to this reality; align downstream scoring narratives to CTID Secure AI v2 (2026-05-06, replaces v1).
46
46
  - **CVSS undercounts AI-discovered + KEV-listed bugs.** CVE-2026-31431 scores CVSS 7.8 (High). Treated as a CVSS-band-7 item, it lands in a 30-day remediation queue. Treated honestly — CISA KEV listed, 732-byte deterministic public PoC, all Linux ≥ 4.14, AI-discovered — it is a 4-hour incident. CVSS misses every one of those amplifiers.
47
47
  - **CVSS local-vector blindness vs. RWEP exploitation reality.** CVE-2026-30615 (Windsurf MCP) scores CVSS 8.0 with AV:L (the NVD-authoritative corrected score; the initial CVSS 9.8 was withdrawn after attack-vector analysis confirmed the local-vector reality — the attacker must control HTML content that the Windsurf MCP client processes). RWEP rates it 35, lower than Copy Fail at 90: the supply-chain prerequisite (a victim first installs a malicious MCP server) plus the local attack vector throttle real exploitation rate. This pair is the canonical example of CVSS-vector-only scoring losing to RWEP's exploitation-evidence weighting.
48
48
  - **Compliance frameworks anchor SLAs on CVSS bands.** NIST 800-53 SI-2, PCI DSS 6.3.3, ISO 27001:2022 A.8.8, and most internal vuln-management policies translate CVSS High/Critical into 30-day/7-day windows. For AI-discovered KEV-listed LPEs with public PoCs, these windows are exploitation windows. RWEP is the layer that lets an org prioritize honestly without re-writing every framework control.
@@ -387,4 +387,4 @@ RWEP scores priority; this section maps the priority bands to the D3FEND defensi
387
387
 
388
388
  **Zero-trust posture:** an RWEP score is not a remediation; it is a triage signal. The remediation closes only when the cited D3FEND technique is verified in production for the affected asset class. RWEP 90 with no deployed `D3-KBPI` instrumentation is an unmitigated finding regardless of patch SLA. Auditors converting RWEP findings into corrective actions must verify both the patch deployment and the compensating-technique deployment.
389
389
 
390
- **AI-pipeline applicability (per AGENTS.md Hard Rule #9):** for AI-pipeline CVEs (model-serving runtime, MCP server, inference gateway), `D3-KBPI` and `D3-EAL` do not apply to serverless inference endpoints. The scoped alternative is `D3-CSPP` at the gateway plus signed-image attestation at the provider. RWEP bands are unchanged; the technique selection shifts to the gateway tier. `D3-FAPA` over training-data corpora is the additional technique for any AML.T0020 (Poison Training Data) finding above RWEP 50.
390
+ **AI-pipeline applicability:** for AI-pipeline CVEs (model-serving runtime, MCP server, inference gateway), `D3-KBPI` and `D3-EAL` do not apply to serverless inference endpoints. The scoped alternative is `D3-CSPP` at the gateway plus signed-image attestation at the provider. RWEP bands are unchanged; the technique selection shifts to the gateway tier. `D3-FAPA` over training-data corpora is the additional technique for any AML.T0020 (Poison Training Data) finding above RWEP 50.
@@ -47,7 +47,7 @@ This skill's entire purpose is to declare framework lag per analysis. The pre-an
47
47
 
48
48
  ### Expanded jurisdictional cross-walk requirement (per `data/global-frameworks.json`)
49
49
 
50
- AGENTS.md hard rule #5 (global-first) now binds against the full expanded catalog, not the EU+UK+AU+ISO baseline. Every gap declaration produced by this skill must cross-walk the cited control against the equivalent obligations in the expanded jurisdiction set tracked in `data/global-frameworks.json`. The cross-walk set as of mid-2026:
50
+ The global-first requirement binds against the full expanded catalog, not the EU+UK+AU+ISO baseline. Every gap declaration produced by this skill must cross-walk the cited control against the equivalent obligations in the expanded jurisdiction set tracked in `data/global-frameworks.json`. The cross-walk set as of mid-2026:
51
51
 
52
52
  - **EU:** GDPR, NIS2 (Directive 2022/2555), DORA (Regulation 2022/2554), EU AI Act (Regulation 2024/1689), EU CRA (Regulation 2024/2847).
53
53
  - **UK:** UK GDPR / DPA 2018, NCSC CAF, Cyber Essentials / CE+.
@@ -69,7 +69,7 @@ AGENTS.md hard rule #5 (global-first) now binds against the full expanded catalo
69
69
  - **Global standards:** ISO 27001:2022 / 27002:2022, ISO/IEC 42001:2023, CSA CCM v4, CIS Controls v8, MITRE ATLAS v5.6.0.
70
70
  - **US sub-national:** NYDFS 23 NYCRR 500 (amended Nov 2023, phased through Nov 2025); state privacy laws (CA CCPA/CPRA, CO CPA, CT CTDPA, IL BIPA, NY SHIELD, TX DPSA, VA CDPA).
71
71
 
72
- A gap declaration that closes section 6 (Global coverage check) without referencing at least the EU, UK, AU, ISO, and a representative selection from {IL, CH, HK, TW, ID, VN, JP-expanded, KR, CN, BR, NYDFS} for any org operating in those jurisdictions fails hard rule #5. The exact set required depends on the org's footprint — but the analyst must consult `data/global-frameworks.json` to enumerate it rather than defaulting to the legacy four-jurisdiction shorthand.
72
+ A gap declaration that closes section 6 (Global coverage check) without referencing at least the EU, UK, AU, ISO, and a representative selection from {IL, CH, HK, TW, ID, VN, JP-expanded, KR, CN, BR, NYDFS} for any org operating in those jurisdictions is incomplete: a global-first analysis must cover every applicable jurisdiction, not a US-centric subset. The exact set required depends on the org's footprint — but the analyst must consult `data/global-frameworks.json` to enumerate it rather than defaulting to the legacy four-jurisdiction shorthand.
73
73
 
74
74
  ## TTP Mapping (MITRE ATLAS v5.6.0 and ATT&CK)
75
75
 
@@ -88,7 +88,7 @@ This skill maps framework controls to attacker TTPs on demand rather than static
88
88
  | NIS2 Art. 21 vs. AI pipeline integrity | AML.T0020 (Poison Training Data), AML.T0010 | No AI-specific control surface |
89
89
  | All frameworks vs. ephemeral inventory | T1610, T1525 | Asset-inventory assumption invalid on serverless/container |
90
90
 
91
- For any gap analysis this skill produces, every cited control must be paired with at least one ATLAS or ATT&CK ID drawn from `data/atlas-ttps.json`. Controls without a mapped TTP fail Hard Rule #4 (no orphaned controls).
91
+ For any gap analysis this skill produces, every cited control must be paired with at least one ATLAS or ATT&CK ID drawn from `data/atlas-ttps.json`. Controls without a mapped TTP are orphaned controls and are rejected — every control recommendation must map to a real ATLAS or ATT&CK TTP.
92
92
 
93
93
  ## Exploit Availability Matrix
94
94
 
@@ -316,7 +316,7 @@ These universal gaps should be surfaced in every framework gap analysis and expl
316
316
 
317
317
  ## Output Format
318
318
 
319
- Every framework gap analysis this skill produces uses the following literal template. Sections are mandatory; empty sections fail Hard Rule #11 (no-MVP ban).
319
+ Every framework gap analysis this skill produces uses the following literal template. Sections are mandatory; empty sections are not acceptable every section must be populated.
320
320
 
321
321
  ```
322
322
  ## Framework Lag Declaration
@@ -350,7 +350,7 @@ finding and should be surfaced to the compliance-theater skill.]
350
350
 
351
351
  ### 6. Global coverage check
352
352
  [EU (NIS2/DORA/EU AI Act), UK (CAF), AU (ISM/Essential 8), ISO 27001:2022, and
353
- NIST equivalents for the same lag. Per Hard Rule #5: US-only output is incomplete.]
353
+ NIST equivalents for the same lag. US-only output is incomplete.]
354
354
  ```
355
355
 
356
356
  The output is consumed by: compliance-theater (theater scoring), policy-exception-gen (compensating-control justification), and global-grc (cross-jurisdictional rollup).
@@ -406,4 +406,4 @@ Every Framework Lag Declaration this skill produces names the missing control. T
406
406
 
407
407
  **Zero-trust posture:** no control is claimed as compensating without verification that the defensive technique is deployed, monitored, and tested against the cited offensive TTP. "We have SC-8 IPsec" is not a compensating control for Dirty Frag — `D3-NI` over a non-IPsec data path is. The Framework Lag Declaration's "What a real control requires" field must name the D3FEND technique by ID.
408
408
 
409
- **AI-pipeline applicability (per AGENTS.md Hard Rule #9):** `D3-EAL` does not apply to serverless inference endpoints; the scoped alternative is `D3-CSPP` at the gateway plus signed-image attestation at the provider. `D3-FAPA` on ephemeral RAG indices degrades to per-query retrieval logging via `D3-IOPR` plus index-build provenance signed at construction. These degradations must be named explicitly in the declaration when the gap concerns an AI pipeline.
409
+ **AI-pipeline applicability:** `D3-EAL` does not apply to serverless inference endpoints; the scoped alternative is `D3-CSPP` at the gateway plus signed-image attestation at the provider. `D3-FAPA` on ephemeral RAG indices degrades to per-query retrieval logging via `D3-IOPR` plus index-build provenance signed at construction. These degradations must be named explicitly in the declaration when the gap concerns an AI pipeline.
@@ -45,7 +45,7 @@ d3fend_refs:
45
45
  - D3-IOPR
46
46
  - D3-PSEP
47
47
  last_threat_review: "2026-05-11"
48
- discovery_mode: "standalone" # v0.13.2: operator-reached via `exceptd brief fuzz-testing-strategy` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
48
+ discovery_mode: "standalone" # operator-reached via `exceptd brief fuzz-testing-strategy` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
49
49
  ---
50
50
 
51
51
  # Fuzz Testing Strategy
@@ -442,7 +442,7 @@ Universal lag: every jurisdiction except Australia (ISM-1623) lacks an operation
442
442
  - **Brazil (LGPD Art. 33-35):** Cross-border transfer requires adequacy decision, SCCs, BCRs, or specific consent; ANPD has signalled AI-tool enforcement interest under LGPD Art. 33.
443
443
  - **US sub-national — NYDFS 23 NYCRR 500 (amended Nov 2023, phased through Nov 2025):** 72-hour cyber-event notification to DFS, CISO accountability, MFA mandate, annual independent audit for Class A companies, Third-Party Service Provider Security Policy at 500.11. NYDFS is the strictest US sub-national financial-sector regime and operationally exceeds most state-level analogues.
444
444
 
445
- Per AGENTS.md rule #5, the global-grc analysis must cross-walk against the full catalog above, not just EU/UK/AU/ISO. A jurisdictional rollup that omits CN, VN, IL, CH, HK, TW, ID, JP-expanded, KR, BR, or NYDFS for an in-scope org is structurally incomplete.
445
+ The global-grc analysis must cross-walk against the full catalog above, not just EU/UK/AU/ISO — a global-first rollup covers every applicable jurisdiction, not a US-centric subset. A jurisdictional rollup that omits CN, VN, IL, CH, HK, TW, ID, JP-expanded, KR, BR, or NYDFS for an in-scope org is structurally incomplete.
446
446
 
447
447
  ---
448
448
 
@@ -542,7 +542,7 @@ Produce a matrix of: threat class × jurisdiction framework × requirement adequ
542
542
 
543
543
  ## Output Format
544
544
 
545
- The skill produces a structured Global GRC Assessment that rolls compliance findings across the org's jurisdictional footprint — EU (NIS2, DORA, EU AI Act, CRA), UK (CAF, Cyber Essentials), AU (ISM, Essential 8, APRA CPS 234), ISO 27001:2022 / 42001:2023, NIST, and the expanded set tracked in `data/global-frameworks.json`. The shape below is consumed downstream by `framework-gap-analysis` (which produces per-jurisdiction Framework Lag Declarations), by `policy-exception-gen` (for cross-jurisdictional exception language), and by CSAF-style auditor evidence bundles. Preserve the per-jurisdiction control-mapping rows verbatim — they are the load-bearing cross-walk per Hard Rule #5.
545
+ The skill produces a structured Global GRC Assessment that rolls compliance findings across the org's jurisdictional footprint — EU (NIS2, DORA, EU AI Act, CRA), UK (CAF, Cyber Essentials), AU (ISM, Essential 8, APRA CPS 234), ISO 27001:2022 / 42001:2023, NIST, and the expanded set tracked in `data/global-frameworks.json`. The shape below is consumed downstream by `framework-gap-analysis` (which produces per-jurisdiction Framework Lag Declarations), by `policy-exception-gen` (for cross-jurisdictional exception language), and by CSAF-style auditor evidence bundles. Preserve the per-jurisdiction control-mapping rows verbatim — they are the load-bearing global-first cross-walk.
546
546
 
547
547
  ```
548
548
  ## Global GRC Assessment
@@ -67,7 +67,7 @@ Identity is the new perimeter, and the perimeter expanded. The 2026 principal po
67
67
 
68
68
  **Agent-as-principal is operational reality.** When an AI coding assistant calls an MCP tool, it does so under the IDE user's OAuth session by default. The agent inherits the user's scopes wholesale — not because anyone designed it that way, but because no current identity standard defines an agent-as-principal model. CVE-2026-30615 (Windsurf MCP local-vector RCE, CVSS 8.0 / AV:L) hinged in part on this implicit inheritance: tool calls executed under the IDE user's privileges with no separate authentication challenge for the agent's actions. The principal who authenticated (the human) is not the principal who took the action (the agent), and the audit trail does not distinguish them.
69
69
 
70
- **Phishing-resistant authentication is now table-stakes.** FIDO2 / WebAuthn synced passkeys are the only widely deployed authenticator class that survives credential phishing, AiTM proxy phishing (evilginx-class), and push-notification fatigue attacks. Orgs still standing on TOTP / SMS / push-MFA in 2026 are shipping password-equivalent risk forward, and the framework gap analysis must say so. AI-assisted phishing kit development means the time-to-weaponize a new bypass technique is hours, not weeks (per DR-5: AI acceleration is current operational reality, not a future consideration).
70
+ **Phishing-resistant authentication is now table-stakes.** FIDO2 / WebAuthn synced passkeys are the only widely deployed authenticator class that survives credential phishing, AiTM proxy phishing (evilginx-class), and push-notification fatigue attacks. Orgs still standing on TOTP / SMS / push-MFA in 2026 are shipping password-equivalent risk forward, and the framework gap analysis must say so. AI-assisted phishing kit development means the time-to-weaponize a new bypass technique is hours, not weeks AI acceleration is current operational reality, not a future consideration.
71
71
 
72
72
  **Workload identity is short-lived or it is broken.** Static service-account keys and long-lived OAuth refresh tokens are credential-theft jackpots. RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025) replaces the original RFC 6749 threat model and assumes short-lived access tokens, sender-constrained tokens (DPoP / mTLS), and rotated refresh tokens. Skills that cite RFC 6749 without RFC 9700 are citing the wrong threat model.
73
73
 
@@ -135,7 +135,7 @@ Sourced from `data/cve-catalog.json` and `data/exploit-availability.json` as of
135
135
 
136
136
  ## Analysis Procedure
137
137
 
138
- This procedure threads the three foundational principles explicitly (per AGENTS.md skill-format requirement).
138
+ This procedure threads the three foundational principles explicitly.
139
139
 
140
140
  ### Defense in Depth (multi-layer identity controls)
141
141
 
@@ -247,13 +247,13 @@ Four specific tests distinguish paper compliance from real posture:
247
247
 
248
248
  3. **MCP / agent access token TTL.** "Show me the access-token TTL configured for your MCP server fleet and AI-agent integrations. Show me the refresh-token rotation policy." If access-token TTLs are measured in weeks, or are unconfigured / default-1-year-from-the-SDK, or refresh tokens are never rotated, this is theater against RFC 9700 BCP. The credential-theft blast radius is multiplied by the TTL.
249
249
 
250
- 4. **Cross-jurisdiction evidence.** "Show me your jurisdiction-specific identity-control evidence for every jurisdiction you operate in: EU NIS2 Art 21 transposition, DORA RTS, UK CAF B2, AU ISM 0974+, ISO 27001 A.5.16; plus IL INCD Doctrine 2.0 / Cyber Defense Methodology 2024, CH FINMA Circ. 2023/1, JP FISC v9, SG MAS TRM §11/§14.2, IN CERT-In Directions, NY DFS 23 NYCRR 500.12." US-only evidence (or worse, NIST-only evidence) for a multi-jurisdictional org is theater per AGENTS.md rule #5 and DR-4.
250
+ 4. **Cross-jurisdiction evidence.** "Show me your jurisdiction-specific identity-control evidence for every jurisdiction you operate in: EU NIS2 Art 21 transposition, DORA RTS, UK CAF B2, AU ISM 0974+, ISO 27001 A.5.16; plus IL INCD Doctrine 2.0 / Cyber Defense Methodology 2024, CH FINMA Circ. 2023/1, JP FISC v9, SG MAS TRM §11/§14.2, IN CERT-In Directions, NY DFS 23 NYCRR 500.12." US-only evidence (or worse, NIST-only evidence) for a multi-jurisdictional org is theater global-first coverage is required, and identity evidence must be jurisdiction-specific rather than US-centric.
251
251
 
252
252
  ---
253
253
 
254
254
  ## Defensive Countermeasure Mapping
255
255
 
256
- Maps the identity-assurance gaps above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability (per AGENTS.md Hard Rule #9).
256
+ Maps the identity-assurance gaps above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
257
257
 
258
258
  | D3FEND Technique | Mapping | Defense-in-Depth Layer | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
259
259
  |---|---|---|---|---|---|
@@ -274,4 +274,4 @@ After producing the identity assurance assessment output, chain into the followi
274
274
  - **`supply-chain-integrity`** — signed identity artefacts. Federation assertion signing keys, OIDC discovery documents, JWKS endpoints, agent SDK binaries, and MCP server packages are all supply-chain artefacts. Run supply-chain-integrity to produce SLSA-level attestation, Sigstore signature verification, and in-toto provenance for the identity artefacts in this skill's federation-surface inventory.
275
275
  - **`compliance-theater`** — paper-MFA theater. If the phishing-resistant coverage matrix in this skill's output shows < 100% phishing-resistant coverage for privileged users while the org's compliance attestations claim MFA-for-all, run compliance-theater for the full structured theater-vs-real-posture report tied to the specific audit reports (SOC 2, ISO, NIS2 conformity) being misrepresented.
276
276
 
277
- For ephemeral / serverless / AI-pipeline contexts (per AGENTS.md rule #9): interactive AAL3 authentication is architecturally impossible inside a serverless function or short-lived container. The scoped alternative is workload-identity-federation (SPIFFE/SPIRE, AWS IAM Roles Anywhere, GCP WIF, Azure Workload Identity) with sender-constrained short-lived tokens (DPoP per RFC 9449 or mTLS per RFC 8705), build-time agent-binary allowlisting baked into the function image, and per-invocation cryptographic device attestation where the platform supports it.
277
+ For ephemeral / serverless / AI-pipeline contexts: interactive AAL3 authentication is architecturally impossible inside a serverless function or short-lived container. The scoped alternative is workload-identity-federation (SPIFFE/SPIRE, AWS IAM Roles Anywhere, GCP WIF, Azure Workload Identity) with sender-constrained short-lived tokens (DPoP per RFC 9449 or mTLS per RFC 8705), build-time agent-binary allowlisting baked into the function image, and per-invocation cryptographic device attestation where the platform supports it.
@@ -118,7 +118,7 @@ Agentic AI is the emerging structural problem on top. AI agents operating on beh
118
118
  | US Treasury OFAC + EU + UK sanctions | Cyber-Related Sanctions program (EO 13694 + 13757 + EU Reg.269/2014 + UK OFSI) | Prohibits transactions with designated cyber-actors | Captured in `data/framework-control-gaps.json#OFAC-Sanctions-Threat-Actor-Negotiation`. IdP-incident-response that escalates to ransomware faces ransom-payment-vs-sanctions screening under time pressure; attribution-to-designated-entity is rarely deterministic during an active incident. |
119
119
  | HIPAA | 164.308(a)(4) (Information Access Management) + 164.312(d) (Person or Entity Authentication) | Access-authorisation policies + entity authentication | Treats the authenticated session as the access boundary; OAuth-consent-mediated scope grant to a third-party app processing PHI is invisible. |
120
120
 
121
- **Cross-jurisdiction posture (per AGENTS.md rule #5).** Any IdP-incident-response analysis for a multi-jurisdiction tenant must cite at minimum: EU NIS2 + DORA + GDPR (Art.33 and Art.34) + national overlays, UK GDPR + NCSC CAF, AU Privacy Act NDB + APRA CPS 234 (where applicable) + Essential 8 + ISM, US NYDFS 500 + state breach-notification laws + sector-specific (HIPAA for healthcare, GLBA + NYDFS for financial), Canada PIPEDA + OSFI B-13 (where applicable), Singapore PDPA + MAS Notice 655, Hong Kong PDPO + HKMA guidance, ISO/IEC 27001:2022, SOC 2, and the OFAC + EU + UK sanctions overlay for any ransomware-bridging incident. US-only (NIST + NYDFS + state laws) is incomplete.
121
+ **Cross-jurisdiction posture.** Any IdP-incident-response analysis for a multi-jurisdiction tenant must cite at minimum: EU NIS2 + DORA + GDPR (Art.33 and Art.34) + national overlays, UK GDPR + NCSC CAF, AU Privacy Act NDB + APRA CPS 234 (where applicable) + Essential 8 + ISM, US NYDFS 500 + state breach-notification laws + sector-specific (HIPAA for healthcare, GLBA + NYDFS for financial), Canada PIPEDA + OSFI B-13 (where applicable), Singapore PDPA + MAS Notice 655, Hong Kong PDPO + HKMA guidance, ISO/IEC 27001:2022, SOC 2, and the OFAC + EU + UK sanctions overlay for any ransomware-bridging incident. US-only (NIST + NYDFS + state laws) is incomplete.
122
122
 
123
123
  ---
124
124
 
@@ -153,13 +153,13 @@ Agentic AI is the emerging structural problem on top. AI agents operating on beh
153
153
  | CVE-2023-3519 Citrix NetScaler RCE | 9.8 | 92 | Yes | Yes | No | Confirmed exploitation 2023-2024 (financial-sector and federal targets) | Yes | Limited — appliance reboot | Network telemetry + IdP-tenant access-pattern alerting |
154
154
  | CVE-2026-30615 Windsurf MCP — adjacent identity surface | 8.6 | 88 | Forward-watched | Yes | Yes | Suspected | Mitigation + vendor patch | n/a | MCP-tool-trust telemetry |
155
155
 
156
- **Honest gap statement (per AGENTS.md rule #10).** IdP-specific CVEs (Okta Auth0 Workforce CVEs, Entra ID Graph CVEs, Auth0 platform CVEs, Ping platform CVEs, OneLogin platform CVEs) are not exhaustively inventoried in `data/cve-catalog.json`. Authoritative sources: vendor advisories (Okta Security, Microsoft MSRC + Security Update Guide, Auth0 Security Advisories, Ping Identity Security Notices, One Identity Customer Advisory), CISA KEV for cross-sector exposure, CISA AA24 series for federal-targeting advisories, and sector intel feeds. Forward-watched.
156
+ **Honest gap statement.** IdP-specific CVEs (Okta Auth0 Workforce CVEs, Entra ID Graph CVEs, Auth0 platform CVEs, Ping platform CVEs, OneLogin platform CVEs) are not exhaustively inventoried in `data/cve-catalog.json`. Authoritative sources: vendor advisories (Okta Security, Microsoft MSRC + Security Update Guide, Auth0 Security Advisories, Ping Identity Security Notices, One Identity Customer Advisory), CISA KEV for cross-sector exposure, CISA AA24 series for federal-targeting advisories, and sector intel feeds. Forward-watched.
157
157
 
158
158
  ---
159
159
 
160
160
  ## Analysis Procedure
161
161
 
162
- This procedure threads the three foundational design principles required by AGENTS.md skill-format spec (defense in depth, least privilege, zero trust) through the seven-phase loop.
162
+ This procedure threads the three foundational design principles (defense in depth, least privilege, zero trust) through the seven-phase loop.
163
163
 
164
164
  **Defense in depth.** Multi-layer authentication for tenant-admin operations: phishing-resistant FIDO2 device-bound passkey at the human layer (skill `identity-assurance`); paired-admin (4-eyes) on federated-trust modification, signing-key rotation, and tenant-wide application permission grants; conditional access requiring known-device + corporate-network + step-up on privileged-role assignment; out-of-band notification on every consent grant for high-risk scope; continuous audit-log alerting on every IdP control-plane operation; downstream-SaaS telemetry for token-use anomalies.
165
165
 
@@ -316,7 +316,7 @@ Pull the conditional-access policy targeting admin roles and list every IP range
316
316
 
317
317
  ## Defensive Countermeasure Mapping
318
318
 
319
- Per AGENTS.md optional 8th section (required for skills shipped on or after 2026-05-11). Maps IdP-tenant compromise findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability per Hard Rule #9.
319
+ Maps IdP-tenant compromise findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
320
320
 
321
321
  | D3FEND ID | Technique | Layer Position | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
322
322
  |---|---|---|---|---|---|
@@ -325,7 +325,7 @@ Per AGENTS.md optional 8th section (required for skills shipped on or after 2026
325
325
  | D3-NTA | Network Traffic Analysis | IdP audit-log telemetry as authoritative source of control-plane operations; downstream-SaaS audit-log telemetry as primary detection when IdP itself is suspect; help-desk-system audit telemetry; IaC + CI configuration scanning for embedded management-API tokens | SOC-aggregated visibility; per-tenant alerting on consent-grant + federation-modification + privileged-role-assignment + break-glass-authentication events | Audit-log alerting continuous, not periodic; SLA on every IdP control-plane operation; downstream-SaaS audit logs treated as primary when IdP is compromised | Applicable. AI-agent traffic monitoring is the specific gap: AI-channel egress (LLM API egress with embedded tenant credentials) is a separate exfiltration path. |
326
326
  | D3-IOPR | Input / Output Pattern Recognition | Authentication-event pattern analysis (impossible-travel, anomalous source-IP, anomalous user-agent); OAuth-app behavioural baseline (typical scope use, typical request pattern); session-token behavioural baseline | Per-user authentication-pattern detection; per-app OAuth-behavioural baseline; per-service-account authentication-pattern baseline | Every authentication outcome verified against historical norm; OAuth-app behavioural drift treated as compromise signal; help-desk-mediated factor swap requires out-of-band identity verification | Critical. AI-agent authentication patterns (sustained API token use, broad scope queries, high-velocity calls) are themselves a detection signal; OAuth grants to AI agents require per-grant behavioural baselining. |
327
327
 
328
- **AI-pipeline-specific posture (per Hard Rule #9).** Conventional D3-MFA cannot apply to AI agents holding session credentials on behalf of users — there is no agent-side biometric inherence factor, and possession factors reduce to API-key custody. The AI-pipeline-appropriate construct is: scoped delegated-authority attestation + per-grant business-purpose attestation + continuous behavioural baselining (D3-IOPR) + out-of-band confirmation for any tenant-control-plane operation requested by an AI agent. Skill `identity-assurance` covers AAL/IAL/FAL constructs for human-side authentication; this skill covers the IdP-tenant-control-plane framing of the agent-side gap.
328
+ **AI-pipeline-specific posture.** Conventional D3-MFA cannot apply to AI agents holding session credentials on behalf of users — there is no agent-side biometric inherence factor, and possession factors reduce to API-key custody. The AI-pipeline-appropriate construct is: scoped delegated-authority attestation + per-grant business-purpose attestation + continuous behavioural baselining (D3-IOPR) + out-of-band confirmation for any tenant-control-plane operation requested by an AI agent. Skill `identity-assurance` covers AAL/IAL/FAL constructs for human-side authentication; this skill covers the IdP-tenant-control-plane framing of the agent-side gap.
329
329
 
330
330
  ---
331
331
 
@@ -128,7 +128,7 @@ This skill is response-shaped — the TTPs below name the incident classes the p
128
128
  | **AML.T0017** | Discover ML Model Ontology | Adversary mapping of deployed model family, system-prompt structure, guardrails, and training-data signal — precursor to extraction and adversarial-input crafting | Identification: anomalous inference-API usage patterns (high-volume queries, structured probing, membership-inference signatures, repeated training-data extraction prompts). Containment: rate-limit + API-key revocation + IP block. Eradication: identify attacker access surface; assess what model-ontology data was exposed. Recovery: re-key, consider model-rotation if proprietary weights are at risk; for training-data exfiltration consider differential-privacy retraining. | No standardized detection signatures; org must build custom telemetry over AI inference APIs. |
129
129
  | **AML.T0051** | LLM Prompt Injection | Prompt-injection breach as incident trigger | Identification: AI-assistant or agentic-system anomalous action (unauthorized data access, anomalous tool invocation, identity-context confusion). Containment: revoke AI-system tool scopes, disable agent autonomy, isolate affected RAG corpus. Eradication: identify injection vector (web content, email signature, document metadata, RAG corpus poisoning) and remove. Recovery: re-deploy with hardened system prompt + tool-scoping per `mcp-agent-trust`. | Detection lags; most orgs discover the incident from downstream effect (unauthorized action) rather than detection at the prompt boundary. |
130
130
 
131
- ATLAS pinned to v5.6.0 (May 2026) per AGENTS.md rule #12. ATT&CK pinned to v19.0 (April 2026) per the same rule; the Defense Evasion (TA0005) split into Stealth (TA0005) and Defense Impairment (TA0112) is traced via `tactic_moved_from` on affected `data/attack-techniques.json` entries and does not introduce breaking changes for the T-IDs cited above.
131
+ ATLAS pinned to v5.6.0 (May 2026). ATT&CK pinned to v19.0 (April 2026); the Defense Evasion (TA0005) split into Stealth (TA0005) and Defense Impairment (TA0112) is traced via `tactic_moved_from` on affected `data/attack-techniques.json` entries and does not introduce breaking changes for the T-IDs cited above.
132
132
 
133
133
  ---
134
134
 
@@ -158,7 +158,7 @@ Detection-tool maturity (mid-2026):
158
158
 
159
159
  ## Analysis Procedure
160
160
 
161
- Before stepping through the IR program assessment, thread the three foundational design principles per AGENTS.md Skill File Format requirements.
161
+ Before stepping through the IR program assessment, thread the three foundational design principles.
162
162
 
163
163
  **Defense in depth — IR as a multi-layer pipeline.** A real IR program is not the playbook document; it is the stack that produces the conditions for the playbook to fire and the conditions for it to succeed:
164
164
  - **Layer 1 — Preparation.** Playbook library (by ATT&CK technique + incident class + sector + jurisdiction), tabletop exercises (at least quarterly, scenarios drawn from current threat-intel feed), runbook tooling (SOAR + ticketing + comms), redundant logging (SIEM + DLP + identity + EDR + AI-system telemetry shipped to immutable store), legal and PR alignment, executive and board awareness, retainer with external IR firm.
@@ -255,7 +255,7 @@ Within 14 days of recovery (or sooner for severe incidents):
255
255
 
256
256
  ### Step 9 — Learning-loop feedback (cross-skill hand-offs)
257
257
 
258
- Per AGENTS.md DR-8 and the skill graph:
258
+ Per the zero-day learning loop and the skill graph:
259
259
  - File `data/zeroday-lessons.json` entry per `zeroday-gap-learn` if a zero-day or new attack class was involved.
260
260
  - File `data/framework-control-gaps.json` entry per `framework-gap-analysis` if a control-class gap was exposed.
261
261
  - Trigger `threat-model-currency` refresh — the incident is a real-world signal that the threat model may be stale.
@@ -272,7 +272,7 @@ Per ISO 27035-1:2023 §6 and NIST 800-61r3 post-incident activity:
272
272
  - Playbook coverage percentage (incident classes with playbook vs. total observed in 24-month window).
273
273
  - AI-class incident detection latency vs. conventional-class incident detection latency — the operationally-relevant gap metric for mid-2026.
274
274
 
275
- **Ephemeral / serverless / AI-pipeline reality (per AGENTS.md rule #9):** Evidence preservation in serverless and container environments is the new hard problem of mid-2026 IR. NIST 800-86 forensic procedures assume the workload still exists at acquisition time. For Lambda / Cloud Run / Azure Functions / Knative / Kubernetes pods scaled to zero, the workload is gone before the SOC opens the ticket. The architecturally honest recommendation: configure continuous forensic-grade telemetry shipping pre-incident (process trees, syscall traces, network flows, container-layer diffs, AI-system prompt / response / tool-invocation logs) to an external immutable store. Treat the absence of this pipeline as a precondition for incident-evidence-loss and document it as a control gap per `framework-gap-analysis` before the first incident, not after.
275
+ **Ephemeral / serverless / AI-pipeline reality:** Evidence preservation in serverless and container environments is the new hard problem of mid-2026 IR. NIST 800-86 forensic procedures assume the workload still exists at acquisition time. For Lambda / Cloud Run / Azure Functions / Knative / Kubernetes pods scaled to zero, the workload is gone before the SOC opens the ticket. The architecturally honest recommendation: configure continuous forensic-grade telemetry shipping pre-incident (process trees, syscall traces, network flows, container-layer diffs, AI-system prompt / response / tool-invocation logs) to an external immutable store. Treat the absence of this pipeline as a precondition for incident-evidence-loss and document it as a control gap per `framework-gap-analysis` before the first incident, not after.
276
276
 
277
277
  ---
278
278
 
@@ -510,7 +510,7 @@ A program passing all four tests is operating IR as infrastructure. A program fa
510
510
 
511
511
  ## Defensive Countermeasure Mapping
512
512
 
513
- Per AGENTS.md Skill File Format optional 8th section (required for skills shipped on or after 2026-05-11): map this skill's findings to MITRE D3FEND IDs from `data/d3fend-catalog.json` with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
513
+ This section maps this skill's findings to MITRE D3FEND IDs from `data/d3fend-catalog.json` with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
514
514
 
515
515
  IR consumes defensive controls across multiple D3FEND categories; the four cited below are the highest-leverage during active incident handling.
516
516
 
@@ -521,9 +521,9 @@ IR consumes defensive controls across multiple D3FEND categories; the four cited
521
521
  | **D3-IOPR** (Input/Output Profiling) | AI-API egress correlation and SaaS-egress anomaly detection. For AI-system incidents, profiling the input (prompt) and output (response) distribution is the defensive surface that can detect AML.T0051 (anomalous prompt patterns), AML.T0017 (extraction-pattern queries), and AML.T0096 (C2-channel encoded payloads). | Identification layer (primary for AI-system incidents). | Scoped to the AI-incident specialist role; raw prompts and responses may contain confidential data and must be access-controlled per data-classification policy. | Default-suspect for prompt distributions outside the baseline; do not whitelist by source identity alone — verify per request. | High applicability — D3-IOPR is the highest-leverage D3FEND technique for AI-system incident detection and is the operational complement to D3-NTA when the egress is to a legitimate AI provider. |
522
522
  | **D3-CSPP** (Client-Server Payload Profiling) | C2 protocol detection during identification; AI-API content-layer detection for AML.T0096. Where the C2 channel is HTTPS to a legitimate service (Box, OneDrive, S3, AI provider), CSPP is the content-shape detection surface that catches the abuse pattern. | Identification layer. | Scoped to the detection-engineering and IR analyst roles; payload-content access controlled. | Default-suspect for novel payload shapes against baseline; verify-not-assume that previously-good clients have not been compromised. | Applies — particularly for AI-API C2 detection where TLS termination at an enterprise proxy enables payload-shape analysis of prompts and responses. |
523
523
 
524
- **Explicit statement per AGENTS.md rule #4 (no orphaned controls)**: each D3FEND technique above maps to one or more incident classes in the TTP Mapping section (T1486 / T1041 / T1567 / T1078, AML.T0096 / T0017 / T0051). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during IR.
524
+ **No orphaned controls**: each D3FEND technique above maps to one or more incident classes in the TTP Mapping section (T1486 / T1041 / T1567 / T1078, AML.T0096 / T0017 / T0051). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during IR.
525
525
 
526
- **AI-pipeline statement per AGENTS.md rule #9**: D3FEND coverage of AI-incident defense is concentrated in D3-IOPR (input/output profiling) and the content-layer subset of D3-CSPP. The ephemeral-compute evidence-preservation problem is largely outside the D3FEND ontology as of mid-2026; the operational fix (continuous forensic-grade telemetry shipping to immutable store) is documented in `attack-surface-pentest` and `defensive-countermeasure-mapping` as a control gap pending ontology coverage.
526
+ **AI-pipeline statement**: D3FEND coverage of AI-incident defense is concentrated in D3-IOPR (input/output profiling) and the content-layer subset of D3-CSPP. The ephemeral-compute evidence-preservation problem is largely outside the D3FEND ontology as of mid-2026; the operational fix (continuous forensic-grade telemetry shipping to immutable store) is documented in `attack-surface-pentest` and `defensive-countermeasure-mapping` as a control gap pending ontology coverage.
527
527
 
528
528
  ---
529
529
 
@@ -532,7 +532,7 @@ IR consumes defensive controls across multiple D3FEND categories; the four cited
532
532
  IR sits downstream of detection and upstream of organizational learning. Route to the following on the indicated trigger:
533
533
 
534
534
  - **`coordinated-vuln-disclosure`** — *upstream input.* When IR identification surfaces a vulnerability against an org product (received via researcher report, bug-bounty queue, or customer escalation), hand off to the CVD intake pipeline. Conversely, when CVD output identifies a vulnerability that is being actively exploited, the resulting EU CRA Art. 11 24h clock is run by the IR team using this skill's regulator-notification matrix.
535
- - **`zeroday-gap-learn`** — *downstream learning loop.* Every incident with a novel attack class or a zero-day vector triggers a learning-loop entry per AGENTS.md DR-8. If IR is operating but `data/zeroday-lessons.json` entries are not being filed, the hand-off is broken.
535
+ - **`zeroday-gap-learn`** — *downstream learning loop.* Every incident with a novel attack class or a zero-day vector triggers a learning-loop entry. If IR is operating but `data/zeroday-lessons.json` entries are not being filed, the hand-off is broken.
536
536
  - **`threat-model-currency`** — *downstream refresh trigger.* An incident is the strongest real-world signal that the threat model may be stale; trigger the currency refresh routine.
537
537
  - **`compliance-theater`** — *paper-IR detection.* The four compliance theater tests in this skill compose with the broader theater detection across frameworks; run `compliance-theater` after this skill when the org is claiming SOC 2 / ISO 27001 / NIST CSF / HIPAA maturity that the IR test results contradict.
538
538
  - **`framework-gap-analysis`** — *control-gap filing.* When an incident exposes that an existing control was insufficient to detect, prevent, or contain, file the gap under the appropriate framework entry per `data/framework-control-gaps.json`.
@@ -370,18 +370,18 @@ vm.unprivileged_userfaultfd = 0
370
370
 
371
371
  ## Defensive Countermeasure Mapping
372
372
 
373
- Maps the kernel LPE findings above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, and zero-trust posture (per AGENTS.md Hard Rule #9). Source: `data/d3fend-catalog.json`.
373
+ Maps the kernel LPE findings above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, and zero-trust posture. Source: `data/d3fend-catalog.json`.
374
374
 
375
375
  | D3FEND Technique | Mapping | Defense-in-Depth Layer | Least-Privilege Scope | Zero-Trust Posture |
376
376
  |---|---|---|---|---|
377
377
  | **D3-PSEP** (Process Segment Execution Prevention) | Counters T1068 page-cache CoW write primitives (Copy Fail) and adjacent kernel write-where exploits by enforcing NX / W^X on user-mapped segments and rejecting writeable-and-executable kernel mappings. | Layer 1 (Harden — kernel build flags + runtime mitigations: SMEP, SMAP, KPTI, KRG). | Per-system — the entire kernel image is the principal scope. | Treat every userspace write to a kernel-shared mapping as untrusted until verified by an immutable mapping policy; auditd / eBPF rules emit a tamper signal on any anomalous write path. |
378
378
  | **D3-ASLR** (Address Space Layout Randomization) | Raises the cost of reliable kernel LPE exploitation by randomising kernel base and module load addresses; Copy Fail is deterministic without an info-leak primitive, so KASLR alone is not sufficient but is the first-floor mitigation against the broader class. | Layer 1 (Harden). | Per-boot — randomisation applies system-wide each boot. | Combine with `kernel.kptr_restrict=2` (already in the sysctl block above) so unprivileged processes cannot read kernel pointers that would defeat KASLR. |
379
- | **D3-EAL** (Executable Allowlisting) | Restricts which userspace executables can run on the host. A Copy Fail PoC is a 732-byte binary; allowlisting denies unauthorised execution of any binary not on the allowlist, raising the cost of post-exploit shell payloads even when the in-kernel write itself succeeds. | Layer 2 (Harden — execve gate). | Per-system / per-workload — fleet baselines (gold images) define the allowlist; SOC / EDR enforces it. | Verify the binary identity on every `execve`; reject on hash mismatch. AGENTS.md rule #9: in ephemeral / serverless contexts bake the allowlist into the function image at build-time. |
379
+ | **D3-EAL** (Executable Allowlisting) | Restricts which userspace executables can run on the host. A Copy Fail PoC is a 732-byte binary; allowlisting denies unauthorised execution of any binary not on the allowlist, raising the cost of post-exploit shell payloads even when the in-kernel write itself succeeds. | Layer 2 (Harden — execve gate). | Per-system / per-workload — fleet baselines (gold images) define the allowlist; SOC / EDR enforces it. | Verify the binary identity on every `execve`; reject on hash mismatch. In ephemeral / serverless contexts bake the allowlist into the function image at build-time. |
380
380
  | **D3-PHRA** (Process Hardware Resource Access) | Constrains hardware-resource access from userspace (page table writes via `/proc/self/mem`, `userfaultfd`, `process_vm_writev`) that the Copy Fail PoC relies on. The sysctl hardening above (`vm.unprivileged_userfaultfd=0`, `kernel.unprivileged_userns_clone=0`) is the D3-PHRA enforcement layer. | Layer 1 (Isolate — kernel-syscall surface). | Per-process — capability set + namespace + seccomp filter define the syscall allowlist. | Default-deny: an unprivileged process gets the minimum syscall surface and is denied `userfaultfd`, `unshare(CLONE_NEWUSER)`, and `process_vm_writev` unless explicitly required. |
381
381
  | **D3-SCP** (System Call Filtering) | Per-container / per-workload seccomp profile blocks the syscalls Copy Fail abuses (`userfaultfd`, `process_vm_writev`, `pwritev2`) without requiring kernel patch. For container-escape variants (T1611 — Copy Fail in a privileged container), this is the only viable runtime mitigation between KEV-listing and the next reboot window. | Layer 2 (Isolate — runtime syscall gate). | Per-container — runtime profile is the principal scope. | Define a default-deny seccomp baseline; the host kernel patch is necessary but seccomp is the per-workload extension that survives an unpatched kernel during the live-patch deployment window. |
382
382
  | **D3-PA** (Process Analysis) | Detects post-exploit anomalies — root shell spawned by previously-unprivileged process, suid-binary creation, capability escalation — that follow a Copy Fail-class write. The auditd and Falco / Tetragon rules in the Detection Rules section above are the D3-PA enforcement layer. | Layer 5 (Detect). | Per-host — SOC / EDR ingest the audit stream. | Continuously evaluate process lineage; alert on uid transitions, capability gains, or suid mounts that don't appear in the baseline. |
383
383
 
384
- **Defense-in-depth posture:** the live-patch is the closure; the five D3FEND techniques above are the layers that must remain active *during* the live-patch deployment window. A SOC claiming "we have EDR" is at one D3FEND layer (D3-PA) for a six-layer-deep finding — the harden / isolate / detect stack collapses to a detect-only posture, and a kernel-write primitive that succeeds before EDR fires is unrecoverable. Per AGENTS.md rule #9: in ephemeral / serverless contexts, D3-PSEP / D3-EAL / D3-SCP / D3-PHRA are configured at image build time; the host-kernel layer remains the CSP's responsibility for managed runtimes, with the consumer responsible for the guest-OS posture on IaaS workloads.
384
+ **Defense-in-depth posture:** the live-patch is the closure; the five D3FEND techniques above are the layers that must remain active *during* the live-patch deployment window. A SOC claiming "we have EDR" is at one D3FEND layer (D3-PA) for a six-layer-deep finding — the harden / isolate / detect stack collapses to a detect-only posture, and a kernel-write primitive that succeeds before EDR fires is unrecoverable. In ephemeral / serverless contexts, D3-PSEP / D3-EAL / D3-SCP / D3-PHRA are configured at image build time; the host-kernel layer remains the CSP's responsibility for managed runtimes, with the consumer responsible for the guest-OS posture on IaaS workloads.
385
385
 
386
386
  ---
387
387
 
@@ -393,4 +393,4 @@ After producing the kernel LPE triage output, the operator should chain into the
393
393
  - **`defensive-countermeasure-mapping`** — map each kernel LPE finding to D3FEND counters (D3-EAL for executable allowlisting at the kernel-module layer, D3-ASLR for address-space layout randomisation hardening, D3-PSEP for process self-modification prevention, D3-PHRA for process hardening / runtime attestation) and produce the defence-in-depth, least-privilege, zero-trust layered remediation plan rather than a single-control patch ticket.
394
394
  - **`attack-surface-pentest`** — verify that the kernel LPE class is in the organisation's pen-test scope (TIBER-EU / DORA TLPT for EU financial-sector orgs, CBEST for UK financial, or the equivalent red-team programme). Most 2025-vintage pen-test scopes are perimeter / web-app focused and do not exercise local LPE primitives against the patched-kernel claim.
395
395
  - **`compliance-theater`** — test whether the org's SI-2 / A.8.8 / PCI 6.3.3 patch-management evidence is CVSS-anchored theater for a KEV-listed, AI-discovered, 732-byte deterministic LPE. The 30-day window is the exploitation window; if the org cannot show live-patch-within-4-hours capability or documented compensating controls, the patch-management control is theater for this CVE class.
396
- - **`policy-exception-gen`** — generate a defensible exception for ephemeral container workloads where the 30-day patch window is architecturally impossible (per AGENTS.md rule #9): immutable image fleets, short-lived serverless functions, and Knative-style scale-to-zero workloads cannot accept a runtime patch and must instead document the compensating controls (host-kernel patched, seccomp profile, namespace isolation, unprivileged-userns disabled) as the exception evidence.
396
+ - **`policy-exception-gen`** — generate a defensible exception for ephemeral container workloads where the 30-day patch window is architecturally impossible: immutable image fleets, short-lived serverless functions, and Knative-style scale-to-zero workloads cannot accept a runtime patch and must instead document the compensating controls (host-kernel patched, seccomp profile, namespace isolation, unprivileged-userns disabled) as the exception evidence.
@@ -345,9 +345,9 @@ After producing the MCP trust assessment output, the operator should chain into
345
345
  - **`defensive-countermeasure-mapping`** — map MCP trust failures to D3FEND counters: D3-EHB (hash-based executable allowlisting for the MCP server binary), D3-CBAN (certificate-based authentication between client and server), D3-MFA (multi-factor authentication on the MCP control plane where remote), D3-CSPP (client-server payload profiling on tool call / tool response shapes). The trust-tier model in Step 5 above is operationalised through these counters.
346
346
  - **`attack-surface-pentest`** — explicitly include each installed MCP server in the in-scope target list for pen-testing and adversary emulation. 2025-vintage pen-test scopes overwhelmingly omit MCP servers; this is the single biggest assumed-out-of-scope gap discovered during this skill's analysis.
347
347
  - **`dlp-gap-analysis`** — MCP tool arguments are a DLP egress channel. Verify that SDK-level prompt logging captures tool-arg egress (filenames, file contents, credential strings passed as arguments) and that DLP classifiers run on the tool-call payload, not just on file/email egress. Without this, an MCP server with filesystem read access is a fully invisible exfiltration path.
348
- - **`framework-gap-analysis`** — when the MCP trust gap fails a specific framework control (NIST-800-53-CM-7 / ISO-27001-2022-A.8.30 / SOC2-CC9 vendor management), invoke this skill to produce the formal gap declaration tied to the organisation's compliance scope and jurisdiction, including the EU NIS2 / DORA / AU Essential 8 mappings per AGENTS.md rule #5.
348
+ - **`framework-gap-analysis`** — when the MCP trust gap fails a specific framework control (NIST-800-53-CM-7 / ISO-27001-2022-A.8.30 / SOC2-CC9 vendor management), invoke this skill to produce the formal gap declaration tied to the organisation's compliance scope and jurisdiction, including the EU NIS2 / DORA / AU Essential 8 mappings (global-first coverage, not US-only).
349
349
 
350
- For ephemeral / serverless AI-pipeline contexts (per AGENTS.md rule #9): live SLSA-attestation verification at runtime is architecturally impossible for inline-pulled MCP servers in serverless functions. The scoped alternative is build-time attestation pinning baked into the function image, with the runtime fetch path disabled at the network layer.
350
+ For ephemeral / serverless AI-pipeline contexts (where some controls are architecturally impossible): live SLSA-attestation verification at runtime is architecturally impossible for inline-pulled MCP servers in serverless functions. The scoped alternative is build-time attestation pinning baked into the function image, with the runtime fetch path disabled at the network layer.
351
351
 
352
352
  ---
353
353
 
@@ -370,7 +370,7 @@ D3FEND v1.3.0+ references from `data/d3fend-catalog.json`. MCP trust failures la
370
370
 
371
371
  **Zero-trust posture:** every MCP server is treated as an untrusted third party regardless of vendor reputation — `D3-EHB` pin on registration, `D3-CBAN` cert verification on every connection, `D3-CSPP` payload inspection on every tool call. No "first-party vendor" exemption; the Cursor / Windsurf / VS Code first-party plugins ship through the same supply-chain (`npm` / `pip` / VS Code marketplace) that AML.T0010 targets.
372
372
 
373
- **AI-pipeline applicability (per AGENTS.md Hard Rule #9):** `D3-EAL` and `D3-EHB` apply only when the MCP server runs as a local executable. For hosted / remote MCP servers (the Claude Code, Cursor, and Windsurf hosted-tool pattern), the scoped alternative is `D3-CBAN` (pinned server identity) + `D3-CSPP` at the egress gateway + `D3-CAA` against the hosted-server provider's audit log feed. The endpoint controls (`D3-EAL`/`D3-EHB`) move from "verify locally before run" to "verify provider attestation before connect."
373
+ **AI-pipeline applicability (some controls are architecturally impossible in ephemeral / hosted contexts):** `D3-EAL` and `D3-EHB` apply only when the MCP server runs as a local executable. For hosted / remote MCP servers (the Claude Code, Cursor, and Windsurf hosted-tool pattern), the scoped alternative is `D3-CBAN` (pinned server identity) + `D3-CSPP` at the egress gateway + `D3-CAA` against the hosted-server provider's audit log feed. The endpoint controls (`D3-EAL`/`D3-EHB`) move from "verify locally before run" to "verify provider attestation before connect."
374
374
 
375
375
  ---
376
376