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} },
    "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"
      }
    ],
    "reconsider": [
      {
        "canonical_id":   "INTEL-SA-00145",
        "current_bucket": "toimplement",
        "title":          "Lazy FP State Restore",
        "sources":        ["intel-psirt"],
        "urls":           ["https://www.intel.com/.../intel-sa-00145.html"],
        "extracted_cves": [],
        "first_seen":     "2026-04-19T09:41:44+00:00"
      }
    ]
  }
  ```

  - `items` are fresh observations from today's fetch: already inside the
    time window and not yet present in state under any alt-ID.
  - `reconsider` holds existing `toimplement`/`tocheck` entries from state,
    submitted for re-review each run (see the "Reconsideration" section
    below). On days where both arrays are empty, write 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`.

## Reconsideration rules (for `reconsider` entries)

Each `reconsider` entry is an item *already* in state under `current_bucket`
= `toimplement` or `tocheck`, from a prior run. Re-examine it against the
**current** `./checker/` tree and current knowledge. You may:

- **Demote** `toimplement` → `tocheck` or `unrelated` if the checker now
  covers the CVE/codename (grep confirms), or if reinterpreting the
  advisory shows it's out of scope.
- **Demote** `tocheck` → `unrelated` if new context settles the ambiguity
  as out-of-scope.
- **Promote** `tocheck` → `toimplement` if you now have firm evidence it's
  a real, in-scope, not-yet-covered CVE.
- **Leave it unchanged** (same bucket) — emit a record anyway; it's cheap
  and documents that the reconsideration happened today.
- **Reassign the canonical ID** — if a CVE has since been assigned to a
  vendor advisory (e.g., an INTEL-SA that previously had no CVE), put the
  CVE in `extracted_cves` and use it as the new `canonical_id`. The merge
  step will rekey the record under the CVE and keep the old ID as an alias.

For every reconsider record you emit, set `"reconsider": true` in its
classification entry — this tells the merge step to **overwrite** the
stored bucket (including demotions), not just promote.

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

These delta files cover the **`items`** array only — they answer "what
did today's fetch surface". Reconsider decisions update state (and surface
in the `current_*.md` snapshots the merge step rewrites); don't duplicate
them here.

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>
- reconsidered: <n> entries re-reviewed; <list any bucket transitions, e.g.
  "CVE-2018-3665: toimplement -> tocheck (now covered at src/vulns/...)">,
  or "no transitions" if every reconsider kept its existing bucket.
```

## `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 (`items` + `reconsider`). For items, use the
  same `stable_id` as in `new_items.json`. For reconsider entries, use the
  entry's `canonical_id` from state as the record's `stable_id`.
- `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.
- **Populate `extracted_cves` / `canonical_id` from context when the feed
  didn't.** If the title, body, or a well-known transient-execution codename
  mapping lets you identify a CVE the feed didn't emit (e.g., "Lazy FP
  State Restore" → `CVE-2018-3665`, "LazyFP" → same, "FP-DSS" → whatever
  CVE AMD/Intel assigned), put the CVE in `extracted_cves` and use it as
  `canonical_id`. This prevents Intel's CVE-less listing entries from
  creating orphan `INTEL-SA-NNNNN` records in the backlog.
- `sources` / `urls`: arrays; default to the item's own single source and
  permalink if you didn't enrich further.
- **`reconsider: true`** — set on every record that corresponds to an
  input from the `reconsider` array. The merge step uses this flag to
  overwrite the stored bucket instead of merging by "strongest wins" —
  this is what enables demotions.
- If both `items` and `reconsider` are 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.