spectre-meltdown-checker/.github/workflows/daily_vuln_scan_prompt.md

Daily transient-execution vulnerability scan

You are a scheduled agent running inside a GitHub Actions job. Your job is to audit public news/advisory sources for transient-execution and CPU side-channel vulnerabilities that may need to be added to spectre-meltdown-checker (this repository).

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 handed to you by the workflow

• Working directory: the repo root (/github/workspace in Actions, or wherever actions/checkout placed it). You may grep the repo to check whether a CVE or codename is already covered.

• state/seen.json — memory carried over from the previous run, with shape:

  {
    "last_run": "2026-04-17T08:00:12Z",
    "seen": {
      "<stable-id-1>": { "bucket": "unrelated", "seen_at": "2026-04-17T08:00:12Z", "source": "phoronix" },
      "<stable-id-2>": { "bucket": "tocheck",   "seen_at": "2026-04-17T08:00:12Z", "source": "oss-sec", "cve": "CVE-2026-1234" }
    }
  }
  

  On the very first run, or when the prior artifact has expired, the file exists but seen is empty and last_run is null.

• Environment: SCAN_DATE (ISO-8601 timestamp of the run start, set by the workflow). Treat this as "now" for all time-window decisions.

Time window

This is a belt-and-suspenders design — use both mechanisms:

1. Primary: stable-id dedup. If an item's stable identifier (see below) is already present in state.seen, skip it entirely — it was classified on a previous day.
2. Secondary: 25-hour window. Among new items, prefer those whose publication/update timestamp is within the last 25 h relative to SCAN_DATE. This bounds work when the prior artifact expired (90-day retention) or when last_run is stale (missed runs). If last_run is older than 25 h, widen the window to now - last_run + 1h so no items are lost across missed runs.
3. Items without a parseable timestamp: include them (fail-safe).

Sources to poll

Fetch each URL with curl -sS -A "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36" -L --max-time 20. On non-2xx or timeout, record the failure in the run summary and continue — do not abort.

RSS / Atom feeds (primary — parse feed timestamps)

Short name	URL
phoronix	https://www.phoronix.com/rss.php
oss-sec	https://seclists.org/rss/oss-sec.rss
lwn	https://lwn.net/headlines/newrss
project-zero	https://googleprojectzero.blogspot.com/feeds/posts/default
vusec	https://www.vusec.net/feed/
comsec-eth	https://comsec.ethz.ch/category/news/feed/
msrc	https://msrc.microsoft.com/update-guide/rss
cisa	https://www.cisa.gov/cybersecurity-advisories/all.xml
cert-cc	https://www.kb.cert.org/vuls/atomfeed/

HTML pages (no RSS — fetch, extract dated entries)

Short name	URL
intel-psirt	https://www.intel.com/content/www/us/en/security-center/default.html
amd-psirt	https://www.amd.com/en/resources/product-security.html
arm-spec	https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability
transient-fail	https://transient.fail/

For HTML pages: look for advisory tables or listings with dates. Extract the advisory title, permalink, and date. If a page has no dates at all, compare its content against state.seen — any new advisory IDs not yet classified count as "new this run".

Stable identifier per source

Use the first available of these, in order, as the dedup key:

1. Vendor advisory ID (INTEL-SA-01234, AMD-SB-7001, ARM-2024-0042, VU#123456, CVE-YYYY-NNNNN)
2. RSS <guid> / Atom <id>
3. Permalink URL (<link>)

Always also record the permalink URL in the output file so a human can click through.

Classification rules

For each new item (not in state.seen) that passes the time window, pick exactly one bucket:

• toimplement — a clearly-identified new transient-execution / CPU side-channel vulnerability in scope, and not already covered by this repo. Verify the second half by grepping the repo for the CVE ID and the codename before classifying; 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. State clearly what would resolve the ambiguity.
• 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.

Outputs

Compute TODAY=$(date -u -d "$SCAN_DATE" +%F). Write these files under the repo root, overwriting if they already exist (they shouldn't unless the workflow re-ran the same day):

• rss_${TODAY}_toimplement.md
• rss_${TODAY}_tocheck.md
• rss_${TODAY}_unrelated.md

Each file uses level-2 headers per source short-name, then one bullet per item: the stable ID (if any), the permalink URL, and 1–2 sentences. Keep entries terse — a human skims these daily.

## oss-sec
- **CVE-2026-1234** — https://www.openwall.com/lists/oss-security/2026/04/18/3
  New Intel transient-execution bug "Foo" disclosed today; affects
  Redwood Cove cores, microcode fix pending. Not yet covered by this
  repo (grepped for CVE-2026-1234 and "Foo" — no matches).

## phoronix
- https://www.phoronix.com/news/Some-Article
  Linux 7.2 drops a compiler-target flag; unrelated to CPU side channels.

If a bucket has no items, write the file with a single line (no new items in this window) so it is obvious the job ran.

Run summary

Append this block to the tocheck file (creating it if empty):

## Run summary
- SCAN_DATE: <value>
- window cutoff: <computed cutoff>
- prior state size: <N> entries, last_run=<value>
- per-source new item counts: phoronix=<n>, oss-sec=<n>, lwn=<n>, ...
- fetch failures: <list, or "none">
- total classified this run: toimplement=<n>, tocheck=<n>, unrelated=<n>

State update

Rewrite state/seen.json with:

• last_run = SCAN_DATE
• seen = union of (pruned prior seen) ∪ (all items classified this run, keyed by stable ID, with {bucket, seen_at=SCAN_DATE, source, cve?})

Pruning (keep state bounded): drop any entry whose seen_at is older than 30 days before SCAN_DATE. The workflow step also does this as a safety net, but do it here too so the in-memory view is consistent.

Guardrails

• Do NOT modify any repo source code. Only write the three markdown output files and state/seen.json.
• Do NOT create commits, branches, or PRs.
• Do NOT call any tool that posts externally (Slack, GitHub comments, issues, email, etc.).
• Do NOT follow links off-site for deeper investigation unless strictly needed to resolve a tocheck ambiguity — budget of at most 5 such follow-ups per run.
• If a source returns unexpectedly large content, truncate to the first ~200 items before parsing.
• If total runtime exceeds 15 minutes, finish whatever you can, write partial outputs, and note it in the run summary.