@blamejs/exceptd-skills 0.12.8 → 0.12.9

package/skills/exploit-scoring/skill.md

@@ -30,6 +30,12 @@ A CVSS 9.8 vulnerability with no public exploit, no active exploitation, and a s
 
 ---
 
+## Frontmatter Scope
+
+The `atlas_refs` and `attack_refs` arrays are intentionally empty. This skill is a scoring methodology — its input is whatever CVE the operator hands it, with whatever TTPs that CVE already carries in `data/cve-catalog.json`. Pinning a fixed TTP subset would mis-frame the score's coverage; RWEP applies to every CVE in the catalog regardless of which ATLAS or ATT&CK technique it maps to. `framework_gaps` is populated because the scoring outcome explicitly references control families (CWE-Top-25-2024-meta, CIS-Controls-v8-Control7) that the RWEP rationale ties remediation timing to.
+
+---
+
 ## Threat Context (mid-2026)
 
 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.

package/skills/mcp-agent-trust/skill.md

@@ -54,6 +54,7 @@ cwe_refs:
   - CWE-918
   - CWE-94
 d3fend_refs:
+  - D3-CAA
   - D3-CBAN
   - D3-CSPP
   - D3-EAL
@@ -324,6 +325,29 @@ For ephemeral / serverless AI-pipeline contexts (per AGENTS.md rule #9): live SL
 
 ---
 
+## Defensive Countermeasure Mapping
+
+D3FEND v1.0+ references from `data/d3fend-catalog.json`. MCP trust failures land on a tightly bounded set of defensive techniques because the attack surface is structural: a tool registered in `mcp.json` runs with the AI assistant's authority unless the listed controls intervene.
+
+| D3FEND ID | Name | Layer | Rationale (what it counters here) |
+|---|---|---|---|
+| `D3-EHB` | Executable Hash-based Allowlist | Host / MCP server registration | Pins each MCP server binary by hash so CVE-2026-30615-class supply-chain swaps (compromised `npx` package replaces the server with an exploit variant) cannot replace the trusted binary silently. Direct counter to AML.T0010 + T1195.001. |
+| `D3-EAL` | Executable Allowlisting | Host / shell-capable tool | Restricts which executables an MCP shell-tool or process-exec-capable server can spawn. Without this, a server with `bash`/`pwsh` tools is a shell on the developer workstation with the developer's authority. |
+| `D3-CAA` | Credential Access Auditing | Identity / MCP bearer-auth | Logs every MCP server's use of the bearer token / OAuth credential and the resources it touched. The audit anchor for AML.T0016 (model and credential exfiltration via tool calls); the only post-hoc evidence stream when an MCP server is trusted but malicious. |
+| `D3-CSPP` | Client-server Payload Profiling | MCP gateway | Gateway-layer inspection of MCP tool-call args and tool-result bodies. The single control that can detect indirect prompt-injection payloads landing in `tools/call` results, AML.T0051 patterns reaching the assistant through document fetches, and AML.T0096 covert C2 over MCP transport. |
+| `D3-CBAN` | Certificate Analysis | Transport / MCP server-side | Validates the MCP server's TLS certificate chain and binds it to a pinned identity registered in the host's MCP catalog. Counters the "stand-up a malicious MCP server with a Let's Encrypt cert pretending to be a sanctioned vendor" pattern. |
+| `D3-MFA` | Multi-factor Authentication | Identity / OAuth client registration | Required for MCP servers registered as OAuth clients against enterprise IdPs. Without phishing-resistant MFA on the registration flow, a compromised developer credential can register an attacker-controlled MCP server inside the org's trust boundary. |
+
+**Defense-in-depth posture:** `D3-EHB` is the registration layer (only signed/hashed binaries register); `D3-EAL` is the runtime layer (only allowlisted child processes spawn); `D3-CSPP` is the in-flight content layer; `D3-CAA` is the post-hoc audit layer; `D3-CBAN` is the transport-identity layer; `D3-MFA` is the registration-identity layer. CVE-2026-30615 demonstrated that any single-layer defence fails — a signed manifest alone (`D3-EHB`) does not prevent an in-band path-traversal RCE that lands once the manifest is honoured.
+
+**Least-privilege scope:** every MCP server's tool allowlist is the minimum set required for its sanctioned use case — a documentation-search server does not get a `bash` tool, an issue-tracker server does not get a `read_file` tool with `/etc/**` glob authority. `D3-EAL` enforces this at the spawn boundary; `D3-CAA` audits every authorisation use against the documented scope.
+
+**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.
+
+**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."
+
+---
+
 ## Compliance Theater Check
 
 > "Your vendor management control (CC9 / SA-12 / A.5.19) documents a review process for third-party software with access to sensitive systems. Enumerate the MCP servers installed on developer workstations that have access to production codebases or credentials. How many of those MCP servers went through your vendor review process? If the answer is zero, the vendor management control is theater for the attack surface where AI-assisted supply chain attacks are actually occurring."

package/skills/policy-exception-gen/skill.md

@@ -38,6 +38,12 @@ This skill generates exception templates for architectural realities that curren
 
 ---
 
+## Frontmatter Scope
+
+The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. Exceptions are generated *against* whatever control the operator names at invocation time — the input is the framework-control ID, and the output is a templated exception keyed to that ID. Pinning a fixed subset here would constrain the skill's input domain to the wrong dimension; any framework gap any other skill produces is a legitimate exception-template input.
+
+---
+
 ## Threat Context (mid-2026)
 
 Most non-trivial mid-2026 production architectures break the literal reading of at least one major framework control. Serverless functions break asset-inventory language; immutable container images break in-place patch-window language; LLM API dependencies break change-management language; Zero Trust environments break network-segmentation language. Where the organization has no defensible exception process, only two outcomes remain: (1) the organization claims compliance falsely (theater) or (2) the audit blocks the architecture entirely.

package/skills/rag-pipeline-security/skill.md

@@ -26,16 +26,18 @@ framework_gaps:
   - NIST-AI-RMF-MEASURE-2.5
   - OWASP-LLM-Top-10-2025-LLM08
   - EU-AI-Act-Art-15
-  - UK-CAF-A1
+  - UK-CAF-B2
   - AU-Essential-8-App-Hardening
 cwe_refs:
   - CWE-1395
   - CWE-1426
 d3fend_refs:
   - D3-CSPP
+  - D3-FCR
+  - D3-FAPA
   - D3-IOPR
   - D3-NTA
-last_threat_review: "2026-05-01"
+last_threat_review: "2026-05-13"
 ---
 
 # RAG Pipeline Security Assessment
@@ -171,6 +173,8 @@ This attack requires:
 | NIST AI RMF MEASURE 2.5 | Evaluate AI risk during operation | Identifies operational monitoring as important. No specific controls for retrieval security, vector store integrity, or indirect prompt injection via retrieved content. |
 | SOC 2 CC6 | Logical and Physical Access | IAM for identified systems. Vector stores as inference surfaces don't map to traditional access control models. |
 | All frameworks | (none) | No framework has controls for: vector store poisoning, embedding manipulation for exfiltration, chunking exploitation, retrieval filter bypass, or indirect prompt injection via retrieved content. |
+| UK CAF | B2 (Identity and access control) | Selected over CAF-A1 because every RAG attack class above resolves to an access-control failure at retrieval time — clearance-aware namespace partitioning, per-query authorisation, and embedding-space ACLs are the missing controls. CAF-A1 (governance) is the parent concern but does not name the retrieval-access-control surface that is the actual mid-2026 gap. |
+| AU Essential Eight | User application hardening | The RAG pipeline is the application surface that hosts the retrieval engine, embedding model, and vector store. App-hardening as written covers browser/Office hardening; the AU mapping is partial because Essential Eight does not contemplate AI pipelines as a user-application class. |
 
 ---
 
@@ -292,6 +296,28 @@ For ephemeral / serverless RAG pipelines (per AGENTS.md rule #9): embedding-dist
 
 ---
 
+## Defensive Countermeasure Mapping
+
+D3FEND v1.0+ references from `data/d3fend-catalog.json`. The five RAG attack classes above map to the following defensive techniques. Coverage for RAG pipelines is uneven across enterprises in mid-2026 — most have `D3-NTA` on the network layer and nothing else.
+
+| D3FEND ID | Name | Layer | Rationale (what it counters here) |
+|---|---|---|---|
+| `D3-FCR` | File Content Rules | Data tier / corpus ingestion | Content classification at ingestion. Direct counter to Attack Class 2 (vector store poisoning) — corpus documents are content-filtered before they reach the embedding model. Also catches Attack Class 5 (indirect prompt injection) when payload patterns are recognisable in the source document. |
+| `D3-FAPA` | File Access Pattern Analysis | Data tier / corpus access | Detects retrieval-time anomalies — a query topology that systematically targets sensitive-document embeddings (Attack Class 1) shows up as an unusual file-access pattern against the corpus index, even when no individual retrieval is suspicious in isolation. |
+| `D3-IOPR` | Input/Output Profiling | RAG pipeline / SDK | Inspects retrieval queries and their resulting context bundles before they reach the LLM prompt. Required for Attack Class 3 (chunking exploitation) and Attack Class 4 (retrieval filter bypass) detection — the offending content shape is only visible at the pipeline boundary between retrieval and generation. |
+| `D3-CSPP` | Client-server Payload Profiling | LLM gateway | Gateway-layer inspection of the final composed prompt (query + retrieved context + instructions). Catches Attack Class 5 patterns that survived `D3-FCR` at ingestion — indirect prompt injection in retrieved context is visible as a structural anomaly in the assembled prompt. |
+| `D3-NTA` | Network Traffic Analysis | Network egress / RAG outputs | Per-identity baseline of RAG-result egress volume and destinations. Catches Attack Class 1's terminal phase — the exfiltrated content has to leave the boundary to reach the attacker. Last-resort detection when content controls fail. |
+
+**Defense-in-depth posture:** `D3-FCR` is the corpus-ingestion layer; `D3-FAPA` is the retrieval-access layer; `D3-IOPR` is the pipeline-internal layer; `D3-CSPP` is the gateway layer; `D3-NTA` is the egress layer. The Attack Class table maps each class to at least two of these — Class 5 (indirect prompt injection) is the canonical example: `D3-FCR` at ingestion + `D3-CSPP` at the gateway, because neither alone catches payloads that pass content rules at ingest but compose into a prompt-injection structure post-retrieval.
+
+**Least-privilege scope:** every query identity has a clearance label; retrieval results are filtered against that label at retrieval time (`D3-FAPA` enforces the filter and audits the pattern). RAG corpora are partitioned per-clearance — a Restricted-clearance corpus is not accessible to a Public-clearance principal even when query similarity would otherwise surface the document.
+
+**Zero-trust posture:** every retrieved chunk is treated as untrusted content. `D3-CSPP` inspects the composed prompt as if the retrieved context came from a hostile source — because under Attack Class 5, it did. No "internal document is trusted" exemption — internal documents are the documented vector for indirect prompt injection that survives external-content filters.
+
+**AI-pipeline applicability (per AGENTS.md Hard Rule #9):** `D3-FAPA` on ephemeral, per-query rebuilt indices degrades to per-query retrieval logging (`D3-IOPR` captures the query + result set) because there is no persistent corpus to baseline against. The scoped alternative is build-time provenance (signed index manifest at construction) combined with query-time `D3-IOPR` capture of the query+result-set tuple — equivalent observation surface, different anchoring.
+
+---
+
 ## Compliance Theater Check
 
 > "Your data classification policy defines sensitivity levels for documents in your knowledge base. Now trace a specific high-sensitivity document through your RAG pipeline: at what point is its classification applied as a retrieval constraint? If the answer is 'it's in a separate namespace' — verify that namespace boundaries are enforced before similarity scoring, not after. If the answer is 'it's not in the RAG system' — verify that the ingestion pipeline cannot be used to introduce it. If neither answer can be verified: the data classification control has no enforcement mechanism in the RAG context."

package/skills/researcher/skill.md

@@ -32,6 +32,12 @@ This skill is the front door to the exceptd library. Operators do not always arr
 
 ---
 
+## Frontmatter Scope
+
+The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. This skill is a dispatch layer — it routes the operator to whichever specialised skill owns the relevant TTPs and framework gaps. The routed-to skill carries the authoritative reference set; duplicating those IDs here would create a divergence surface the next time a downstream skill's mappings change. The `data_deps` list is the complete dependency declaration: every catalog the researcher reads is enumerated there.
+
+---
+
 ## Threat Context (mid-2026)
 
 Most security teams in mid-2026 sit on a torrent of raw threat input: CISA KEV additions, vendor advisories, ATLAS updates, red-team reports, internal SIEM alerts, framework amendment bulletins, supply-chain notices. The two failure modes are symmetric and equally damaging.

package/skills/security-maturity-tiers/skill.md

@@ -38,6 +38,12 @@ Three tiers. Each is complete, not a stepping stone to the next. An organization
 
 ---
 
+## Frontmatter Scope
+
+The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. This skill produces a roadmap shape that applies to *every* security domain the project covers (kernel patching, AI systems, cryptography, MCP, RAG, identity, supply chain, etc.). The three-tier roadmap is domain-agnostic; the domain-specific TTPs and framework gaps live in the downstream skill that owns the domain. Pinning a fixed subset here would falsely imply tier-mapping applies only to that subset.
+
+---
+
 ## How to Use This Skill
 
 This skill produces a three-column roadmap for any security domain. Tell it:

package/skills/skill-update-loop/skill.md

@@ -41,6 +41,12 @@ This meta-skill manages the evolution of all other exceptd skills. It is the loo
 
 ---
 
+## Frontmatter Scope
+
+The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. This skill operates on the *catalog and skill inventory itself* — it has no adversary TTP attached because its threat model is platform-currency drift, not an external adversary. Every TTP and framework-gap mapped by any other skill in the project is implicitly in scope for this loop's audit; pinning a subset would mis-bound the work.
+
+---
+
 ## Threat Context
 
 The threat context this skill defends against is not a specific adversary technique — it is the **drift attack against the platform's own currency**: an exceptd installation whose skills, catalogs, framework references, and ATLAS pins age silently between releases until the operator-facing analysis is calibrated to a threat model that no longer exists.

package/skills/threat-model-currency/skill.md

@@ -27,6 +27,10 @@ last_threat_review: "2026-05-01"
 
 # Threat Model Currency Assessment
 
+## Frontmatter Scope
+
+The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. This skill is a meta-assessment of *every* threat model — its job is to surface gaps against the full 14-class mid-2026 landscape that downstream skills enumerate. Pinning a fixed TTP or framework-gap subset here would understate the assessment's actual coverage (every ATLAS / ATT&CK ID and every framework gap any other skill maps becomes an in-scope currency check). The 14 threat classes are listed in the body; each one references the downstream skill that carries the authoritative TTP and framework-gap IDs.
+
 ## Purpose
 
 Most organizational threat models were last substantially revised 2–4 years ago. They describe the threat landscape of 2021–2022: ransomware, supply chain (SolarWinds-era), cloud misconfiguration, credential phishing using template emails. This is not the 2026 threat landscape.

package/skills/zeroday-gap-learn/skill.md

@@ -34,6 +34,12 @@ This skill runs the full learning loop: zero-day description → attack vector e
 
 ---
 
+## Frontmatter Scope
+
+The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. This skill exists to *generate* TTP-to-gap mappings from incoming zero-days, not to consume a fixed set — its output flows back into `data/atlas-ttps.json` and `data/framework-control-gaps.json` as new entries. Pinning a static reference set here would mis-frame the loop: every TTP and gap mapped by any other skill is a legitimate input, and the skill's job is to produce the *next* entries, not to inherit a fixed subset.
+
+---
+
 ## Threat Context (mid-2026)
 
 The zero-day learning cycle has compressed. The frameworks have not.