vulnerability-spoiler-alert turns commit patches into pre-CVE findings

Four setup steps, one API key, and a cron you can retime

Installation is a fork plus a secret. Add either `ANTHROPIC_API_KEY` or `OPENAI_API_KEY` under Settings, Secrets and variables, Actions, and set the Pages source to GitHub Actions. The `GITHUB_TOKEN` needs no setup because Actions supplies it, so the only credential you actually paste is the key for the provider you picked. Then edit the `repositories` array and the provider and model in `.github/workflows/monitor.yml`, and enable the workflows in the Actions tab. The schedule is an ordinary cron entry, and the shipped value is every six hours:

schedule:
  - cron: '0 */6 * * *'  # Every 6 hours

A manual run is available at Actions, Monitor Vulnerabilities, Run workflow, which is what you want on the first pass to see output without waiting for the next tick. Once it runs, the output has two readers. The site is a GitHub Pages deployment with a live site link, and a feed.xml sits beside it, so the same findings arrive as a page or as a subscription. Neither needs a server, a database or an account, and both come out of the Pages build. The choice between them is a reading habit rather than a feature: the page carries the label badges and the collapsed false-positive section, while the feed gives you the stream as it lands, which is the half of the pipeline nobody has reviewed yet.

true-positive without a CVE label is the negative-day state, and it is the point

The label table is the whole verification model, and it has three entries. `true-positive` marks a real vulnerability, verified by hand or automatically, and displays as a green VERIFIED badge until a CVE is assigned, at which point it turns to CONFIRMED. `false-positive` dims the finding and moves it into a collapsible section. A third label, `cve:CVE-<ID>`, is the promotion mechanism. So a finding carrying `true-positive` and nothing else is confirmed real but still inside the window before a CVE is assigned, which is the state the project exists to surface. The CVE checker keeps re-checking verified findings until one matches, which means the same issue sits on the site as unconfirmed for as long as it takes for a CVE to appear.

A GHSA advisory will not promote a finding, and that is deliberate

The label documentation is explicit that only a real CVE counts. A GitHub Security Advisory on its own does not promote a verified finding to CONFIRMED, and the cve label can be applied either automatically by the CVE checker or manually. The distinction is a scope decision rather than a technical limit. A GHSA covers a narrower disclosure path than a CVE record, and treating one as equivalent would push findings into a confirmed state on weaker evidence. The practical effect for a reader is that the badge on the site reflects CVE assignment, not the project's own confidence, so a VERIFIED badge with a linked advisory is still a candidate and not a published vulnerability.

Applying a label is what rebuilds the site

The site is not regenerated on a schedule of its own. It rebuilds when labels are added or removed, which puts a person in the publication path in a way most automated feeds avoid. Adding `false-positive` to a noisy finding removes it from the main flow of the page without deleting the record, and adding `cve:CVE-<ID>` to a verified finding changes how it is presented. The pipeline that produces those findings is a separate scheduled job, but the thing the public reads is downstream of a triage decision. That arrangement means the site can stay current without anyone maintaining a web server, and it also means a finding nobody has looked at stays visible for as long as the model keeps producing it.

The scanning logic is not in this repository

This project is described as an example usage of vulnerability-spoiler-alert-action, by Eugene Lim, and the underlying research is written up separately in a post on discovering negative days through LLM workflows for vulnerability research. The idea it borrows from that work is the negative day: the gap between a fix landing and the disclosure becoming public, a window where the patch is public on the repository but the vulnerability is not yet named. What lives here is the wiring. The action that scans repositories and runs the model calls is elsewhere, so reading this repository tells you which eight repositories are watched and how often, but not how a commit is turned into a finding. The monitored list is Express, Node.js, Django, Flask, Rails, Apache HTTPD, nginx and Grafana.

Zero dependencies describes the site build, not the scanning step

The architecture notes list three properties: the site build script uses only built-in Node.js APIs with zero dependencies, the output is a static site of plain HTML plus an RSS feed deployed through GitHub Pages, and the styling is a deliberate retro theme. The first of those is scoped precisely, and it is worth keeping in mind while reading it. Zero dependencies covers the part that renders pages, not the part that decides what to render. The model call goes to Claude or OpenAI over the network on every scheduled run, and the state of the scan lives in the separate action rather than in this repository, so nothing here runs offline. The feed is a plain RSS document at the published site, which also means anything that can read a URL can consume the findings without touching GitHub.

The state file at the repository root is never explained

The top level of the repository holds a `.claude/` directory, a `scripts/` directory, a `LICENSE`, a `README.md`, a `.github/` directory, a `.gitignore`, and two JSON files: `repos.json` and `.vulnerability-spoiler-state.json`. The README explains how to change the watch list, and it points at the `repositories` array in the workflow file rather than at `repos.json`. The state file gets no explanation at all, and neither does its relationship to the action running in a separate repository. Anyone who forks this to watch their own dependencies will be editing the workflow array as documented, with a file at the root whose purpose has to be guessed. The repository is MIT licensed, not archived, and the last push was on 2026-09-01.

Editorial conclusion

Adopt vulnerability-spoiler-alert if you want a cheap feed of candidates rather than a verdict, and if reading a commit diff yourself before acting is an acceptable part of the workflow. Do not adopt it as an authoritative advisory channel: the promotion from verified to confirmed depends on a human applying labels, and a GHSA-only advisory never gets a finding promoted. Before trusting a finding, read the commit it points at and check whether the label that carries it was applied by a person or by the CVE checker.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository