Nightly security sweep: turn Dependabot and code-scanning (CodeQL) alerts into board-tracked issues
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- github, github-actions, javascript
Direzione di ricerca
Start with scripts/dependabot-alerts.mjs, dependabot-alerts.yml, and the relevant rules in AGENTS.md; compare the existing Dependabot sweep with the CodeQL API and workflow permissions described here. Check the credential dependency in #2544 and the v2/main scanning split in #2545 before implementation. Done means nightly, deduplicated Dependabot and code-scanning findings are filed and boarded, while malformed listings write nothing.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
Security alerts reach this repo from two GitHub sources, and only one of them becomes tracked work:
| Source | What produces it | Swept into issues today? |
|---|---|---|
| Dependabot alerts | vulnerable dependency ranges in a lockfile | Yes, daily (dependabot-alerts.yml, #2233). It files issues, but cannot board them: PROJECT_TOKEN does not exist (#2462). |
| Code scanning alerts | CodeQL (default setup), plus any other tool that uploads SARIF | No. Nothing reads them. |
CodeQL is not a third source: it is the tool behind the code-scanning alerts on Security → Code scanning. A sweep reads them all through one API, GET /repos/{owner}/{repo}/code-scanning/alerts, and can split by tool.name.
What that gap cost during the v2.9.0 release:
- A high-severity ReDoS reached the release PR undetected. CodeQL flagged
clients/cli/src/error-handler.ts:169only as a check on the milestone-merge PR (#2536). It was a regression from this milestone's #2423 work, fixed in #2540 / #2541, with the release on hold meanwhile. - Three high-severity alerts sit open with no issue: #74, #75, #76, all
js/incomplete-sanitization("does not escape backslash characters"), inscripts/dependabot-alerts.mjs:435,:679andscripts/sdk-watch.mjs:442. Nothing tracks them, and the code is unchanged onv2/main.
The deeper problem: CodeQL never looks at v2/main
CodeQL runs as default setup (languages: actions, javascript-typescript, schedule: weekly). Default setup analyzes the default branch (main) and PRs that target it. Every analysis on record is refs/heads/main or a PR into main, and the only PRs analyzed are the four milestone merges (#2304, #2381, #2456, #2536).
So no v2 development work is scanned until the milestone merge. A nightly sweep of the alerts cannot fix that on its own: an alert for code on v2/main does not exist until that code reaches a PR against main. It is the same blind spot AGENTS.md already records for Dependabot ("a vulnerable dependency introduced on v2/main and not yet merged to main produces no alert at all"), and for CodeQL it covers every line of first-party code.
Goal
A nightly sweep turns open Dependabot and code-scanning alerts into board-tracked issues, one per actionable finding, with no duplicates, the same way dependabot-alerts.yml does for Dependabot today.
Scanning v2/main itself, so that those alerts exist for v2 code before the release PR, is split out as #2545.
Design sketch
The sweep
Extend scripts/dependabot-alerts.mjs into a security-alert sweep, or add a sibling scripts/code-scanning-alerts.mjs with a shared filing and boarding core. It keeps the existing sweep's invariants:
- Re-check against
v2/mainbefore filing. Dependabot re-checks each vulnerable range againstv2/main's lockfile. For code scanning, the equivalent is to take the alert on thev2/mainref once #2545 makes that ref exist. Until then, check that the alert's file and line still hold the flagged code onv2/main, and skip one already fixed there. - One issue per finding, deduplicated by a marker that encodes tool + rule + alert number, with markers trusted only on automation-authored issues (the
AGENTS.mdrule, since the repo is public). - Board it directly at
Todo/Highonce the credential exists, the same standing override the Dependabot sweep uses. Without the credential, fall back to the labeled, milestoned triage hand-off. - Fail loudly on a bad listing (rate limit, truncated or 5xx response) and write nothing, as #2425 made the Dependabot sweep do.
- Never close an issue. A fixed alert closes itself; closing its issue is a maintainer act.
- No model in any write-capable job. This sweep is deterministic and needs none.
Out of scope unless we choose it: secret scanning (GET …/secret-scanning/alerts). It is a third alert type, would need its own read permission, and its alerts should not be copied into a public issue body. Decide explicitly rather than by omission.
Credential
The GitHub App is now its own issue, #2544, and its permission list there already includes what this sweep needs:
| Permission (GitHub App) | Needed for | Workflow permissions: equivalent |
|---|---|---|
| Repository → Dependabot alerts: read | GET …/dependabot/alerts |
vulnerability-alerts: read |
| Repository → Code scanning alerts: read | GET …/code-scanning/alerts |
security-events: read |
| Repository → Administration: read (optional) | turns the sweep's automated-security-fixes check from UNVERIFIED into a real assertion |
none: GITHUB_TOKEN cannot hold it |
| Repository → Secret scanning alerts: read (only if secret scanning is in scope) | GET …/secret-scanning/alerts |
secret-scanning-alerts: read |
Both reads are available to GITHUB_TOKEN through workflow permissions:, so the listing half does not strictly need the App. Only the board write does. Putting everything on the App still keeps the sweep to one identity with one scope list, so add the two read permissions when the App is created.
Blocked on
#2544 (the GitHub App), for the board write. Part of tracker #2543.
Acceptance
- A nightly sweep files one issue per open, unfixed-on-
v2/mainDependabot and code-scanning alert, deduplicated, and boards it atTodo/Highwhen the credential is present - The sweep fails loudly, writing nothing, on a rate-limited or malformed listing
- The sweep would file today's open alerts; #74, #75 and #76 are being fixed directly in #2546
- Lingua principale
- TypeScript
- Stelle
- 11.1k
- Fork
- 1.6k
- Merge medio
- 5h 29m
- PR unite (30g)
- 158
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di modelcontextprotocol/inspector
-
enhancement v2
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
modelcontextprotocol/inspector#2782 ·
I maintainer di solito rispondono entro 1 giorno
-
CLI tests seed the developer's real ~/.mcp-inspector/mcp.json (cli.test.ts, completion.test.ts)Apertabug v2
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
modelcontextprotocol/inspector#2765 ·
I maintainer di solito rispondono entro 1 giorno
-
chore v2
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
modelcontextprotocol/inspector#2752 ·
I maintainer di solito rispondono entro 1 giorno
-
SSE transport: connection succeeds then marked 'Failed' after first event, works fine with raw curlAperta
Difficoltà 4/5 1-2 giorni Idoneità per principianti 53/100
modelcontextprotocol/inspector#2783 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement v2
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
modelcontextprotocol/inspector#2772 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di modelcontextprotocol/inspector
Issue simili
-
[Bug]: REST API URL starting with "http" but no scheme (e.g. httpbin.org/get) is not given an http:// prefixForse già presa @ItsDeadlyProgrammer l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
appsmithorg/appsmith#42471 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ehmpathy/rhachet-roles-bhrain#705 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Status: Triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
mermaid-js/mermaid#8546 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
braintrustdata/braintrust-sdk-javascript#2659 ·
I maintainer di solito rispondono entro 1 giorno