@blamejs/exceptd-skills 0.12.6 → 0.12.8

package/data/playbooks/secrets.json

@@ -376,7 +376,7 @@
         {
           "id": "aws-access-key-id",
           "type": "log_pattern",
-          "value": "AKIA[0-9A-Z]{16}",
+          "value": "Within the secret-regex-scan-text-files artifact, bounded by the repo-tree scope and applied to env-files, auth-config-files, and iac-credential-bearers content: regex AKIA[0-9A-Z]{16}",
           "description": "AWS Access Key ID. Long-lived IAM user credential. Scraper-bot priority target.",
           "confidence": "deterministic",
           "deterministic": true,
@@ -448,7 +448,7 @@
         {
           "id": "ssh-private-key-block",
           "type": "log_pattern",
-          "value": "-----BEGIN ((RSA|EC|DSA|OPENSSH|ENCRYPTED) )?PRIVATE KEY-----",
+          "value": "Across the union of secret-regex-scan-text-files (text-file content) and ssh-private-keys (file inventory) artifacts: regex `-----BEGIN ((RSA|EC|DSA|OPENSSH|ENCRYPTED) )?PRIVATE KEY-----` matches, OR the ssh-private-keys artifact lists any private-key file under the repo tree (committed key material is always a finding regardless of regex hit on the surrounding text)",
           "description": "Inline SSH/PEM private key material in a text file.",
           "confidence": "deterministic",
           "deterministic": true,
@@ -475,7 +475,7 @@
         {
           "id": "world-writable-env-file",
           "type": "file_path",
-          "value": ".env / .env.* / .envrc with mode 0666 or 0664 (group/world writable)",
+          "value": "Within the world-writable-secret-files artifact, restricted to entries from the env-files artifact: any .env / .env.* / .envrc with mode 0666 or 0664 (group/world writable)",
           "description": "Env file writable by group or world. Tampering primitive.",
           "confidence": "deterministic",
           "deterministic": true,
@@ -484,7 +484,7 @@
         {
           "id": "ssh-key-bad-perms",
           "type": "file_path",
-          "value": "~/.ssh/id_* file with mode != 0600",
+          "value": "Within the world-writable-secret-files artifact, restricted to entries from the ssh-private-keys artifact and ~/.ssh/id_* paths: any private-key file with mode != 0600",
           "description": "SSH private key with permissive permissions. ssh-agent refuses to load; user often chmods to 0644 or 0666 'to make it work'.",
           "confidence": "deterministic",
           "deterministic": true,

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/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 };
   },
 };
@@ -714,9 +731,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 +847,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-13T03:58:09.357Z",
+  "_generated_at": "2026-05-13T13:51:52.021Z",
   "atlas_version": "5.1.0",
   "skill_count": 38,
   "skills": [