¿Qué comprobaciones en los pull requests de actualización automática de dependencias han detectado una versión maliciosa o defectuosa, y cuáles solo generan ruido?

Pregunta abierta

Los bots de actualización abren un pull request por cada nueva versión de una dependencia, y los equipos pequeños suelen fusionarlo en cuanto la compilación está en verde, porque revisar cada diff del proyecto original no es escalable. Existen varias comprobaciones adicionales. La documentación de npm describe declaraciones de procedencia (provenance) que vinculan un paquete publicado con su repositorio de origen y con las instrucciones de compilación, así como un comando npm audit signatures que informa de las firmas del registro y de las attestations verificadas. Otras posibilidades son: comparar el contenido del paquete descomprimido en lugar del número de versión, inspeccionar los scripts de instalación y los nuevos binarios, revisar el diff del lockfile en busca de incorporaciones transitivas inesperadas, rechazar versiones publicadas hace menos tiempo que un periodo de espera, comprobar que la etiqueta (tag) de la versión existe en el repositorio de origen y fijar las dependencias mediante digests. Cada comprobación tiene un coste en tiempo de pipeline y en atención de quien revisa, y cada una genera algo de ruido. Lo que falta es un registro de cuáles de estas comprobaciones han bloqueado en la práctica una versión que después resultó estar comprometida o defectuosa, en qué ecosistema, y cuál fue la tasa de ruido. ¿La comprobación que detectó algo también saltó en muchas versiones inofensivas? ¿La detección provino de una comprobación automática o de una persona que leyó un diff que la comprobación había marcado? ¿Ha sido alguna vez la comprobación de procedencia la señal decisiva, o la ausencia de procedencia sigue siendo demasiado habitual como para actuar en consecuencia?

Qué contiene una respuesta útil

El ecosistema (npm, PyPI, crates.io, módulos de Go, imágenes de contenedor) y el número de pull requests de actualización en el periodo. Por cada comprobación: cómo se implementó, cuántos pull requests bloqueó o marcó, cuántos de ellos se consideraron después problemas reales y cómo se llegó a ese juicio (aviso público, reversión en el proyecto original, análisis propio). Para cada detección real, si el mismo problema habría sido detectado solo con las pruebas del CI. El periodo de espera utilizado, si lo hubo, y cualquier versión que ese periodo haya retrasado y que después resultara ser una corrección de seguridad importante. La proporción de dependencias que llegan a publicar procedencia, ya que una comprobación que se aplica a pocos paquetes demuestra poco. Si las comprobaciones cambiaron el comportamiento de fusión del equipo (más o menos actualizaciones fusionadas) y si alguna vez se fusionó una actualización con una comprobación fallida porque se consideraba ruido. Los informes de cero detecciones durante un periodo largo son útiles y deben indicar cuántos pull requests abarcaron.