@blamejs/exceptd-skills 0.18.3 → 0.18.5

package/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## 0.18.5 — 2026-06-14
+
+The manifest's per-skill cross-reference arrays — data dependencies, framework gaps, and ATT&CK / ATLAS / D3FEND / RFC / CWE references — now include every reference a skill declares in its own frontmatter. Previously a reference present in a skill's frontmatter but missing from the manifest cache could silently drop out of the reverse-reference surfaces (for instance, a skill not appearing under a D3FEND technique it actually maps). A predeploy gate now holds the manifest cache to cover frontmatter, so the reference graph cannot drift again.
+
+## 0.18.4 — 2026-06-14
+
+Correctness fixes in the skill linter, attestation diffing, and the jurisdiction index. The required-section check no longer accepts a heading that appears only inside a fenced code example, nor a deeper sub-heading standing in for a top-level section — both previously let a non-compliant skill pass. `attest diff` no longer reports an object-valued signal override (the per-indicator false-positive-check maps) as changed when its content is identical, so the field-level diff agrees with the overall evidence verdict. ENISA references now index under the dedicated EU_ENISA jurisdiction instead of collapsing into the generic EU bucket, and the indexed-jurisdiction count in the index metadata reflects every mapped jurisdiction.
+
 ## 0.18.3 — 2026-06-14
 
 The release pipeline now enforces the project's patch-only version cadence as a predeploy gate: a minor or major version bump fails the gates unless it carries an explicit, committed authorization. A release-engineering safeguard; the CLI surface is unchanged.

package/bin/exceptd.js

@@ -6410,7 +6410,11 @@ function diffSignalOverrides(a, b) {
   const allIds = new Set([...Object.keys(a), ...Object.keys(b)]);
   const out = { total_compared: allIds.size, changed: [], unchanged_count: 0 };
   for (const id of allIds) {
-    if (a[id] !== b[id]) out.changed.push({ id, a: a[id] || null, b: b[id] || null });
+    // Deep, order-insensitive compare — signal_overrides hold OBJECT values
+    // (the `<indicator-id>__fp_checks` maps), so a reference-strict `!==` would
+    // report byte-identical FP-check content as "changed", contradicting the
+    // evidence_hash verdict. Reuse the same comparator diffArtifacts uses.
+    if (artifactsDiffer(a[id], b[id])) out.changed.push({ id, a: a[id] ?? null, b: b[id] ?? null });
     else out.unchanged_count++;
   }
   return out;
@@ -9316,5 +9320,6 @@ module.exports = {
   _verifyAttestationSidecar: verifyAttestationSidecar,
   _emit: emit,
   _diffArtifacts: diffArtifacts,
+  _diffSignalOverrides: diffSignalOverrides,
   _resolveSelfAttestation: resolveSelfAttestation,
 };

package/data/_indexes/_meta.json

@@ -1,21 +1,21 @@
 {
   "schema_version": "1.1.0",
-  "generated_at": "2026-06-14T14:15:46.628Z",
+  "generated_at": "2026-06-14T15:51:29.599Z",
   "generator": "scripts/build-indexes.js",
   "source_count": 64,
   "source_hashes": {
-    "manifest.json": "58e3b2b80b32fb30a31db9857fcbd356ddd6c61da6dbc3a762c85a4d212dc787",
+    "manifest.json": "d6486b4209c765883b69c32a3f52df0956c2e9cb770cc0d603fafb5b15aeb865",
     "README.md": "e7b854e7db9a364a1b368b5084b4f0c2a8282f0459ce39800ac1d1dabdc06074",
     "data/atlas-ttps.json": "5bc59e23d6c2defa54168de161a0825299b9cc4a49c6b26df2dae70b4f42eedf",
     "data/attack-techniques.json": "53c6f248760eecb11a0354f74ab467a5814e95075a686b9b3bf18c34e2f7435e",
     "data/cve-catalog.json": "eedd129c657e535d53df5d4d44fa54009b69cde85673cf7c9d426054eddc43d2",
     "data/cwe-catalog.json": "359263361fa52069e2856cc352d8f1c757d614ea840db6ef3ff5e696185ca220",
-    "data/d3fend-catalog.json": "9a54bccb9f24f84b32024216cc3f53819a053721ac8ab43c326859e68fc0ffaf",
+    "data/d3fend-catalog.json": "349d14b2777342d38e5f8b0149a9ebd7703ee59f67a9efee200d1e19313088ac",
     "data/dlp-controls.json": "d2406c482dddd30e49203879999dc4b3a7fd4d0494d6a61d86b91ee76415df19",
     "data/exploit-availability.json": "ec2656f0d9a893610e27b43eb6035fe9b18e057c9f6dfaac7e7d4959bbcbb795",
     "data/framework-control-gaps.json": "760c2275803c6da3665ce538c5176bde6f041b68cc3d4808b8de961dfcdee6b8",
     "data/global-frameworks.json": "9ba563a85f7f8d6c3c957de64945e20925a89d0ed6ea6fc561cf093811acf558",
-    "data/rfc-references.json": "b21d03b948c41bc8a854e2f057948ecf844bd8c105848aeb141d1eadf8192c31",
+    "data/rfc-references.json": "5db2f7006a1d7f2b8642a3e393213394e92798604576df973d0a0b8550f4b5ac",
     "data/zeroday-lessons.json": "8c69eec9103eeea236ceb1a157d62b35bafcf8a5de86502e25e4587cc5931247",
     "skills/kernel-lpe-triage/skill.md": "0f79c641cef6e5f4a942eb94f43c460562bf83dfb67ae112d146c39c6b320fb0",
     "skills/ai-attack-surface/skill.md": "6eefa7772f1faf9c8ed971f2a827cd48398a12ab3b691b258c7c8364a5deb39c",
@@ -84,7 +84,7 @@
     "trigger_table_entries": 688,
     "chains_cve_entries": 446,
     "chains_cwe_entries": 181,
-    "jurisdictions_indexed": 29,
+    "jurisdictions_indexed": 34,
     "handoff_dag_nodes": 51,
     "summary_cards": 51,
     "section_offsets_skills": 51,

package/data/_indexes/jurisdiction-map.json

@@ -488,8 +488,23 @@
     "skill_count": 2
   },
   "EU_ENISA": {
-    "skills": [],
+    "skills": [
+      "ai-c2-detection",
+      "cloud-security",
+      "compliance-theater",
+      "container-runtime-security",
+      "coordinated-vuln-disclosure",
+      "incident-response-playbook",
+      "pqc-first",
+      "researcher",
+      "sector-energy",
+      "sector-federal-government",
+      "sector-financial",
+      "sector-healthcare",
+      "sector-telecom",
+      "skill-update-loop"
+    ],
     "example_excerpts": {},
-    "skill_count": 0
+    "skill_count": 14
   }
 }

package/data/d3fend-catalog.json

@@ -51,13 +51,20 @@
       "Executable Script"
     ],
     "skills_referencing": [
+      "ai-attack-surface",
       "attack-surface-pentest",
+      "cloud-security",
+      "container-runtime-security",
       "defensive-countermeasure-mapping",
       "dlp-gap-analysis",
       "fuzz-testing-strategy",
       "kernel-lpe-triage",
       "mcp-agent-trust",
-      "supply-chain-integrity"
+      "mlops-security",
+      "sector-energy",
+      "sector-federal-government",
+      "supply-chain-integrity",
+      "webapp-security"
     ],
     "implementation_examples": [
       "AppLocker (Windows)",
@@ -101,8 +108,11 @@
       "File Hash"
     ],
     "skills_referencing": [
+      "container-runtime-security",
       "defensive-countermeasure-mapping",
       "mcp-agent-trust",
+      "mlops-security",
+      "sector-federal-government",
       "supply-chain-integrity"
     ],
     "implementation_examples": [
@@ -143,9 +153,11 @@
       "Process Segment"
     ],
     "skills_referencing": [
+      "container-runtime-security",
       "defensive-countermeasure-mapping",
       "fuzz-testing-strategy",
-      "kernel-lpe-triage"
+      "kernel-lpe-triage",
+      "sector-energy"
     ],
     "implementation_examples": [
       "NX bit (x86_64)",
@@ -216,7 +228,8 @@
       "System Call"
     ],
     "skills_referencing": [
-      "defensive-countermeasure-mapping"
+      "defensive-countermeasure-mapping",
+      "kernel-lpe-triage"
     ],
     "implementation_examples": [
       "seccomp-bpf profiles (Docker default, gVisor)",
@@ -363,10 +376,14 @@
       "Authentication Service"
     ],
     "skills_referencing": [
+      "api-security",
       "cloud-iam-incident",
+      "cloud-security",
       "defensive-countermeasure-mapping",
       "idp-incident-response",
       "mcp-agent-trust",
+      "sector-federal-government",
+      "sector-financial",
       "supply-chain-integrity"
     ],
     "implementation_examples": [
@@ -405,10 +422,17 @@
       "Authentication Service"
     ],
     "skills_referencing": [
+      "age-gates-child-safety",
+      "api-security",
       "cloud-iam-incident",
       "defensive-countermeasure-mapping",
+      "email-security-anti-phishing",
+      "identity-assurance",
       "idp-incident-response",
-      "mcp-agent-trust"
+      "mcp-agent-trust",
+      "sector-financial",
+      "sector-healthcare",
+      "webapp-security"
     ],
     "implementation_examples": [
       "FIDO2 / WebAuthn (phishing-resistant)",
@@ -531,14 +555,21 @@
     "skills_referencing": [
       "ai-attack-surface",
       "ai-c2-detection",
+      "api-security",
       "attack-surface-pentest",
       "cloud-iam-incident",
+      "cloud-security",
       "defensive-countermeasure-mapping",
       "dlp-gap-analysis",
+      "email-security-anti-phishing",
       "idp-incident-response",
+      "incident-response-playbook",
       "rag-pipeline-security",
       "ransomware-response",
-      "sector-telecom"
+      "sector-energy",
+      "sector-financial",
+      "sector-telecom",
+      "webapp-security"
     ],
     "implementation_examples": [
       "Zeek / Suricata flow analysis",
@@ -578,8 +609,11 @@
     ],
     "skills_referencing": [
       "ai-c2-detection",
+      "cloud-security",
+      "container-runtime-security",
       "defensive-countermeasure-mapping",
       "dlp-gap-analysis",
+      "sector-energy",
       "sector-telecom"
     ],
     "implementation_examples": [
@@ -624,13 +658,21 @@
       "Application Payload"
     ],
     "skills_referencing": [
+      "age-gates-child-safety",
+      "ai-attack-surface",
       "ai-c2-detection",
+      "api-security",
       "attack-surface-pentest",
       "defensive-countermeasure-mapping",
       "dlp-gap-analysis",
+      "email-security-anti-phishing",
+      "identity-assurance",
+      "incident-response-playbook",
       "mcp-agent-trust",
       "rag-pipeline-security",
-      "ransomware-response"
+      "ransomware-response",
+      "sector-healthcare",
+      "webapp-security"
     ],
     "implementation_examples": [
       "AI-API request body inspection at egress proxy (CloudFlare AI Gateway, LiteLLM proxy)",
@@ -668,16 +710,27 @@
       "Resource Access"
     ],
     "skills_referencing": [
+      "age-gates-child-safety",
       "ai-attack-surface",
       "ai-c2-detection",
+      "ai-risk-management",
+      "api-security",
       "cloud-iam-incident",
+      "cloud-security",
+      "container-runtime-security",
       "defensive-countermeasure-mapping",
       "dlp-gap-analysis",
+      "email-security-anti-phishing",
       "fuzz-testing-strategy",
       "idp-incident-response",
+      "incident-response-playbook",
+      "mlops-security",
       "rag-pipeline-security",
       "ransomware-response",
-      "sector-telecom"
+      "sector-financial",
+      "sector-healthcare",
+      "sector-telecom",
+      "webapp-security"
     ],
     "implementation_examples": [
       "LLM output classifier for safety-bypass content (Llama Guard, Granite Guardian)",
@@ -714,6 +767,7 @@
     ],
     "skills_referencing": [
       "defensive-countermeasure-mapping",
+      "incident-response-playbook",
       "ransomware-response"
     ],
     "implementation_examples": [
@@ -754,7 +808,9 @@
       "File Access"
     ],
     "skills_referencing": [
-      "defensive-countermeasure-mapping"
+      "ai-attack-surface",
+      "defensive-countermeasure-mapping",
+      "rag-pipeline-security"
     ],
     "implementation_examples": [
       "auditd FIM with behavioral rules",
@@ -792,7 +848,9 @@
     ],
     "skills_referencing": [
       "ai-c2-detection",
+      "container-runtime-security",
       "defensive-countermeasure-mapping",
+      "sector-energy",
       "sector-telecom"
     ],
     "implementation_examples": [
@@ -834,7 +892,8 @@
       "Process Tree"
     ],
     "skills_referencing": [
-      "defensive-countermeasure-mapping"
+      "defensive-countermeasure-mapping",
+      "kernel-lpe-triage"
     ],
     "implementation_examples": [
       "Sysmon process-creation events with parent-child Sigma rules",
@@ -909,7 +968,8 @@
       "Process Environment Variable Access"
     ],
     "skills_referencing": [
-      "cloud-iam-incident"
+      "cloud-iam-incident",
+      "mcp-agent-trust"
     ],
     "implementation_examples": [
       "AWS Secrets Manager + CloudTrail GetSecretValue audit with anomaly baseline per principal",
@@ -1027,7 +1087,9 @@
       "Source Code",
       "Configuration File"
     ],
-    "skills_referencing": [],
+    "skills_referencing": [
+      "rag-pipeline-security"
+    ],
     "implementation_examples": [
       "gitleaks / trufflehog pre-commit and CI-time secret scanning",
       "YARA rules on uploaded files at SaaS file-upload boundaries",

package/data/rfc-references.json

@@ -142,7 +142,9 @@
     "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": [],
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]",
     "keywords": [
@@ -194,7 +196,9 @@
     "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": [],
+    "skills_referencing": [
+      "incident-response-playbook"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC 6045. [STANDARDS-TRACK]",
     "keywords": [
@@ -224,7 +228,9 @@
     "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": [],
+    "skills_referencing": [
+      "incident-response-playbook"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. [STANDARDS-TRACK]",
     "keywords": [
@@ -306,7 +312,9 @@
     "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": [],
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the \"MAIL FROM\" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408.",
     "keywords": [
@@ -388,7 +396,9 @@
     "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": [],
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
     "last_verified": "2026-05-27",
     "abstract": "Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.",
     "keywords": [
@@ -518,7 +528,9 @@
     "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": [],
+    "skills_referencing": [
+      "incident-response-playbook"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletes RFCs 5070 and 6685.",
     "keywords": [
@@ -673,7 +685,9 @@
     "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": [],
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.",
     "keywords": [
@@ -702,7 +716,9 @@
     "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": [],
+    "skills_referencing": [
+      "email-security-anti-phishing"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.",
     "keywords": [
@@ -1003,7 +1019,9 @@
     "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": [],
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format (\"security.txt\") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.",
     "working_group": "NON WORKING GROUP",
@@ -1291,7 +1309,9 @@
     "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": [],
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "OASIS Common Security Advisory Framework (CSAF) version 2.0 — the canonical machine-readable format for vendor security advisories. CSAF-2.0 documents are signed JSON conforming to a strict schema (product_tree, vulnerabilities[], document.tracking, document.references), enabling automated ingestion by SBOM tooling, vulnerability scanners, and incident-response platforms. Supersedes the legacy CVRF format. Required for vendors participating in the OpenSSF / CISA / ENISA coordinated-disclosure ecosystem."
   },
@@ -1331,7 +1351,9 @@
     "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": [],
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "ISO/IEC 29147:2018 — Information technology, Security techniques, Vulnerability disclosure. Defines the receipt-side requirements for an organisation's vulnerability disclosure program (VDP): point-of-contact discoverability, acknowledgement timelines, communication protocols, advisory publication. Paired with ISO/IEC 30111 (vulnerability handling processes). Referenced by NIS2 Art.12 + EU CRA Annex I §1(2)(c) as the baseline VDP standard."
   },
@@ -1342,7 +1364,9 @@
     "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": [],
+    "skills_referencing": [
+      "coordinated-vuln-disclosure"
+    ],
     "last_verified": "2026-05-19",
     "abstract": "ISO/IEC 30111:2019 — Information technology, Security techniques, Vulnerability handling processes. Defines the internal-side vulnerability-handling lifecycle: triage, investigation, resolution, release, post-release. Paired with ISO/IEC 29147 (disclosure-side requirements). Together the two standards cover the operator-facing vulnerability-handling obligation cited by NIS2 / EU CRA / FedRAMP / FDA premarket cybersecurity guidance."
   },

package/lib/lint-skills.js

@@ -474,9 +474,16 @@ function validateFrontmatter(fm, skillName) {
 function findMissingSections(body, requiredSections) {
   const sections = requiredSections || REQUIRED_SECTIONS;
   const lines = body.split(/\r?\n/);
-  // Index every heading line (any depth) so we know where each section ends.
+  // Index heading lines so we know where each section ends. Skip lines inside
+  // fenced code blocks: a heading inside a ```markdown example block is
+  // documentation, not a real section, and must not satisfy a required-section
+  // check (otherwise a skill whose required sections appear only inside a fence
+  // passes the gate vacuously).
   const headings = [];
+  let inFence = false;
   for (let i = 0; i < lines.length; i++) {
+    if (/^\s*(?:```|~~~)/.test(lines[i])) { inFence = !inFence; continue; }
+    if (inFence) continue;
     const m = lines[i].match(/^(#{1,6})\s+(.+?)\s*$/);
     if (m) {
       headings.push({ line: i, depth: m[1].length, title: m[2].trim() });
@@ -490,6 +497,10 @@ function findMissingSections(body, requiredSections) {
   const findHeading = (title) => {
     const t = title.toLowerCase();
     return headings.find((h) => {
+      // Required sections are top-level (H1/H2). A deeper heading — e.g. the H3
+      // "### Compliance Theater Check Result" inside Output Format — must NOT
+      // satisfy the standalone "## Compliance Theater Check" requirement.
+      if (h.depth > 2) return false;
       const lower = h.title.toLowerCase();
       if (lower === t) return true;
       if (lower.startsWith(t)) {