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} },
  "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.

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

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

9.0 KiB Raw Blame History Unescape Escape