Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only.
A new advisory against a dev-only transitive dependency turns the self-scan red for every open PR, including PRs that cannot possibly have caused it and whose authors cannot act on it.
What happened on 2026-09-30
A brace-expansion advisory published overnight. main's self-scan was green at 2026-09-29 12:41. The next branch to run CI was #1238, a docs-only PR from a first-time contributor touching three markdown files. Its checks went red, and the contributor reasonably tried to explain the failure himself.
Both affected copies came in through jest, so they are dev-only and transitive. Nothing in that PR could have caused it, and nothing its author could do would have fixed it.
The question
Should the self-scan gate treat dev-only findings differently from runtime ones?
Arguments for keeping it strict: a dev dependency still executes on developer machines and in CI, and supply-chain attacks on build tooling are a real category. Going quiet on them is how you stop noticing.
Arguments for softening: a red check that no PR author can act on trains everyone to ignore red checks, which is worse than the risk being flagged. It also lands on first-time contributors, who are least equipped to tell an unrelated break from their own mistake.
Decided 2026-09-30: make the failure self-explanatory. When the scan fails on findings that also exist on the base branch, the output must say so plainly, for example 2 of 2 findings pre-exist on the base branch and are not caused by this change. The scan already diffs against a baseline, so it has the information it needs.
This is the exit criterion for this issue. It closes when that message ships.
Why not the alternatives. Not failing on dev-only findings was rejected: dev dependencies execute on developer machines and in CI, build-tooling supply-chain attacks are a real category, and going quiet on them undermines what this project is for. Auto-baselining them was rejected too: the baseline should record deliberate acceptances, not automatic ones, or it stops meaning anything.
Giving the Self Fix workflow's PRs CI is split out separately. It shortens the window rather than changing the gate, and it carries its own supply-chain tradeoff, so it is a different decision.
Context
Self Fix PRs never get CI. #1250, the automated brace-expansion fix, arrived with zero checks and sat at BLOCKED. GitHub does not trigger workflows for PRs opened by the github-actions bot using the default GITHUB_TOKEN, to prevent recursive loops. So the automation detects, fixes and opens a PR within minutes, then waits for a human. On 2026-09-30 that was about two hours, during which every other open PR was red.
A new advisory against a dev-only transitive dependency turns the self-scan red for every open PR, including PRs that cannot possibly have caused it and whose authors cannot act on it.
What happened on 2026-09-30
A
brace-expansionadvisory published overnight.main's self-scan was green at 2026-09-29 12:41. The next branch to run CI was #1238, a docs-only PR from a first-time contributor touching three markdown files. Its checks went red, and the contributor reasonably tried to explain the failure himself.Both affected copies came in through
jest, so they are dev-only and transitive. Nothing in that PR could have caused it, and nothing its author could do would have fixed it.The question
Should the self-scan gate treat dev-only findings differently from runtime ones?
Arguments for keeping it strict: a dev dependency still executes on developer machines and in CI, and supply-chain attacks on build tooling are a real category. Going quiet on them is how you stop noticing.
Arguments for softening: a red check that no PR author can act on trains everyone to ignore red checks, which is worse than the risk being flagged. It also lands on first-time contributors, who are least equipped to tell an unrelated break from their own mistake.
Decided 2026-09-30: make the failure self-explanatory. When the scan fails on findings that also exist on the base branch, the output must say so plainly, for example
2 of 2 findings pre-exist on the base branch and are not caused by this change. The scan already diffs against a baseline, so it has the information it needs.This is the exit criterion for this issue. It closes when that message ships.
Why not the alternatives. Not failing on dev-only findings was rejected: dev dependencies execute on developer machines and in CI, build-tooling supply-chain attacks are a real category, and going quiet on them undermines what this project is for. Auto-baselining them was rejected too: the baseline should record deliberate acceptances, not automatic ones, or it stops meaning anything.
Giving the Self Fix workflow's PRs CI is split out separately. It shortens the window rather than changing the gate, and it carries its own supply-chain tradeoff, so it is a different decision.
Context
Self Fix PRs never get CI. #1250, the automated brace-expansion fix, arrived with zero checks and sat at
BLOCKED. GitHub does not trigger workflows for PRs opened by thegithub-actionsbot using the defaultGITHUB_TOKEN, to prevent recursive loops. So the automation detects, fixes and opens a PR within minutes, then waits for a human. On 2026-09-30 that was about two hours, during which every other open PR was red.