@blamejs/exceptd-skills 0.12.7 → 0.12.9
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.
- package/AGENTS.md +15 -1
- package/ARCHITECTURE.md +21 -5
- package/CHANGELOG.md +150 -0
- package/README.md +1 -1
- package/bin/exceptd.js +416 -69
- package/data/_indexes/_meta.json +44 -44
- package/data/_indexes/activity-feed.json +34 -34
- package/data/_indexes/catalog-summaries.json +9 -9
- package/data/_indexes/chains.json +249 -11
- package/data/_indexes/frequency.json +63 -5
- package/data/_indexes/jurisdiction-map.json +13 -3
- package/data/_indexes/section-offsets.json +1171 -1027
- package/data/_indexes/summary-cards.json +2 -2
- package/data/_indexes/token-budget.json +232 -152
- package/data/atlas-ttps.json +189 -1
- package/data/cve-catalog.json +34 -22
- package/data/cwe-catalog.json +290 -1
- package/data/d3fend-catalog.json +163 -1
- package/data/framework-control-gaps.json +243 -0
- package/data/playbooks/containers.json +23 -5
- package/data/playbooks/cred-stores.json +9 -9
- package/data/playbooks/crypto.json +8 -8
- package/data/playbooks/hardening.json +46 -10
- package/data/playbooks/library-author.json +16 -20
- package/data/playbooks/mcp.json +1 -0
- package/data/playbooks/runtime.json +7 -7
- package/data/playbooks/sbom.json +11 -11
- package/data/playbooks/secrets.json +4 -4
- package/data/rfc-references.json +144 -0
- package/lib/playbook-runner.js +119 -35
- package/lib/prefetch.js +27 -6
- package/lib/refresh-external.js +32 -9
- package/lib/schemas/skill-frontmatter.schema.json +2 -2
- package/manifest-snapshot.json +1 -1
- package/manifest.json +73 -73
- package/orchestrator/index.js +1 -1
- package/package.json +2 -1
- package/sbom.cdx.json +6 -6
- package/scripts/check-sbom-currency.js +87 -0
- package/scripts/check-test-coverage.README.md +148 -0
- package/scripts/check-test-coverage.js +476 -0
- package/scripts/hooks/pre-commit.sh +19 -0
- package/scripts/predeploy.js +14 -30
- package/skills/age-gates-child-safety/skill.md +3 -0
- package/skills/ai-attack-surface/skill.md +29 -1
- package/skills/ai-c2-detection/skill.md +30 -1
- package/skills/ai-risk-management/skill.md +3 -0
- package/skills/api-security/skill.md +3 -0
- package/skills/attack-surface-pentest/skill.md +3 -0
- package/skills/cloud-security/skill.md +3 -0
- package/skills/compliance-theater/skill.md +6 -0
- package/skills/container-runtime-security/skill.md +3 -0
- package/skills/coordinated-vuln-disclosure/skill.md +8 -1
- package/skills/defensive-countermeasure-mapping/skill.md +1 -1
- package/skills/dlp-gap-analysis/skill.md +3 -0
- package/skills/email-security-anti-phishing/skill.md +9 -1
- package/skills/exploit-scoring/skill.md +6 -0
- package/skills/identity-assurance/skill.md +6 -1
- package/skills/incident-response-playbook/skill.md +8 -2
- package/skills/kernel-lpe-triage/skill.md +24 -4
- package/skills/mcp-agent-trust/skill.md +28 -1
- package/skills/mlops-security/skill.md +3 -0
- package/skills/ot-ics-security/skill.md +3 -0
- package/skills/policy-exception-gen/skill.md +6 -0
- package/skills/rag-pipeline-security/skill.md +30 -1
- package/skills/researcher/skill.md +6 -0
- package/skills/sector-energy/skill.md +3 -0
- package/skills/sector-federal-government/skill.md +3 -0
- package/skills/sector-financial/skill.md +3 -0
- package/skills/sector-healthcare/skill.md +3 -0
- package/skills/security-maturity-tiers/skill.md +25 -1
- package/skills/skill-update-loop/skill.md +38 -0
- package/skills/supply-chain-integrity/skill.md +3 -0
- package/skills/threat-model-currency/skill.md +4 -0
- package/skills/threat-modeling-methodology/skill.md +3 -0
- package/skills/webapp-security/skill.md +3 -0
- package/skills/zeroday-gap-learn/skill.md +6 -0
package/scripts/predeploy.js
CHANGED
|
@@ -118,7 +118,7 @@ const GATES = [
|
|
|
118
118
|
{
|
|
119
119
|
name: "SBOM currency check (sbom.cdx.json vs. live surface)",
|
|
120
120
|
command: process.execPath,
|
|
121
|
-
args: ["
|
|
121
|
+
args: [path.join(ROOT, "scripts", "check-sbom-currency.js")],
|
|
122
122
|
ciJobName: "Data integrity (catalog + manifest snapshot)",
|
|
123
123
|
},
|
|
124
124
|
{
|
|
@@ -151,37 +151,21 @@ const GATES = [
|
|
|
151
151
|
ciJobName: "Data integrity (catalog + manifest snapshot)",
|
|
152
152
|
requiresKeys: true,
|
|
153
153
|
},
|
|
154
|
+
{
|
|
155
|
+
// AGENTS.md hard rule #15 (e2e no-MVP). Every diff that touches a
|
|
156
|
+
// CLI verb, CLI flag, lib/orchestrator/scripts export, playbook
|
|
157
|
+
// indicator, or CVE iocs field must land with a covering test
|
|
158
|
+
// reference in the same PR. The analyzer parses git diff against
|
|
159
|
+
// origin/main, classifies each change shape, and fails if a covered
|
|
160
|
+
// surface lacks a test literal anywhere under tests/. Blocking — a
|
|
161
|
+
// covered surface change without a covering test fails the gate.
|
|
162
|
+
name: "Diff coverage (feature changes require test coverage)",
|
|
163
|
+
command: process.execPath,
|
|
164
|
+
args: [path.join(ROOT, "scripts", "check-test-coverage.js")],
|
|
165
|
+
ciJobName: "Diff coverage",
|
|
166
|
+
},
|
|
154
167
|
];
|
|
155
168
|
|
|
156
|
-
/* Inline checker, run as `node -e`, so the predeploy gate stays one
|
|
157
|
-
* file and the SBOM regen logic stays in scripts/refresh-sbom.js
|
|
158
|
-
* (single source of truth). Compares the persisted sbom.cdx.json
|
|
159
|
-
* against the live skill_count + catalog_count derived from
|
|
160
|
-
* manifest.json + data/. Exits nonzero on drift, with a hint to run
|
|
161
|
-
* `npm run refresh-sbom`. */
|
|
162
|
-
function sbomCurrencyChecker() {
|
|
163
|
-
return [
|
|
164
|
-
"const fs=require('fs');const path=require('path');",
|
|
165
|
-
"const root=" + JSON.stringify(ROOT) + ";",
|
|
166
|
-
"const sbomPath=path.join(root,'sbom.cdx.json');",
|
|
167
|
-
"if(!fs.existsSync(sbomPath)){console.error('sbom.cdx.json not found — run `npm run refresh-sbom`.');process.exit(1);}",
|
|
168
|
-
"const sbom=JSON.parse(fs.readFileSync(sbomPath,'utf8'));",
|
|
169
|
-
"const manifest=JSON.parse(fs.readFileSync(path.join(root,'manifest.json'),'utf8'));",
|
|
170
|
-
"const dataDir=path.join(root,'data');",
|
|
171
|
-
"const liveCatalogs=fs.readdirSync(dataDir).filter(f=>f.endsWith('.json')).length;",
|
|
172
|
-
"const liveSkills=Array.isArray(manifest.skills)?manifest.skills.length:0;",
|
|
173
|
-
"const props=Object.fromEntries((sbom.metadata&&sbom.metadata.properties||[]).map(p=>[p.name,p.value]));",
|
|
174
|
-
"const sbomCatalogs=Number(props['exceptd:catalog:count']);",
|
|
175
|
-
"const sbomSkills=Number(props['exceptd:skill:count']);",
|
|
176
|
-
"let drift=false;",
|
|
177
|
-
"if(sbomCatalogs!==liveCatalogs){console.error(`SBOM catalog count ${sbomCatalogs} != live ${liveCatalogs}`);drift=true;}",
|
|
178
|
-
"if(sbomSkills!==liveSkills){console.error(`SBOM skill count ${sbomSkills} != live ${liveSkills}`);drift=true;}",
|
|
179
|
-
"if(sbom.bomFormat!=='CycloneDX'||sbom.specVersion!=='1.6'){console.error('SBOM is not CycloneDX 1.6');drift=true;}",
|
|
180
|
-
"if(drift){console.error('Run `npm run refresh-sbom` to regenerate sbom.cdx.json.');process.exit(1);}",
|
|
181
|
-
"console.log(`SBOM current — ${sbomSkills} skills, ${sbomCatalogs} catalogs.`);",
|
|
182
|
-
].join("");
|
|
183
|
-
}
|
|
184
|
-
|
|
185
169
|
function runGate(gate) {
|
|
186
170
|
if (gate.requiresKeys) {
|
|
187
171
|
const pubKey = path.join(ROOT, "keys", "public.pem");
|
|
@@ -39,6 +39,9 @@ framework_gaps:
|
|
|
39
39
|
- OWASP-LLM-Top-10-2025-LLM01
|
|
40
40
|
- OWASP-LLM-Top-10-2025-LLM02
|
|
41
41
|
- SOC2-CC6-logical-access
|
|
42
|
+
- EU-AI-Act-Art-15
|
|
43
|
+
- UK-CAF-A1
|
|
44
|
+
- AU-Essential-8-App-Hardening
|
|
42
45
|
cwe_refs:
|
|
43
46
|
- CWE-1039
|
|
44
47
|
- CWE-1426
|
|
@@ -46,7 +49,10 @@ cwe_refs:
|
|
|
46
49
|
d3fend_refs:
|
|
47
50
|
- D3-IOPR
|
|
48
51
|
- D3-NTA
|
|
49
|
-
|
|
52
|
+
- D3-EAL
|
|
53
|
+
- D3-FAPA
|
|
54
|
+
- D3-CSPP
|
|
55
|
+
last_threat_review: "2026-05-13"
|
|
50
56
|
---
|
|
51
57
|
|
|
52
58
|
# AI Attack Surface Assessment
|
|
@@ -275,6 +281,28 @@ For each identified risk, declare the framework gap:
|
|
|
275
281
|
|
|
276
282
|
---
|
|
277
283
|
|
|
284
|
+
## Defensive Countermeasure Mapping
|
|
285
|
+
|
|
286
|
+
D3FEND v1.0+ references from `data/d3fend-catalog.json`. The AI attack surface enumerated above lands on five primary defensive techniques. Each entry below identifies which ATLAS TTP class the countermeasure addresses and the defense-in-depth layer it occupies.
|
|
287
|
+
|
|
288
|
+
| D3FEND ID | Name | Layer | Rationale (what it counters here) |
|
|
289
|
+
|---|---|---|---|
|
|
290
|
+
| `D3-IOPR` | Input/Output Profiling | SDK / application | SDK-level prompt and completion inspection — the foundational control for AML.T0051 (prompt injection), AML.T0096 (LLM C2), AML.T0054 (extraction). Without per-call I/O profiling, every detection step below is degraded. |
|
|
291
|
+
| `D3-CSPP` | Client-server Payload Profiling | LLM / MCP gateway | Gateway-layer inspection of tool-call args and prompt/completion bodies. Necessary when the AI client (mobile app, browser extension, IDE) cannot host `D3-IOPR` instrumentation in-process — the gateway becomes the only content-aware control. |
|
|
292
|
+
| `D3-EAL` | Executable Allowlisting | Endpoint / managed host | Restricts which AI-tool binaries (IDE assistants, browser extensions, MCP servers) can execute on managed endpoints. Direct counter to AML.T0010 (ML supply-chain compromise) for tooling shipped as native binaries; precondition for managed-endpoint clipboard- and code-completion controls. |
|
|
293
|
+
| `D3-FAPA` | File Access Pattern Analysis | Endpoint / data tier | Detects RAG-corpus and training-data abuse by pattern-matching the file-access shape of AML.T0018 (model poisoning at training time) and AML.T0020 (RAG retrieval abuse). Anchors the data-tier defence against poisoning that prompt-layer controls cannot see. |
|
|
294
|
+
| `D3-NTA` | Network Traffic Analysis | Network egress | Per-identity baseline of model-API and MCP-server egress. Catches the AML.T0017 capability-development pattern (PROMPTFLUX-style rapid querying) and the AML.T0096 covert-C2 destination shape when SDK instrumentation is partial or missing. |
|
|
295
|
+
|
|
296
|
+
**Defense-in-depth posture:** `D3-EAL` is the prerequisite endpoint layer (only sanctioned AI clients run); `D3-FAPA` is the data-tier layer (RAG and training corpora); `D3-IOPR` and `D3-CSPP` are the content-aware application and gateway layers; `D3-NTA` is the network-observability backstop. Skills that recommend a single layer alone are flagged as incomplete during Analysis Procedure Step 7.
|
|
297
|
+
|
|
298
|
+
**Least-privilege scope:** every AI principal (human developer, agent identity, MCP server) has the minimum set of model-API, MCP-tool, and RAG-corpus authorisations required for its sanctioned use case. `D3-EAL` allowlists are per-host-class (developer ≠ production ≠ CI); `D3-FAPA` access-pattern baselines are per-corpus-per-principal; `D3-IOPR` logs include the principal identity on every prompt/completion pair.
|
|
299
|
+
|
|
300
|
+
**Zero-trust posture:** every prompt is verified content-shape and origin-identity before downstream tool invocation; every RAG retrieval is clearance-checked at retrieval time (not just at index time); every MCP tool call has its args inspected at the gateway before reaching the tool. No "trusted prompt" exemption — AML.T0051 indirect prompt injection enters via documents and tool outputs, not just user prompts.
|
|
301
|
+
|
|
302
|
+
**AI-pipeline applicability (per AGENTS.md Hard Rule #9):** `D3-EAL` is not applicable to serverless inference endpoints (no executable to allowlist on the consumer side). The scoped alternative is `D3-CSPP` at the gateway plus signed-image attestation at the provider — the model-serving container is the executable surface, and its provenance is the prerequisite. `D3-FAPA` on ephemeral RAG indices degrades to per-query retrieval logging (`D3-IOPR`) plus index-build provenance signed at construction.
|
|
303
|
+
|
|
304
|
+
---
|
|
305
|
+
|
|
278
306
|
## Compliance Theater Check
|
|
279
307
|
|
|
280
308
|
> "Your security awareness training includes phishing detection. 82.6% of phishing emails now contain AI-generated content indistinguishable by grammar or style checks. Open your most recent phishing simulation report: what percentage of simulated phishes used AI-generated content? If zero, the simulation is testing resistance to 2021 phishing, not 2026 phishing. If your detection rule set has not been updated to reflect AI-generated content as the baseline, the control is theater for the threat it claims to address."
|
|
@@ -28,6 +28,11 @@ framework_gaps:
|
|
|
28
28
|
- NIST-800-53-SC-7
|
|
29
29
|
- ISO-27001-2022-A.8.16
|
|
30
30
|
- SOC2-CC7-anomaly-detection
|
|
31
|
+
- NIS2-Art21-incident-handling
|
|
32
|
+
- UK-CAF-C1
|
|
33
|
+
- AU-Essential-8-App-Hardening
|
|
34
|
+
cwe_refs:
|
|
35
|
+
- CWE-918
|
|
31
36
|
rfc_refs:
|
|
32
37
|
- RFC-8446
|
|
33
38
|
- RFC-9180
|
|
@@ -43,7 +48,7 @@ d3fend_refs:
|
|
|
43
48
|
- D3-NI
|
|
44
49
|
- D3-NTA
|
|
45
50
|
- D3-NTPM
|
|
46
|
-
last_threat_review: "2026-05-
|
|
51
|
+
last_threat_review: "2026-05-13"
|
|
47
52
|
---
|
|
48
53
|
|
|
49
54
|
# AI C2 Detection
|
|
@@ -390,6 +395,30 @@ For every identity flagged in Step 2, every prompt flagged in Step 3, every Sesa
|
|
|
390
395
|
|
|
391
396
|
---
|
|
392
397
|
|
|
398
|
+
## Defensive Countermeasure Mapping
|
|
399
|
+
|
|
400
|
+
D3FEND v1.0+ references from `data/d3fend-catalog.json`. Maps the SesameOp / PROMPTFLUX / PROMPTSTEAL detection surfaces to the defense-in-depth layer they actually live on.
|
|
401
|
+
|
|
402
|
+
| D3FEND ID | Name | Layer | Rationale (what it counters here) |
|
|
403
|
+
|---|---|---|---|
|
|
404
|
+
| `D3-NTA` | Network Traffic Analysis | Network egress | Establishes the AI-provider-egress baseline (per-identity volume, cadence, time-of-day) that SesameOp's persistent bursty-but-aperiodic shape violates. Primary detection control when SDK-level prompt logging is absent. |
|
|
405
|
+
| `D3-NTPM` | Network Traffic Policy Mapping | Network egress | Per-identity sanctioned-business-reason allowlist for AI provider domains. Implements the SC-7 real_requirement; without it, blanket domain allowlisting is theater. |
|
|
406
|
+
| `D3-CSPP` | Client-server Payload Profiling | Gateway / TLS-inspected proxy | The only layer that can observe prompt/completion content shape (entropy, base64 ratio, recognisable IOC tokens) without per-SDK instrumentation. Covers the QUIC / HTTP/3 case where boundary inspection sees only ciphertext. |
|
|
407
|
+
| `D3-IOPR` | Input/Output Profiling | SDK / application | SDK-level prompt and completion logging with identity binding. The single most-load-bearing control for AI C2 — every Step in the Analysis Procedure degrades to "structurally zero coverage" without it. |
|
|
408
|
+
| `D3-CA` | Connection Attempt Analysis | Network egress | Detects the AI-API connection from processes that have no business reason on this host type (e.g. a system service contacting `api.openai.com`). Cheap; deployable without TLS interception. |
|
|
409
|
+
| `D3-DA` | Domain Analysis | Network egress | Catches Oblivious HTTP (RFC 9458) relays and atypical AI-provider edge endpoints whose direct upstream is a sanctioned LLM provider — the SesameOp evasion shape when ECH is in play. |
|
|
410
|
+
| `D3-NI` | Network Isolation | Network segmentation | For non-developer host classes (databases, network gear, OT) where no AI API egress is ever sanctioned, hard-blocking the provider AS-paths removes the C2 channel entirely. |
|
|
411
|
+
|
|
412
|
+
**Defense-in-depth posture:** `D3-NTA` + `D3-CA` + `D3-NI` are the network layer; `D3-CSPP` is the gateway layer; `D3-IOPR` is the SDK layer; `D3-NTPM` is the policy layer that binds the other four to identity. No single layer is sufficient — SesameOp is invisible to network-only deployments without `D3-CSPP` or `D3-IOPR`, and `D3-IOPR` is invisible without `D3-NTPM` to give it the per-identity baseline against which Step 3 anomaly detection fires.
|
|
413
|
+
|
|
414
|
+
**Least-privilege scope:** `D3-NTPM` is implemented per-identity-per-business-reason — the developer using Cursor on a workstation is allowlisted for `api.anthropic.com`; the same developer's service account is not. `D3-IOPR` retention is scoped to the identities authorised to call AI APIs; prompts from unauthorised identities trigger Step 2 the moment they appear in the log, not after retention review.
|
|
415
|
+
|
|
416
|
+
**Zero-trust posture:** every prompt is logged and identity-bound regardless of source host trust level; `D3-CSPP` and `D3-IOPR` verify content shape on every call rather than sampling. The verification primitive at the gateway is entropy + identity + business-reason; at the SDK layer it is full prompt + identity + retention. No "trusted developer" exemption — PROMPTFLUX is delivered to developer workstations as readily as to production hosts.
|
|
417
|
+
|
|
418
|
+
**AI-pipeline applicability (per AGENTS.md Hard Rule #9):** `D3-IOPR` is the only control that survives serverless / ephemeral runtimes; per-host `D3-NTA` and `D3-CA` cannot baseline a host whose lifetime is shorter than the correlation window. The scoped alternative for ephemeral workloads is workload-identity-bound `D3-IOPR` correlated by IAM role / service-account identity rather than by host — preserving the PROMPTFLUX cadence shape and PROMPTSTEAL credential-access correlation across short-lived function invocations.
|
|
419
|
+
|
|
420
|
+
---
|
|
421
|
+
|
|
393
422
|
## Compliance Theater Check
|
|
394
423
|
|
|
395
424
|
> "Your SC-7 boundary-protection evidence shows AI provider domains — `api.openai.com`, `api.anthropic.com`, `generativelanguage.googleapis.com`, Azure OpenAI endpoints, Bedrock endpoints — on the egress allowlist, with NetFlow or Zeek records demonstrating that egress is monitored. Now answer two questions. First: for each AI provider domain on the allowlist, does the allowlist entry enumerate the specific sanctioned business reason and the identities or services entitled to use it, or is the entry a blanket allow for the domain? Second: do you have SDK-level prompt and completion logging, bound to identity, retained for at least 90 days, and forwarded to the SIEM, for every place AI APIs are called in production? If the allowlist is a blanket domain allow and SDK-level prompt logging is absent, the SC-7 control is theater for AI C2 — boundary inspection of an allowlisted domain cannot distinguish a developer prompt from a SesameOp-encoded C2 prompt, and you have no content-layer evidence to fall back on. SC-7 evidence is structurally incomplete for any org using AI APIs in production unless both an identity-bound business-reason allowlist and SDK-level prompt logging are in place. The control gap is recorded in `data/framework-control-gaps.json` under NIST-800-53-SC-7 — the real requirement names exactly these components."
|
|
@@ -32,6 +32,12 @@ This skill identifies the specific, testable conditions where audit-passing cont
|
|
|
32
32
|
|
|
33
33
|
---
|
|
34
34
|
|
|
35
|
+
## Frontmatter Scope
|
|
36
|
+
|
|
37
|
+
The `atlas_refs` and `attack_refs` arrays are intentionally empty. This skill is a meta-analysis that correlates findings *across* every other playbook and skill in the project — it has no native TTP attachment because its input is the existing TTP-to-control evidence base produced elsewhere. The `framework_gaps` array is populated because each theater pattern below points at specific named controls (FedRAMP-Rev5-Moderate, CMMC-2.0-Level-2, and the two ALL- gaps) whose mid-2026 inadequacy is the skill's primary subject. Defensive Countermeasure Mapping is not present as a body section because this skill produces a *coverage-gap* output, not a defensive-control prescription — the D3FEND mapping is the responsibility of the downstream skills the gap-findings route into.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
35
41
|
## Threat Context (mid-2026)
|
|
36
42
|
|
|
37
43
|
The defining mid-2026 reality is that an organization can pass a clean ISO 27001:2022, SOC 2 Type II, or PCI DSS 4.0 audit while remaining exposed to KEV-listed deterministic LPEs and zero-interaction RCEs. The contrast cases drive every theater pattern below:
|
|
@@ -29,7 +29,14 @@ framework_gaps:
|
|
|
29
29
|
- NIST-800-218-SSDF
|
|
30
30
|
- ISO-27001-2022-A.8.8
|
|
31
31
|
- SOC2-CC9-vendor-management
|
|
32
|
-
|
|
32
|
+
- NIS2-Art21-incident-handling
|
|
33
|
+
- UK-CAF-D1
|
|
34
|
+
- AU-Essential-8-Patch
|
|
35
|
+
rfc_refs:
|
|
36
|
+
- ISO-29147
|
|
37
|
+
- ISO-30111
|
|
38
|
+
- RFC-9116
|
|
39
|
+
- CSAF-2.0
|
|
33
40
|
cwe_refs:
|
|
34
41
|
- CWE-1357
|
|
35
42
|
d3fend_refs: []
|
|
@@ -208,7 +208,7 @@ Zero-trust-compliant defense maps to controls that verify per request. Implicit-
|
|
|
208
208
|
Example: "CVE — Linux kernel LPE. Canonical: CVE-2026-31431 (Copy Fail)."
|
|
209
209
|
|
|
210
210
|
## Offensive technique set (input to D3FEND query)
|
|
211
|
-
- <AML.
|
|
211
|
+
- <AML.T0001-or-similar / T0001-or-similar / CWE-<id> list, with one-line descriptions>
|
|
212
212
|
|
|
213
213
|
## Defensive-coverage map
|
|
214
214
|
| D3FEND ID | Name | Tactic (DiD layer) | Privilege scope | ZT posture | Deployed? | AI-pipeline applicable? | Framework controls partially mapped | Live-tunable? |
|
|
@@ -39,7 +39,15 @@ framework_gaps:
|
|
|
39
39
|
- NIST-800-53-SI-3
|
|
40
40
|
- ISO-27001-2022-A.8.16
|
|
41
41
|
- SOC2-CC7-anomaly-detection
|
|
42
|
-
|
|
42
|
+
- NIS2-Art21-incident-handling
|
|
43
|
+
- UK-CAF-C1
|
|
44
|
+
- AU-Essential-8-App-Hardening
|
|
45
|
+
rfc_refs:
|
|
46
|
+
- RFC-7489
|
|
47
|
+
- RFC-6376
|
|
48
|
+
- RFC-7208
|
|
49
|
+
- RFC-8616
|
|
50
|
+
- RFC-8461
|
|
43
51
|
cwe_refs: []
|
|
44
52
|
d3fend_refs:
|
|
45
53
|
- D3-NTA
|
|
@@ -30,6 +30,12 @@ A CVSS 9.8 vulnerability with no public exploit, no active exploitation, and a s
|
|
|
30
30
|
|
|
31
31
|
---
|
|
32
32
|
|
|
33
|
+
## Frontmatter Scope
|
|
34
|
+
|
|
35
|
+
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.
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
33
39
|
## Threat Context (mid-2026)
|
|
34
40
|
|
|
35
41
|
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.
|
|
@@ -38,6 +38,9 @@ framework_gaps:
|
|
|
38
38
|
- ISO-27001-2022-A.8.30
|
|
39
39
|
- SOC2-CC6-logical-access
|
|
40
40
|
- PSD2-RTS-SCA
|
|
41
|
+
- NIS2-Art21-incident-handling
|
|
42
|
+
- UK-CAF-B2
|
|
43
|
+
- AU-Essential-8-MFA
|
|
41
44
|
rfc_refs:
|
|
42
45
|
- RFC-7519
|
|
43
46
|
- RFC-8725
|
|
@@ -52,7 +55,9 @@ cwe_refs:
|
|
|
52
55
|
- CWE-798
|
|
53
56
|
- CWE-862
|
|
54
57
|
- CWE-863
|
|
55
|
-
d3fend_refs:
|
|
58
|
+
d3fend_refs:
|
|
59
|
+
- D3-MFA
|
|
60
|
+
- D3-CSPP
|
|
56
61
|
last_threat_review: "2026-05-11"
|
|
57
62
|
---
|
|
58
63
|
|
|
@@ -37,7 +37,13 @@ framework_gaps:
|
|
|
37
37
|
- NIST-800-53-AC-2
|
|
38
38
|
- ISO-27001-2022-A.8.16
|
|
39
39
|
- SOC2-CC7-anomaly-detection
|
|
40
|
-
|
|
40
|
+
- NIS2-Art21-incident-handling
|
|
41
|
+
- UK-CAF-D1
|
|
42
|
+
- AU-Essential-8-Backup
|
|
43
|
+
rfc_refs:
|
|
44
|
+
- RFC-6545
|
|
45
|
+
- RFC-6546
|
|
46
|
+
- RFC-7970
|
|
41
47
|
cwe_refs: []
|
|
42
48
|
d3fend_refs:
|
|
43
49
|
- D3-RPA
|
|
@@ -120,7 +126,7 @@ This skill is response-shaped — the TTPs below name the incident classes the p
|
|
|
120
126
|
|---|---|---|---|---|
|
|
121
127
|
| **T1486** | Data Encrypted for Impact | Ransomware | Identification: EDR file-encryption telemetry, share-mass-write pattern. Containment: network-segment isolation, identity revocation. Eradication: backup-validation-before-restore. Recovery: validated-restore + service-level verification. Lessons: feed to `zeroday-gap-learn` if initial access was a known CVE. | Detection coverage strong; identity-rotation maturity weak. NYDFS 24h ransom-payment clock and OFAC sanctions screening intersect at decision-to-pay. |
|
|
122
128
|
| **T1041** | Exfiltration Over C2 Channel | Data exfiltration via established C2 | Identification: DLP egress, anomalous outbound bandwidth, beaconing patterns. Containment: egress filtering, certificate-pinned proxy. Eradication: C2 artifact removal. Recovery: identity + secrets rotation. Lessons: detection-engineering gap analysis. | EDR coverage variable; encrypted exfiltration to legitimate services (Box, OneDrive, S3) often missed by signature-based DLP. |
|
|
123
|
-
| **T1567** | Exfiltration Over Web Service | Exfiltration via legitimate web/SaaS services including AI-API | Identification: web-egress to anomalous services or anomalous-volume to legitimate services; for AI-API channel pair with `ai-c2-detection`. Containment: egress block of identified channel, AI-API key revocation, MCP-server scope reduction. Eradication: identify exfiltrated dataset, follow data-incident sub-playbook. Recovery: re-key + re-issue access. | AI-API exfiltration (sub-technique T1567
|
|
129
|
+
| **T1567** | Exfiltration Over Web Service | Exfiltration via legitimate web/SaaS services including AI-API | Identification: web-egress to anomalous services or anomalous-volume to legitimate services; for AI-API channel pair with `ai-c2-detection`. Containment: egress block of identified channel, AI-API key revocation, MCP-server scope reduction. Eradication: identify exfiltrated dataset, follow data-incident sub-playbook. Recovery: re-key + re-issue access. | AI-API exfiltration (sub-technique T1567.<sub-technique-id> pattern; ATLAS overlap with AML.T0017) typically blends with legitimate traffic — see `ai-c2-detection` for content-layer detection. |
|
|
124
130
|
| **T1078** | Valid Accounts | Identity compromise as initial access | Identification: anomalous-sign-in UEBA, impossible-travel, MFA-fatigue patterns. Containment: account disable + session revocation + re-authentication for affected blast radius. Eradication: credential rotation, token revocation, OAuth-grant audit, AI-agent service-account rotation. Recovery: re-issue under zero-trust posture. Lessons: identity-control gap analysis. | Dominant initial-access vector mid-2026; coverage strong for human accounts, weak for AI-agent / service-account / OAuth-app identities. |
|
|
125
131
|
| **AML.T0096** | LLM API as C2 | AI-API as command-and-control channel (SesameOp pattern) | Identification: see `ai-c2-detection` skill — content-layer detection at the AI API egress boundary, prompt-and-response correlation, anomalous AI-API usage shape. Containment: AI-API egress block or proxy-mediated allowlist. Eradication: identify the agent or workload abusing the channel. Recovery: re-issue AI-API keys under scoped least-privilege. | Detection coverage near-absent in legacy SOC stacks; the AI traffic shape is novel and signatures do not exist for most enterprise SIEMs. |
|
|
126
132
|
| **AML.T0017** | ML Model Exfiltration | Model weights, training data, or system-prompt extraction | 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 data sensitivity. 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. |
|
|
@@ -26,6 +26,8 @@ framework_gaps:
|
|
|
26
26
|
- NIS2-Art21-patch-management
|
|
27
27
|
- NIST-800-53-SC-8
|
|
28
28
|
- CIS-Controls-v8-Control7
|
|
29
|
+
- UK-CAF-D1
|
|
30
|
+
- AU-Essential-8-Patch
|
|
29
31
|
rfc_refs:
|
|
30
32
|
- RFC-4301
|
|
31
33
|
- RFC-4303
|
|
@@ -41,7 +43,7 @@ d3fend_refs:
|
|
|
41
43
|
- D3-EAL
|
|
42
44
|
- D3-PHRA
|
|
43
45
|
- D3-PSEP
|
|
44
|
-
last_threat_review: "2026-05-
|
|
46
|
+
last_threat_review: "2026-05-13"
|
|
45
47
|
---
|
|
46
48
|
|
|
47
49
|
# Kernel LPE Triage
|
|
@@ -134,6 +136,24 @@ Note: ATLAS refs are intentionally empty in frontmatter — these are Linux kern
|
|
|
134
136
|
|
|
135
137
|
---
|
|
136
138
|
|
|
139
|
+
## Compliance Theater Check
|
|
140
|
+
|
|
141
|
+
Run this check for any org claiming patch-management compliance for kernel LPE class CVEs:
|
|
142
|
+
|
|
143
|
+
> "Your patch-management control (NIST SI-2 / ISO 27001:2022 A.8.8 / PCI-DSS v4 6.3.3 / NIS2 Art. 21(2)(g) / UK-CAF B4 / AU-ISM-1493) documents a 30-day remediation window for Critical/High CVEs. CVE-2026-31431 (Copy Fail) is CISA KEV listed with a public deterministic exploit requiring no privileges and KEV listing dated 2026-03-15. What is the actual time, on this fleet, between KEV listing and confirmed patch-or-mitigate for the affected kernel versions? If that interval exceeds 72 hours without live-patching as a deployed capability for the affected hosts, the patch-management control is theater for the KEV-class kernel-LPE threat surface."
|
|
144
|
+
|
|
145
|
+
**Theater fingerprints (any of these reduces the control to paper compliance):**
|
|
146
|
+
|
|
147
|
+
- Patch SLA is measured against advisory-publication date, not KEV-listing date — KEV listings are the operational signal that exploitation is happening now, and the SLA must trigger from there.
|
|
148
|
+
- The fleet inventory cannot answer "which hosts run the affected kernel version" within minutes — without live inventory, the SLA cannot be measured.
|
|
149
|
+
- Live-patching is described as "available" but no kernel was live-patched in the last 30 days — capability without operation is theater.
|
|
150
|
+
- The compensating-controls plan for hosts that cannot be rebooted within SLA is undocumented or relies on controls the CVE PoC bypasses (e.g. AppArmor profiles where the exploit runs as the legitimate user).
|
|
151
|
+
- "Patch management" includes only OS vendor patches, not third-party kernel modules or out-of-tree drivers — Dirty Frag RxRPC class lives in the network subsystem and is often patched on an asymmetric cadence.
|
|
152
|
+
|
|
153
|
+
**Real requirement:** patch SLA anchored to KEV listing date, fleet inventory live enough to answer "affected hosts" in under 5 minutes, live-patching deployed and exercised in the prior 30 days, written compensating-controls plan that survives the PoC test, third-party kernel modules in scope.
|
|
154
|
+
|
|
155
|
+
---
|
|
156
|
+
|
|
137
157
|
## Analysis Procedure
|
|
138
158
|
|
|
139
159
|
When a user invokes this skill, perform this assessment in order:
|
|
@@ -156,10 +176,10 @@ Ask for or assess:
|
|
|
156
176
|
Exposed if: kernel >= 4.14 AND kernel < [patched version for distribution]
|
|
157
177
|
Patched versions:
|
|
158
178
|
RHEL 8/9: kernel-4.18.0-553.xx.el8 / kernel-5.14.0-427.xx.el9
|
|
159
|
-
Ubuntu 22.04: linux-image-5.15.0-
|
|
160
|
-
Ubuntu 24.04: linux-image-6.8.0-xxx (check USN-
|
|
179
|
+
Ubuntu 22.04: linux-image-5.15.0-<patch-revision> (check USN-7<advisory-number>)
|
|
180
|
+
Ubuntu 24.04: linux-image-6.8.0-xxx (check USN-7<advisory-number>)
|
|
161
181
|
Debian 12: 6.1.xxx (check DSA-5xxx)
|
|
162
|
-
Amazon Linux 2: kernel 5.10.xxx (check ALAS-2026-
|
|
182
|
+
Amazon Linux 2: kernel 5.10.xxx (check ALAS-2026-<advisory-number>)
|
|
163
183
|
SUSE 15: kernel 5.14.xxx (check SUSE-SU-2026:xxx)
|
|
164
184
|
```
|
|
165
185
|
|
|
@@ -33,6 +33,9 @@ framework_gaps:
|
|
|
33
33
|
- OWASP-LLM-Top-10-2025-LLM06
|
|
34
34
|
- SOC2-CC9-vendor-management
|
|
35
35
|
- SWIFT-CSCF-v2026-1.1
|
|
36
|
+
- EU-AI-Act-Art-15
|
|
37
|
+
- UK-CAF-A1
|
|
38
|
+
- AU-Essential-8-App-Hardening
|
|
36
39
|
rfc_refs:
|
|
37
40
|
- RFC-6749
|
|
38
41
|
- RFC-7519
|
|
@@ -51,12 +54,13 @@ cwe_refs:
|
|
|
51
54
|
- CWE-918
|
|
52
55
|
- CWE-94
|
|
53
56
|
d3fend_refs:
|
|
57
|
+
- D3-CAA
|
|
54
58
|
- D3-CBAN
|
|
55
59
|
- D3-CSPP
|
|
56
60
|
- D3-EAL
|
|
57
61
|
- D3-EHB
|
|
58
62
|
- D3-MFA
|
|
59
|
-
last_threat_review: "2026-05-
|
|
63
|
+
last_threat_review: "2026-05-13"
|
|
60
64
|
---
|
|
61
65
|
|
|
62
66
|
# MCP Agent Trust Assessment
|
|
@@ -321,6 +325,29 @@ For ephemeral / serverless AI-pipeline contexts (per AGENTS.md rule #9): live SL
|
|
|
321
325
|
|
|
322
326
|
---
|
|
323
327
|
|
|
328
|
+
## Defensive Countermeasure Mapping
|
|
329
|
+
|
|
330
|
+
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.
|
|
331
|
+
|
|
332
|
+
| D3FEND ID | Name | Layer | Rationale (what it counters here) |
|
|
333
|
+
|---|---|---|---|
|
|
334
|
+
| `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. |
|
|
335
|
+
| `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. |
|
|
336
|
+
| `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. |
|
|
337
|
+
| `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. |
|
|
338
|
+
| `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. |
|
|
339
|
+
| `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. |
|
|
340
|
+
|
|
341
|
+
**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.
|
|
342
|
+
|
|
343
|
+
**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.
|
|
344
|
+
|
|
345
|
+
**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.
|
|
346
|
+
|
|
347
|
+
**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."
|
|
348
|
+
|
|
349
|
+
---
|
|
350
|
+
|
|
324
351
|
## Compliance Theater Check
|
|
325
352
|
|
|
326
353
|
> "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."
|
|
@@ -38,6 +38,12 @@ This skill generates exception templates for architectural realities that curren
|
|
|
38
38
|
|
|
39
39
|
---
|
|
40
40
|
|
|
41
|
+
## Frontmatter Scope
|
|
42
|
+
|
|
43
|
+
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.
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
41
47
|
## Threat Context (mid-2026)
|
|
42
48
|
|
|
43
49
|
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.
|
|
@@ -25,14 +25,19 @@ framework_gaps:
|
|
|
25
25
|
- NIST-800-53-SI-12
|
|
26
26
|
- NIST-AI-RMF-MEASURE-2.5
|
|
27
27
|
- OWASP-LLM-Top-10-2025-LLM08
|
|
28
|
+
- EU-AI-Act-Art-15
|
|
29
|
+
- UK-CAF-B2
|
|
30
|
+
- AU-Essential-8-App-Hardening
|
|
28
31
|
cwe_refs:
|
|
29
32
|
- CWE-1395
|
|
30
33
|
- CWE-1426
|
|
31
34
|
d3fend_refs:
|
|
32
35
|
- D3-CSPP
|
|
36
|
+
- D3-FCR
|
|
37
|
+
- D3-FAPA
|
|
33
38
|
- D3-IOPR
|
|
34
39
|
- D3-NTA
|
|
35
|
-
last_threat_review: "2026-05-
|
|
40
|
+
last_threat_review: "2026-05-13"
|
|
36
41
|
---
|
|
37
42
|
|
|
38
43
|
# RAG Pipeline Security Assessment
|
|
@@ -168,6 +173,8 @@ This attack requires:
|
|
|
168
173
|
| 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. |
|
|
169
174
|
| SOC 2 CC6 | Logical and Physical Access | IAM for identified systems. Vector stores as inference surfaces don't map to traditional access control models. |
|
|
170
175
|
| 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. |
|
|
176
|
+
| 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. |
|
|
177
|
+
| 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. |
|
|
171
178
|
|
|
172
179
|
---
|
|
173
180
|
|
|
@@ -289,6 +296,28 @@ For ephemeral / serverless RAG pipelines (per AGENTS.md rule #9): embedding-dist
|
|
|
289
296
|
|
|
290
297
|
---
|
|
291
298
|
|
|
299
|
+
## Defensive Countermeasure Mapping
|
|
300
|
+
|
|
301
|
+
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.
|
|
302
|
+
|
|
303
|
+
| D3FEND ID | Name | Layer | Rationale (what it counters here) |
|
|
304
|
+
|---|---|---|---|
|
|
305
|
+
| `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. |
|
|
306
|
+
| `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. |
|
|
307
|
+
| `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. |
|
|
308
|
+
| `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. |
|
|
309
|
+
| `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. |
|
|
310
|
+
|
|
311
|
+
**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.
|
|
312
|
+
|
|
313
|
+
**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.
|
|
314
|
+
|
|
315
|
+
**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.
|
|
316
|
+
|
|
317
|
+
**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.
|
|
318
|
+
|
|
319
|
+
---
|
|
320
|
+
|
|
292
321
|
## Compliance Theater Check
|
|
293
322
|
|
|
294
323
|
> "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."
|
|
@@ -32,6 +32,12 @@ This skill is the front door to the exceptd library. Operators do not always arr
|
|
|
32
32
|
|
|
33
33
|
---
|
|
34
34
|
|
|
35
|
+
## Frontmatter Scope
|
|
36
|
+
|
|
37
|
+
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.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
35
41
|
## Threat Context (mid-2026)
|
|
36
42
|
|
|
37
43
|
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.
|