@blamejs/exceptd-skills 0.12.22 → 0.12.23

package/data/_indexes/_meta.json

@@ -1,10 +1,10 @@
 {
   "schema_version": "1.1.0",
-  "generated_at": "2026-05-15T06:49:36.722Z",
+  "generated_at": "2026-05-15T14:25:49.905Z",
   "generator": "scripts/build-indexes.js",
   "source_count": 50,
   "source_hashes": {
-    "manifest.json": "2adf0e88322f3903ffd323dbcee69b406c7d801a1539cb1e79e569e47bbafc4c",
+    "manifest.json": "6fda2187c6d4dfbc333a711cea0991d59c459ded1ed5005126a8c555b9e77cf2",
     "data/atlas-ttps.json": "20339e0ae3cd89c06f1385be31c50f408f827edc2e8ab8aef026ade3bcf0a917",
     "data/attack-techniques.json": "6db08a8e8a4d03d9309b1d185112de7f3c9595d2cd3d24566b7ce0b3b8aa5d1a",
     "data/cve-catalog.json": "7936ba3c8f27156235bf327830e8f1a684658865e97f089aed98b2a7cdbb88ef",
@@ -83,7 +83,7 @@
     "frequency_fields": 7,
     "activity_feed_events": 50,
     "catalog_summaries": 11,
-    "stale_content_findings": 0
+    "stale_content_findings": 1
   },
   "invalidation_note": "If any source file in source_hashes has a different SHA-256 than recorded here, the indexes are stale. Re-run `npm run build-indexes`."
 }

package/data/_indexes/stale-content.json

@@ -3,12 +3,19 @@
     "schema_version": "1.0.0",
     "reference_date": "2026-05-01",
     "note": "Stale-content snapshot derived from audit-cross-skill checks. Re-runs of build-indexes against the same inputs produce byte-identical output (reference_date is manifest.threat_review_date, not 'now'). audit-cross-skill.js remains the canonical interactive audit.",
-    "finding_count": 0,
+    "finding_count": 1,
     "by_severity": {
       "high": 0,
-      "medium": 0,
+      "medium": 1,
       "low": 0
     }
   },
-  "findings": []
+  "findings": [
+    {
+      "severity": "medium",
+      "category": "badge_drift",
+      "artifact": "README.md",
+      "detail": "jurisdictions badge shows 35, live count is 34"
+    }
+  ]
 }

package/data/playbooks/ai-api.json

@@ -297,7 +297,7 @@
         "monitor": 40,
         "close": 25
       },
-      "framework_lag_declaration": "NIST 800-53 SI-3/SC-7/AC-2, ISO 27001:2022 A.8.16, SOC 2 CC6/CC7, EU AI Act Art.15 are all structurally insufficient for AI-API C2. The shared failure: each control treats the AI API endpoint as a legitimate authorized SaaS, the service account using it as authorized, and the traffic over it as business-as-usual. The SesameOp pattern operates entirely inside that authorized envelope. Until frameworks add 'AI-API egress baseline + content inspection + bearer-token-to-process attribution' controls, anomaly-detection audit opinions provide zero signal about AI-as-C2 exposure. Companion gap: secrets-management controls (IA-5, A.8.5) focus on repository-committed keys and ignore the dotfile credential surface where most developer keys actually live. Lag = ~190 days behind the SesameOp pattern's first documentation; no framework body has issued draft language as of 2026-05-11.",
+      "framework_lag_declaration": "NIST 800-53 SI-3/SC-7/AC-2, ISO 27001:2022 A.8.16, SOC 2 CC6/CC7, EU AI Act Art.15 are all structurally insufficient for AI-API C2. The shared failure: each control treats the AI API endpoint as a legitimate authorized SaaS, the service account using it as authorized, and the traffic over it as business-as-usual. The SesameOp pattern operates entirely inside that authorized envelope. Until frameworks add 'AI-API egress baseline + content inspection + bearer-token-to-process attribution' controls, anomaly-detection audit opinions provide zero signal about AI-as-C2 exposure. Companion gap: secrets-management controls (IA-5, A.8.5) focus on repository-committed keys and ignore the dotfile credential surface where most developer keys actually live. Lag = ~190 days behind the SesameOp pattern's first documentation; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat egress monitoring and trust-boundary enforcement as outcomes without naming AI-API endpoints as a distinct exfiltration channel — B3/B4 evidence passes while authorized-SaaS C2 channels stay invisible. AU Essential 8 ML2 Application Control (E8 M.1) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1546 cover process-lineage and admin-privilege restriction, but Essential 8 does not yet enumerate AI-API endpoints in its allowlist guidance — operators who allow AI SaaS at the proxy retain no per-token attribution.",
       "skill_chain": [
         {
           "skill": "ai-c2-detection",

package/data/playbooks/containers.json

@@ -257,7 +257,7 @@
         "monitor": 65,
         "close": 35
       },
-      "framework_lag_declaration": "NIST 800-190 + CIS K8s Benchmark + NIST 800-53 CM-7 + ISO A.8.9 + PCI Req.2.2 collectively cover container hardening but accept cluster-wide attestation as evidence. None require per-manifest analysis as a control. Manifest drift in GitOps repos can introduce privileged: true / hostPID / unscoped capabilities faster than any attestation cadence. EU CRA + NIST SSDF + SLSA cover supply-chain posture but most orgs are at SLSA L1-L2 without digest pinning. Gap = ~21 days between manifest drift and review cadence; per-CVE gap (e.g. Leaky Vessels) is hours from public PoC to weaponization vs. weeks of node-staging windows.",
+      "framework_lag_declaration": "NIST 800-190 + CIS K8s Benchmark + NIST 800-53 CM-7 + ISO A.8.9 + PCI Req.2.2 collectively cover container hardening but accept cluster-wide attestation as evidence. None require per-manifest analysis as a control. Manifest drift in GitOps repos can introduce privileged: true / hostPID / unscoped capabilities faster than any attestation cadence. EU CRA + NIST SSDF + SLSA cover supply-chain posture but most orgs are at SLSA L1-L2 without digest pinning. Gap = ~21 days between manifest drift and review cadence; per-CVE gap (e.g. Leaky Vessels) is hours from public PoC to weaponization vs. weeks of node-staging windows. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat container-runtime hardening as an outcome assessable via attestation, without binding evidence to per-manifest privileged-flag or host-namespace exposure. AU Essential 8 ML2 Application Control (E8 M.1) + Configure Microsoft Office Macro Settings (E8 M.2 — by analogy, application-execution policy) plus ACSC ISM-1546 and ISM-1683 (workload isolation) cover application execution and workload separation, but Essential 8 has no maturity-level requirement that bans privileged + hostPID + hostNetwork in cluster manifests.",
       "skill_chain": [
         {
           "skill": "container-runtime-security",

package/data/playbooks/cred-stores.json

@@ -236,7 +236,7 @@
         "monitor": 60,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-63b AAL specs, NIST 800-53 IA-2/IA-5, ISO A.5.16/A.5.17, NIS2 Art.21(2)(j), PCI-DSS Req.8 collectively specify target authenticator properties (phishing-resistant, short-lived, MFA-gated). They do not require enumeration of credentials actually present on developer endpoints. SSO + MFA attestation is accepted as evidence even when local credential stores hold long-lived bearer tokens that bypass SSO. Gap = ~25 days between credential-store drift (new PAT issued, new long-lived AWS key created) and any framework's review cadence.",
+      "framework_lag_declaration": "NIST 800-63b AAL specs, NIST 800-53 IA-2/IA-5, ISO A.5.16/A.5.17, NIS2 Art.21(2)(j), PCI-DSS Req.8 collectively specify target authenticator properties (phishing-resistant, short-lived, MFA-gated). They do not require enumeration of credentials actually present on developer endpoints. SSO + MFA attestation is accepted as evidence even when local credential stores hold long-lived bearer tokens that bypass SSO. Gap = ~25 days between credential-store drift (new PAT issued, new long-lived AWS key created) and any framework's review cadence. UK CAF Principle B2 (Identity and Access Control) defines authentication outcomes and credential-management practice, but does not require enumeration of credentials persisted in local credential stores outside the SSO/IdP envelope. AU Essential 8 ML2 MFA (E8 M.4) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1546 cover authenticator strength and admin-privilege scope but treat long-lived bearer tokens stored in dotfiles / OS keychains as out of frame — Essential 8 evidence passes while landed-attacker credential harvest stays trivial.",
       "skill_chain": [
         {
           "skill": "identity-assurance",

package/data/playbooks/crypto-codebase.json

@@ -322,7 +322,7 @@
         "monitor": 45,
         "close": 25
       },
-      "framework_lag_declaration": "Frameworks structurally bind the OPERATING organization, not the library author. NIST 800-53 SC-13, ISO 27001:2022 A.8.24/A.8.28, PCI DSS 4.0 §3.6/§8.3.2 all push obligations downstream to consumers who inherit the shipped defaults. EU CRA Annex I §1 is the first framework with direct upstream obligations on manufacturers of products with digital elements, but its binding date for vulnerability-handling and SBOM provisions is 2026-09-11 (four months from now) with full compliance 2027-12-11. NIS2 Art.21(2)(g) exerts indirect pressure via essential-entity consumers. UK CAF C.5 + UK PSTI covers connected products only. ISO 27001:2022 A.8.28 'secure coding' is silent on PQC, KDF iteration minimums, RNG-source requirements, constant-time-implementation requirements — the longest structural laggard. NIST IR 8547 + OMB M-23-02 + CNSA 2.0 push federal-system PQC migration through 2030 but rely on procurement pressure to flow upstream. Gap = ~365 days from operational PQC readiness (2024-08-13 FIPS finalization) to binding library-author obligations (2026-09-11 EU CRA partial bind). Compensating controls (downstream-consumer adoption pressure, supply-chain auditing tools, voluntary SECURITY.md disclosure of cryptographic provenance) must close this gap pending EU CRA enforcement.",
+      "framework_lag_declaration": "Frameworks structurally bind the OPERATING organization, not the library author. NIST 800-53 SC-13, ISO 27001:2022 A.8.24/A.8.28, PCI DSS 4.0 §3.6/§8.3.2 all push obligations downstream to consumers who inherit the shipped defaults. EU CRA Annex I §1 is the first framework with direct upstream obligations on manufacturers of products with digital elements, but its binding date for vulnerability-handling and SBOM provisions is 2026-09-11 (four months from now) with full compliance 2027-12-11. NIS2 Art.21(2)(g) exerts indirect pressure via essential-entity consumers. UK CAF C.5 + UK PSTI covers connected products only. ISO 27001:2022 A.8.28 'secure coding' is silent on PQC, KDF iteration minimums, RNG-source requirements, constant-time-implementation requirements — the longest structural laggard. NIST IR 8547 + OMB M-23-02 + CNSA 2.0 push federal-system PQC migration through 2030 but rely on procurement pressure to flow upstream. Gap = ~365 days from operational PQC readiness (2024-08-13 FIPS finalization) to binding library-author obligations (2026-09-11 EU CRA partial bind). Compensating controls (downstream-consumer adoption pressure, supply-chain auditing tools, voluntary SECURITY.md disclosure of cryptographic provenance) must close this gap pending EU CRA enforcement. AU Essential 8 ML2 Patch Applications (E8 M.2) plus ACSC ISM-1138 (cryptographic-algorithm transition), ISM-0467 (approved cryptographic algorithms), and ISM-0471 (cryptographic protocol selection) reference downstream consumer migration but place no obligation on upstream library authors to ship PQC-by-default, KDF iteration minima, or constant-time implementations — Essential 8 evidence flows from operating-org posture, not from library-publisher posture.",
       "skill_chain": [
         {
           "skill": "pqc-first",

package/data/playbooks/crypto.json

@@ -288,7 +288,7 @@
         "monitor": 45,
         "close": 25
       },
-      "framework_lag_declaration": "Every framework in scope is structurally insufficient for HNDL. NIST 800-53 SC-8/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I all permit fully-classical cryptographic posture as 'strong cryptography'. NIST itself is the exception: FIPS 203/204/205 are finalized, NIST IR 8547 is a published migration roadmap, OMB M-23-02 mandates federal PQC inventory — but the 800-53 control catalog is unchanged. ISO 27001:2022 was published before PQC finalization and has no scheduled amendment. PCI Council and EU regulators are publicly aware but have not amended binding controls. Lag = ~180 days behind operational readiness (PQC has been production-ready since 2024-08-13) and 4-8+ years behind the CRQC horizon that drives the harvest-now-decrypt-later attack. Compensating controls (crypto-agility, hybrid algorithms, layered encryption envelopes) must close this gap before SLA-only compliance can be accepted.",
+      "framework_lag_declaration": "Every framework in scope is structurally insufficient for HNDL. NIST 800-53 SC-8/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I all permit fully-classical cryptographic posture as 'strong cryptography'. NIST itself is the exception: FIPS 203/204/205 are finalized, NIST IR 8547 is a published migration roadmap, OMB M-23-02 mandates federal PQC inventory — but the 800-53 control catalog is unchanged. ISO 27001:2022 was published before PQC finalization and has no scheduled amendment. PCI Council and EU regulators are publicly aware but have not amended binding controls. Lag = ~180 days behind operational readiness (PQC has been production-ready since 2024-08-13) and 4-8+ years behind the CRQC horizon that drives the harvest-now-decrypt-later attack. Compensating controls (crypto-agility, hybrid algorithms, layered encryption envelopes) must close this gap before SLA-only compliance can be accepted. UK CAF Principles B3 (Data Security) and B4 (System Security) treat cryptography as an outcome (data-in-transit + data-at-rest protection) without naming PQC migration or HNDL exposure as a B3/B4 requirement — CAF evidence passes against fully-classical posture. AU Essential 8 ML2 Patch Applications + Patch Operating Systems (E8 M.2) plus ACSC ISM-1138 (cryptographic-algorithm transition) and ISM-0467 (approved cryptographic algorithms) reference algorithm-suite policy, but ISM transition guidance remains advisory in 2026-05 and Essential 8 maturity levels do not bind PQC inventory + migration deadlines.",
       "skill_chain": [
         {
           "skill": "pqc-first",

package/data/playbooks/hardening.json

@@ -226,7 +226,7 @@
         "monitor": 65,
         "close": 30
       },
-      "framework_lag_declaration": "NIST CM-6, ISO A.8.9, Essential 8 OS Hardening, CMMC CM.L2-3.4.1/2 all permit baseline + change-management evidence without requiring continuous attestation of the specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement mode) that determine whether a vulnerable kernel is actually exploitable. Gap = ~21 days at typical orgs between drift event and review. For environments using GitOps-deployed kernel parameters, drift can occur faster than monitoring catches.",
+      "framework_lag_declaration": "NIST CM-6, ISO A.8.9, Essential 8 OS Hardening, CMMC CM.L2-3.4.1/2 all permit baseline + change-management evidence without requiring continuous attestation of the specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement mode) that determine whether a vulnerable kernel is actually exploitable. Gap = ~21 days at typical orgs between drift event and review. For environments using GitOps-deployed kernel parameters, drift can occur faster than monitoring catches. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat OS hardening as a system-security outcome assessable via baseline-and-change-management evidence, without binding to continuous attestation of specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement) — CAF evidence passes against a host whose flags drifted hours after the last review. AU Essential 8 ML2 Patch Operating Systems (E8 M.2) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1144 / ISM-1493 (vulnerability management) reference OS-hardening posture but do not enumerate the per-sysctl flag set whose state determines whether a vulnerable kernel is actually exploitable.",
       "skill_chain": [
         {
           "skill": "kernel-lpe-triage",

package/data/playbooks/kernel.json

@@ -224,7 +224,7 @@
         "monitor": 70,
         "close": 30
       },
-      "framework_lag_declaration": "NIST SI-2 + ISO A.8.8 + NIS2 Art.21(2)(c) permit 30-day patch SLAs that are inadequate for KEV-listed kernel LPEs with confirmed exploitation. NIST 800-53 Rev. 5.1.1 does not require KEV-aware prioritization, only risk-based — leaving it to implementer interpretation. Real-world tempo: weaponization in hours, patch SLA in weeks. Gap = ~28 days. Compensating controls (live-patch, MAC, kernel hardening) MUST close this gap before SLA-only compliance can be accepted.",
+      "framework_lag_declaration": "NIST SI-2 + ISO A.8.8 + NIS2 Art.21(2)(c) permit 30-day patch SLAs that are inadequate for KEV-listed kernel LPEs with confirmed exploitation. NIST 800-53 Rev. 5.1.1 does not require KEV-aware prioritization, only risk-based — leaving it to implementer interpretation. Real-world tempo: weaponization in hours, patch SLA in weeks. Gap = ~28 days. Compensating controls (live-patch, MAC, kernel hardening) MUST close this gap before SLA-only compliance can be accepted. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat patching as an outcome without binding to KEV-aware tempo; CAF evidence passes against the 30-day SLA that real-world weaponization beats. AU Essential 8 ML2 / ML3 Patch Operating Systems (E8 M.2) sets a 48-hour patch target for internet-facing services with known exploitation, and ACSC ISM-1144 / ISM-1493 (vulnerability management + critical patching) name kernel patching specifically — but Essential 8 maturity adoption surveys show ML3 attainment <15% across regulated AU entities, leaving the structural gap operational even where the framework anticipates it.",
       "skill_chain": [
         {
           "skill": "kernel-lpe-triage",

package/data/playbooks/mcp.json

@@ -326,7 +326,7 @@
         "monitor": 50,
         "close": 25
       },
-      "framework_lag_declaration": "Every framework in scope (NIST 800-53 SA-12/CM-7, ISO 27001:2022 A.5.19/A.5.20/A.8.30, SOC 2 CC9, NIS2 Art.21(2)(d), EU AI Act Art.15, EU CRA Art.13) is structurally insufficient. The shared structural failure: every control treats third-party software risk as a procurement event with a discrete vendor list, while MCP servers are continuously sideloaded by developers from package registries with no procurement signal, no enforced signing, and no allowlist that survives version drift. Until frameworks add a 'developer-installed AI tool plugin' control category with mandatory manifest signature verification + version pinning with integrity hash + provenance attestation, vendor-management audit opinions provide zero signal about MCP exposure. Gap = ~210 days behind operational reality; no framework body has issued draft language as of 2026-05-11.",
+      "framework_lag_declaration": "Every framework in scope (NIST 800-53 SA-12/CM-7, ISO 27001:2022 A.5.19/A.5.20/A.8.30, SOC 2 CC9, NIS2 Art.21(2)(d), EU AI Act Art.15, EU CRA Art.13) is structurally insufficient. The shared structural failure: every control treats third-party software risk as a procurement event with a discrete vendor list, while MCP servers are continuously sideloaded by developers from package registries with no procurement signal, no enforced signing, and no allowlist that survives version drift. Until frameworks add a 'developer-installed AI tool plugin' control category with mandatory manifest signature verification + version pinning with integrity hash + provenance attestation, vendor-management audit opinions provide zero signal about MCP exposure. Gap = ~210 days behind operational reality; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat third-party tooling as a procurement-and-supply-chain assurance outcome, with no Principle that names developer-installed AI tool plugins as a distinct surface — CAF B3/B4 evidence remains silent on MCP-server sideload. AU Essential 8 ML2 Application Control (E8 M.1) + Restrict Admin Privileges (E8 M.5) plus ACSC ISM-1490 (application control) and ISM-1657 (supply chain) cover application-execution allowlisting in principle, but Essential 8 maturity guidance assumes a discrete vendor list and does not enumerate registry-pulled MCP servers as application-control scope.",
       "skill_chain": [
         {
           "skill": "mcp-agent-trust",

package/data/playbooks/runtime.json

@@ -230,7 +230,7 @@
         "monitor": 65,
         "close": 35
       },
-      "framework_lag_declaration": "NIST CM-7 + AC-6, ISO A.8.2 + A.8.18, and NIS2 Art.21(2)(i) treat least-privilege and least-functionality as policy outcomes reviewable annually. They do not require programmatic enumeration of the specific primitives (sudoers NOPASSWD, non-baseline SUID, world-writable cron, host-mounted systemd services, listening sockets on non-loopback) that attackers use to convert foothold into root. A host can be CM-7/AC-6 compliant on paper while presenting dozens of LPE primitives to a landed attacker. Gap = ~21 days between drift and policy review at typical orgs; for fast-moving environments (containerized + GitOps-deployed), drift accumulates faster than annual review can catch.",
+      "framework_lag_declaration": "NIST CM-7 + AC-6, ISO A.8.2 + A.8.18, and NIS2 Art.21(2)(i) treat least-privilege and least-functionality as policy outcomes reviewable annually. They do not require programmatic enumeration of the specific primitives (sudoers NOPASSWD, non-baseline SUID, world-writable cron, host-mounted systemd services, listening sockets on non-loopback) that attackers use to convert foothold into root. A host can be CM-7/AC-6 compliant on paper while presenting dozens of LPE primitives to a landed attacker. Gap = ~21 days between drift and policy review at typical orgs; for fast-moving environments (containerized + GitOps-deployed), drift accumulates faster than annual review can catch. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat least-privilege as a system-security outcome assessable through control-design evidence, without binding to per-host enumeration of LPE primitives (sudoers NOPASSWD, non-baseline SUID, writable cron, host-mount services). AU Essential 8 ML2 Restrict Admin Privileges (E8 M.5) + Patch Operating Systems (E8 M.2) plus ACSC ISM-1175 (privilege management) and ISM-1490 (application control) cover admin-account and application-execution policy, but Essential 8 maturity evidence does not enumerate the specific runtime primitives that convert foothold into root.",
       "skill_chain": [
         {
           "skill": "attack-surface-pentest",

package/data/playbooks/sbom.json

@@ -390,7 +390,7 @@
         "monitor": 50,
         "close": 30
       },
-      "framework_lag_declaration": "Supply-chain frameworks have advanced fastest of any class in this exceptd release, but implementation gaps are pervasive. NIST 800-53 SA-12, NIST 800-218 SSDF, ISO 27001:2022 A.8.30/A.5.20, SOC 2 CC9.2, PCI DSS 4.0 sect.6.3, NIS2 Art.21(2)(d), DORA Art.28, EU CRA Art.13/14 all permit (a) SBOM as deliverable without continuous correlation, (b) lockfile-pinning without integrity hash, (c) direct-deps-only SBOM, (d) absence of VEX statements, (e) absence of AI-generated-code provenance, (f) model weights treated as content blobs. Lag = ~90 days behind operational tooling (SLSA / Sigstore / in-toto / VEX-CSAF) and ~210 days behind AI-coding-assistant adoption tempo. Compensating controls (continuous CVE correlation, integrity-pinned lockfiles, transitive SBOM completeness, VEX maintenance, AI-code provenance, model weight signature verification + safetensors-only loading) MUST close the gap before SBOM-as-deliverable compliance can be accepted.",
+      "framework_lag_declaration": "Supply-chain frameworks have advanced fastest of any class in this exceptd release, but implementation gaps are pervasive. NIST 800-53 SA-12, NIST 800-218 SSDF, ISO 27001:2022 A.8.30/A.5.20, SOC 2 CC9.2, PCI DSS 4.0 sect.6.3, NIS2 Art.21(2)(d), DORA Art.28, EU CRA Art.13/14 all permit (a) SBOM as deliverable without continuous correlation, (b) lockfile-pinning without integrity hash, (c) direct-deps-only SBOM, (d) absence of VEX statements, (e) absence of AI-generated-code provenance, (f) model weights treated as content blobs. Lag = ~90 days behind operational tooling (SLSA / Sigstore / in-toto / VEX-CSAF) and ~210 days behind AI-coding-assistant adoption tempo. Compensating controls (continuous CVE correlation, integrity-pinned lockfiles, transitive SBOM completeness, VEX maintenance, AI-code provenance, model weight signature verification + safetensors-only loading) MUST close the gap before SBOM-as-deliverable compliance can be accepted. UK CAF Principles B5 (Resilient Networks & Systems) and D1 (Response and Recovery Planning) treat supply-chain assurance and recovery readiness as outcomes, with no Principle binding continuous CVE correlation against the shipped SBOM or VEX maintenance as evidence. AU Essential 8 ML2 Patch Applications (E8 M.2) plus ACSC ISM-0717 (supply-chain risk management) and ISM-1657 (vendor assessment) cover supply-chain due diligence, but Essential 8 patch-tempo evidence accepts vendor advisories without requiring SBOM-driven transitive-CVE correlation or AI-generated-code provenance.",
       "skill_chain": [
         {
           "skill": "supply-chain-integrity",

package/data/playbooks/secrets.json

@@ -76,6 +76,8 @@
       "nis2",
       "dora",
       "uk-caf",
+      "au-ism",
+      "au-essential-8",
       "hipaa"
     ]
   },
@@ -138,6 +140,18 @@
             "california_resident_records_affected",
             "containment_record"
           ]
+        },
+        {
+          "jurisdiction": "AU",
+          "regulation": "Privacy Act 1988 — Notifiable Data Breaches scheme (s26WK)",
+          "obligation": "notify_regulator",
+          "window_hours": 720,
+          "clock_starts": "analyze_complete",
+          "evidence_required": [
+            "secret_inventory",
+            "australian_resident_records_affected",
+            "remediation_completed_evidence"
+          ]
         }
       ],
       "theater_fingerprints": [
@@ -227,7 +241,7 @@
         "monitor": 60,
         "close": 30
       },
-      "framework_lag_declaration": "GDPR Art.32, ISO A.8.24, PCI-DSS Req.3, SOC 2 CC6.1 collectively cover encryption + key management + access control in production storage backends. None of them name 'secret in source artifact' as a distinct exposure category, despite this being the dominant 2025-2026 cloud-compromise vector. NIS2 Art.21(2)(j) names cryptography but not development-workflow exposure. Gap = ~30 days between developer commit and framework's quarterly access-review cadence; in practice, scraper bots exploit faster than any framework cadence.",
+      "framework_lag_declaration": "GDPR Art.32, ISO A.8.24, PCI-DSS Req.3, SOC 2 CC6.1 collectively cover encryption + key management + access control in production storage backends. None of them name 'secret in source artifact' as a distinct exposure category, despite this being the dominant 2025-2026 cloud-compromise vector. NIS2 Art.21(2)(j) names cryptography but not development-workflow exposure. Gap = ~30 days between developer commit and framework's quarterly access-review cadence; in practice, scraper bots exploit faster than any framework cadence. UK CAF Principle B2 (Identity and Access Control) treats credential lifecycle as an outcome reviewable on cycle, not as a per-commit scanning obligation — secrets embedded in source artifacts do not register against B2 evidence. AU Essential 8 ML2 MFA (E8 M.4) + Restrict Admin Privileges (E8 M.5) and ISM-1546 cover MFA + admin-account hygiene but provide no signal on long-lived bearer-token exposure inside developer repositories.",
       "skill_chain": [
         {
           "skill": "dlp-gap-analysis",

package/lib/auto-discovery.js

@@ -31,7 +31,7 @@ const fs = require("fs");
 const path = require("path");
 const { scoreCustom, RWEP_WEIGHTS, ACTIVE_EXPLOITATION_LADDER } = require("./scoring");
 
-// C: stored rwep_factors must reproduce the stored rwep_score.
+// Stored rwep_factors must reproduce the stored rwep_score.
 // `buildScoringInputs` is the single source of truth for both — it captures
 // the conservative defaults applied to a freshly-imported KEV draft (CISA
 // only lists vulnerabilities with documented exploitation, so we assume a
@@ -199,7 +199,7 @@ function buildKevDraftEntry(kevEntry, nvdPayload, epssPayload) {
   const knownRansomware =
     String(kevEntry.knownRansomwareCampaignUse || "").toLowerCase() === "known";
 
-  // C: stored rwep_factors and computed rwep_score MUST agree.
+  // Stored rwep_factors and computed rwep_score MUST agree.
   // Previously rwep_factors held nulls (for unknown poc/ai/reboot) but
   // rwep_score was computed from concrete defaults (poc=true, reboot=true).
   // `scoring.validate()` then flagged every auto-imported draft for

package/lib/cross-ref-api.js

@@ -19,12 +19,12 @@ const ROOT = path.join(__dirname, '..');
 const DATA_DIR = process.env.EXCEPTD_DATA_DIR || path.join(ROOT, 'data');
 const INDEX_DIR = path.join(DATA_DIR, '_indexes');
 
-// DD P1-1: cache entries store the parsed payload AND the mtimeMs of the
-// source file at parse-time. Each load call re-stats the file; if mtime
-// matches, the cached value is returned (one syscall, no parse). If mtime
-// changed, re-parse + repopulate. If stat fails (file vanished mid-run,
-// permission glitch), fall back to the cached value. Pre-fix the cache was
-// process-lifetime — long-running `orchestrator watch` processes never saw
+// Cache entries store the parsed payload AND the mtimeMs of the source
+// file at parse-time. Each load call re-stats the file; if mtime matches,
+// the cached value is returned (one syscall, no parse). If mtime changed,
+// re-parse + repopulate. If stat fails (file vanished mid-run, permission
+// glitch), fall back to the cached value. Without mtime-keyed
+// invalidation, long-running `orchestrator watch` processes never see
 // `data/cve-catalog.json` mutations driven by `exceptd refresh --apply`.
 const _cache = new Map();
 
@@ -106,13 +106,14 @@ function entries(catalog) {
  * that references it across skills, framework gaps, theater fingerprints,
  * recipes, and zero-day lessons.
  *
- * FF P1-4: auto-imported drafts (entries with `_auto_imported === true`) are
+ * Auto-imported drafts (entries with `_auto_imported === true`) are
  * EXCLUDED by default. Drafts carry conservative-default mechanical fields
  * and null analytical fields pending curation; downstream analyze / bundle
- * emitters that assume `byCve()` returns curated data would treat the draft's
- * placeholders as authoritative. The cve-curation flow (which surfaces the
- * editorial questionnaire) opts in via `byCve(id, { include_drafts: true })`.
- * Every other caller stays on the default exclude path.
+ * emitters that assume `byCve()` returns curated data would treat the
+ * draft's placeholders as authoritative. The cve-curation flow (which
+ * surfaces the editorial questionnaire) opts in via
+ * `byCve(id, { include_drafts: true })`; every other caller stays on the
+ * default exclude path.
  */
 function byCve(cveId, opts) {
   const includeDrafts = !!(opts && opts.include_drafts);

package/lib/cve-curation.js

@@ -76,7 +76,7 @@ function loadCveEntrySchema() {
   }
 }
 
-// J7: lazy-loaded module-level catalog cache. The ATLAS / ATT&CK / CWE /
+// Lazy-loaded module-level catalog cache. The ATLAS / ATT&CK / CWE /
 // framework-control-gaps catalogs don't change inside a single CLI process,
 // so re-reading them per `curate()` call is wasted I/O. Cache once per
 // process; batch-curate paths (future) get the speedup for free.
@@ -87,7 +87,7 @@ function loadJsonRaw(absPath) {
   catch { return null; }
 }
 
-// J4: resolve a catalog path that may be absolute (operator passed
+// Resolve a catalog path that may be absolute (operator passed
 // `--catalog C:\tmp\cat.json` or `/tmp/cat.json`) or repo-relative. Plain
 // `path.join(ROOT, abs)` mishandles absolute paths on Windows.
 function resolveCatalogPath(p) {
@@ -141,11 +141,10 @@ function pickCandidates(draftDigest, catalog, idField, descriptionField) {
   return candidates.slice(0, 5);
 }
 
-// J5: report the actual upstream source on a draft. The previous check
-// only knew about `_source_ghsa_id`; OSV-imported drafts (MAL-*, SNYK-*,
-// RUSTSEC-*, etc. that land via lib/source-osv.js) carry `_source_osv_id`
-// and were always tagged "unknown". Add a registry so future sources are
-// a one-line addition.
+// Report the actual upstream source on a draft. A check that only knows
+// about `_source_ghsa_id` would tag every OSV-imported draft (MAL-*,
+// SNYK-*, RUSTSEC-*, etc. that land via lib/source-osv.js) as "unknown".
+// The registry makes future sources a one-line addition.
 const SOURCE_FIELDS = [
   { field: "_source_ghsa_id", label: "GHSA" },
   { field: "_source_osv_id", label: "OSV" },
@@ -161,9 +160,9 @@ function autoImportedFrom(draft) {
   return "unknown";
 }
 
-// J3: severity word. cvss_score: null no longer collapses to "low" (which
-// is wrong + misleading on a draft that has not been scored yet). Use
-// "unrated" so operators can grep for unsevered drafts and the curate
+// Severity word. cvss_score: null returns "unrated" — collapsing it to
+// "low" would be wrong + misleading on a draft that has not been scored
+// yet. "unrated" lets operators grep for unscored drafts and the curate
 // summary reflects the actual state.
 function severityWord(score) {
   if (typeof score !== "number" || Number.isNaN(score)) return "unrated";
@@ -173,7 +172,7 @@ function severityWord(score) {
   return "low";
 }
 
-// J2: the fields the strict CVE schema requires. Used to (a) extend the
+// The fields the strict CVE schema requires. Used to (a) extend the
 // questionnaire so the operator is prompted for every blocking gap, and
 // (b) compute `residual_warnings` after an apply.
 const REQUIRED_SCHEMA_FIELDS = [
@@ -300,10 +299,10 @@ function buildQuestionnaire(cveId, draft) {
   // specific ASK to surface what the reviewer needs to decide.
   const questions = [];
 
-  // J6: pre-filled empty containers (`iocs: {}`, `atlas_refs: []`) used to
-  // be treated as "answered" because `if (!draft.iocs)` is truthy for {}.
-  // Use explicit emptiness checks so drafts seeded with empty objects /
-  // arrays still get the prompt.
+  // Pre-filled empty containers (`iocs: {}`, `atlas_refs: []`) must NOT
+  // be treated as "answered". `if (!draft.iocs)` is truthy for {}, which
+  // would skip the prompt. Use explicit emptiness checks so drafts
+  // seeded with empty objects / arrays still get the prompt.
   const arrEmpty = (a) => !Array.isArray(a) || a.length === 0;
   const objEmpty = (o) => !o || typeof o !== "object" || Object.keys(o).length === 0;
 
@@ -380,9 +379,9 @@ function buildQuestionnaire(cveId, draft) {
     });
   }
 
-  // J2: schema-required field prompts. Without these populated, the apply
-  // path cannot produce a schema-passing entry — i.e. the entry stays a
-  // draft even after curate --apply. Prompt for them explicitly so the
+  // Schema-required field prompts. Without these populated, the apply
+  // path cannot produce a schema-passing entry — the entry stays a draft
+  // even after curate --apply. Prompt for them explicitly so the
   // operator sees what's actually blocking promotion.
   if (draft.cvss_score === null || draft.cvss_score === undefined
       || draft.cvss_vector === null || draft.cvss_vector === undefined
@@ -460,7 +459,7 @@ function buildQuestionnaire(cveId, draft) {
 }
 
 /**
- * J1: apply operator-supplied answers to a draft and write back atomically.
+ * Apply operator-supplied answers to a draft and write back atomically.
  *
  * Answers shape (each key optional; missing keys leave the draft unchanged
  * for that field):

package/lib/lint-skills.js

@@ -162,11 +162,11 @@ function readJson(p) {
 function parseFrontmatter(text) {
   const lines = text.split(/\r?\n/);
   const result = {};
-  // S4: track every top-level key we've already assigned. YAML's
-  // last-wins semantics would let a tampered skill set name twice
-  // ("name: real-skill\nname: evil-skill") and silently take the
-  // second value — a skill-identity spoofing primitive. Refuse
-  // duplicates outright; an honest skill never has them.
+  // Track every top-level key we've already assigned. YAML's last-wins
+  // semantics would let a tampered skill set name twice
+  // ("name: real-skill\nname: evil-skill") and silently take the second
+  // value — a skill-identity spoofing primitive. Refuse duplicates
+  // outright; an honest skill never has them.
   const seenKeys = new Set();
   let i = 0;
   while (i < lines.length) {