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:

  ```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.