Zum Inhalt

A vulnerability report pages without a word of what it says, and a secret by its kind and its file

  • Status: accepted
  • Date: 2026-11-08

Context

The blueprint turns on private vulnerability reporting and secret scanning in every repository, and SECURITY.md promises to acknowledge a report within 7 days and to assess it within 14. GitHub tells of a new report, and of a secret that secret scanning found, only by mail, which is easy to miss for a week. Its webhook brings both: repository_advisory with the actions reported and published, and secret_scanning_alert with created, reopened, publicly_leaked and resolved, for the permissions Repository security advisories: Read and Secret scanning alerts: Read.

A report is under embargo until its advisory is published: its summary and its description may say how to break the software. A chat of Telegram is not encrypted end to end, a log of Cloudflare and the recent deliveries of the app keep what the pager writes there, and the control repository runs Claude. The webhook of a secret carries no secret, but the answer of GET …/secret-scanning/alerts/{number} does. Neither webhook says where a secret was found, nor does GitHub send an event when the maintainer accepts or closes a report.

Options

  1. The report as it is, with its summary in the message: the most useful message, and a leak of the embargo into Telegram, the log and the control repository.
  2. Nothing but a link, as GitHub's mail does: safe, but it says neither how urgent the report is nor by when it needs an answer.
  3. Its id, its severity and its days, never what it says, with one reminder on the day before the acknowledgement is due, which reads only the state of the advisory, and a secret by its kind and its file.

Decision

Option 3. The rules read of a report its id, its severity, if the reporter gave one, and its day, and drop the rest of the payload; the thing keeps the same, so no summary or description reaches a message, a record of Workers KV, a log, the answer to GitHub or the control repository, which a text in the topic of a report gives the message as Dennis sees it: the repository, the id and its link, the severity and the two days. A report offers ⏰ Later and ✖ Ignore and no button that sends it to Claude, and its advisory published ticks it ✅.

Six days after the report, the schedule asks GitHub for the state of the advisory, with a token of the app for repository_advisories: read, and reads only that field: still in triage, the report comes again, which notifies; accepted as a draft, it needs no reminder; closed, withdrawn or published, its message says so. When GitHub doesn't tell the state, the reminder comes all the same, since one reminder too many costs less than a promise missed. The day of the reminder is in the metadata of the record, which the list of the schedule reads already, so it costs no read or list of its own.

An alert of secret scanning is an entry of the security message of its repository, the bundle of code scanning, renamed 🛡 Security in demo, so that one message holds what the security of a repository needs. Its entry names the kind of its secret and the file of its first place, from GET …/secret-scanning/alerts/{number}/locations, with a token for secret_scanning_alerts: read, whose answer holds no secret; the pager never reads the alert itself. A security message of secrets alone offers no 🛠 Start fix: a secret that leaked is revoked where it was issued, which no change of the code does; with code scanning in the message, 🛠 Start fix sends only its alerts. An event of secret scanning that failed always comes again, since one push brings one event per alert and a leak missed is worse than a late copy; a copy from before the alert was resolved is known by its time, which the pager keeps for four hours, and changes nothing.

Consequences

Dennis learns of a report at once, with how urgent it is and by when SECURITY.md promises an answer, and once more on the day before, without the report leaving GitHub; to read it, he opens its link. The app needs two more permissions and two more events, which an app registered before must be given by hand, as docs/setup.md says. test/security.test.ts sends a report with a summary and a description, and an alert with a secret, through the route of the webhook, and fails when any of them shows in a message, a record, a log or an answer. A new field of a report that the pager would show needs a new look at this decision first.