@blamejs/exceptd-skills 0.9.1

package/skills/zeroday-gap-learn/skill.md

@@ -0,0 +1,350 @@
+---
+name: zeroday-gap-learn
+version: "1.0.0"
+description: Run the zero-day learning loop — CVE to attack vector to control gap to framework gap to new control requirement
+triggers:
+  - zero day lesson
+  - zeroday gap
+  - what control gap enabled this
+  - learn from exploit
+  - exploit to control gap
+  - what should have caught this
+  - 0day learning
+data_deps:
+  - cve-catalog.json
+  - zeroday-lessons.json
+  - framework-control-gaps.json
+  - atlas-ttps.json
+atlas_refs: []
+attack_refs: []
+framework_gaps: []
+forward_watch:
+  - New CISA KEV entries
+  - New ATLAS TTP additions in each ATLAS release
+  - Framework updates that close previously open gaps
+  - Vendor advisories for MCP/AI tool supply chain CVEs
+last_threat_review: "2026-05-01"
+---
+
+# Zero-Day Learning Loop
+
+Every significant zero-day is a test of the control landscape. The question is not only "how do we patch this?" — it is "what control, if it had existed and been implemented, would have prevented or detected this?" The answer tells us what frameworks are missing.
+
+This skill runs the full learning loop: zero-day description → attack vector extraction → control gap identification → framework coverage assessment → new control requirement generation → exposure scoring.
+
+---
+
+## Threat Context (mid-2026)
+
+The zero-day learning cycle has compressed. The frameworks have not.
+
+- **41% of 2025 zero-days were discovered by attackers using AI-assisted reverse engineering** (AGENTS.md DR-5). Copy Fail (CVE-2026-31431) was AI-found in approximately one hour. The historical learning rhythm — researcher disclosure → industry analysis → framework update cycle measured in quarters or years — is incompatible with AI-discovery cadence measured in weeks.
+- **The compounding consequence**: when a zero-day is announced, the relevant question is no longer "when will the patch ship?" but "what control, if it had existed, would have stopped this, and how do we add that control to the next thousand systems before the AI-generated variant lands?" Without a running learning loop, every novel TTP becomes a one-off incident response rather than a control-system improvement.
+- **AI-acceleration also compresses variant generation.** A single disclosed primitive (Copy Fail's deterministic page-cache CoW; SesameOp's AI-API C2 channel) can be re-applied by AI tooling to adjacent code paths within days. Frameworks that only respond to specific CVE-IDs miss the class-level lesson entirely.
+- **Compliance frameworks do not include zero-day learning as a required control category.** The "learn from incidents" language in NIST CSF 2.0 IMPROVE and ISO 27001:2022 A.5.7 is process-only, no required artifact. An org can be fully compliant while patching every CVE and learning nothing.
+
+This skill exists because the gap between AI-accelerated zero-day production and framework-driven control evolution is the dominant mid-2026 risk multiplier.
+
+---
+
+## Framework Lag Declaration
+
+Frameworks do not require a zero-day learning loop as a control. The closest analogs are process controls without learning artifacts.
+
+| Framework | Control | What It Says | Why It Fails as a Learning Loop |
+|---|---|---|---|
+| NIST CSF 2.0 | IMPROVE function (ID.IM) | "Identify improvements to organizational cybersecurity risk management processes, procedures, and activities." | Process-level guidance only. Does not require: (a) per-zero-day attack-vector extraction, (b) framework-gap mapping, (c) new-control-requirement generation, (d) measurable closure of identified gaps. Compliance is satisfied by having "an improvement process" without showing it produced any specific control. |
+| NIST 800-53 Rev 5 | CA-7 (Continuous Monitoring) + IR-4 (Incident Handling — Lessons Learned) | Lessons learned from incidents and continuous monitoring. | Lessons-learned is required after incidents, but not after public zero-days the org wasn't directly hit by. The most valuable learning surface — other people's incidents — is outside the control's scope. |
+| ISO 27001:2022 | A.5.7 (Threat intelligence) | Information about information security threats shall be collected and analyzed. | Threat-intel collection is required; learning-loop output (new control requirements, framework-gap artifacts) is not. Process compliance with zero learning output is auditable as "compliant." |
+| ISO 27001:2022 | A.5.27 (Learning from information security incidents) | Knowledge gained from incidents shall be used to strengthen controls. | Limited to incidents the org experienced. Does not require learning from industry-wide zero-days that didn't hit the org. |
+| SOC 2 | CC4 (Monitoring Activities) | Ongoing/separate evaluations of internal controls. | Evaluation cadence is internal-controls focused, not threat-landscape focused. No requirement to re-evaluate controls against newly-disclosed TTPs. |
+| NIS2 Directive | Art. 21 — incident handling and crisis management | Essential/important entities must handle incidents. | Same scope problem: incidents the org experienced, not zero-days landing across the sector. |
+| MITRE ATT&CK / ATLAS | TTP catalogs | Reference taxonomies. | Not frameworks of required controls — they describe TTPs, they do not require an org to maintain a learning loop against them. |
+
+Across all of these: **the learning loop is not a required control output, only an implied behavior.** An org can pass every audit while patching CVEs and absorbing zero TTP-level lessons.
+
+---
+
+## TTP Mapping
+
+This skill is meta — it does not pin to a single TTP class. The learning loop iterates over the full corpus declared in this skill's `data_deps`. Frontmatter `atlas_refs` and `attack_refs` are intentionally empty.
+
+| Input Catalog | Role in the Learning Loop |
+|---|---|
+| `data/cve-catalog.json` | The CVE-level corpus: each entry is a candidate lesson input. New entries trigger a new loop run per AGENTS.md DR-8. |
+| `data/atlas-ttps.json` (MITRE ATLAS v5.1.0) | The AI/ML TTP taxonomy. Attack-vector extraction maps the CVE's mechanism to an ATLAS ID (e.g., AML.T0096 for SesameOp AI-as-C2). |
+| `data/framework-control-gaps.json` | The control-gap corpus. Framework-coverage assessment writes into this file via new entries or `status` updates. |
+| `data/zeroday-lessons.json` | The output corpus. Each completed loop produces one entry here — the durable artifact of the lesson. |
+
+The skill consumes all four and produces a delta against `zeroday-lessons.json` and `framework-control-gaps.json`. Coverage of any one specific TTP is the responsibility of the topic-specific skills (`kernel-lpe-triage`, `ai-attack-surface`, `mcp-agent-trust`, `ai-c2-detection`).
+
+---
+
+## Exploit Availability Matrix
+
+Status of the learning-loop entry for each CVE currently in `data/cve-catalog.json`:
+
+| CVE | KEV | PoC | AI-Discovered / AI-Enabled | RWEP | Lesson-Entry Status in `zeroday-lessons.json` |
+|---|---|---|---|---|---|
+| CVE-2026-31431 (Copy Fail) | Yes | Yes (732-byte) | Yes (AI-discovered ~1h) | 90 | Complete — pre-run lesson encoded below; new control requirements CISA-KEV-RESPONSE-SLA, LIVE-PATCH-CAPABILITY, KERNEL-EXPLOITATION-DETECTION generated |
+| CVE-2026-43284 (Dirty Frag — ESP/IPsec) | No | Yes (chain) | No | 38 | Complete — pre-run lesson encoded; new control requirements CRYPTO-SUBSYSTEM-INTEGRITY, PRE-PATCH-DISCLOSURE-RESPONSE generated |
+| CVE-2026-43500 (Dirty Frag — RxRPC) | No | Yes (chain) | No | 32 | Complete — covered jointly with CVE-2026-43284 (chain partner) |
+| CVE-2025-53773 (Copilot prompt-injection RCE) | No | Yes (demonstrated) | Yes (AI tooling enables) | 42 | Complete — pre-run lesson encoded; new control requirements AI-TOOL-ACTION-AUTHORIZATION, AI-TOOL-INPUT-SANITIZATION, PROMPT-INJECTION-MONITORING generated |
+| CVE-2026-30615 (Windsurf MCP RCE) | No | Partial | No (supply-chain) | 35 | Complete — pre-run lesson encoded; new control requirements MCP-SERVER-SIGNING, MCP-TOOL-ALLOWLIST, MCP-SUPPLY-CHAIN-AUDIT generated |
+
+Per AGENTS.md DR-8: every new entry added to `data/cve-catalog.json` must produce a corresponding entry here and in `data/zeroday-lessons.json` before the catalog change ships. Any CVE in the catalog without a complete lesson entry is a pre-ship-checklist failure.
+
+---
+
+## The Learning Loop
+
+```
+Input: zero-day (CVE ID, description, or vulnerability class)
+   ↓
+Step 1: Attack vector extraction
+   — What technical mechanism was used?
+   — What privileges were required?
+   — What was the exploitation complexity?
+   ↓
+Step 2: Defense chain analysis
+   — What control SHOULD have prevented this exploitation?
+   — What control SHOULD have detected this exploitation?
+   — Was that control in any major framework?
+   — Was it typically implemented?
+   ↓
+Step 3: Framework coverage assessment
+   — For each major framework: does it have a control that covers this?
+   — Is the control adequate (specific enough, actionable enough)?
+   — Or is the control present but insufficient (too vague, wrong time horizon)?
+   ↓
+Step 4: Gap classification
+   — Missing entirely: no framework has a control for this attack class
+   — Insufficient: controls exist but are inadequate for this specific TTP
+   — Compliant-but-exposed: org can pass audit of the control and still be vulnerable
+   ↓
+Step 5: New control requirement generation
+   — What specific, testable control would actually address this?
+   — What evidence would demonstrate the control is working?
+   ↓
+Step 6: Exposure scoring
+   — How many compliance-passing orgs are still exposed?
+   — What is the RWEP for this zero-day?
+Output: Lesson entry for data/zeroday-lessons.json
+```
+
+---
+
+## Pre-Run Lessons (Encoded from Documented Zero-Days)
+
+### Lesson: CVE-2026-31431 (Copy Fail)
+
+**Attack vector:** Page-cache copy-on-write primitive in the Linux kernel. Unprivileged local user. Deterministic. No race condition. Single-stage. 732 bytes.
+
+**What control should have prevented this:**
+- Prevention: No local code execution → no LPE opportunity. But local code execution is baseline in any multi-user system or container environment. Prevention at this layer is not realistic.
+- Mitigation before patch: seccomp profile blocking `userfaultfd`, user namespace restrictions, kernel hardening. These reduce attack surface but do not eliminate it.
+- Patch: Apply kernel update. Live patching (kpatch/livepatch/kGraft) enables patching without service interruption.
+
+**What control should have detected this:**
+- Detection: auditd/eBPF monitoring for exploitation patterns — privilege escalation from unprivileged context, unusual /proc/self/mem writes, userfaultfd usage outside known applications.
+- None of these are required by any major framework.
+
+**Framework coverage assessment:**
+
+| Framework | Control | Assessment |
+|---|---|---|
+| NIST 800-53 SI-2 | Flaw Remediation | Present but insufficient: 30-day SLA is exploitation window for CISA KEV + public PoC |
+| ISO 27001 A.8.8 | Technical vulnerability management | Present but insufficient: "appropriate timescales" undefined; no live-patch requirement |
+| PCI DSS 6.3.3 | Critical patches within 1 month | Present but insufficient: same problem |
+| ASD ISM-1623 | Patch within 48h with exploit | Closest to adequate, but: no live-patch mandate, 48h window still long for 732-byte public exploit |
+| Any framework | Detection for LPE exploitation patterns | Missing entirely: no framework requires auditd/eBPF exploitation detection |
+| Any framework | Live kernel patching as required capability | Missing entirely |
+
+**New control requirements generated:**
+
+1. **CISA-KEV-RESPONSE-SLA**: For any CVE on the CISA KEV catalog: deploy verified mitigation (patch, live patch, or documented compensating controls) within 4 hours of KEV listing or patch availability, whichever is later.
+
+2. **LIVE-PATCH-CAPABILITY**: For any system that processes production workloads and cannot tolerate unplanned reboots: live kernel patching capability (kpatch, livepatch, kGraft, or equivalent) must be deployed and tested quarterly.
+
+3. **KERNEL-EXPLOITATION-DETECTION**: Deploy auditd or eBPF-based monitoring rules for kernel privilege escalation indicators. Alert within 60 seconds of pattern detection.
+
+**Exposure scoring:**
+- RWEP: 90 (current, with patch+live-patch available)
+- Organizations compliant with standard patch management controls but still exposed: estimated 80%+ during the first week after KEV listing (based on industry patch deployment lag data)
+- Coverage failure: standard controls allow full exploitation window while displaying "compliant" status
+
+---
+
+### Lesson: CVE-2026-43284/43500 (Dirty Frag)
+
+**Attack vector:** Page-cache write primitive chain through ESP/IPsec (CVE-2026-43284) and RxRPC (CVE-2026-43500) subsystems. Chained — requires fingerprinting to select correct gadget. Disclosed before patches existed.
+
+**What control should have prevented/detected this:**
+- Critical insight: the exploitation path runs through the IPsec subsystem → controls that rely on IPsec for network isolation are not compensating controls for Dirty Frag exposure
+
+**New control requirements generated:**
+
+1. **CRYPTO-SUBSYSTEM-INTEGRITY**: Network controls claiming compliance via IPsec must include: kernel CVE status for IPsec-related CVEs, and explicit acknowledgment if IPsec-based controls are degraded by an unpatched IPsec CVE.
+
+2. **PRE-PATCH-DISCLOSURE-RESPONSE**: For vulnerabilities disclosed before patches exist: immediately inventory affected systems, isolate high-risk systems at network layer, deploy detection rules, commit to patch timeline.
+
+---
+
+### Lesson: CVE-2025-53773 (GitHub Copilot Prompt Injection RCE)
+
+**Attack vector:** Hidden prompt injection in GitHub Copilot PR descriptions. Developer reviews PR with Copilot → injected instructions execute in developer session → RCE. CVSS 9.6.
+
+**What control should have prevented this:**
+- Access control for AI tool actions: the developer's GitHub session was correctly authenticated. The RCE happened because the AI tool executed adversarial instructions with the developer's authorization context.
+- There is no framework control for "AI tool authorization scope at the action level."
+
+**New control requirements generated:**
+
+1. **AI-TOOL-ACTION-AUTHORIZATION**: AI coding assistants must have explicitly scoped permissions. Any action taken by an AI tool (file write, terminal command, API call) requires explicit user approval unless within a pre-approved action whitelist. Implied authorization from context is insufficient.
+
+2. **AI-TOOL-INPUT-SANITIZATION**: Content ingested by AI tools from external sources (PR descriptions, code comments, documentation, web pages) must be treated as potentially adversarial. AI tools should apply adversarial instruction classifiers to externally sourced content before including it in model context.
+
+3. **PROMPT-INJECTION-MONITORING**: Log all AI tool actions, including the content of prompts that triggered those actions. Alert on AI actions that deviate from the user's stated intent or that weren't preceded by an explicit user request.
+
+**Framework coverage:** Missing entirely in all major frameworks. CVSS 9.6 with active exploitation demonstrated and no framework control category for this attack class.
+
+---
+
+### Lesson: CVE-2026-30615 (Windsurf MCP Zero-Interaction RCE)
+
+**Attack vector:** Malicious MCP server achieves RCE without user interaction. AI coding assistant autonomously calls malicious tool, code executes. 150M+ affected.
+
+**New control requirements generated:**
+
+1. **MCP-SERVER-SIGNING**: All MCP servers must have verifiable provenance (npm provenance attestation, signed manifest, or equivalent). AI coding assistants must refuse to load unsigned MCP servers.
+
+2. **MCP-TOOL-ALLOWLIST**: AI clients must implement explicit tool allowlists. Default deny — only tools in the allowlist may be called, regardless of what the MCP server exposes.
+
+3. **MCP-SUPPLY-CHAIN-AUDIT**: MCP server installations must go through the organization's third-party software audit process. Automated installation of MCP packages without review is equivalent to installing unaudited dependencies.
+
+**Framework coverage:** Missing entirely. Supply chain security controls (SA-12, A.5.19) don't address MCP servers as a category.
+
+---
+
+### Lesson: SesameOp (ATLAS AML.T0096 — AI as C2)
+
+**Attack vector:** Compromised host encodes C2 commands in LLM API prompt fields. Exfiltrated data returned in completion fields. Traffic indistinguishable from legitimate AI API usage.
+
+**New control requirements generated:**
+
+1. **AI-API-BEHAVIORAL-BASELINE**: All AI API usage from organizational networks must be baselined (which processes, which users, what volumes, what times). Deviations from baseline must trigger alerts.
+
+2. **AI-API-PROCESS-ALLOWLIST**: Maintain an allowlist of processes authorized to make AI API calls. AI API calls from unlisted processes must alert.
+
+3. **AI-API-CORRELATION**: Correlate AI API call events with security-relevant host events (file access, credential access, lateral movement). AI API calls correlated with security events within defined time windows must escalate.
+
+**Framework coverage:** Missing entirely. SI-4 (system monitoring) and A.8.16 (monitoring activities) don't address AI API behavioral baselines.
+
+---
+
+## Analysis Procedure for New Zero-Days
+
+When a user provides a new CVE or vulnerability description:
+
+### Step 1: Extract attack vector
+
+Document:
+- What technical capability does the attacker need to execute this?
+- What system components are used in the attack path?
+- What is the exploitation complexity? (deterministic / race condition / heap spray / etc.)
+- Is the exploit AI-assisted or AI-discovered?
+- What is the blast radius? (specific config / default config / all major distros)
+
+### Step 2: Defense chain analysis
+
+Ask and answer:
+1. **Prevention control:** What configuration, capability, or process would have prevented this exploit from being possible?
+2. **Detection control:** What monitoring rule or anomaly detection would have fired during exploitation?
+3. **Response trigger:** What evidence would appear in logs or alerts during/after exploitation?
+
+For each: Is this control required by any major framework?
+
+### Step 3: Framework coverage matrix
+
+Run through each applicable framework:
+- NIST 800-53 (which control family?)
+- ISO 27001:2022 (which Annex A control?)
+- SOC 2 (which trust service criterion?)
+- PCI DSS 4.0 (which requirement?)
+- NIS2 (which Art. 21 measure?)
+- CIS Controls v8 (which control?)
+- ASD Essential 8 (which mitigation?)
+- ISO 27001:2022 (which control?)
+- MITRE ATLAS v5.1.0 (which TTP? Is it covered?)
+
+For each: Covered (adequate) / Covered (insufficient) / Missing entirely
+
+### Step 4: Generate new control requirements
+
+Write new control requirements in the format:
+```
+[CONTROL-ID]: [One-line control name]
+Description: [Specific, testable requirement]
+Evidence: [What demonstrates compliance]
+Framework gap it closes: [Which framework controls are insufficient]
+CVE evidence: [Which CVEs demonstrate this gap]
+```
+
+### Step 5: Calculate exposure score
+
+Estimate: What percentage of organizations that pass audits of existing controls are still exposed to this vulnerability?
+
+Use: Known patch deployment lag statistics + framework SLA vs. RWEP gap analysis.
+
+### Step 6: Produce lesson entry
+
+Format the output for addition to `data/zeroday-lessons.json`.
+
+---
+
+## Output Format
+
+```
+## Zero-Day Learning Loop: [CVE-ID / Vulnerability Name]
+
+**Date:** YYYY-MM-DD
+**RWEP:** [score]
+
+### Attack Vector
+[Extracted attack vector analysis]
+
+### Defense Chain Analysis
+| Layer | Required Control | Framework Coverage |
+|---|---|---|
+| Prevention | [control] | [Covered/Insufficient/Missing] |
+| Detection | [control] | [Covered/Insufficient/Missing] |
+| Response | [control] | [Covered/Insufficient/Missing] |
+
+### Framework Coverage Matrix
+[Per-framework table]
+
+### Gap Classification
+[Missing entirely / Insufficient / Compliant-but-exposed]
+
+### New Control Requirements
+[Generated requirements in standard format]
+
+### Exposure Scoring
+Estimated % of audit-passing orgs still exposed: [X]%
+Reason: [RWEP vs. framework SLA gap analysis]
+
+### Lesson Entry (for data/zeroday-lessons.json)
+[Ready-to-add JSON entry]
+```
+
+---
+
+## Compliance Theater Check
+
+Run this check against any organization claiming a mature vulnerability-management or threat-intelligence program:
+
+> "Pull the org's vulnerability-management runbook for the most recent five CISA-KEV-listed zero-days. For each: was the CVE patched? Almost certainly yes. Now ask the harder question: for each, where is the artifact that says (a) what attack vector this zero-day used, (b) what control would have caught it pre-patch, (c) which framework control was responsible for that detection/prevention, (d) was that framework control adequate, and (e) what new internal control requirement, if any, was created? If the answer is `we patched it, ticket closed` with no artifact, the program is patching CVEs and learning nothing. The next AI-generated variant of the same primitive will land against the same unchanged control surface. That is compliance theater for the threat-intel function — process compliance (A.5.7) with zero learning-loop output."
+
+> "Open `data/zeroday-lessons.json` (or the org's equivalent). Count the entries. Compare to the count of CVEs the org actually responded to in the same period. If the lesson-entry count is < CVE-response count, the loop is partial. Per AGENTS.md DR-8, partial is failure: every zero-day-in-scope must produce a lesson entry. The gap between CVEs-patched and lessons-learned is the size of the theater. The org's `Improve` function (NIST CSF 2.0) is not running."
+
+> "Ask: in the last 12 months, has a single internal control requirement been created or modified as a result of a public zero-day the org was NOT directly hit by? If no, the org's threat-intelligence control (ISO A.5.7) is consumption-only — collecting feeds, not changing controls. Threat-intel without control-system change is library subscription, not security capability."

package/vendor/blamejs/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for describing the origin of the Work and
+      reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 blamejs contributors
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied. See the License for the specific language governing
+   permissions and limitations under the License.

package/vendor/blamejs/README.md

@@ -0,0 +1,54 @@
+# Vendored from blamejs
+
+Subset of [blamejs](https://github.com/blamejs/blamejs), Apache-2.0, pinned to
+upstream commit [`1442f17`](https://github.com/blamejs/blamejs/commit/1442f17758a4bd511c63877561c0ffa759f66a87).
+
+## What's here
+
+| File | Upstream | Why vendored |
+|---|---|---|
+| `retry.js` | `lib/retry.js` | Battle-tested exponential backoff + crypto jitter + AbortSignal + circuit-breaker. Used by `lib/job-queue.js` and `lib/refresh-external.js` for HTTP retry semantics on KEV/EPSS/NVD/IETF/GitHub fetches. |
+| `worker-pool.js` | `lib/worker-pool.js` | Generic worker_threads pool with bounded queue, per-task timeout, worker recycle. Used by `scripts/build-indexes.js --parallel` and any future CPU-bound fan-out work. |
+| `LICENSE` | `LICENSE` | Apache-2.0 license text (identical to exceptd's). |
+| `_PROVENANCE.json` | — | sha256 of each vendored file + upstream file at pin, plus the strip rules applied. `lib/validate-vendor.js` re-hashes on every predeploy run. |
+
+## Flatten-and-inline strategy
+
+Each vendored file is a single-file leaf:
+
+- No imports of upstream blamejs siblings (`framework-error`, `constants`,
+  `validate-opts`, `numeric-bounds`, `lazy-require`, `audit`,
+  `observability`, `safe-async`).
+- Public surface preserved verbatim where possible. Behavior preserved
+  verbatim where preserved. Audit/observability sinks become no-op stubs
+  so call-site code from upstream patterns drops in cleanly.
+- Error envelope: upstream uses typed `XxxError` classes with stable
+  `code` strings. We replace the class with vanilla `Error` carrying the
+  same `code` field. Callers that switch on `err.code` keep working;
+  callers that did `instanceof WorkerPoolError` must switch to `err.code`.
+
+Every file lists its specific strip rules in its header banner and in
+`_PROVENANCE.json`.
+
+## Updating the pin
+
+1. Note the new upstream commit hash.
+2. Copy the upstream file into this directory.
+3. Re-apply the strip rules in the file header (the diff against the
+   raw upstream file is small).
+4. Update `_PROVENANCE.json` with the new commit, vendored sha256, and
+   upstream sha256 at pin.
+5. Run `npm run validate-vendor` — it confirms the recorded hashes
+   match the on-disk vendored copies.
+6. Bump the project version per the cadence rules. Pin updates are
+   patch-level; a structural change to the vendored surface is minor.
+
+## What we DON'T vendor
+
+| Upstream module | Why skipped |
+|---|---|
+| `lib/queue.js`, `lib/queue-local.js`, `lib/queue-redis.js`, `lib/queue-sqs.js` | DB-backed / cluster-aware / cloud-queue adapters. exceptd is an offline-first static-data CLI corpus with no database. The in-memory `lib/job-queue.js` covers the actual use case. |
+| `lib/http-client.js`, `lib/http-client-cache.js`, `lib/http-client-cookie-jar.js`, `lib/http-message-signature.js` | Full production HTTP client. Our needs are bounded to `fetch` + 10s `AbortController` timeout; stdlib is sufficient. |
+| `lib/cache.js`, `lib/cache-redis.js`, `lib/cache-status.js`, `lib/cdn-cache-control.js` | HTTP-layer cache with negotiation. The exceptd cache (`.cache/upstream/`) is a simple JSON file-per-entry layout with a flat index, a different problem. |
+| `lib/circuit-breaker.js` (standalone) | The `CircuitBreaker` class is already part of `retry.js` and is what we use; the standalone module is for callers that want only the breaker without the retry surface. |
+| `lib/audit.js`, `lib/observability.js`, `lib/framework-error.js`, etc. | exceptd has no audit chain, no metrics sink, and no framework-error infrastructure. The relevant call sites in the vendored files have been replaced with no-op stubs or vanilla `Error` objects. |

package/vendor/blamejs/_PROVENANCE.json

@@ -0,0 +1,54 @@
+{
+  "_schema_version": "1.0.0",
+  "_note": "Provenance manifest for vendored blamejs subset. lib/validate-vendor.js re-hashes each vendored file and verifies the recorded sha256 — silent hand-edits to a vendored copy fail the build. To re-vendor, copy the upstream file, re-apply the strip rules documented in each vendored file's header, refresh sha256 here, then re-run `npm run validate-vendor`.",
+  "source_repo": "https://github.com/blamejs/blamejs",
+  "license": "Apache-2.0",
+  "license_file": "LICENSE",
+  "license_sha256": "812075be5abe785284e823a97d09b5d1515b0221e3128059e1f5065de3c907d5",
+  "pinned_commit": "1442f17758a4bd511c63877561c0ffa759f66a87",
+  "pinned_at": "2026-05-11",
+  "files": {
+    "retry.js": {
+      "vendored_path": "vendor/blamejs/retry.js",
+      "vendored_sha256": "2b9a7d99a8477740dade4e4490e436817c250a3d63e9d91898a9cdaaeff82ac4",
+      "upstream_path": "lib/retry.js",
+      "upstream_sha256_at_pin": "e307f19a9012265d71f25fcf8e43e595479d38d1358f4b607b052d0ce053abb0",
+      "stripped": [
+        "observability event sink (_emitEvent → no-op)",
+        "audit chain hooks",
+        "lazy-require for safeAsync (replaced with stdlib AbortSignal-aware sleep)",
+        "numeric-checks dep (replaced with two inline predicates)",
+        "constants C.TIME.seconds(...) (replaced with literal ms values)"
+      ],
+      "exceptd_deltas": [
+        "_sleep timer is NOT unref'd — preserves event-loop liveness for one-shot CLI callers (refresh-external, prefetch, build-indexes --parallel). Upstream's safeAsync.sleep semantics around unref are not guaranteed; this delta is documented inline."
+      ],
+      "surface_preserved": [
+        "withRetry(fn, opts)",
+        "isRetryable(err)",
+        "backoffDelay(attempt, opts)",
+        "CircuitBreaker",
+        "DEFAULT_RETRY",
+        "DEFAULT_BREAKER"
+      ]
+    },
+    "worker-pool.js": {
+      "vendored_path": "vendor/blamejs/worker-pool.js",
+      "vendored_sha256": "57d8f5c3bca23cd4ef2a16adf4107bc60c4da3fbc9bb861580edc76ed9a2d132",
+      "upstream_path": "lib/worker-pool.js",
+      "upstream_sha256_at_pin": "262f99e9cc3d4a8f4eba9ad3e28401e8a1f47f78040afa63c9b17eb998437171",
+      "stripped": [
+        "WorkerPoolError class (replaced with vanilla Error with `code` field)",
+        "validate-opts dep (replaced with inline whitelist + type checks)",
+        "numeric-bounds dep (replaced with inline predicates)",
+        "audit event sink (_emitAudit → no-op stub)",
+        "constants C.BYTES.kib / C.TIME.minutes (replaced with literal int values)"
+      ],
+      "surface_preserved": [
+        "create(scriptPath, opts) -> { run, drain, terminate, stats }",
+        "bounded size + maxQueueDepth + taskTimeoutMs",
+        "worker recycle on uncaught error / timeout / exit"
+      ]
+    }
+  }
+}