init: daily vulnerability watch automation

scripts used by the cron vuln-watch workflow from the master branch.
2026-04-22 16:43:20 +02:00 · 2026-04-19 08:25:16 +00:00
commit 94356c4992
7 changed files with 904 additions and 0 deletions
--- a/scripts/daily_vuln_watch_prompt.md
+++ b/scripts/daily_vuln_watch_prompt.md
@@ -0,0 +1,155 @@
+# Daily transient-execution vulnerability scan — classification step
+
+You are a scheduled agent running inside a GitHub Actions job. A preceding
+workflow step has already fetched all configured sources, applied HTTP
+conditional caching, deduped against prior state, and written the pre-filtered
+list of new items to `new_items.json`. Your only job is to classify each item.
+
+## What counts as "relevant"
+
+spectre-meltdown-checker detects, reports, and suggests mitigations for CPU
+vulnerabilities such as: Spectre v1/v2/v4, Meltdown, Foreshadow/L1TF, MDS
+(ZombieLoad/RIDL/Fallout), TAA, SRBDS, iTLB Multihit, Zenbleed, Downfall (GDS),
+Retbleed, Inception, SRSO, BHI, RFDS, Reptar, FP-DSS, and any similar
+microarchitectural side-channel or speculative-execution issue on x86
+(Intel/AMD) or ARM CPUs. It also surfaces related hardware mitigation features
+(SMAP/SMEP/UMIP/IBPB/eIBRS/STIBP…) when they gate the remediation for a tracked
+CVE.
+
+It does **not** track generic software CVEs, GPU driver bugs, networking
+stacks, filesystem bugs, userspace crypto issues, or unrelated kernel
+subsystems.
+
+## Inputs
+
+- `new_items.json` — shape:
+
+  ```json
+  {
+    "scan_date": "2026-04-18T14:24:43+00:00",
+    "window_cutoff": "2026-04-17T13:24:43+00:00",
+    "per_source": {
+      "phoronix": {"status": 200, "new": 2, "total_in_feed": 75},
+      "oss-sec":  {"status": 304, "new": 0}
+    },
+    "items": [
+      {
+        "source": "phoronix",
+        "stable_id": "CVE-2026-1234",
+        "title": "...",
+        "permalink": "https://...",
+        "guid": "...",
+        "published_at": "2026-04-18T05:00:00+00:00",
+        "extracted_cves": ["CVE-2026-1234"],
+        "vendor_ids": [],
+        "snippet": "first 400 chars of description, tags stripped"
+      }
+    ]
+  }
+  ```
+
+  `items` is already: (a) within the time window, (b) not known to prior
+  state under any of its alt-IDs. If `items` is empty, your only job is to
+  write the three stub output files with `(no new items in this window)`.
+
+- `./checker/` is a checkout of the **`test`** branch of this repo (the
+  development branch where coded-but-unreleased CVE checks live). This is
+  the source of truth for whether a CVE is already covered. Grep this
+  directory — not the working directory root, which only holds the
+  vuln-watch scripts and has no checker code.
+
+## Classification rules
+
+For each item in `items`, pick exactly one bucket:
+
+- **toimplement** — a clearly-identified new transient-execution / CPU
+  side-channel vulnerability in scope, **and not already covered by this
+  repo**. To verify the second half: grep `./checker/` for each entry of
+  `extracted_cves` *and* for any codename in the title (e.g., "FP-DSS",
+  "Inception"). If either matches existing code, demote to `tocheck`.
+- **tocheck** — plausibly in-scope but ambiguous: mitigation-only feature
+  (LASS, IBT, APIC-virt, etc.); item seemingly already implemented but worth
+  confirming scope; unclear applicability (e.g. embedded-only ARM SKU);
+  CVE-ID pending; contradictory info across sources.
+- **unrelated** — everything else.
+
+Tie-breakers: prefer `tocheck` over `unrelated` when uncertain. Prefer
+`tocheck` over `toimplement` when the CVE ID is still "reserved" / "pending" —
+false positives in `toimplement` waste human time more than false positives
+in `tocheck`.
+
+`WebFetch` is available for resolving `tocheck` ambiguity. Budget: **3
+follow-ups per run total**. Do not use it for items you already plan to file
+as `unrelated` or `toimplement`.
+
+## Outputs
+
+Compute `TODAY` = the `YYYY-MM-DD` prefix of `scan_date`. Write three files at
+the repo root, overwriting if present:
+
+- `watch_${TODAY}_toimplement.md`
+- `watch_${TODAY}_tocheck.md`
+- `watch_${TODAY}_unrelated.md`
+
+Each file uses level-2 headers per source short-name, then one bullet per
+item: the stable ID, the permalink, and 1–2 sentences of context.
+
+```markdown
+## oss-sec
+- **CVE-2026-1234** — https://www.openwall.com/lists/oss-security/2026/04/18/3
+  New Intel transient-execution bug "Foo"; affects Redwood Cove cores.
+  Not yet covered (grepped CVE-2026-1234 and "Foo" — no matches).
+```
+
+If a bucket has no items, write `(no new items in this window)`.
+
+Append the following block to the **tocheck** file (creating it if
+otherwise empty):
+
+```markdown
+## Run summary
+- scan_date: <value>
+- per-source counts (from per_source): ...
+- fetch failures (status != 200/304): ...
+- total classified this run: toimplement=<n>, tocheck=<n>, unrelated=<n>
+```
+
+## `classifications.json` — required side-channel for the merge step
+
+Also write `classifications.json` at the repo root. It is a JSON array, one
+record per item in `new_items.json.items`:
+
+```json
+[
+  {
+    "stable_id":      "CVE-2026-1234",
+    "canonical_id":   "CVE-2026-1234",
+    "bucket":         "toimplement",
+    "extracted_cves": ["CVE-2026-1234"],
+    "sources":        ["phoronix"],
+    "urls":           ["https://www.phoronix.com/news/..."]
+  }
+]
+```
+
+Rules:
+
+- One record per input item. Same `stable_id` as in `new_items.json`.
+- `canonical_id`: prefer the first `extracted_cves` entry if any; otherwise
+  the item's `stable_id`. **Use the same `canonical_id` for multiple items
+  that are really the same CVE from different sources** — the merge step
+  will collapse them into one entry and add alias rows automatically.
+- `sources` / `urls`: arrays; default to the item's own single source and
+  permalink if you didn't enrich further.
+- If `new_items.json.items` is empty, write `[]`.
+
+## Guardrails
+
+- Do NOT modify any repo source code. Only write the four output files.
+- Do NOT create commits, branches, or PRs.
+- Do NOT call tools that post externally (Slack, GitHub comments, issues, …).
+- Do NOT re-fetch the RSS/HTML sources — that was the prior step's job.
+  `WebFetch` is only for drilling into a specific advisory/article URL to
+  resolve a `tocheck` ambiguity (budget 3).
+- If total runtime exceeds 10 minutes, finish what you have, write partial
+  outputs (+ a note in the tocheck run summary), and exit cleanly.