@blamejs/exceptd-skills 0.12.7 → 0.12.9

package/data/rfc-references.json

@@ -320,5 +320,149 @@
       "pqc-first"
     ],
     "last_verified": "2026-05-11"
+  },
+  "RFC-7489": {
+    "number": 7489,
+    "title": "Domain-based Message Authentication, Reporting, and Conformance (DMARC)",
+    "status": "Informational",
+    "published": "2015-03",
+    "tracker": "https://www.rfc-editor.org/info/rfc7489",
+    "relevance": "Defines DMARC — the email-authentication policy framework that binds SPF + DKIM results to a published domain-owner policy. Operator-facing email security depends on a published DMARC record with `p=reject` or `p=quarantine`; relaxed policies (`p=none`) are equivalent to no DMARC for spoofing-defense purposes. Cited alongside DKIM (RFC 6376) and SPF (RFC 7208) as the authoritative tri-RFC for anti-spoofing posture.",
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-6376": {
+    "number": 6376,
+    "title": "DomainKeys Identified Mail (DKIM) Signatures",
+    "status": "Internet Standard",
+    "published": "2011-09",
+    "tracker": "https://www.rfc-editor.org/info/rfc6376",
+    "relevance": "Cryptographic signing of email by the originating domain. DMARC verification relies on either SPF or DKIM aligning with the From-header domain. Operationally, DKIM is the load-bearing half of DMARC — SPF breaks on legitimate forwarding paths; DKIM survives them. Key-length lag is the recurring framework gap: many deployments still use 1024-bit RSA keys despite IETF guidance to rotate to ≥2048-bit.",
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-7208": {
+    "number": 7208,
+    "title": "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email",
+    "status": "Proposed Standard",
+    "published": "2014-04",
+    "tracker": "https://www.rfc-editor.org/info/rfc7208",
+    "relevance": "Authorizes which IPs may send mail on behalf of a domain. DMARC's path-based authentication half. Limits: a strict 10-DNS-lookup ceiling that operators routinely blow past through nested includes, leading to permerror DMARC outcomes; SPF breaks across legitimate forwarders, which is why DKIM (RFC 6376) is the load-bearing half operationally.",
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-8616": {
+    "number": 8616,
+    "title": "Email Authentication for Internationalized Mail",
+    "status": "Proposed Standard",
+    "published": "2019-06",
+    "tracker": "https://www.rfc-editor.org/info/rfc8616",
+    "relevance": "Updates DKIM / SPF / DMARC handling for internationalized domain names (IDN) and internationalized email-address local parts. Operator-facing: phishing campaigns increasingly leverage IDN homoglyphs (e.g. Cyrillic `а` for Latin `a`), and a DMARC implementation that doesn't honor RFC 8616 normalization rules can fail to align IDN-bearing From-headers correctly. Treat as a compatibility prerequisite for any anti-spoofing posture covering global mail flows.",
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-8461": {
+    "number": 8461,
+    "title": "SMTP MTA Strict Transport Security (MTA-STS)",
+    "status": "Proposed Standard",
+    "published": "2018-09",
+    "tracker": "https://www.rfc-editor.org/info/rfc8461",
+    "relevance": "Forces TLS on inbound SMTP between MTAs that publish a `_mta-sts` policy. Closes the historical 'opportunistic-TLS-downgrade' attack window where a network-positioned attacker stripped the STARTTLS handshake. Operator-facing: an MTA-STS policy in `enforce` mode plus monitoring via TLSRPT (RFC 8460) is the baseline for inbound email confidentiality. Phishing-defense relevance is indirect — STARTTLS stripping enables session-layer manipulation that downstream defenses (DMARC, content classifiers) cannot recover from.",
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "ISO-29147": {
+    "number": null,
+    "title": "ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure",
+    "status": "International Standard",
+    "published": "2018-10",
+    "tracker": "https://www.iso.org/standard/72311.html",
+    "relevance": "Internationally-recognized vulnerability-disclosure procedure standard. Operator-facing: an org claiming a CVD program must demonstrate the documented procedures cover receipt, triage, advisory drafting, notification, and post-disclosure review. Twin to ISO 30111 (handling); together they form the disclosure ↔ handling pair. The RFC 9116 (security.txt) artifact is the operator-facing surface that operationalizes ISO 29147 receipt requirements.",
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "ISO-30111": {
+    "number": null,
+    "title": "ISO/IEC 30111:2019 Information technology — Security techniques — Vulnerability handling processes",
+    "status": "International Standard",
+    "published": "2019-10",
+    "tracker": "https://www.iso.org/standard/69725.html",
+    "relevance": "Internal handling counterpart to ISO 29147. Defines the internal processes (investigation, resolution, release) that follow a disclosed vulnerability through to fix. Operator-facing: paired with ISO 29147 it supplies the end-to-end CVD lifecycle. Many compliance frameworks (NIS2, EU CRA) reference 'a documented vulnerability handling process'; ISO 30111 is the canonical artifact that satisfies the wording.",
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-9116": {
+    "number": 9116,
+    "title": "A File Format to Aid in Security Vulnerability Disclosure",
+    "status": "Proposed Standard",
+    "published": "2022-04",
+    "tracker": "https://www.rfc-editor.org/info/rfc9116",
+    "relevance": "Defines the `/.well-known/security.txt` file format. Operator-facing CVD entry point: researchers reaching a domain consult `/.well-known/security.txt` for the disclosure contact + policy URL + preferred encryption + acknowledgments page. Absence is a recurring CVD-friction finding; presence with a stale `Expires` header is equivalent to absence. Pair with ISO 29147 receipt requirements.",
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "CSAF-2.0": {
+    "number": null,
+    "title": "OASIS Common Security Advisory Framework Version 2.0",
+    "status": "OASIS Standard",
+    "published": "2022-11",
+    "tracker": "https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html",
+    "relevance": "Machine-readable security advisory format adopted by EU CRA, CISA, and major vendor PSIRTs. Replaces the CVRF-1.2 format. Operator-facing: CSAF 2.0 documents carry the same advisory content traditionally found in vendor PDFs but in a parseable JSON form that consumers can ingest for fleet-wide impact assessment. exceptd emits CSAF-2.0 close.evidence_package bundles from `exceptd run --format csaf-2.0` for downstream auditor consumption.",
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-6545": {
+    "number": 6545,
+    "title": "Real-time Inter-network Defense (RID)",
+    "status": "Proposed Standard",
+    "published": "2012-04",
+    "tracker": "https://www.rfc-editor.org/info/rfc6545",
+    "relevance": "Defines the RID schema for exchanging incident-response data between organizations and CSIRTs. Operator-facing relevance is via the IODEF (RFC 7970) payload that RID transports — the pair is the IETF-standardized cross-organizational incident-coordination protocol. Adoption lags; in practice many SOCs use ad-hoc CSV/JSON exchanges instead, leaving compliance with 'documented coordination channel' requirements weakly evidenced.",
+    "skills_referencing": [
+      "incident-response-playbook"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-6546": {
+    "number": 6546,
+    "title": "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS",
+    "status": "Proposed Standard",
+    "published": "2012-04",
+    "tracker": "https://www.rfc-editor.org/info/rfc6546",
+    "relevance": "Specifies the HTTP-over-TLS transport for RID (RFC 6545) messages. Operator-facing: provides the wire-level protocol for IODEF/RID message exchange when an organization commits to standardized incident-data coordination. Pair this with RFC 6545 (schema) and RFC 7970 (IODEF v2 payload).",
+    "skills_referencing": [
+      "incident-response-playbook"
+    ],
+    "last_verified": "2026-05-13"
+  },
+  "RFC-7970": {
+    "number": 7970,
+    "title": "The Incident Object Description Exchange Format Version 2",
+    "status": "Proposed Standard",
+    "published": "2016-11",
+    "tracker": "https://www.rfc-editor.org/info/rfc7970",
+    "relevance": "IODEF v2 — the structured-incident payload format carried by RID. Operator-facing: IODEF v2 is the canonical machine-readable incident record. Use cases include cross-CSIRT coordination, regulator submissions where structured data is requested, and SIEM-to-SIEM federation. Adoption is sector-uneven; healthcare and financial sectors have stronger uptake than general industry.",
+    "skills_referencing": [
+      "incident-response-playbook"
+    ],
+    "last_verified": "2026-05-13"
   }
 }

package/lib/playbook-runner.js

@@ -418,26 +418,118 @@ function analyze(playbookId, directiveId, detectResult, agentSignals = {}) {
   const an = resolvedPhase(playbook, directiveId, 'analyze');
   const directive = findDirective(playbook, directiveId);
 
-  // Match catalogued CVEs from the domain.cve_refs list. The agent submits
-  // signal values; engine joins to the catalog for RWEP context.
-  // VEX filter (agentSignals.vex_filter): a set of CVE IDs the operator
-  // has formally declared not_affected via a CycloneDX/OpenVEX statement.
-  // We drop those from matched_cves before scoring, and surface them
-  // separately so the analyze response still records the disposition.
+  // Resolve catalogued CVEs from the domain.cve_refs list. This list is the
+  // playbook's CVE scan-coverage enumeration — every CVE this playbook can
+  // detect. By itself it is NOT a statement that the operator is affected by
+  // any of these CVEs; affected-ness requires evidence correlation in detect.
+  //
+  // Two distinct sets are computed below:
+  //
+  //   catalogBaselineCves — every CVE the playbook scans for, with full
+  //       per-CVE catalog context (RWEP / KEV / CVSS / AI-discovery /
+  //       active-exploitation / patch state). Always populated when the
+  //       playbook has domain.cve_refs. Each entry carries correlated_via=null
+  //       and a `note` flagging it as catalog-only.
+  //
+  //   matchedCves       — CVEs the operator's submitted evidence actually
+  //       correlates to. Correlation paths:
+  //         (a) An indicator fired (verdict === 'hit') whose attack_ref or
+  //             atlas_ref intersects the CVE's attack_refs / atlas_refs in
+  //             the catalog.
+  //         (b) An agentSignal explicitly references the CVE id with a
+  //             truthy value (`agentSignals[cveId] === true`) or with a
+  //             string value 'hit' / 'detected' / 'affected'.
+  //       Each entry carries correlated_via=<reason string> so downstream
+  //       consumers (CSAF / SARIF / OpenVEX / human renderer) can show the
+  //       provenance, and so an empty matchedCves means "no evidence
+  //       correlated to operator's submission" rather than "playbook has
+  //       no CVEs of interest."
+  //
+  // VEX filter (agentSignals.vex_filter): a set of CVE IDs the operator has
+  // formally declared not_affected via CycloneDX/OpenVEX. VEX-dropped CVEs
+  // are removed from BOTH arrays (they're not affected — neither correlated
+  // nor part of effective scan coverage for this run).
   const cveRefs = playbook.domain.cve_refs || [];
   const vexFilter = agentSignals.vex_filter instanceof Set ? agentSignals.vex_filter
     : (Array.isArray(agentSignals.vex_filter) ? new Set(agentSignals.vex_filter) : null);
-  const allMatches = cveRefs.map(id => xref.byCve(id)).filter(r => r.found);
-  const matchedCves = vexFilter
-    ? allMatches.filter(c => !vexFilter.has(c.cve_id))
-    : allMatches;
+  const allCves = cveRefs.map(id => xref.byCve(id)).filter(r => r.found);
+  const catalogBaselineCves = vexFilter
+    ? allCves.filter(c => !vexFilter.has(c.cve_id))
+    : allCves;
   const vexDropped = vexFilter
-    ? allMatches.filter(c => vexFilter.has(c.cve_id)).map(c => c.cve_id)
+    ? allCves.filter(c => vexFilter.has(c.cve_id)).map(c => c.cve_id)
     : [];
 
-  // RWEP composition: start from the catalogue's per-CVE rwep_score (already
-  // baked from KEV + PoC + AI-disc + active-exploitation + blast-radius), then
-  // adjust by playbook's rwep_inputs based on detect hits + agent signals.
+  // Build correlation map: cve_id -> array of "indicator_hit:<id>" / "signal:<id>" reasons.
+  const correlationsByCve = new Map();
+  const addCorrelation = (cveId, reason) => {
+    if (!correlationsByCve.has(cveId)) correlationsByCve.set(cveId, []);
+    const arr = correlationsByCve.get(cveId);
+    if (!arr.includes(reason)) arr.push(reason);
+  };
+  // (a) indicator-hit → CVE via shared attack_ref / atlas_ref.
+  const playbookDetect = resolvedPhase(playbook, directiveId, 'detect');
+  const indicatorRefs = new Map(); // indicator.id -> { attack_ref, atlas_ref }
+  for (const ind of (playbookDetect.indicators || [])) {
+    indicatorRefs.set(ind.id, { attack_ref: ind.attack_ref || null, atlas_ref: ind.atlas_ref || null });
+  }
+  const firedIndicators = (detectResult.indicators || []).filter(i => i.verdict === 'hit');
+  for (const fired of firedIndicators) {
+    const refs = indicatorRefs.get(fired.id) || { attack_ref: fired.attack_ref || null, atlas_ref: fired.atlas_ref || null };
+    if (!refs.attack_ref && !refs.atlas_ref) continue;
+    for (const c of catalogBaselineCves) {
+      const attackHit = refs.attack_ref && Array.isArray(c.attack_refs) && c.attack_refs.includes(refs.attack_ref);
+      const atlasHit = refs.atlas_ref && Array.isArray(c.atlas_refs) && c.atlas_refs.includes(refs.atlas_ref);
+      if (attackHit || atlasHit) addCorrelation(c.cve_id, `indicator_hit:${fired.id}`);
+    }
+  }
+  // (b) agentSignals explicitly referencing a CVE id.
+  for (const c of catalogBaselineCves) {
+    const sig = agentSignals[c.cve_id];
+    if (sig === true || sig === 'hit' || sig === 'detected' || sig === 'affected') {
+      addCorrelation(c.cve_id, `signal:${c.cve_id}`);
+    }
+  }
+
+  const matchedCves = catalogBaselineCves.filter(c => correlationsByCve.has(c.cve_id));
+
+  // Per-CVE shape — identical between matched_cves and catalog_baseline_cves
+  // so consumers can iterate either without branching. matched_cves entries
+  // carry a non-null correlated_via array; catalog_baseline_cves entries
+  // carry correlated_via:null and a `note` clarifying the field's intent.
+  const cveShape = (c, correlatedVia) => ({
+    cve_id: c.cve_id,
+    rwep: c.rwep_score,
+    cvss_score: c.entry?.cvss_score ?? null,
+    cvss_vector: c.entry?.cvss_vector ?? null,
+    cisa_kev: c.cisa_kev,
+    cisa_kev_date: c.entry?.cisa_kev_date ?? null,
+    cisa_kev_due_date: c.entry?.cisa_kev_due_date ?? null,
+    poc_available: c.entry?.poc_available ?? null,
+    ai_discovered: c.ai_discovered,
+    ai_assisted_weaponization: c.entry?.ai_assisted_weaponization ?? null,
+    active_exploitation: c.active_exploitation,
+    patch_available: c.entry?.patch_available ?? null,
+    patch_required_reboot: c.entry?.patch_required_reboot ?? null,
+    live_patch_available: c.entry?.live_patch_available ?? null,
+    epss_score: c.entry?.epss_score ?? null,
+    epss_date: c.entry?.epss_date ?? null,
+    atlas_refs: c.atlas_refs,
+    attack_refs: c.attack_refs,
+    affected_versions: c.entry?.affected_versions ?? null,
+    correlated_via: correlatedVia,
+  });
+
+  const matchedCveEntries = matchedCves.map(c => cveShape(c, correlationsByCve.get(c.cve_id)));
+  const catalogBaselineEntries = catalogBaselineCves.map(c => ({
+    ...cveShape(c, null),
+    note: 'Catalog-baseline entry — this CVE is in the playbook\'s scan coverage but no submitted evidence correlated to it. Not a statement that the operator is affected.',
+  }));
+
+  // RWEP composition: start from the per-CVE rwep_score of evidence-correlated
+  // matches (NOT catalog baseline) so RWEP base reflects what the operator's
+  // evidence actually surfaced. Adjust by playbook's rwep_inputs based on
+  // detect hits + agent signals.
   const baseRwep = matchedCves.length ? Math.max(...matchedCves.map(c => c.rwep_score)) : 0;
   let adjustedRwep = baseRwep;
   const rwepBreakdown = [];
@@ -495,27 +587,19 @@ function analyze(playbookId, directiveId, detectResult, agentSignals = {}) {
     // Pull every required field from the catalog entry; null is only emitted
     // when the catalog itself lacks the value, never when we just forgot to
     // forward it. EPSS is included because validate-cves --live populates it.
-    matched_cves: matchedCves.map(c => ({
-      cve_id: c.cve_id,
-      rwep: c.rwep_score,
-      cvss_score: c.entry?.cvss_score ?? null,
-      cvss_vector: c.entry?.cvss_vector ?? null,
-      cisa_kev: c.cisa_kev,
-      cisa_kev_date: c.entry?.cisa_kev_date ?? null,
-      cisa_kev_due_date: c.entry?.cisa_kev_due_date ?? null,
-      poc_available: c.entry?.poc_available ?? null,
-      ai_discovered: c.ai_discovered,
-      ai_assisted_weaponization: c.entry?.ai_assisted_weaponization ?? null,
-      active_exploitation: c.active_exploitation,
-      patch_available: c.entry?.patch_available ?? null,
-      patch_required_reboot: c.entry?.patch_required_reboot ?? null,
-      live_patch_available: c.entry?.live_patch_available ?? null,
-      epss_score: c.entry?.epss_score ?? null,
-      epss_date: c.entry?.epss_date ?? null,
-      atlas_refs: c.atlas_refs,
-      attack_refs: c.attack_refs,
-      affected_versions: c.entry?.affected_versions ?? null,
-    })),
+    //
+    // matched_cves — evidence-correlated only. Each entry has a non-null
+    // correlated_via[] array naming the indicator hits or agent signals that
+    // tied the operator's submission to this CVE. Empty array means the
+    // playbook's scan coverage saw no matching evidence in this run.
+    matched_cves: matchedCveEntries,
+    // catalog_baseline_cves — every CVE the playbook scans for, with the
+    // same per-CVE shape but correlated_via=null and a note explaining the
+    // field is scan-coverage metadata, NOT an operator-affected list. Use
+    // this when surfacing "what CVEs does this playbook check for?" Use
+    // matched_cves when surfacing "what CVEs is the operator actually
+    // affected by based on submitted evidence?"
+    catalog_baseline_cves: catalogBaselineEntries,
     rwep: { base: baseRwep, adjusted: adjustedRwep, breakdown: rwepBreakdown, threshold: directive ? resolvedPhase(playbook, directiveId, 'direct').rwep_threshold : null },
     blast_radius_score: blastRadiusScore,
     blast_radius_basis: blastRubric.find(r => r.blast_radius_score === blastRadiusScore) || null,

package/lib/prefetch.js

@@ -80,15 +80,24 @@ const SOURCES = {
       .filter(Boolean),
   },
   pins: {
-    description: "MITRE GitHub releases for ATLAS / ATT&CK / D3FEND / CWE pin checks",
+    description: "MITRE GitHub releases for ATLAS / ATT&CK pin checks",
     rate: { tokens: 30, windowMs: 60 * 60_000 },   // anon: 60/h, leave headroom
     rate_with_key: { tokens: 500, windowMs: 60 * 60_000 },
     concurrency: 2,
+    // D3FEND and CWE were previously listed here but neither project
+    // publishes via GitHub Releases — D3FEND distributes the ontology
+    // from d3fend/d3fend-ontology without tagged releases, and CWE
+    // ships its catalog as XML/JSON downloads from cwe.mitre.org rather
+    // than a GitHub repo. The old api.github.com URLs (mitre/cwe and
+    // d3fend/d3fend-data) returned HTTP 404 on every refresh, surfacing
+    // as "2 error(s)" in the prefetch summary. Pin currency for those
+    // two frameworks is tracked via lib/upstream-check.js against
+    // cwe.mitre.org and d3fend.mitre.org respectively; the prefetch
+    // registry only contains sources that actually have a GitHub
+    // Releases feed to poll.
     expand: () => [
       { id: "mitre-atlas__atlas-data__releases", url: "https://api.github.com/repos/mitre-atlas/atlas-data/releases?per_page=5" },
       { id: "mitre-attack__attack-stix-data__releases", url: "https://api.github.com/repos/mitre-attack/attack-stix-data/releases?per_page=5" },
-      { id: "d3fend__d3fend-data__releases", url: "https://api.github.com/repos/d3fend/d3fend-data/releases?per_page=5" },
-      { id: "mitre__cwe__releases", url: "https://api.github.com/repos/mitre/cwe/releases?per_page=5" },
     ],
   },
 };
@@ -364,14 +373,26 @@ async function main() {
   const opts = parseArgs(process.argv);
   if (opts.help) {
     printHelp();
-    process.exit(0);
+    return;
   }
+  // Why process.exitCode and not process.exit():
+  // On Windows + Node 25 (libuv), calling process.exit() synchronously
+  // while in-flight fetch / AbortController teardown is still mid-close
+  // produced `Assertion failed: !(handle->flags & UV_HANDLE_CLOSING),
+  // file src\win\async.c, line 76` followed by exit 3221226505
+  // (STATUS_STACK_BUFFER_OVERRUN). The summary line had already
+  // flushed, so operators saw the crash *after* their summary —
+  // contractually correct but visibly noisy. Letting the event loop
+  // drain naturally — via exitCode + return — lets undici's connection
+  // pool and the AbortController signal listeners finish teardown
+  // before the process exits, eliminating the assertion. Same pattern
+  // documented in CLAUDE.md for v0.11.11's `ci` #100 regression.
   try {
     const result = await prefetch(opts);
-    process.exit(result.errors > 0 ? 1 : 0);
+    process.exitCode = result.errors > 0 ? 1 : 0;
   } catch (err) {
     console.error(`prefetch: fatal: ${err.message}`);
-    process.exit(2);
+    process.exitCode = 2;
   }
 }
 

package/lib/refresh-external.js

@@ -43,6 +43,21 @@ const ROOT = path.join(__dirname, "..");
 const ABS = (p) => path.join(ROOT, p);
 const TODAY = new Date().toISOString().slice(0, 10);
 
+// v0.12.8: the CVE catalog path used by refresh-external is overridable so
+// tests can redirect to a tempdir instead of mutating the real shipped
+// data/cve-catalog.json. Resolution order:
+//   1. opts.catalog (--catalog CLI arg)
+//   2. process.env.EXCEPTD_CVE_CATALOG (env var)
+//   3. ROOT/data/cve-catalog.json (default)
+// All four write-sites in this file route through resolveCatalogPath() so
+// that the redirect is consistent across the advisory-import, GHSA-import,
+// and per-source merge code paths.
+function resolveCatalogPath(opts) {
+  if (opts && opts.catalog) return path.resolve(opts.catalog);
+  if (process.env.EXCEPTD_CVE_CATALOG) return path.resolve(process.env.EXCEPTD_CVE_CATALOG);
+  return ABS("data/cve-catalog.json");
+}
+
 function parseArgs(argv) {
   const out = {
     apply: false,
@@ -64,6 +79,8 @@ function parseArgs(argv) {
     else if (a === "--help" || a === "-h") out.help = true;
     else if (a === "--advisory") { out.advisory = argv[++i]; }
     else if (a.startsWith("--advisory=")) { out.advisory = a.slice("--advisory=".length); }
+    else if (a === "--catalog") { out.catalog = argv[++i]; }
+    else if (a.startsWith("--catalog=")) { out.catalog = a.slice("--catalog=".length); }
     else if (a === "--from-cache") {
       // accept either --from-cache <path> or --from-cache (default path)
       const next = argv[i + 1];
@@ -204,7 +221,7 @@ const KEV_SOURCE = {
     }
     ctx.cveCatalog._meta = ctx.cveCatalog._meta || {};
     ctx.cveCatalog._meta.last_updated = TODAY;
-    writeJson(ABS("data/cve-catalog.json"), ctx.cveCatalog);
+    writeJson(ctx.cvePath || ABS("data/cve-catalog.json"), ctx.cveCatalog);
     return { updated: updated + added, added, drift_updated: updated, errors };
   },
 };
@@ -279,7 +296,7 @@ const EPSS_SOURCE = {
     }
     ctx.cveCatalog._meta = ctx.cveCatalog._meta || {};
     ctx.cveCatalog._meta.last_updated = TODAY;
-    writeJson(ABS("data/cve-catalog.json"), ctx.cveCatalog);
+    writeJson(ctx.cvePath || ABS("data/cve-catalog.json"), ctx.cveCatalog);
     return { updated, errors };
   },
 };
@@ -324,7 +341,7 @@ const NVD_SOURCE = {
     }
     ctx.cveCatalog._meta = ctx.cveCatalog._meta || {};
     ctx.cveCatalog._meta.last_updated = TODAY;
-    writeJson(ABS("data/cve-catalog.json"), ctx.cveCatalog);
+    writeJson(ctx.cvePath || ABS("data/cve-catalog.json"), ctx.cveCatalog);
     return { updated, errors };
   },
 };
@@ -652,17 +669,20 @@ function rfcDiffFromCache(ctx) {
 
 function pinsDiffFromCache(ctx) {
   // Cache layout under pins/: <owner>__<repo>__releases.json arrays.
+  // Only repos that publish via GitHub Releases live here — D3FEND and CWE
+  // were removed in the same pass that pruned them from lib/prefetch.js's
+  // SOURCES.pins (neither project tags releases on GitHub; D3FEND ships
+  // the ontology from d3fend/d3fend-ontology without tagged releases,
+  // and CWE distributes XML from cwe.mitre.org). Pin currency for those
+  // two frameworks is monitored via lib/upstream-check.js against their
+  // canonical mitre.org endpoints, not through the prefetch cache.
   const PIN_REPOS = {
     atlas_version:  "mitre-atlas__atlas-data__releases",
     attack_version: "mitre-attack__attack-stix-data__releases",
-    d3fend_version: "d3fend__d3fend-data__releases",
-    cwe_version:    "mitre__cwe__releases",
   };
   const localOf = {
     atlas_version:  ctx.manifest.atlas_version,
     attack_version: ctx.manifest.attack_version,
-    d3fend_version: ctx.d3fendCatalog?._meta?.version || ctx.d3fendCatalog?._meta?.d3fend_version || null,
-    cwe_version:    ctx.cweCatalog?._meta?.version || ctx.cweCatalog?._meta?.cwe_version || null,
   };
   const diffs = [];
   let errors = 0;
@@ -714,9 +734,11 @@ function synthesizeFromFixture(ctx, sourceName) {
 // --- IO helpers --------------------------------------------------------
 
 function loadCtx(opts) {
+  const cvePath = resolveCatalogPath(opts);
   const ctx = {
     manifest: JSON.parse(fs.readFileSync(ABS("manifest.json"), "utf8")),
-    cveCatalog: JSON.parse(fs.readFileSync(ABS("data/cve-catalog.json"), "utf8")),
+    cvePath, // remember the resolved path; applyDiff callbacks write through it
+    cveCatalog: JSON.parse(fs.readFileSync(cvePath, "utf8")),
     rfcCatalog: JSON.parse(fs.readFileSync(ABS("data/rfc-references.json"), "utf8")),
     cweCatalog: JSON.parse(fs.readFileSync(ABS("data/cwe-catalog.json"), "utf8")),
     d3fendCatalog: JSON.parse(fs.readFileSync(ABS("data/d3fend-catalog.json"), "utf8")),
@@ -828,7 +850,8 @@ async function seedSingleAdvisory(opts) {
   }
 
   // Apply: write to cve-catalog.json with the _auto_imported flag.
-  const catalogPath = ABS("data/cve-catalog.json");
+  // v0.12.8: honor --catalog / EXCEPTD_CVE_CATALOG so tests can redirect.
+  const catalogPath = resolveCatalogPath(opts);
   const catalog = JSON.parse(fs.readFileSync(catalogPath, "utf8"));
   if (catalog[cveId] && !catalog[cveId]._auto_imported && !catalog[cveId]._draft) {
     // Refuse to overwrite a human-curated entry.

package/lib/schemas/skill-frontmatter.schema.json

@@ -71,9 +71,9 @@
       "type": "array",
       "items": {
         "type": "string",
-        "pattern": "^(RFC-[0-9]+|DRAFT-[A-Z0-9-]+)$"
+        "pattern": "^(RFC-[0-9]+|DRAFT-[A-Z0-9-]+|ISO-[0-9]+|CSAF-[0-9]+\\.[0-9]+)$"
       },
-      "description": "Optional. IETF RFC numbers (e.g. RFC-8446) or Internet-Draft slugs (e.g. DRAFT-IETF-TLS-ECDHE-MLKEM) the skill depends on. Each must resolve in data/rfc-references.json."
+      "description": "Optional. IETF RFC numbers (e.g. RFC-8446), Internet-Draft slugs (e.g. DRAFT-IETF-TLS-ECDHE-MLKEM), ISO standards (e.g. ISO-29147), or OASIS CSAF advisory format (CSAF-2.0). Each must resolve in data/rfc-references.json."
     },
     "cwe_refs": {
       "type": "array",

package/manifest-snapshot.json

@@ -1,6 +1,6 @@
 {
   "_comment": "Auto-generated by scripts/refresh-manifest-snapshot.js — do not hand-edit. Public skill surface used by check-manifest-snapshot.js to detect breaking removals.",
-  "_generated_at": "2026-05-13T04:36:44.853Z",
+  "_generated_at": "2026-05-13T15:30:27.029Z",
   "atlas_version": "5.1.0",
   "skill_count": 38,
   "skills": [