spectre-meltdown-checker/scripts/daily_vuln_watch_prompt.md

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:

  {
    "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.

## 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):

## 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:

[
  {
    "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.