Quels contrôles sur les pull requests automatisées de mise à jour des dépendances ont détecté une version malveillante ou défaillante, et lesquels ne font qu'ajouter du bruit ?

Question ouverte

Les robots de mise à jour ouvrent des pull requests pour chaque nouvelle version de dépendance, et les petites équipes ont tendance à fusionner sur la base d'un build vert, car lire chaque diff amont ne passe pas à l'échelle. Plusieurs contrôles supplémentaires existent. La documentation npm décrit des déclarations de provenance qui relient un paquet publié à son dépôt source et à ses instructions de build, ainsi qu'une commande npm audit signatures qui rapporte les signatures et attestations de registre vérifiées. Autres candidats : comparer le paquet décompressé plutôt que le numéro de version, inspecter les scripts d'installation et les nouveaux binaires, lire le diff du lockfile à la recherche d'ajouts transitifs inattendus, refuser les versions plus récentes qu'une période d'attente, vérifier que le tag de version existe dans le dépôt source, et épingler sur des empreintes (digests). Chaque contrôle a un coût en temps de pipeline et en attention du relecteur, et chacun produit du bruit. Ce qui manque, c'est un historique indiquant lesquels de ces contrôles ont, en pratique, bloqué une version qui s'est révélée compromise ou défaillante, dans quel écosystème, et quel était le taux de bruit. Le contrôle qui a détecté quelque chose se déclenchait-il aussi sur de nombreuses versions inoffensives ? La détection venait-elle d'un contrôle automatisé ou d'une personne lisant un diff signalé par le contrôle ? Les contrôles de provenance ont-ils déjà été le signal décisif, ou l'absence de provenance est-elle encore trop fréquente pour agir dessus ?

Ce qu'une réponse utile contient

L'écosystème (npm, PyPI, crates.io, modules Go, images de conteneur) et le nombre de pull requests de mise à jour sur la période. Pour chaque contrôle : comment il a été mis en œuvre, combien de pull requests il a bloquées ou signalées, combien d'entre elles ont ensuite été jugées de vrais problèmes, et comment ce jugement a été établi (avis public, retour en arrière en amont, analyse propre). Pour chaque détection réelle, si le même problème aurait été détecté par les seuls tests de CI. La période d'attente utilisée, le cas échéant, et toute version dont la période d'attente a retardé une publication qui s'est ensuite révélée être un correctif de sécurité important. La part des dépendances qui publient effectivement une provenance, car un contrôle qui s'applique à peu de paquets prouve peu de choses. Si les contrôles ont modifié le comportement de fusion de l'équipe (plus ou moins de mises à jour fusionnées), et si une mise à jour a déjà été fusionnée malgré un contrôle en échec, parce que ce contrôle était considéré comme du bruit. Les retours faisant état de zéro détection sur une longue période sont utiles et devraient indiquer combien de pull requests ont été couvertes.