Apaguemos Dependabot

• Se señala que las alertas excesivas de Dependabot terminan haciendo que los desarrolladores pierdan tiempo en lugar de resolver problemas reales de seguridad
• Como ocurrió en el ecosistema de Go, se generan miles de PR y advertencias incluso en repositorios no afectados, lo que provoca confusión
• Al usar una GitHub Action basada en govulncheck, se puede detectar solo el código realmente vulnerable y eliminar alertas innecesarias
• Las actualizaciones de dependencias se gestionan de forma más segura y eficiente mediante pruebas periódicas y verificación de versiones recientes que con PR automatizados
• Este enfoque es importante para reducir la fatiga por alertas (alert fatigue) y aliviar la carga de los mantenedores de código abierto

---

Problemas de Dependabot

• Dependabot genera en masa alertas de seguridad y PR automáticos, lo que dificulta que los desarrolladores distingan los problemas realmente importantes
  • Incluso una modificación menor en el paquete de Go filippo.io/edwards25519 generó miles de PR
  • También se enviaron alertas de seguridad erróneas a repositorios no afectados, como Wycheproof
• Las alertas incluyen puntajes CVSS incorrectos y métricas de compatibilidad bajas, creando una preocupación innecesaria
• Se indica que este exceso de notificaciones reduce la confianza y la eficiencia de la respuesta de seguridad

Una alternativa con govulncheck

• La base de datos de vulnerabilidades de Go ofrece metadatos detallados a nivel de versión, paquete y símbolo
  • Por ejemplo, la vulnerabilidad GO-2026-4503 solo afecta al símbolo Point.MultiScalarMult
• govulncheck usa análisis estático para detectar únicamente el código vulnerable que realmente puede ser llamado
  • Si se usa junto con go mod why, permite determinar con precisión si una dependencia indirecta tiene impacto
  • Según el resultado del análisis, aunque exista una vulnerabilidad, no se emite una alerta si el código no llama a ese símbolo
• Se puede integrar fácilmente mediante la CLI (govulncheck -json) o la API de Go (golang.org/x/vuln/scan)

Sustitución con GitHub Actions

• En lugar de Dependabot, se puede configurar una GitHub Action de govulncheck para ejecutar revisiones automáticas todos los días
  • Solo envía alertas cuando se detectan vulnerabilidades reales
  • Como no genera PR automáticos, los desarrolladores pueden concentrarse en los problemas de seguridad importantes
• Reducir las alertas erróneas ayuda a aliviar la fatiga por alertas de seguridad (alert fatigue) y mejora la calidad de la respuesta
• También elimina el problema de enviar PR innecesarios a mantenedores de código abierto

Cómo gestionar las actualizaciones de dependencias

• Las dependencias deben administrarse en bloque según el ciclo de desarrollo de cada proyecto
  • Se deben ejecutar pruebas diarias con las versiones más recientes, pero realizar las actualizaciones reales solo cuando sea necesario
  • En Go se pueden probar las versiones recientes con go get -u -t ./..., y en npm con el comando npm update
• Este enfoque permite asegurar tanto la rapidez de respuesta ante vulnerabilidades de seguridad como la estabilidad
  • Las pruebas con versiones recientes ayudan a detectar antes los problemas de compatibilidad
  • También evita que se desplieguen de inmediato dependencias que contengan código malicioso
• Con geomys/sandboxed-step, es posible ejecutar de forma aislada con gVisor en un entorno de CI

Conclusión y contexto de apoyo

• La automatización de Dependabot a menudo genera más ruido (noise) que seguridad real
• Un enfoque basado en govulncheck y pruebas periódicas es una forma más precisa y sostenible de gestionar la seguridad
• El mantenimiento de código abierto del autor del artículo continúa gracias al apoyo, a través de la organización Geomys, de Ava Labs, Teleport, Tailscale y Sentry, entre otros
• Este modelo contribuye al mantenimiento estable del ecosistema open source y a mejorar la calidad de la seguridad

[GN⁺]

Opiniones de Hacker News

• Dependabot tiene cierto valor
  Pero una herramienta que solo compara números de versión con una base de datos de vulnerabilidades no puede determinar si el código real está expuesto a esa vulnerabilidad, así que genera mucho ruido
  Una herramienta que me impresionó recientemente es CodeQL. Se puede ejecutar en GitHub Advanced Security y rastrea el flujo real del código para mostrar visualmente la ruta completa desde una entrada hasta un uso riesgoso
  Gracias a eso, ofrece información sobre la que sí se puede actuar y tiene pocos falsos positivos. Claro, en lenguajes dinámicos como Python puede haber código que evada la detección, pero en la mayoría de los casos sigue siendo bastante útil
  • Antes CodeQL ayudaba al proyecto, pero últimamente llegó a un nivel tan molesto que el equipo decidió desactivarlo
    Empezaron a aparecer comentarios del tipo “agrega una variable intermedia inútil” solo para evitar advertencias de CodeQL. Se siente como una herramienta sobreajustada a los datos
  • Me cuesta estar de acuerdo con eso de que “casi no tiene falsos positivos”. Según el teorema de Rice, ese tipo de análisis perfecto es imposible
  • En mi experiencia, CodeQL tiene muchos falsos positivos y no hay una forma sencilla de ejecutarlo localmente, así que terminas con dependencia del proveedor
  • Que subas la versión de una dependencia no garantiza que mejore la seguridad. La nueva versión también podría traer vulnerabilidades nuevas
• En paquetes de NPM salen demasiadas alertas de ReDoS. La mayoría son paquetes que solo se usan en código cliente, pero aparecen demasiadas alertas que no tienen nada que ver con el backend. Para nosotros, un ReDoS del lado del cliente no significa nada
  • En realidad creo que un DoS no es una vulnerabilidad de seguridad sino un problema de disponibilidad. Sí, la disponibilidad es una de las CIA de seguridad, pero en la práctica se parece más a un problema operativo. Clasificar un DoS como tema de seguridad no es más que un vestigio histórico
  • Yo mantengo el paquete debug, y llegan demasiados reportes basura de ReDoS. En algunos casos hasta les asignan un CVE, y dan ganas de abandonar por completo el ecosistema de JS
  • Con las herramientas de revisión de código con IA pasa algo parecido. Aunque sea una herramienta que corre localmente con permisos de usuario, igual te dice que sanitices entradas sin necesidad. Al final es una pérdida de tiempo
  • Nosotros también tenemos el mismo problema. En especial, las alertas de ReDoS que vienen de dependencias de desarrollo meten mucho ruido innecesario
  • ReDoS es un bug del motor de expresiones regulares, y motores como V8 siguen sin ofrecer por defecto un motor de regex seguro
• Govulncheck es una de las mejores cosas del ecosistema Go
  Estamos usando una GitHub Action que hicimos para avisar cuando en un PR se agrega una llamada vulnerable.
  Si lo usas junto con el automerge de Dependabot, también es una buena combinación para mantener codebases de JS
  • Govulncheck tampoco es perfecto. Tiene falsos positivos y no hay forma de excluir una vulnerabilidad específica por número de CVE
• Dependabot es útil, pero al mismo tiempo te recuerda todos los días la importancia de minimizar dependencias
  • Yo también empiezo el día revisando PRs de Dependabot cada mañana.
    Si las pruebas son buenas, a veces descubres bugs en versiones nuevas, pero en el proceso eso también termina en contribuciones a open source. Es molesto, pero ayuda a formar un buen hábito
  • También estoy de acuerdo. No tengo tantos proyectos, pero Dependabot sí resulta bastante útil
• Ojalá Dependabot se administrara como una pestaña dentro del repositorio en lugar de por correo electrónico.
  Las notificaciones por email son molestas y tampoco me gusta que se acumulen PRs. Preferiría atenderlo concentradamente en ciertos horarios
  • Con la configuración de dependabot.yml puedes ajustar la frecuencia de ejecución y la cantidad de PRs
    Consulta la documentación oficial
  • También puedes desactivar los PR automáticos y crearlos manualmente solo cuando los necesites.
    Incluso puedes ir corrigiéndolo tú mismo para reducir la cantidad de issues
  • Si usas la extensión Refined GitHub, la vista por defecto queda un poco más limpia.
    Personalmente recomiendo Renovate. Soporta más lenguajes y más opciones de automerge
• El enfoque de govulncheck en Go (rastrear la ruta real de llamadas) debería ser el estándar en todos los ecosistemas
  El problema de fondo de Dependabot es que confunde la gestión de dependencias con un problema de seguridad.
  Una vulnerabilidad en una función que nunca se llama no es un tema de seguridad, sino ruido
  En Python, siento que pip-audit --desc es mejor que Dependabot.
  Hasta que exista un análisis estático perfecto, una revisión manual trimestral podría ser incluso más segura
  • Pero cuando los clientes escanean el código con herramientas de este tipo, no te creen si respondes “esa función no se usa”.
    Ahí es donde aparece la brecha entre la seguridad real y las prácticas de seguridad
  • También es válida la pregunta: “si no la usan, ¿por qué esa función sigue en el código?”
• No entiendo por qué la industria aceptó estos escáneres de seguridad superficiales
  La mayoría de los CVE en realidad no afectan, pero las empresas se esfuerzan por llevar a 0 la cantidad de vulnerabilidades en imágenes de contenedor
  Además, cuando actualizas dependencias, inevitablemente aparecen CVE nuevos. Eso pasa porque la mayoría del software no hace backport de parches
  • No me queda muy claro cómo se conecta esa parte de “no hacen backport” con la frase anterior
• La ventaja de Dependabot o Renovate es que funcionan sin importar el lenguaje
  Cuantos más repositorios tengas y más variados sean los lenguajes, menos realista es agregar un workflow de CI perfecto para cada caso
  No es perfecto, pero creo que sigue siendo mucho mejor que no hacer nada
• Me da curiosidad de dónde salen los puntajes CVSS de Dependabot.
  ¿Genera los CVE automáticamente?
  • El CVSS es un puntaje que asume el peor escenario posible, así que no refleja el riesgo real.
    La base de datos de vulnerabilidades de GitHub está más enfocada en cantidad que en calidad, y Dependabot funciona como un spammer tonto de alertas
  • Incluso se puede dudar de si ese bug es realmente una vulnerabilidad.
    Si el problema solo ocurre cuando llamas una función de forma incorrecta, probablemente el código ya ni siquiera estaba funcionando
• En nuestra empresa pasa algo parecido.
  El escaneo de imágenes de contenedor en GCP le lanza a Vanta un montón de alertas de CVE, pero la mayoría no se pueden corregir o en realidad son rutas que no se usan
  Me pregunto si habrá alguna herramienta que haga este tipo de filtrado basado en contexto
  • En nuestra empresa usamos Aikido Code. Intenta filtrar con IA el impacto real de las vulnerabilidades.
    Los resultados en general son positivos, pero con un codebase grande y muchas dependencias sigue siendo difícil bajar la cantidad de CVE