@blamejs/exceptd-skills 0.12.41 → 0.13.0

package/scripts/predeploy.js

@@ -166,22 +166,16 @@ const GATES = [
     ciJobName: "Diff coverage",
   },
   {
-    // v0.12.12 — Validate every playbook in data/playbooks/ against the
-    // JSON schema + cross-playbook + cross-catalog references. Runs as
-    // informational (warnings, not failures) for v0.12.12 so the patch-
-    // class release can land without retroactively breaking schema-drift
-    // cases that operators have not yet reconciled. v0.13.0 will flip
-    // `informational: false`.
-    name: "Validate playbooks (schema + cross-refs, informational)",
+    // Validate every playbook in data/playbooks/ against the JSON schema
+    // + cross-playbook + cross-catalog references. v0.12.12 first wired
+    // this as informational so the patch-class release could land without
+    // retroactively breaking schema-drift cases; v0.13.0 flips it to
+    // required because the 20-playbook canonical set (including the 4
+    // v0.13.0 additions) all validate cleanly.
+    name: "Validate playbooks (schema + cross-refs)",
     command: process.execPath,
     args: [path.join(ROOT, "lib", "validate-playbooks.js")],
     ciJobName: "Validate playbooks",
-    informational: true,
-    // cap informational acceptance at exit 1 so a CRASH (137 OOM,
-    // 139 SIGSEGV, 134 SIGABRT, etc.) surfaces as a real failure instead of
-    // being absorbed under the informational bucket. Matches the
-    // forward-watch gate (line ~111) which already pins the same ceiling.
-    informationalMaxExitCode: 1,
   },
 ];
 

package/scripts/refresh-reverse-refs.js

@@ -113,6 +113,26 @@ const CATALOGS = [
     source: 'cve.entries',
     entryKey: null, // value is the iterating CVE id
   },
+  // v0.13.0: ATLAS / ATT&CK back-edge — every ATLAS TTP and ATT&CK
+  // technique gets a `cve_refs` array carrying the CVE ids that cite it.
+  // Pre-v0.13 these catalogs had only forward refs (CVE → TTP); operators
+  // reading an ATLAS / ATT&CK entry could not see which CVEs cite it
+  // without grepping the whole catalog. New back-edges close the
+  // asymmetric-edges cluster the cycle 20 audit B flagged.
+  {
+    file: 'atlas-ttps.json',
+    forwardField: 'atlas_refs',
+    reverseField: 'cve_refs',
+    source: 'cve.entries',
+    entryKey: null,
+  },
+  {
+    file: 'attack-techniques.json',
+    forwardField: 'attack_refs',
+    reverseField: 'cve_refs',
+    source: 'cve.entries',
+    entryKey: null,
+  },
 ];
 
 function readJson(p) {
@@ -223,6 +243,71 @@ function rebuildCatalog(cfg, manifest, cveCatalog) {
   };
 }
 
+/**
+ * v0.13.0: playbook `fed_by` reverse direction. Every playbook declares
+ * `feeds_into[]` listing playbook ids it chains TO; `fed_by[]` is the
+ * symmetric "which playbooks chain into me." Pre-v0.13 operators reading
+ * a playbook couldn't see what fed it without grepping every other
+ * playbook's feeds_into. The reverse field lives on the playbook's
+ * top-level under `_meta.fed_by` (paired with the existing _meta.feeds_into
+ * for shape symmetry).
+ */
+function rebuildPlaybookReverse() {
+  const playbooksDir = path.join(DATA_DIR, 'playbooks');
+  if (!fs.existsSync(playbooksDir)) return { file: 'playbooks/*.json', source: 'playbook.feeds_into', reverseField: 'fed_by', changed: 0, added: 0, removed: 0, unchanged: 0, orphans: [] };
+  const files = fs.readdirSync(playbooksDir).filter((n) => n.endsWith('.json'));
+  const playbookEntries = [];
+  for (const f of files) {
+    const filePath = path.join(playbooksDir, f);
+    let data;
+    try { data = JSON.parse(fs.readFileSync(filePath, 'utf8')); }
+    catch (e) { continue; }
+    if (!data || !data._meta || !data._meta.id) continue;
+    playbookEntries.push({ file: f, filePath, data });
+  }
+  // Build reverse index: target-id -> Set<source-id>
+  // feeds_into entries are objects with `playbook_id` + `condition`.
+  // The fed_by reverse is a simple array of source playbook ids (the
+  // condition is per-edge; preserved on feeds_into, not duplicated on
+  // fed_by — operators read fed_by to find candidates, then look at the
+  // source playbook's feeds_into for the gating condition).
+  const index = new Map();
+  for (const { data } of playbookEntries) {
+    const meta = data._meta;
+    const targets = Array.isArray(meta.feeds_into) ? meta.feeds_into : [];
+    for (const t of targets) {
+      const targetId = (t && typeof t === 'object') ? t.playbook_id : t;
+      if (!targetId || typeof targetId !== 'string') continue;
+      if (!index.has(targetId)) index.set(targetId, new Set());
+      index.get(targetId).add(meta.id);
+    }
+  }
+  let changed = 0, added = 0, removed = 0, unchanged = 0;
+  const orphans = [];
+  const knownIds = new Set(playbookEntries.map((e) => e.data._meta.id));
+  for (const { filePath, data } of playbookEntries) {
+    const meta = data._meta;
+    const before = Array.isArray(meta.fed_by) ? [...meta.fed_by] : [];
+    const computed = index.has(meta.id) ? Array.from(index.get(meta.id)).sort() : [];
+    const beforeSet = new Set(before);
+    const computedSet = new Set(computed);
+    const sameContent = before.length === computed.length && before.every((x, i) => x === computed[i]);
+    if (!sameContent) {
+      meta.fed_by = computed;
+      fs.writeFileSync(filePath, JSON.stringify(data, null, 2) + '\n', 'utf8');
+      changed += 1;
+      for (const s of computed) if (!beforeSet.has(s)) added += 1;
+      for (const s of before) if (!computedSet.has(s)) removed += 1;
+    } else {
+      unchanged += 1;
+    }
+  }
+  for (const targetId of index.keys()) {
+    if (!knownIds.has(targetId)) orphans.push(targetId);
+  }
+  return { file: 'playbooks/*.json', source: 'playbook.feeds_into', reverseField: 'fed_by', changed, added, removed, unchanged, orphans };
+}
+
 function main() {
   const manifest = readJson(MANIFEST_PATH);
   const cveCatalog = readJson(CVE_CATALOG_PATH);
@@ -230,6 +315,7 @@ function main() {
   for (const cfg of CATALOGS) {
     results.push(rebuildCatalog(cfg, manifest, cveCatalog));
   }
+  results.push(rebuildPlaybookReverse());
   for (const r of results) {
     process.stdout.write(
       `${r.file} (${r.source || 'skills'} → ${r.reverseField}): ${r.changed} entries changed ` +

package/scripts/refresh-sbom.js

@@ -249,7 +249,6 @@ function buildSbom() {
   const pkg = readJson(PACKAGE_PATH);
   const manifest = readJson(MANIFEST_PATH);
   const catalogs = countDataCatalogs(DATA_DIR);
-  const timestamp = new Date().toISOString();
   const skillCount = Array.isArray(manifest.skills) ? manifest.skills.length : 0;
   const catalogCount = catalogs.length;
   const vendorProv = loadVendorProvenance();
@@ -263,9 +262,27 @@ function buildSbom() {
     a['bom-ref'] < b['bom-ref'] ? -1 : a['bom-ref'] > b['bom-ref'] ? 1 : 0,
   );
 
-  const serialNumber =
-    'urn:uuid:' +
-    uuidV4FromSeed(`${pkg.name}@${pkg.version}@${timestamp}`);
+  // v0.13.0: derive both serialNumber and metadata.timestamp from the
+  // bundle content hash, not wall-clock. Pre-v0.13 every refresh produced
+  // a new UUID + timestamp even when the bundle content was byte-identical,
+  // so the SBOM-currency gate produced noisy diffs and the predeploy
+  // comparison could not rely on stable byte-identity. The comment at the
+  // top of this file says "stable across observers" — the implementation
+  // contradicted it. Now: identical content → identical SBOM.
+  //
+  // The synthetic timestamp uses the bundle SHA folded into a date string
+  // anchored at the Unix epoch + a deterministic offset; this is NOT a
+  // real audit timestamp (the `metadata.lifecycles[]` block carries the
+  // intended-lifecycle phase for that). Operators wanting the wall-clock
+  // time of a refresh should read the file's mtime or refresh-report.json.
+  const seed = `${pkg.name}@${pkg.version}@${bundleSha}`;
+  const serialNumber = 'urn:uuid:' + uuidV4FromSeed(seed);
+  // Synthetic ISO timestamp derived from the seed — preserves the
+  // CycloneDX 1.6 metadata.timestamp schema requirement (must be an
+  // ISO-8601 string) while remaining content-stable.
+  const seedHash = crypto.createHash('sha256').update(seed).digest();
+  const offsetSeconds = seedHash.readUInt32BE(0); // deterministic offset
+  const timestamp = new Date(Date.UTC(2026, 0, 1) + offsetSeconds * 1000).toISOString();
 
   const dataflowInput = catalogs
     .map((c) => `data/${c}`)

package/skills/age-gates-child-safety/skill.md

@@ -24,13 +24,9 @@ triggers:
   - ofcom
   - esafety
 data_deps:
-  - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
-  - global-frameworks.json
   - cwe-catalog.json
   - d3fend-catalog.json
-  - dlp-controls.json
+  - framework-control-gaps.json
 atlas_refs: []
 attack_refs:
   - T1078

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

@@ -13,9 +13,7 @@ triggers:
   - promptsteal
   - promptflux
 data_deps:
-  - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
+  - d3fend-catalog.json
 atlas_refs:
   - AML.T0043
   - AML.T0051
@@ -61,7 +59,7 @@ forward_watch:
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — Chroma vector DB CWE-190 + CWE-362 chain by haehae; impacts RAG vector store integrity; track patch and downstream RAG advisory
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — NVIDIA Megatron Bridge overly permissive allowed list by Satoki Tsuji; AI training-stack supply-chain exposure; track patch and SBOM advisory
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — NVIDIA Megatron Bridge path traversal by haehae; AI training-stack file-system trust boundary; track patch and SBOM advisory
-last_threat_review: "2026-05-15"
+last_threat_review: "2026-05-17"
 ---
 
 # AI Attack Surface Assessment
@@ -160,6 +158,15 @@ AI-assisted reconnaissance is observed at 36,000 probes per second per campaign.
 | PCI DSS 4.0 | 6.4.1 | Web application protection (WAF). WAFs operate on HTTP request/response patterns. They have no semantic understanding of prompt injection embedded in JSON `message` fields. |
 | MITRE ATT&CK | Enterprise | Does not include prompt injection as a technique. AI-as-C2 (SesameOp) is not in ATT&CK as of mid-2026. ATLAS v5.4.0 covers these but is not part of SOC detection engineering programs that are ATT&CK-mapped. |
 | NIST AI RMF | MEASURE 2.5 | Measure AI risks during operation. Provides a framework for thinking about AI risk but no specific controls for prompt injection, MCP supply chain, or AI-as-C2. |
+| EU NIS2 | Art. 21(2)(d) (supply-chain security) + Art. 21(2)(e) (security in acquisition, development and maintenance) | "Appropriate and proportionate" supply-chain language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI) do not enumerate MCP servers or LLM API providers as in-scope supply-chain components. An essential entity can meet NIS2 supplier-management obligations with traditional SaaS vendor reviews while having zero coverage of AI-assistant tool ecosystems. |
+| EU DORA | Art. 8 (ICT asset management) + Art. 28 (ICT third-party register) + Art. 30 (key contractual provisions) | Financial-entity ICT third-party language scoped to traditional ICT providers. LLM API providers acting as data processors for prompt content and developer-environment MCP servers are not enumerated as ICT third-party service providers. ESAs RTS on subcontracting (JC 2024/53) is silent on AI/ML SaaS dependency classes. |
+| EU AI Act (Regulation 2024/1689) | Art. 15 (accuracy, robustness, cybersecurity) for high-risk AI + Art. 9 (risk management) | High-risk AI cybersecurity language refers to "state of the art" without naming prompt injection, MCP supply chain, or AI-as-C2 as scoped attack classes. Conformity assessments (Annex VI/VII) accept documentation completeness; harmonized standards (CEN-CENELEC JTC 21) through 2026-2027 may operationalize this. |
+| UK NCSC CAF | Principle A4 (Supply Chain), B2 (Identity and Access Control), B4 (System Security), C1 (Security Monitoring) | Outcome-based language. NCSC's 2024 guidance on securing AI systems and the DSIT AI Cyber Code of Practice (2025) name the attack classes at the principle level (prompt injection, model supply chain, monitoring), but the CAF outcome statements are unchanged. An organisation achieves CAF outcomes at Achieved level with zero MCP-trust controls and zero prompt-injection detection. |
+| UK DSIT AI Cyber Code of Practice (2025) | 13 principles for secure AI development and deployment | Principles-based. Names training-data integrity, model-deployment security, monitoring, and supply chain — but as principles, not testable controls. No technical floor for prompt-injection defence, MCP allowlisting, or AI-as-C2 detection. |
+| AU ASD Essential 8 | Strategy: Application Control + User Application Hardening + Restrict Administrative Privileges | Application Control (allowlisting) covers what runs locally; it does not cover AI-assistant tool-use chains where the AI agent dynamically composes the executed action. None of the eight strategies address prompt injection, model supply chain, or LLM-as-C2 channel. |
+| AU ASD ISM | ISM-1808 (cloud consumer responsibilities) + ISM-1728 (supply chain risk) + ISM-1228 (event monitoring) | ISM-1728 supply-chain control is scoped to traditional vendor classes; LLM APIs and MCP servers fall outside enumerated supply-chain categories. ISM-1228 event-log monitoring assumes signature-or-rule detection over known indicators — AI API egress as C2 and prompt-injection-coerced actions produce no traditional indicator. |
+| AU Voluntary AI Safety Standard (10 guardrails, 2024) | Guardrails 5 (test and monitor), 6 (transparency), 8 (record-keeping) | Voluntary, principles-language. Operationally identical to the UK DSIT AI Cyber Code lag — names the right concerns at the principle layer without testable controls for prompt injection, MCP trust, or AI-as-C2 detection. |
+| AU APRA CPS 234 | Para 27 (information security capability proportional to vulnerabilities and threats) + APRA CPG 235 (managing data risk) | "Proportional" capability language. APRA-regulated entities deploying AI assistants meet CPS 234 attestation with traditional information-security capability; AI-specific attack surface is not an examined capability class. APRA Information Paper on AI (2024) names the risks at the supervisory level without altering CPS 234 obligations. |
 
 ---
 

package/skills/ai-c2-detection/skill.md

@@ -13,9 +13,10 @@ triggers:
   - covert channel ai
   - aml.t0096
 data_deps:
-  - atlas-ttps.json
   - cve-catalog.json
+  - d3fend-catalog.json
   - framework-control-gaps.json
+  - rfc-references.json
 atlas_refs:
   - AML.T0096
   - AML.T0017
@@ -48,7 +49,7 @@ d3fend_refs:
   - D3-NI
   - D3-NTA
   - D3-NTPM
-last_threat_review: "2026-05-15"
+last_threat_review: "2026-05-17"
 ---
 
 # AI C2 Detection
@@ -153,6 +154,14 @@ PROMPTSTEAL uses LLMs as live intelligence analysts for exfiltration targeting.
 | ISO 27001:2022 A.8.16 | Monitoring Activities | Monitoring of systems, networks, and applications. No guidance for AI API behavioral baseline, no mention of AI traffic as a monitoring concern. |
 | SOC 2 CC7 | System Operations (Anomaly Detection) | Detect and respond to security events. CC7 implementations baseline network traffic and system events. AI API calls are typically in the same anomaly detection blind spot as other SaaS traffic. |
 | ATT&CK T1071 | Application Layer Protocol | ATT&CK documents C2 over application protocols. AI API as C2 fits the technique but detection guidance doesn't address legitimate-endpoint C2 specifically. |
+| EU NIS2 | Art. 21(2)(b) (incident handling) + Art. 21(2)(g) (network and information systems security including monitoring) | "Appropriate and proportionate" monitoring language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI, ENISA) do not enumerate AI-API egress baselining as an expected monitoring control. An essential entity meets the NIS2 monitoring obligation with traditional SIEM coverage while leaving AI-as-C2 entirely undetected. |
+| EU DORA | Art. 10 (detection) + Art. 17 (ICT-related incident management) | Detection obligation for financial entities. RTS on threat-led penetration testing (TIBER-EU JC 2024/40) does not include AI-as-C2 scenarios in the TT&P inventory as of mid-2026. CBEST / iCAST scenario libraries lag by 12-18 months. |
+| EU AI Act (Regulation 2024/1689) | Art. 15 (cybersecurity for high-risk AI systems) + Art. 72 (post-market monitoring) | High-risk AI cybersecurity language addresses adversarial robustness and integrity of the AI system itself. AI APIs being abused as a C2 channel by non-AI malware is outside the scoped attack surface — providers do not log per-prompt to detect attacker use, and operators have no mandated detection control for legitimate-endpoint C2. |
+| UK NCSC CAF | Principle C1 (Security Monitoring) + Principle C2 (Proactive Security Event Discovery) | Outcome-based monitoring language. NCSC's 2024 guidance on monitoring egress to SaaS APIs recommends behavioural baselining but the CAF outcome statements are satisfied by traditional endpoint and network monitoring. An organisation can meet C1 / C2 at Achieved level with zero AI-API egress baselining. |
+| UK NCSC Cyber Assessment Framework — sectoral profiles (Telecoms Security Code of Practice, Energy CAF profile) | Sector-specific monitoring obligations | Sectoral CAF profiles inherit C1/C2 outcomes; none enumerate AI API egress as an in-scope monitored channel. Telecoms operators meeting the TSA 2021 Code monitoring obligations have the same blind spot. |
+| AU ASD Essential 8 | Strategy: Application Control + User Application Hardening | Application Control (allowlisting) covers what runs locally; it does not cover what allowed applications connect to. A whitelisted browser or IDE making AI API calls passes Application Control while operating as a C2 channel. Essential 8 does not include an egress-control strategy. |
+| AU ASD ISM | ISM-1228 (event log monitoring) + ISM-0859 (network access controls) + ISM-1729 (data loss prevention) | Event-log monitoring assumes signature-or-rule detection over known malicious indicators. ISM-1729 DLP addresses outbound sensitive-data flows but is content-pattern based — AI-API egress with attacker-controlled prompts is data-flowing-to-a-trusted-vendor from the DLP perspective. |
+| AU APRA CPS 234 | Para 27(b) (capability to detect and respond to information security incidents in a timely manner) | "Timely" detection capability. APRA CPS 234 attestations are satisfied by SIEM/SOC capability over traditional indicators. AI-as-C2 detection capability is not a CPS 234 examined control. |
 
 ---
 

package/skills/ai-risk-management/skill.md

@@ -18,10 +18,12 @@ triggers:
   - ai management system
 data_deps:
   - atlas-ttps.json
-  - framework-control-gaps.json
-  - global-frameworks.json
+  - cve-catalog.json
   - cwe-catalog.json
   - d3fend-catalog.json
+  - exploit-availability.json
+  - framework-control-gaps.json
+  - global-frameworks.json
   - zeroday-lessons.json
 atlas_refs:
   - AML.T0051

package/skills/api-security/skill.md

@@ -17,13 +17,7 @@ triggers:
   - ai api security
   - mcp transport
   - openapi security
-data_deps:
-  - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
-  - cwe-catalog.json
-  - d3fend-catalog.json
-  - rfc-references.json
+data_deps: []
 atlas_refs:
   - AML.T0096
   - AML.T0017
@@ -67,7 +61,7 @@ forward_watch:
   - NGINX Rift CVE-2026-42945 (disclosed 2026-05-13, source depthfirst) — KEV-watch predicted CISA KEV listing by 2026-05-29; track for active-exploitation confirmation and patch advisory affecting API gateway / reverse-proxy deployments
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — LiteLLM 3-bug SSRF + Code Injection chain by k3vg3n; LLM-proxy API surface; track upstream patch and CVE assignments
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — LiteLLM full SSRF + Code Injection by Out Of Bounds (Byung Young Yi); duplicate-class with the k3vg3n entry; track unified patch advisory
-last_threat_review: "2026-05-11"
+last_threat_review: "2026-05-17"
 ---
 
 # API Security Assessment
@@ -118,6 +112,11 @@ APIs are now the integration substrate of every non-trivial system. The mid-2026
 | BR Open Finance (Bacen) | FAPI 2.0 derivative | Banking-API auth surface only. |
 | IN UPI / Account Aggregator (NPCI / RBI) | Payments + AA security framework | Sector-specific payment-API + consent-API surface. AI-API egress out of scope. |
 | NYDFS 23 NYCRR 500 | §500.5 penetration testing | APIs are in scope for the annual pen test where they expose covered data. "Annual" is structurally inadequate against agentic API-exploit timelines. |
+| UK NCSC CAF | Principle B2 (Identity and Access Control), B4 (System Security), C1 (Security Monitoring) | Outcome-based assessment. CAF outcomes are silent on BOLA / BFLA / BOPLA as testable surfaces and silent on AI-API egress baselining. An organisation can achieve CAF outcomes at Achieved level with zero per-object authorisation testing and zero AI-API consumer monitoring. NCSC API Security Guidance (2024) recommends per-object scoping but is not a CAF outcome statement. |
+| UK FCA / PRA SS1/21 (Operational Resilience) + CBEST | Important Business Service tolerance + threat-led pen testing | CBEST scenario libraries lag adversary capability 12-18 months and rarely include BOLA/BFLA-by-AI-agent or AI-API-as-C2 test cases. An FCA-attested operational-resilience programme can be "compliant" with zero exercised coverage of agentic API exploitation. |
+| AU ASD Essential 8 | Strategy: Restrict Administrative Privileges + Application Control + MFA | None of the eight strategies address API-level authorisation (per-object scoping, per-field scoping) or AI-API egress monitoring. Essential 8 ML3 attestation does not bind any API security control surface. |
+| AU ASD ISM | ISM-1228 (event log monitoring) + ISM-1546 (MFA on privileged access) + ISM-1808 (cloud consumer responsibilities) | Event-log monitoring assumes traditional indicators; BOLA / BFLA exploitation produces authenticated, authorised log entries with attacker-supplied object IDs. ISM-1808 cloud-consumer language does not address AI-API consumer scope. |
+| AU APRA CPS 234 + CPS 230 | Para 27 (information security capability) + CPS 230 ICT-service-provider obligations | "Proportional capability" language. APRA-regulated entities meet CPS 234 attestation with traditional API gateway + WAF posture; per-object authorisation testing depth and AI-API consumer monitoring are not examined capability classes. CPS 230 third-party-arrangements obligations do not enumerate AI-API providers as in-scope material service providers. |
 
 ---
 

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

@@ -16,10 +16,10 @@ triggers:
   - asm
 data_deps:
   - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
   - cwe-catalog.json
   - d3fend-catalog.json
+  - exploit-availability.json
+  - framework-control-gaps.json
 atlas_refs:
   - AML.T0043
   - AML.T0051

package/skills/cloud-iam-incident/skill.md

@@ -23,12 +23,8 @@ triggers:
   - access key public repo
 data_deps:
   - cve-catalog.json
-  - atlas-ttps.json
-  - attack-techniques.json
-  - framework-control-gaps.json
-  - global-frameworks.json
-  - cwe-catalog.json
   - d3fend-catalog.json
+  - framework-control-gaps.json
 atlas_refs:
   - AML.T0051
 attack_refs:

package/skills/cloud-security/skill.md

@@ -20,11 +20,7 @@ triggers:
   - falco
 data_deps:
   - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
-  - cwe-catalog.json
   - d3fend-catalog.json
-  - rfc-references.json
 atlas_refs:
   - AML.T0010
   - AML.T0017

package/skills/compliance-theater/skill.md

@@ -11,7 +11,7 @@ triggers:
   - checkbox security
   - audit theater
 data_deps:
-  - framework-control-gaps.json
+  - atlas-ttps.json
   - cve-catalog.json
   - exploit-availability.json
 atlas_refs: []
@@ -21,7 +21,7 @@ framework_gaps:
   - ALL-PROMPT-INJECTION-ACCESS-CONTROL
   - FedRAMP-Rev5-Moderate
   - CMMC-2.0-Level-2
-last_threat_review: "2026-05-14"
+last_threat_review: "2026-05-17"
 ---
 
 # Compliance Theater Detection
@@ -65,6 +65,14 @@ Compliance theater is the operational shadow of framework lag. Per-framework lag
 | NIST 800-53 | AT-2 (Security Awareness Training) | Drafted against human-template phishing. 82.6% of phishing emails now contain AI-generated content. Grammar/style heuristics are no longer reliable detectors. A < 5% click rate on human-generated simulations says nothing about resistance to AI-generated highly personalized spear-phishing. |
 | US FedRAMP | Rev 5 Moderate baseline | Authorization-as-evidence pattern. A current ATO certifies that the CSP's control implementation was assessed against the Rev 5 Moderate baseline at a point in time. It does not certify that the CSP has any control over MCP servers running in tenant developer environments, prompt-injection attack surface in AI features, or AI-API providers used downstream. The Authority To Operate is treated by procurement as a security guarantee — Pattern 6 (Vendor/Third-Party Risk Theater) recurs at the federal-cloud layer. |
 | US DoD | CMMC 2.0 Level 2 (110 NIST 800-171 practices) | Certification-as-evidence pattern. A Level 2 certificate attests to assessor-verified implementation of the 110 practices at the time of assessment. It does not cover AI coding-assistant supply chain, MCP server trust on engineering workstations developing CUI-touching software, or model-update change control. The same Pattern 5 (Change Management Theater) and Pattern 6 (Vendor Management Theater) patterns recur with sharper consequences because CMMC gates DoD contract eligibility. |
+| EU NIS2 | Art. 21(2)(c) (vulnerability handling and disclosure) + Art. 21(2)(d) (supply-chain security) | "Appropriate and proportionate" measures language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI, CNIL, ENISA technical guidance) typically pin remediation to CVSS bands with month-scale SLAs. NIS2 does not operationalize CISA-KEV-class urgency, AI-discovery weighting, or MCP/LLM third-party scope. An essential entity can be NIS2-compliant on paper while leaving CVE-2026-31431 and CVE-2026-30615 class exposures unaddressed inside the regulator's expected remediation window. |
+| EU DORA | Art. 6 (ICT risk-management framework) + Art. 28 (ICT third-party risk) | Financial-entity ICT risk language scoped to traditional ICT providers and cloud outsourcing. Does not enumerate LLM API providers as ICT third-party service providers requiring the Art. 28 register, contractual safeguards, and exit-strategy obligations. ESAs RTS on subcontracting (JC 2024/53) is silent on MCP servers running inside trading-desk developer environments. Pattern 6 (Vendor Management Theater) recurs cleanly inside a DORA-compliant TPRM programme. |
+| EU AI Act (Regulation 2024/1689) | Art. 9 (risk management) + Art. 15 (accuracy, robustness, cybersecurity) for high-risk AI | High-risk AI cybersecurity language refers to "state of the art" without naming prompt injection, model-update change control, or MCP supply chain as scoped attack classes. Conformity assessments under Annex VI/VII can pass on documentation completeness while leaving Pattern 3 (Access Control Theater) and Pattern 5 (Change Management Theater) wide open. Implementing acts and harmonized standards (CEN-CENELEC JTC 21) through 2026-2027 may tighten this. |
+| UK NCSC CAF | Principle A2 (Risk Management), B2 (Identity and Access Control), B4 (System Security), D1 (Response and Recovery) | Outcome-based assessment language ("Risks are identified, assessed and understood"; "Access is appropriately controlled"). Outcome language permits theater because the auditor verifies that an outcome statement exists, not that the underlying control disrupts the documented adversary TTP. NCSC's 2024 prompt-injection and AI-supply-chain guidance updates the threat narrative but the CAF outcome statements are unchanged — Patterns 3 / 5 / 6 recur cleanly inside a CAF Level-3 attestation. |
+| UK FCA / PRA SS1/21 (Operational Resilience) | Important Business Service tolerance + scenario testing | Operational-resilience scenario testing is principle-based about severe-but-plausible disruptions. CBEST TIBER-EU scenario libraries lag adversary capability 12-18 months and rarely include AI-as-C2 / prompt-injection / MCP-class scenarios. An FCA-attested IBS resilience programme can be "compliant" with zero exercised coverage of Patterns 3 / 4 / 5 / 6 / 7. |
+| AU APRA CPS 234 | Para 26 (notification) + Para 27 (information security capability proportional to vulnerabilities and threats) | "Proportional to vulnerabilities and threats" language. APRA quarterly returns and tripartite reviews verify documented capability exists; they do not verify the capability disrupts a current-vintage TTP. CPS 234 attestation can be clean while Patterns 1 / 3 / 5 / 6 / 7 are all present. CPS 230 operational-resilience overlay (effective 2025-07-01) is silent on AI-specific operational scenarios. |
+| AU ASD Essential 8 | Patch Applications + Patch Operating Systems + Restrict Administrative Privileges (ML1-ML3) | ML3 48-hour patch window with public exploit is the closest national baseline to adequate for Pattern 1, but the other six strategies (User Application Hardening, Office Macros, Application Control, Daily Backups, MFA, Restrict Admin) do not address Patterns 3 / 5 / 6 / 7 at all. ACSC assessments score the eight strategies; they do not score AI-pipeline integrity or LLM-provider third-party risk. |
+| AU Voluntary AI Safety Standard (10 guardrails, 2024) | Guardrails 5 (test and monitor), 7 (transparency), 8 (record-keeping), 10 (stakeholder engagement) | Voluntary, principles-language. Operationally identical to the EU AI Act / UK DSIT AI Cyber Code lag — names the right concerns at the principle layer without testable controls. Patterns 3 / 4 / 5 are unaddressed by current guardrail attestation. |
 
 The pre-analyzed gaps for these controls live in the framework-gap-analysis skill's Built-In Gap Catalog. This skill consumes those gaps and produces a theater detection per gap.
 

package/skills/container-runtime-security/skill.md

@@ -22,11 +22,9 @@ triggers:
   - vllm
 data_deps:
   - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
   - cwe-catalog.json
   - d3fend-catalog.json
-  - rfc-references.json
+  - framework-control-gaps.json
 atlas_refs:
   - AML.T0010
 attack_refs:

package/skills/dlp-gap-analysis/skill.md

@@ -18,13 +18,12 @@ triggers:
   - embedding store exfil
   - clipboard ai paste
 data_deps:
-  - dlp-controls.json
   - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
-  - global-frameworks.json
   - cwe-catalog.json
   - d3fend-catalog.json
+  - dlp-controls.json
+  - framework-control-gaps.json
+  - global-frameworks.json
 atlas_refs:
   - AML.T0096
   - AML.T0017

package/skills/email-security-anti-phishing/skill.md

@@ -20,14 +20,7 @@ triggers:
   - deepfake phishing
   - ai phishing
   - secure email gateway
-data_deps:
-  - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
-  - cwe-catalog.json
-  - d3fend-catalog.json
-  - rfc-references.json
-  - dlp-controls.json
+data_deps: []
 atlas_refs: []
 attack_refs:
   - T1566

package/skills/exploit-scoring/skill.md

@@ -12,14 +12,16 @@ triggers:
   - patch priority
   - beyond cvss
 data_deps:
+  - atlas-ttps.json
   - cve-catalog.json
   - exploit-availability.json
+  - zeroday-lessons.json
 atlas_refs: []
 attack_refs: []
 framework_gaps:
   - CWE-Top-25-2024-meta
   - CIS-Controls-v8-Control7
-last_threat_review: "2026-05-15"
+last_threat_review: "2026-05-17"
 ---
 
 # Real-World Exploit Priority (RWEP) Scoring
@@ -57,7 +59,10 @@ RWEP exists because the exploit development cycle has compressed. The factors th
 | ISO 27001:2022 | A.8.8 (Management of technical vulnerabilities) | "Appropriate timescales" set by risk classification, typically CVSS-driven | Risk classification methodology is not specified; in practice orgs use CVSS bands. Standard offers no guidance distinguishing AI-discovered KEV-listed from theoretical High. |
 | CIS Controls v8 | Control 7 (Continuous Vulnerability Management) | IG1/IG2/IG3 timelines indexed on CVSS Critical/High | Same CVSS-anchored SLA failure. No factor for KEV status as a re-prioritization trigger. |
 | NIS2 Directive | Art. 21 (vulnerability handling) | "Appropriate measures" — methodology unspecified | In practice essential/important entities map this to CVSS-driven internal SLAs. Standard does not require any non-CVSS factor. |
-| ASD Essential 8 | Patch Operating Systems ML1–ML3 | ML3: 48h for OS vulns "with working exploit" | Closest to adequate — at least incorporates exploit availability. Still does not model AI-discovery, KEV, blast radius, or live-patch availability. 48h window remains long for AI-accelerated weaponization. |
+| UK NCSC CAF | Principle B4 (System Security) — vulnerability and patch management contributing outcomes | Outcome-based: "Vulnerabilities are identified and addressed appropriately" | Outcome language permits CVSS-only prioritization. No requirement to factor KEV listing, public-PoC availability, or AI-discovery into the remediation cadence. NCSC Vulnerability Management Guidance (2024) recommends but does not require exploit-availability weighting. |
+| UK Cyber Essentials Plus | Patch management criterion | Critical/High patches within 14 days | CVSS-anchored 14-day window. No factor for CISA KEV / public PoC. Tighter than NIST/PCI but still framework-lag-vulnerable for AI-accelerated 4-hour weaponization. |
+| AU ASD Essential 8 | Patch Operating Systems ML1–ML3 | ML3: 48h for OS vulns "with working exploit" | Closest to adequate — at least incorporates exploit availability. Still does not model AI-discovery, KEV, blast radius, or live-patch availability. 48h window remains long for AI-accelerated weaponization. |
+| AU ASD ISM | Control ISM-1493 (vulnerability management) + ISM-1144 (patching frequency) | Risk-based patching aligned to vendor severity / exploitability | "Exploitability" not operationalized as KEV / public-PoC / AI-discovery factors. Risk-based language permits CVSS-only ranking in practice. |
 | FedRAMP Continuous Monitoring | Vuln scan cadence + CVSS-band remediation | Monthly scans, CVSS-banded SLAs | Cadence-based detection plus CVSS-banded remediation cannot respond inside the AI-accelerated exploit window. |
 
 Across all of these, the framework lag is the same shape: **CVSS-as-risk-proxy.** RWEP is the operational corrective layer.

package/skills/framework-gap-analysis/skill.md

@@ -13,9 +13,9 @@ triggers:
   - compliance gap
   - why doesn't this control cover
 data_deps:
-  - framework-control-gaps.json
   - atlas-ttps.json
   - cve-catalog.json
+  - exploit-availability.json
   - global-frameworks.json
 atlas_refs: []
 attack_refs: []

package/skills/fuzz-testing-strategy/skill.md

@@ -16,10 +16,9 @@ triggers:
   - api fuzz
 data_deps:
   - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
   - cwe-catalog.json
   - d3fend-catalog.json
+  - zeroday-lessons.json
 atlas_refs:
   - AML.T0043
 attack_refs:

package/skills/global-grc/skill.md

@@ -17,9 +17,10 @@ triggers:
   - multi-jurisdiction
   - global compliance
 data_deps:
-  - global-frameworks.json
-  - framework-control-gaps.json
   - atlas-ttps.json
+  - exploit-availability.json
+  - framework-control-gaps.json
+  - global-frameworks.json
 atlas_refs: []
 attack_refs: []
 framework_gaps: []

package/skills/identity-assurance/skill.md

@@ -21,10 +21,8 @@ triggers:
   - phishing-resistant
 data_deps:
   - cve-catalog.json
-  - atlas-ttps.json
+  - exploit-availability.json
   - framework-control-gaps.json
-  - cwe-catalog.json
-  - d3fend-catalog.json
   - rfc-references.json
 atlas_refs:
   - AML.T0051

package/skills/idp-incident-response/skill.md

@@ -29,11 +29,8 @@ triggers:
   - tenant compromise
 data_deps:
   - cve-catalog.json
-  - attack-techniques.json
-  - framework-control-gaps.json
-  - global-frameworks.json
-  - cwe-catalog.json
   - d3fend-catalog.json
+  - framework-control-gaps.json
 atlas_refs: []
 attack_refs:
   - T1078.004

package/skills/incident-response-playbook/skill.md

@@ -17,12 +17,8 @@ triggers:
   - prompt injection incident
   - model exfiltration incident
 data_deps:
-  - cve-catalog.json
-  - atlas-ttps.json
-  - framework-control-gaps.json
-  - global-frameworks.json
-  - cwe-catalog.json
   - d3fend-catalog.json
+  - framework-control-gaps.json
   - zeroday-lessons.json
 atlas_refs:
   - AML.T0096

package/skills/kernel-lpe-triage/skill.md

@@ -15,8 +15,8 @@ triggers:
   - kernel patch
   - live kernel patch
 data_deps:
-  - cve-catalog.json
-  - exploit-availability.json
+  - d3fend-catalog.json
+  - rfc-references.json
 atlas_refs: []
 attack_refs:
   - T1068

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

@@ -14,9 +14,11 @@ triggers:
   - claude code security
   - ai agent security
 data_deps:
-  - cve-catalog.json
   - atlas-ttps.json
-  - framework-control-gaps.json
+  - cve-catalog.json
+  - d3fend-catalog.json
+  - exploit-availability.json
+  - rfc-references.json
 atlas_refs:
   - AML.T0010
   - AML.T0016
@@ -65,7 +67,7 @@ forward_watch:
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — LiteLLM full SSRF + Code Injection by Out Of Bounds (Byung Young Yi); duplicate-class with the k3vg3n entry; track unified patch advisory
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — LM Studio 5-bug exploit chain by STARLabs SG; impacts local MCP/agent runtime trust; track patch and integration advisories
   - Pwn2Own Berlin 2026 (disclosed 2026-05-14, embargo ends 2026-08-12) — Claude Code MCP collision-scored entry by Viettel Cyber Security; CVE in flight; track MCP trust and tool-collision advisory
-last_threat_review: "2026-05-15"
+last_threat_review: "2026-05-17"
 ---
 
 # MCP Agent Trust Assessment
@@ -142,6 +144,14 @@ Every MCP server listed in popular registries (MCP Hub, npm `@modelcontextprotoc
 | CIS Controls v8 | Control 2 (Inventory and Control of Software Assets) | Software inventory and allowlisting. Does not explicitly cover MCP servers. AI coding assistant MCP configs are not in scope for most enterprise software inventory processes. |
 | PCI DSS 4.0 | 12.3.4 | Review and manage third-party service providers. Scoped to service providers with access to cardholder data. An MCP server running on a developer workstation accessing a PCI-scoped codebase is not clearly in scope and would not appear in vendor management reviews. |
 | SWIFT CSCF v2026 | 1.1 (SWIFT Environment Protection — allowlisted software inside the secure zone) | Mandates allowlisted software and protected operator-PC posture for the SWIFT secure zone. The control's allowlist concept is the closest existing analogue to MCP tool allowlisting, but CSCF 1.1 was written for traditional middleware and does not contemplate MCP servers, agent-mediated tool calls, or model-judgment-as-authorization on operator workstations adjacent to the SWIFT zone. |
+| EU NIS2 | Art. 21(2)(d) (supply-chain security) + Art. 21(2)(e) (security in acquisition, development and maintenance) | "Appropriate and proportionate" supply-chain language. Member-state transpositions (BSI IT-SiG 2.0, ANSSI, CNIL) do not enumerate MCP servers as in-scope third-party components. An essential entity meets the NIS2 supplier-management obligation with traditional SaaS vendor reviews while leaving developer-workstation MCP servers entirely outside the supply-chain register. |
+| EU DORA | Art. 28 (ICT third-party risk register) + Art. 30 (key contractual provisions) + Art. 6 (ICT risk-management framework) | Financial-entity ICT third-party language scoped to traditional ICT providers and cloud outsourcing. ESAs RTS on subcontracting (JC 2024/53) is silent on MCP servers running inside trading-desk developer environments, even though those MCP servers can reach repository, trading-system, and ticketing-system tools via the AI assistant. |
+| EU AI Act (Regulation 2024/1689) | Art. 9 (risk management for high-risk AI) + Art. 15 (cybersecurity) + Art. 25 (responsibilities along the AI value chain) | Art. 25 addresses providers, deployers, importers, and distributors but does not categorize MCP server publishers as in-scope value-chain actors. High-risk AI cybersecurity language refers to "state of the art" without naming MCP supply chain as a scoped attack class. |
+| UK NCSC CAF | Principle A4 (Supply Chain), B4 (System Security), B2 (Identity and Access Control) | Outcome-based language. NCSC's 2024 guidance on securing AI systems names supply-chain integrity for AI tooling, but the CAF outcome statements are unchanged — an organisation can achieve A4 / B4 outcomes at Achieved level with zero MCP server allowlisting, no signature verification, and no per-server authentication. |
+| UK DSIT AI Cyber Code of Practice (2025) | Principle 7 (secure software supply chain) + Principle 8 (secure development) | Names supply-chain integrity for AI development but as a principle, not a testable control. No technical floor for MCP signing, allowlisting, or per-server auth. |
+| AU ASD Essential 8 | Strategy: Application Control + Restrict Administrative Privileges | Application Control (allowlisting) is the closest existing strategy to MCP allowlisting but is scoped to operating-system-level executables. MCP servers run as long-lived child processes spawned by the AI assistant's process — Application Control rarely reaches the npm/pip-installed JavaScript or Python that constitutes an MCP server. None of the eight strategies address agent-mediated tool execution. |
+| AU ASD ISM | ISM-1728 (managing cyber supply chain risk) + ISM-1808 (cloud consumer responsibilities) + ISM-0935 (application control) | ISM-1728 supply-chain language is scoped to traditional vendor classes; MCP servers fall outside enumerated supply-chain categories. ISM-0935 application control is operating-system-level and does not reach package-level MCP servers. |
+| AU APRA CPS 234 / CPS 230 | Para 27 (information security capability) + CPS 230 ICT-service-provider obligations | "Capability commensurate with vulnerabilities and threats" language. APRA-regulated entities deploying AI coding assistants meet CPS 234 attestation with traditional vendor-management capability; MCP-specific supply-chain capability is not an examined control. CPS 230 (effective 2025-07-01) third-party-arrangements obligations do not enumerate MCP servers as in-scope material service providers. |
 
 **Fundamental gap:** No current framework has a control category for "AI tool trust boundaries" — the concept that an AI model can be the authorization mechanism for code execution, and that this creates a new class of supply chain and access control risk.