Welche Prüfungen bei automatisierten Dependency-Update-Pull-Requests haben eine bösartige oder defekte Version abgefangen, und welche erzeugen nur Störgeräusche?

Offene Frage

Update-Bots eröffnen für jede neue Abhängigkeitsversion einen Pull Request, und kleine Teams mergen in der Regel bei grünem Build, weil das Lesen jedes Upstream-Diffs nicht skaliert. Es gibt mehrere zusätzliche Prüfungen. Die npm-Dokumentation beschreibt Provenance-Angaben, die ein veröffentlichtes Paket mit seinem Quell-Repository und seinen Build-Anweisungen verknüpfen, sowie einen Befehl npm audit signatures, der verifizierte Registry-Signaturen und Attestierungen meldet. Weitere Kandidaten: das entpackte Paket statt nur die Versionsnummer zu diffen, Install-Skripte und neue Binärdateien zu prüfen, den Lockfile-Diff auf unerwartete transitive Ergänzungen zu lesen, Versionen abzulehnen, die jünger als eine Wartefrist sind, zu prüfen, ob der Release-Tag im Quell-Repository existiert, und auf Digests zu pinnen. Jede Prüfung kostet Pipeline-Zeit und Aufmerksamkeit der Reviewenden, und jede erzeugt etwas Störgeräusch. Was fehlt, ist eine Aufzeichnung darüber, welche dieser Prüfungen in der Praxis tatsächlich eine Version blockiert haben, die sich später als kompromittiert oder defekt herausstellte, in welchem Ökosystem und wie hoch die Störgeräuschrate war. Hat die Prüfung, die etwas abgefangen hat, auch bei vielen harmlosen Versionen ausgelöst? Kam der Fund von einer automatisierten Prüfung oder von einer Person, die einen von der Prüfung markierten Diff gelesen hat? Waren Provenance-Prüfungen jemals das entscheidende Signal, oder ist das Fehlen von Provenance noch zu verbreitet, um daraus zu handeln?

Was eine nützliche Antwort enthält

Das Ökosystem (npm, PyPI, crates.io, Go-Module, Container-Images) und die Anzahl der Update-Pull-Requests im Zeitraum. Pro Prüfung: wie sie umgesetzt wurde, wie viele Pull Requests sie blockiert oder markiert hat, wie viele davon später als echte Probleme beurteilt wurden und wie diese Beurteilung zustande kam (öffentlicher Hinweis, Upstream-Revert, eigene Analyse). Für jeden echten Fund: ob dasselbe Problem auch allein durch CI-Tests entdeckt worden wäre. Die verwendete Wartefrist, falls vorhanden, sowie jede Version, deren Auslieferung durch die Wartefrist verzögert wurde und die sich später als wichtige Sicherheitskorrektur herausstellte. Der Anteil der Abhängigkeiten, die überhaupt Provenance veröffentlichen, denn eine Prüfung, die nur für wenige Pakete gilt, beweist wenig. Ob die Prüfungen das Merge-Verhalten des Teams verändert haben (mehr oder weniger gemergte Updates) und ob je ein Update trotz fehlgeschlagener Prüfung gemergt wurde, weil die Prüfung als Störgeräusch galt. Berichte über null Funde über einen langen Zeitraum sind nützlich und sollten angeben, wie viele Pull Requests erfasst wurden.