@blamejs/exceptd-skills 0.19.1 → 0.19.3

package/scripts/check-ttp-references.js

@@ -0,0 +1,152 @@
+#!/usr/bin/env node
+"use strict";
+
+/**
+ * TTP reference-integrity gate.
+ *
+ * data/attack-techniques.json and data/atlas-ttps.json are the pinned copies of
+ * ATT&CK and ATLAS. Every other file that names a technique — countermeasure
+ * maps, DLP controls, playbooks, skill bodies, CVE entries — is referring INTO
+ * those two catalogs. This gate proves those references resolve.
+ *
+ * The failure it exists for: MITRE retires and renumbers techniques between
+ * releases. When a pin is bumped, the two source catalogs get remapped, but
+ * references living in other files are easy to miss — nothing dereferences them
+ * at runtime, so a stale id keeps rendering in operator output as if it were
+ * current. It points at a MITRE page that no longer resolves, and any control
+ * claiming to counter it is now mapped to nothing (AGENTS.md Hard Rule #4: no
+ * orphaned controls). A bumped pin left exactly this residue in the D3FEND and
+ * DLP maps, invisible to every other gate.
+ *
+ * The check is offline: it resolves references against the pinned catalogs, not
+ * against MITRE. That is deliberate — scripts/check-ttp-upstream.js is the
+ * network check that asks whether the PINS are current, and it cannot block a
+ * release because it needs connectivity. This one can block, because a
+ * reference that does not resolve against the pin we ship is broken no matter
+ * what upstream says.
+ *
+ * Exit codes: 0 all references resolve, 1 unresolved references found.
+ */
+
+const fs = require("node:fs");
+const path = require("node:path");
+
+const ROOT = path.resolve(__dirname, "..");
+
+/**
+ * ATT&CK ids are TNNNN[.NNN]; ATLAS ids are AML.TNNNN[.NNN]. The lookbehind
+ * matters: without it the ATT&CK alternative matches the "T0017" inside
+ * "AML.T0017" and reports a phantom bare-ATT&CK reference for every ATLAS id in
+ * the tree. It covers the hyphen as well, because ATLAS ids also appear in
+ * filenames, where the dot is not a legal separator.
+ */
+const TTP_PATTERN = /\bAML\.T\d{4}(?:\.\d{3})?\b|(?<!AML[.-])\bT\d{4}(?:\.\d{3})?\b/g;
+
+/** Files whose ids are definitions, not references. */
+const SOURCE_CATALOGS = ["data/attack-techniques.json", "data/atlas-ttps.json"];
+
+const SEARCH_ROOTS = ["data", "playbooks", "skills", "lib", "orchestrator", "bin"];
+const SEARCH_EXTS = new Set([".json", ".md", ".js"]);
+const SKIP_DIRS = new Set(["node_modules", "_indexes", "vendor", ".git"]);
+
+/**
+ * Tokens that match the pattern without being references to a technique.
+ * Every entry needs a reason: an unexplained allowlist is how a real stale id
+ * eventually gets parked here to make the gate green.
+ */
+const NOT_REFERENCES = [
+  {
+    id: "T1234",
+    file: "lib/gap-detectors.js",
+    why: "placeholder in a comment describing the reference-extraction pattern itself, not a claim about a technique",
+  },
+];
+
+function loadKnownIds() {
+  const known = new Set();
+  for (const rel of SOURCE_CATALOGS) {
+    const catalog = JSON.parse(fs.readFileSync(path.join(ROOT, rel), "utf8"));
+    for (const key of Object.keys(catalog)) {
+      if (key !== "_meta") known.add(key);
+    }
+  }
+  return known;
+}
+
+function* walk(dir) {
+  let names;
+  try {
+    names = fs.readdirSync(dir);
+  } catch {
+    return;
+  }
+  for (const name of names) {
+    if (SKIP_DIRS.has(name)) continue;
+    const full = path.join(dir, name);
+    let stat;
+    try {
+      stat = fs.statSync(full);
+    } catch {
+      continue;
+    }
+    if (stat.isDirectory()) {
+      yield* walk(full);
+    } else if (SEARCH_EXTS.has(path.extname(name))) {
+      yield full;
+    }
+  }
+}
+
+function allowed(id, rel) {
+  return NOT_REFERENCES.some((e) => e.id === id && e.file === rel);
+}
+
+function scan(root = ROOT) {
+  const known = loadKnownIds();
+  const sources = new Set(SOURCE_CATALOGS);
+  const unresolved = new Map();
+
+  for (const dirName of SEARCH_ROOTS) {
+    const dir = path.join(root, dirName);
+    if (!fs.existsSync(dir)) continue;
+
+    for (const file of walk(dir)) {
+      const rel = path.relative(root, file).replace(/\\/g, "/");
+      if (sources.has(rel)) continue;
+
+      const text = fs.readFileSync(file, "utf8");
+      for (const id of text.match(TTP_PATTERN) || []) {
+        if (known.has(id) || allowed(id, rel)) continue;
+        if (!unresolved.has(id)) unresolved.set(id, new Set());
+        unresolved.get(id).add(rel);
+      }
+    }
+  }
+
+  return { unresolved, knownCount: known.size };
+}
+
+function main() {
+  const { unresolved, knownCount } = scan();
+
+  if (unresolved.size) {
+    console.error("TTP reference integrity: FAIL");
+    for (const [id, files] of [...unresolved].sort((a, b) => a[0].localeCompare(b[0]))) {
+      console.error(`  ${id} — not defined in the pinned catalogs`);
+      for (const f of [...files].sort()) console.error(`      ${f}`);
+    }
+    console.error(
+      `\n${unresolved.size} unresolved ${unresolved.size === 1 ? "reference" : "references"}. ` +
+        `Either the id was retired upstream and these files still name it — repoint them at the ` +
+        `successor — or it is a technique the pinned catalogs do not carry yet, in which case import it.`
+    );
+    process.exitCode = 1;
+    return;
+  }
+
+  console.log(`TTP reference integrity: PASS — every referenced technique resolves against the ${knownCount} pinned ids`);
+}
+
+if (require.main === module) main();
+
+module.exports = { scan, TTP_PATTERN, NOT_REFERENCES, loadKnownIds };

package/scripts/check-version-tags.js

@@ -104,18 +104,32 @@ const COMMENT_EXEMPT = new Set([
 // need to name individual local-only files. Untracked-but-NOT-ignored files
 // ARE still scanned: a new file a contributor is about to commit is exactly
 // what the gate must catch. Computed via `git check-ignore` over the walked set.
+// Returns the ignored subset, or NULL when git cannot answer.
+//
+// "No path matched" and "the question could not be asked" are different
+// results and must not collapse into the same empty set. Without a repository
+// — a build context that omits .git/, or git not installed — an empty set
+// silently reclassifies every local-only file as part of the shipped surface,
+// so the gate reports violations in files a clone never contains. Returning
+// null lets the caller say it could not determine the surface instead of
+// asserting a wrong one.
 function gitIgnoredSet(relPaths) {
   if (!relPaths.length) return new Set();
   try {
     const out = execFileSync("git", ["check-ignore", "--stdin"], {
       cwd: ROOT, input: relPaths.join("\n"), encoding: "utf8", maxBuffer: 64 * 1024 * 1024,
+      stdio: ["pipe", "pipe", "pipe"],
     });
     return new Set(out.split(/\r?\n/).filter(Boolean));
   } catch (e) {
-    // `git check-ignore --stdin` exits 1 when NO path is ignored (not an
-    // error); any paths it did match are on stdout. Absent that, none ignored.
+    // Exit 1 with no stderr is git's way of saying "no path matched" — a real
+    // answer, and an empty set is correct. Anything else (git missing, not a
+    // repository, .git absent) means the question went unanswered.
+    const status = e && typeof e.status === "number" ? e.status : null;
+    const stderr = e && e.stderr ? String(e.stderr).trim() : "";
     const out = e && e.stdout ? String(e.stdout) : "";
-    return new Set(out.split(/\r?\n/).filter(Boolean));
+    if (status === 1 && !stderr) return new Set(out.split(/\r?\n/).filter(Boolean));
+    return null;
   }
 }
 
@@ -185,12 +199,16 @@ function countLineViolations(rel) {
 function scanCurrent() {
   const files = walk(ROOT);
   const ignored = gitIgnoredSet(files);
+  // Without git the shipped surface is unknowable: local-only files are
+  // indistinguishable from tracked ones, so any result would be a guess.
+  // Report that rather than emit findings the baseline cannot be compared to.
+  if (ignored === null) return { byFile: {}, filenameViolations: [], surfaceUnknown: true };
   const byFile = {};
   const filenameViolations = [];
   for (const rel of files) {
-    // Skip git-ignored, local-only files (a contributor's private working notes
-    // that `git clone` never ships). Untracked-but-not-ignored files are still
-    // scanned — a new file about to be committed is what the gate guards.
+    // Skip git-ignored, local-only files that `git clone` never ships.
+    // Untracked-but-not-ignored files are still scanned — a new file about to
+    // be committed is exactly what the gate guards.
     if (ignored.has(rel)) continue;
     if (FILENAME_VERSION_RE.test(rel)) filenameViolations.push(rel);
     const n = countLineViolations(rel);
@@ -229,6 +247,32 @@ function main() {
   const wantUpdate = process.argv.includes("--update-baseline");
   const current = scanCurrent();
 
+  if (current.surfaceUnknown) {
+    // Never write a baseline from a scan that could not tell shipped files from
+    // local ones — that would bake the wrong surface in permanently.
+    //
+    // Automation is the one place this must not degrade to a skip. This gate
+    // runs inside predeploy, and predeploy guards the publish job, so a
+    // silently-skipped run there stops enforcing on exactly the path that
+    // ships. Locally — a container built without .git, a tarball inspection —
+    // skipping is the honest answer, because the shipped surface genuinely is
+    // not knowable there and failing would only punish the harness.
+    const inAutomation = process.env.CI === "true" || !!process.env.GITHUB_ACTIONS;
+    if (inAutomation) {
+      console.error("[check-version-tags] FAIL — no git repository available, so the shipped");
+      console.error("  surface cannot be determined. In automation this is a failure, not a skip:");
+      console.error("  this gate runs inside predeploy, which guards publishing. Ensure the job");
+      console.error("  checks out git metadata (actions/checkout provides it by default).");
+      process.exitCode = 2;
+      return;
+    }
+    console.error("[check-version-tags] SKIPPED — no git repository available, so the shipped");
+    console.error("  surface cannot be determined. This is not a pass; run it where git metadata");
+    console.error("  is present. In CI the same condition fails instead.");
+    process.exitCode = 0;
+    return;
+  }
+
   if (wantUpdate) {
     writeBaseline(current);
     process.exitCode = 0;

package/scripts/predeploy.js

@@ -222,6 +222,32 @@ const GATES = [
     args: [path.join(ROOT, "scripts", "check-framework-gap-coverage.js")],
     ciJobName: "Data integrity (catalog + manifest snapshot)",
   },
+  {
+    // TTP reference-integrity gate. The two pinned MITRE catalogs define the
+    // techniques; every other file naming one is referring into them. MITRE
+    // retires and renumbers between releases, and a reference living outside
+    // the source catalogs is never dereferenced at runtime — so a stale id
+    // keeps rendering in operator output, pointing at a page that no longer
+    // resolves and leaving any control mapped to it orphaned (Hard Rule #4).
+    // Resolves against the pin rather than the network, so it can block.
+    name: "TTP reference integrity (no orphaned technique ids)",
+    command: process.execPath,
+    args: [path.join(ROOT, "scripts", "check-ttp-references.js")],
+    ciJobName: "Data integrity (catalog + manifest snapshot)",
+  },
+  {
+    // EPSS pair-consistency gate. A CVE's epss_score and epss_percentile come
+    // from the same daily publication, where the percentile is the score's
+    // rank — so sorting a publication's entries by score must sort them by
+    // percentile too. Refreshing one field without the other leaves an entry
+    // that passes every range and type check while ranking a CVE on a score
+    // that no longer supports it, which is precisely the input operators
+    // prioritise by. The ordering check catches that offline.
+    name: "EPSS score/percentile consistency",
+    command: process.execPath,
+    args: [path.join(ROOT, "scripts", "check-epss-consistency.js")],
+    ciJobName: "Data integrity (catalog + manifest snapshot)",
+  },
   {
     // Version-tag drift gate. Compares the tracked tree against a
     // baseline snapshot of pre-existing `// vX.Y.Z` comments and

package/scripts/refresh-sbom.js

@@ -12,9 +12,14 @@
  *   - bomFormat / specVersion        CycloneDX 1.6
  *   - serialNumber                   urn:uuid v4 derived from a stable
  *                                    hash of (project name + version +
- *                                    timestamp) so reruns produce a new
- *                                    UUID per refresh.
- *   - metadata.timestamp             ISO 8601 of generation
+ *                                    bundle digest), so identical content
+ *                                    reproduces the identical UUID and a
+ *                                    rerun that changed nothing is a no-op
+ *                                    rather than a spurious diff.
+ *   - metadata.timestamp             the release date this version's
+ *                                    CHANGELOG heading declares — NOT the
+ *                                    wall-clock moment of generation, which
+ *                                    would make the artifact irreproducible
  *   - metadata.tools                 this script itself, version pulled
  *                                    from package.json at refresh time
  *   - metadata.component             application entry for exceptd-skills,
@@ -145,13 +150,31 @@ const SELF_EXCLUDED = new Set(['sbom.cdx.json']);
  * side check for the cache. */
 const DERIVABLE_PREFIXES = ['data/_indexes/'];
 
+/* Files npm puts in every tarball regardless of the `files` allowlist.
+ * package.json is never listed in `files` (npm adds it unconditionally), so
+ * expanding the allowlist alone left the one file that declares the bin
+ * entrypoint, the engines floor and the dependency set outside the hashed
+ * inventory — the SBOM described 247 of the 268 files an operator receives and
+ * said nothing about the gap. It is not derivable and not self-referential, so
+ * nothing but the omission kept it out. README.md and LICENSE get the same
+ * unconditional treatment from npm but are already named in `files`, so a
+ * union covers the general rule without double-counting them. sources/README.md
+ * is here for the same reason: npm collects README files it finds, `files` never
+ * names that directory, and it shipped unhashed.
+ *
+ * This list is maintained by hand, which is only safe because something else
+ * checks it: lib/validate-package.js compares the real `npm pack` output against
+ * this SBOM, so a file npm decides to ship that is missing here fails a gate
+ * instead of shipping silently. */
+const ALWAYS_SHIPPED = ['package.json', 'sources/README.md'];
+
 function isDerivable(rel) {
   return DERIVABLE_PREFIXES.some((p) => rel === p.replace(/\/$/, '') || rel.startsWith(p));
 }
 
 function expandAllowlist(allowlist) {
   const abs = [];
-  for (const entry of allowlist) {
+  for (const entry of [...allowlist, ...ALWAYS_SHIPPED]) {
     const full = path.join(REPO_ROOT, entry);
     if (!fs.existsSync(full)) continue; // tolerate a stale entry; predeploy gate flags
     const stat = fs.statSync(full);
@@ -171,6 +194,38 @@ function expandAllowlist(allowlist) {
   return rel;
 }
 
+/* metadata.timestamp — the release date this version's CHANGELOG heading
+ * declares, as an ISO-8601 instant.
+ *
+ * The field has to be deterministic: the SBOM-currency gate compares the
+ * committed artifact against a freshly generated one, so a wall-clock value
+ * would differ on every run and the comparison could never mean anything.
+ * The previous approach kept determinism by folding the bundle hash into a
+ * date offset, but the offset was a full uint32 of SECONDS — a 136-year
+ * spread — so the field routinely landed a century or more in the future
+ * (the shipped value read 2147-11-20). Deterministic, and untrue: consumers
+ * that sort or age-check SBOMs read that as a real creation date.
+ *
+ * The CHANGELOG heading is both deterministic and true. Its format is already
+ * enforced by scripts/check-changelog-extract.js, which the release flow runs
+ * before this script, so the date is guaranteed present by the time a release
+ * regenerates the SBOM. Refusing is deliberate when it is absent — inventing a
+ * placeholder is what produced the 2147 date in the first place. */
+function releaseTimestamp(version) {
+  const changelogPath = path.join(REPO_ROOT, 'CHANGELOG.md');
+  const text = fs.readFileSync(changelogPath, 'utf8');
+  const escaped = version.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+  const m = text.match(new RegExp('^## ' + escaped + ' [—-] (\\d{4}-\\d{2}-\\d{2})\\s*$', 'm'));
+  if (!m) {
+    throw new Error(
+      `refresh-sbom: CHANGELOG.md has no dated heading for ${version}. ` +
+      `Add "## ${version} — YYYY-MM-DD" before regenerating — metadata.timestamp ` +
+      `is the release date, and there is no honest value to fall back to.`,
+    );
+  }
+  return `${m[1]}T00:00:00.000Z`;
+}
+
 function toPosixRel(absPath) {
   return path
     .relative(REPO_ROOT, absPath)
@@ -303,12 +358,7 @@ function buildSbom() {
   // 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 timestamp = releaseTimestamp(pkg.version);
 
   const dataflowInput = catalogs
     .map((c) => `data/${c}`)
@@ -366,6 +416,22 @@ function buildSbom() {
           name: 'exceptd:integrity:method',
           value: 'Ed25519 per-skill (lib/sign.js)',
         },
+        // An operator verifying the bundle holds the SBOM, not this script.
+        // Without these two properties the only record of what the inventory
+        // deliberately omits was a source comment they never see, so a partial
+        // inventory was indistinguishable from a complete one. State the
+        // uncovered prefix and the check that covers it instead.
+        {
+          name: 'exceptd:integrity:uncovered:prefix',
+          value: DERIVABLE_PREFIXES.join(','),
+        },
+        {
+          name: 'exceptd:integrity:uncovered:rationale',
+          value:
+            'Regenerated by `npm run build-indexes` and mutated by the test suite, so a ' +
+            'pinned per-file hash would race any run between generation and verification. ' +
+            'Covered instead by the pre-computed-index freshness gate in `npm run predeploy`.',
+        },
         {
           name: 'exceptd:runtime:dependency:count',
           value: String(Object.keys(pkg.dependencies || {}).length),
@@ -409,4 +475,11 @@ if (require.main === module) {
   main();
 }
 
-module.exports = { buildSbom, expandAllowlist, bundleDigest };
+module.exports = {
+  buildSbom,
+  expandAllowlist,
+  bundleDigest,
+  releaseTimestamp,
+  ALWAYS_SHIPPED,
+  DERIVABLE_PREFIXES,
+};

package/scripts/release.js

@@ -295,8 +295,15 @@ function cmdPrepare(opts) {
   _ok("signed + indexes + snapshot + sbom regenerated");
 
   _section("test-count baseline");
-  // Growth is fine (the gate only fails on shrinkage), but refreshing keeps
-  // the canonical-count guard meaningful when a release adds test files.
+  // Check BEFORE refreshing. `--update-baseline` writes whatever it observes,
+  // so calling it unconditionally rebaselined a shrunken suite downward and the
+  // shrinkage gate — which runs later, in `gates` — then compared the new count
+  // against itself and passed. Releasing was the one path that disarmed the
+  // guard, which is the path it exists to guard. Run the gate first so a drop
+  // stops the release here; refresh only once it has agreed nothing was lost,
+  // which still captures growth. A deliberate removal is re-baselined by hand
+  // with the command the gate's own failure message prints.
+  _run("node", ["scripts/check-test-count.js"]);
   _run("node", ["scripts/check-test-count.js", "--update-baseline"]);
 
   _section("codebase-patterns currency (advisory)");

package/skills/defensive-countermeasure-mapping/skill.md

@@ -215,7 +215,7 @@ The skill produces a Defensive Countermeasure Map per input (CVE ID, ATLAS / ATT
 Example: "CVE — Linux kernel LPE. Canonical: CVE-2026-31431 (Copy Fail)."
 
 ## Offensive technique set (input to D3FEND query)
-- <AML.T0001-or-similar / T0001-or-similar / CWE-<id> list, with one-line descriptions>
+- <AML.T####-or-similar / T####-or-similar / CWE-<id> list, with one-line descriptions>
 
 ## Defensive-coverage map
 | D3FEND ID | Name | Tactic (DiD layer) | Privilege scope | ZT posture | Deployed? | AI-pipeline applicable? | Framework controls partially mapped | Live-tunable? |

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

@@ -91,7 +91,7 @@ IR obligations span four layers — methodology (NIST 800-61r3, ISO 27035, SANS
 | ISO/IEC 27035-1:2023 | Information security incident management — Principles and process | Process model: plan & prepare → detect & report → assess & decide → respond → learn lessons. | Process-shaped, not playbook-shaped. No AI-class sub-types. No regulator-clock matrix. Conformance does not imply playbook completeness. |
 | ISO/IEC 27035-2:2023 | Guidelines to plan and prepare for incident response | Planning, team structure, communication. | Same process orientation. Mentions "external reporting obligations" without operationalizing EU CRA / NIS2 / AI Act / NYDFS clocks. |
 | NIST SP 800-53 rev 5 | IR-4 Incident Handling; IR-5 Incident Monitoring; IR-6 Incident Reporting; IR-8 Incident Response Plan | Method-neutral control objectives. | Per `framework-control-gaps.json` NIST-800-53-AC-2: AC-2 (Account Management) does not require AI-agent identity lifecycle management; identity-compromise (T1078) detection feeds IR but the underlying control gap leaves AI-agent service accounts under-instrumented. IR-4 says "implement an incident handling capability" without specifying AI-class handling. |
-| ISO/IEC 27001:2022 | A.5.24 Information security incident management planning and preparation; A.5.26 Response to information security incidents; A.8.16 Monitoring activities | Process-level requirements for incident response and monitoring. | Per `framework-control-gaps.json` ISO-27001-2022-A.8.16: monitoring requirements are technology-neutral but AI-system telemetry (prompt logs, embedding-store access, model-output classification) is not addressed. An ISO 27001-certified org with no AI-system monitoring is formally compliant and operationally blind to AML.T0051 / T0096 / T0017. |
+| ISO/IEC 27001:2022 | A.5.24 Information security incident management planning and preparation; A.5.26 Response to information security incidents; A.8.16 Monitoring activities | Process-level requirements for incident response and monitoring. | Per `framework-control-gaps.json` ISO-27001-2022-A.8.16: monitoring requirements are technology-neutral but AI-system telemetry (prompt logs, embedding-store access, model-output classification) is not addressed. An ISO 27001-certified org with no AI-system monitoring is formally compliant and operationally blind to AML.T0051 / AML.T0096 / AML.T0017. |
 | SOC 2 | CC7 (System operations — security event detection, incident response) | Trust services criteria for anomaly detection and incident response. | Per `framework-control-gaps.json` SOC2-CC7-anomaly-detection: CC7 requires anomaly detection without specifying coverage for AI-API C2 (AML.T0096), training-data exfiltration (AML.T0017), or prompt-injection incident triggers (AML.T0051). Auditors test for "an anomaly detection system" without testing whether it covers AI traffic shape. Theater-prone. |
 | EU NIS2 Directive (2022/2555) | Art. 23 — incident notification | 24h early warning, 72h initial notification, 1-month final report to national CSIRT for significant incidents at essential/important entities. | Clocks are explicit; significance criteria are partly Member-State-defined; cross-border coordination via ENISA CSIRTs Network. The IR playbook must run the clocks; the directive does not define playbook content. |
 | EU DORA (Regulation 2022/2554) | Art. 17 (ICT incident management); Art. 19 (major ICT-related incident reporting); Art. 18 (classification) | Financial-entity-specific: 4h initial notification for major ICT incidents, 72h intermediate, 1-month final, all to competent authority (national + ECB/EIOPA/ESMA depending on entity). | DORA 4h is tighter than NIS2 24h; an entity in scope of both runs whichever is shorter. DORA RTS on classification (2024) defines "major" but the operational determination at the 4h mark requires triage maturity most entities lack. |
@@ -162,7 +162,7 @@ Before stepping through the IR program assessment, thread the three foundational
 
 **Defense in depth — IR as a multi-layer pipeline.** A real IR program is not the playbook document; it is the stack that produces the conditions for the playbook to fire and the conditions for it to succeed:
 - **Layer 1 — Preparation.** Playbook library (by ATT&CK technique + incident class + sector + jurisdiction), tabletop exercises (at least quarterly, scenarios drawn from current threat-intel feed), runbook tooling (SOAR + ticketing + comms), redundant logging (SIEM + DLP + identity + EDR + AI-system telemetry shipped to immutable store), legal and PR alignment, executive and board awareness, retainer with external IR firm.
-- **Layer 2 — Identification.** SIEM correlation rules mapped to ATT&CK; EDR / XDR on every endpoint and workload; UEBA for identity-anomaly detection; AI-incident detectors per `ai-c2-detection` for AML.T0096 / T0017 / T0051; threat-intel feed integration; honeypot / canary telemetry.
+- **Layer 2 — Identification.** SIEM correlation rules mapped to ATT&CK; EDR / XDR on every endpoint and workload; UEBA for identity-anomaly detection; AI-incident detectors per `ai-c2-detection` for AML.T0096 / AML.T0017 / AML.T0051; threat-intel feed integration; honeypot / canary telemetry.
 - **Layer 3 — Containment.** Network-segment isolation capability (SDN, microsegmentation, firewall policy push); identity revocation capability (Conditional Access, OAuth-grant revocation, service-account rotation); endpoint isolation (EDR-driven network quarantine); AI-API egress block; cloud-workload pause/snapshot.
 - **Layer 4 — Eradication and recovery.** Artifact removal (file, registry, scheduled task, persistence mechanism); credential rotation at scope (privileged, service, AI-agent, OAuth app, API key); validated backup restore; AI-system rollback (model version, system prompt, RAG corpus state); service-level verification before declaring recovery.
 - **Layer 5 — Lessons learned.** Post-incident review (root-cause analysis using the Diamond Model and the Unified Kill Chain for adversary-narrative reconstruction); playbook update; detection-engineering refinement; control-gap filing per `framework-gap-analysis`; zero-day learning per `zeroday-gap-learn`; threat-model refresh per `threat-model-currency`; skill-update propagation per `skill-update-loop`.
@@ -192,7 +192,7 @@ When an incident fires, classify before responding. Classification dimensions:
 - **Incident class** — ransomware, data exfiltration, identity compromise, supply-chain, AI-system breach, business-email-compromise, DoS, insider, other.
 - **Impact severity** — confidentiality / integrity / availability per the org's incident-severity matrix.
 - **Jurisdictional notification clock** — per the matrix in Section 7. Which clocks start, when did they start (awareness moment), who is the named officer per clock.
-- **AI-class flag** — does the incident involve an AI system as victim, vector, or attacker? AI-as-victim: AML.T0051/T0017. AI-as-vector: AML.T0096. AI-as-attacker: agent-initiated unauthorized action.
+- **AI-class flag** — does the incident involve an AI system as victim, vector, or attacker? AI-as-victim: AML.T0051/AML.T0017. AI-as-vector: AML.T0096. AI-as-attacker: agent-initiated unauthorized action.
 - **Sector flag** — does a sectoral framework apply (`sector-healthcare`, `sector-financial`, `sector-energy`, `sector-federal-government`)?
 
 ### Step 3 — Declaration and runbook activation
@@ -500,7 +500,7 @@ Four concrete tests distinguish a real IR program from IR theater. Run them in o
 
 > **Test 2 — Walk me through your EU DORA 4-hour initial-notification process, named officer included.** Substitute the tightest jurisdictional clock that applies to the org (DORA 4h for in-scope financial entities; SG CSA CCoP2.0 2h for SG CII; NERC CIP-008 1h for North American electric utilities; CERT-In 6h for India-operating entities; AU SOCI 12h; CRA Art. 11 24h for EU manufacturers). If the answer is "we'll figure it out when it happens" or "legal will handle it," the program will miss the clock during a real incident. The named officer must be identifiable, reachable on a documented out-of-band channel, and trained on the determination criteria for the relevant "significance" or "major" or "actively exploited" thresholds. If the org cannot produce the named officer's contact card and the decision tree they will use at 03:00 on a Saturday, the regulator-notification capability is theater.
 
-> **Test 3 — Do you have an AI-class incident playbook, and when was it last exercised?** Three failure modes signal theater: (a) "AI is just IT — we use our normal playbook" — the org has not engaged with AML.T0096 / T0017 / T0051 detection and containment specifics; (b) "we don't run AI systems" — verify against actual product surface (Copilot, Claude, ChatGPT, Gemini, AI features embedded in SaaS, internal agentic systems, RAG features); (c) "we have a draft playbook but never tested it" — untested AI-class playbooks fail at the same rate as untested conventional playbooks, but the failure modes are unfamiliar to the SOC. Particular smell: the AI-class playbook exists in the security team's shared drive but the AI-platform team and the data-science team have never seen it. AI-incident response requires cross-team rehearsal; AML.T0017 forensics requires data-science skills the SOC does not have.
+> **Test 3 — Do you have an AI-class incident playbook, and when was it last exercised?** Three failure modes signal theater: (a) "AI is just IT — we use our normal playbook" — the org has not engaged with AML.T0096 / AML.T0017 / AML.T0051 detection and containment specifics; (b) "we don't run AI systems" — verify against actual product surface (Copilot, Claude, ChatGPT, Gemini, AI features embedded in SaaS, internal agentic systems, RAG features); (c) "we have a draft playbook but never tested it" — untested AI-class playbooks fail at the same rate as untested conventional playbooks, but the failure modes are unfamiliar to the SOC. Particular smell: the AI-class playbook exists in the security team's shared drive but the AI-platform team and the data-science team have never seen it. AI-incident response requires cross-team rehearsal; AML.T0017 forensics requires data-science skills the SOC does not have.
 
 > **Test 4 — Enumerate every jurisdictional notification clock that applies to your operations, name the officer for each, and produce the last drill record per clock.** If the org cannot enumerate clocks — clocks are discovered mid-incident, while running them late — the program will miss at least one in a real cross-jurisdictional event. The minimum enumeration for a multinational organization: EU (CRA Art. 11 + NIS2 Art. 23 + DORA Art. 19 if financial + AI Act Art. 73 if high-risk AI), UK (NIS + UK GDPR), AU (SOCI), JP (NISC + APPI), IL (INCD + PPA), SG (CSA CCoP2.0 + PDPC), IN (CERT-In), BR (LGPD), CN (MLPS + CSL + DSL + PIPL), US-NYDFS, US-HIPAA (if in scope), US-NERC (if in scope), AE (TDRA + DIFC DP). For each: clock, authority, channel, named officer, last drill. If the clocks live in a regulatory-comms team's binder rather than the IR runbook library, the program will run them out of sequence with the technical response and burn one of them.
 
@@ -521,7 +521,7 @@ IR consumes defensive controls across multiple D3FEND categories; the four cited
 | **D3-IOPR** (Input/Output Profiling) | AI-API egress correlation and SaaS-egress anomaly detection. For AI-system incidents, profiling the input (prompt) and output (response) distribution is the defensive surface that can detect AML.T0051 (anomalous prompt patterns), AML.T0017 (extraction-pattern queries), and AML.T0096 (C2-channel encoded payloads). | Identification layer (primary for AI-system incidents). | Scoped to the AI-incident specialist role; raw prompts and responses may contain confidential data and must be access-controlled per data-classification policy. | Default-suspect for prompt distributions outside the baseline; do not whitelist by source identity alone — verify per request. | High applicability — D3-IOPR is the highest-leverage D3FEND technique for AI-system incident detection and is the operational complement to D3-NTA when the egress is to a legitimate AI provider. |
 | **D3-CSPP** (Client-Server Payload Profiling) | C2 protocol detection during identification; AI-API content-layer detection for AML.T0096. Where the C2 channel is HTTPS to a legitimate service (Box, OneDrive, S3, AI provider), CSPP is the content-shape detection surface that catches the abuse pattern. | Identification layer. | Scoped to the detection-engineering and IR analyst roles; payload-content access controlled. | Default-suspect for novel payload shapes against baseline; verify-not-assume that previously-good clients have not been compromised. | Applies — particularly for AI-API C2 detection where TLS termination at an enterprise proxy enables payload-shape analysis of prompts and responses. |
 
-**No orphaned controls**: each D3FEND technique above maps to one or more incident classes in the TTP Mapping section (T1486 / T1041 / T1567 / T1078, AML.T0096 / T0017 / T0051). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during IR.
+**No orphaned controls**: each D3FEND technique above maps to one or more incident classes in the TTP Mapping section (T1486 / T1041 / T1567 / T1078, AML.T0096 / AML.T0017 / AML.T0051). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during IR.
 
 **AI-pipeline statement**: D3FEND coverage of AI-incident defense is concentrated in D3-IOPR (input/output profiling) and the content-layer subset of D3-CSPP. The ephemeral-compute evidence-preservation problem is largely outside the D3FEND ontology as of mid-2026; the operational fix (continuous forensic-grade telemetry shipping to immutable store) is documented in `attack-surface-pentest` and `defensive-countermeasure-mapping` as a control gap pending ontology coverage.
 

package/skills/mlops-security/skill.md

@@ -117,7 +117,7 @@ Descriptions sourced from `data/atlas-ttps.json` (ATLAS v2026.07, released 2026-
 |---|---|---|---|
 | AML.T0010 | ML Supply Chain Compromise (sub-techniques: GPU Firmware, ML Framework, Model Repository, MCP Server) | Cross-cutting — touches every ingestion point: dependencies in training environment (AML.T0010.001), model pulls from Hugging Face / vendor registries (AML.T0010.002), MCP plugins in dev tooling (AML.T0010.003) | No framework mandates registry-side cryptographic verification of all ingested artifacts; the SLSA-style attestation chain for ML artifacts is draft, not required |
 | AML.T0018 | Manipulate AI Model (sub-techniques: Poison Training Data, Trojan Model via direct weight manipulation, Federated Learning Poisoning) | Training pipeline and post-training tampering — adversary modifies weights either through poisoned training data persisted into weights or through direct binary edit of an unsigned checkpoint | No framework requires model-weight signature verification at registry write and at deployment read; CWE-502 deserialization risk on `.pt` / `SavedModel` is unmapped to compliance control |
-| AML.T0020 | Poison Training Data (sub-techniques: Inject at Scale, Craft Targeted, RAG Knowledge Base Poisoning) | Data ingestion → feature store → training. Adversary contaminates training corpus to embed targeted misbehavior. Sub-technique AML.T0020.002 is RAG-side (see `rag-pipeline-security`); AML.T0020.000 / 001 are MLOps-side. | No framework requires training-data lineage attestation, source signing, or poisoning-detection scanning at ingestion. EU AI Act Art. 10 requires data-governance documentation but not cryptographic attestation. |
+| AML.T0020 | Poison Training Data (sub-techniques: Inject at Scale, Craft Targeted, RAG Knowledge Base Poisoning) | Data ingestion → feature store → training. Adversary contaminates training corpus to embed targeted misbehavior. ATLAS carries this as a single technique with no sub-techniques; the RAG-corpus variant is covered in `rag-pipeline-security`, the training-pipeline variant here. | No framework requires training-data lineage attestation, source signing, or poisoning-detection scanning at ingestion. EU AI Act Art. 10 requires data-governance documentation but not cryptographic attestation. |
 | AML.T0043 | Craft Adversarial Data (White-Box, Black-Box, Physical) | Inference serving and feedback loop — adversary crafts inputs to either cause misclassification at inference time or to poison the feedback corpus when feedback is logged for retraining | No framework requires adversarial-robustness testing for deployed models or adversarial-input detection at the serving layer; AI RMF MEASURE-2.5 recommends but does not require |
 | AML.T0017 | Discover ML Model Ontology (Probe, Extract System Prompt, Map Filters) | Model registry exposure — adversary maps deployed model family, extracts metadata, infers training corpus, harvests prompts and guardrails | No framework requires model-registry RBAC at the granularity needed (per-project read scoping, signed registry queries, audit of model-extraction-pattern queries) |
 | T1195.001 | Supply Chain Compromise: Software Dependencies and Development Tools | Training pipeline dependency chain — Python wheels, CUDA drivers, ML framework versions, notebook kernels | SCA detects known-vulnerable; XZ-class novel compromise is not detectable without SLSA L3 + reproducible builds for the training environment |

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

@@ -188,7 +188,7 @@ Descriptions sourced verbatim from `data/atlas-ttps.json` (ATLAS v2026.07, relea
 
 | ATLAS ID | ATLAS Name | RAG Attack Class | Control Gap That Lets It Land | Controls That Partially Cover It |
 |---|---|---|---|---|
-| AML.T0020 | Poison Training Data (incl. sub-technique AML.T0020.002 — RAG Knowledge Base Poisoning) | Vector store poisoning (Attack Class 2): adversary injects malicious documents into the retrieval corpus — either behavioral instructions or false facts | Data integrity controls (SI-7, SI-12) are designed for traditional structured data. No framework requires integrity monitoring of vector store contents, embedding distribution shift detection, or hash-based verification of knowledge-base documents. Ingestion pipelines accept unstructured content by design. | NIST-800-53-SI-7, NIST-800-53-SI-12 (both partial — neither covers embedding-space integrity); ALL-AI-PIPELINE-INTEGRITY (universal gap, no framework has the control) |
+| AML.T0020 | Poison Training Data — ATLAS carries no sub-technique for the RAG knowledge-base variant, which this skill treats as its own attack class | Vector store poisoning (Attack Class 2): adversary injects malicious documents into the retrieval corpus — either behavioral instructions or false facts | Data integrity controls (SI-7, SI-12) are designed for traditional structured data. No framework requires integrity monitoring of vector store contents, embedding distribution shift detection, or hash-based verification of knowledge-base documents. Ingestion pipelines accept unstructured content by design. | NIST-800-53-SI-7, NIST-800-53-SI-12 (both partial — neither covers embedding-space integrity); ALL-AI-PIPELINE-INTEGRITY (universal gap, no framework has the control) |
 | AML.T0043 | Craft Adversarial Data | Embedding manipulation for data exfiltration (Attack Class 1): adversary crafts queries whose embeddings land near sensitive document embeddings, forcing retrieval | No framework requires adversarial-robustness testing for retrieval engines. SI-3 (malicious code protection) does not contemplate adversarial inputs to embedding models. Access control models (AC-3) operate on identified resources, not embedding-similarity-fragments. | NIST-800-53-SI-3, NIST-AI-RMF-MEASURE-2.5 (both partial — neither covers retrieval-engine adversarial robustness) |
 | AML.T0051 | LLM Prompt Injection (incl. AML.T0051.001 — Indirect Prompt Injection) | Indirect prompt injection via retrieved documents (Attack Class 5): adversarial instructions stored in the knowledge base execute in the LLM's context when retrieved | No framework has a control for prompt injection as an access control failure. The AI agent's service account is properly authorized — AC-2's perspective sees the access as legitimate. ATLAS documents the technique; no framework implements controls. Universal gap `ALL-PROMPT-INJECTION-ACCESS-CONTROL` is open. | NIST-800-53-AC-2 (partial — does not surface model-mediated unauthorized action); ISO-27001-2022-A.8.28 (partial — secure coding scope does not include semantic vulnerabilities); ALL-PROMPT-INJECTION-ACCESS-CONTROL (universal gap) |
 | AML.T0054 | LLM Jailbreak / Craft Adversarial Data — NLP | Retrieval filter bypass (Attack Class 4) and chunking exploitation (Attack Class 3): semantic border crossing, namespace confusion, split-and-reassemble of sensitive content across chunks | No framework requires safety-guardrail testing for retrieval-augmented systems. NIST AI RMF recommends adversarial testing but does not require it. Filter-application-order (pre-similarity vs. post-similarity) is not addressed by any control. | NIST-AI-RMF-GOVERN-1.7 (partial — recommends but does not require red-team testing); NIST-800-53-SI-12 (partial — retention only, not retrieval scope) |

package/skills/ransomware-response/skill.md

@@ -127,7 +127,7 @@ Cross-cutting gap: **no security framework treats the four ransomware-specific d
 | **T1078** | Valid Accounts | Initial access via credential reuse from infostealer markets; AD privilege chain mapping pre-encryption; lateral movement via valid accounts to broaden encryption scope. | Identification: anomalous sign-in UEBA, impossible-travel, infostealer-market evidence. Containment: account disable + session revocation + MFA re-enrollment. Eradication: krbtgt double-rotation, OAuth-grant audit, AD admin-group review. |
 | **T1059** | Command and Scripting Interpreter | Living-off-the-land via PowerShell, WMI, PsExec; Cobalt Strike Beacon / Sliver / Brute Ratel as C2 framework. | Identification: EDR script-block-logging, suspicious WMI invocations, JA3 fingerprints. Containment: EDR quarantine, egress block to C2 destinations. Eradication: artifact removal, persistence-mechanism cleanup. |
 
-Shadow Copy deletion and exfil-staging via Web Service align to the parent IR playbook's `T1486` and `T1567` entries; the parent's `AML.T0096 / T0017 / T0051` entries do not apply to ransomware-as-a-class but may apply if AI-system data is exfiltrated within the ransomware operation.
+Shadow Copy deletion and exfil-staging via Web Service align to the parent IR playbook's `T1486` and `T1567` entries; the parent's `AML.T0096 / AML.T0017 / AML.T0051` entries do not apply to ransomware-as-a-class but may apply if AI-system data is exfiltrated within the ransomware operation.
 
 ATLAS pinned to v2026.07 (August 2026). ATT&CK pinned to v19.2 (August 2026). Both are explicit version pins — never silently upgraded.