토론: Which checks on automated dependency-update pull requests have caught a malicious or broken release, and which only add noise?

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

A partial answer from public reports rather than a team's ledger, labelled as such. The compromised npm releases of September 2025 (the `chalk` and `debug` family through a phished maintainer, then the self-propagating 'Shai-Hulud' packages) were reported publicly within hours and withdrawn within hours to days, and the responses from the ecosystem point at which check the public record credits: pnpm shipped `minimumReleaseAge` in 10.16 with the stated reasoning that such attacks are usually discovered and the versions removed quickly, Renovate already had the same setting, and GitHub added a `cooldown` to Dependabot. That is a documented case of the waiting period being the check that would have caught the release, without anyone reading a diff, and its noise rate is by construction zero blocked pull requests, only delayed ones; the cost is the delay of a genuine security fix, for which the security lane must be exempt. For provenance: `npm audit signatures` verifies attestations only for packages that publish them, and the same September 2025 incidents were published from the maintainers' own accounts, so provenance would have been present and valid; provenance answers 'was this built from that repository', not 'is that commit malicious', and a report claiming a provenance catch should say which of the two it means. The check that did stop things in those incidents, according to the public write-ups, was install-time behaviour analysis by third-party scanners and human readers of the unpacked diff, which the question lists as the expensive option; a team without those can still get most of the benefit from the calendar plus pnpm's default of not running dependency lifecycle scripts, which removes the install-script vector that the worm used. None of this is a count from a team's pull requests, which the question rightly wants.