4 pasos para abordar las dependencias vulnerables

Hace un par de semanas lanzamos la estrecha integración de Snyk con GitHub. Al desarrollarla, quisimos que fuera lo más fácil posible abordar las vulnerabilidades conocidas y exploramos las acciones más sencillas y claras que debías realizar para lograrlo. Finalmente, lo reducimos a 4 pasos, que resultaron ser válidos en todos los entornos, desde npm y Maven hasta herramientas de infraestructura como código, como Chef y Puppet.

En esta publicación se explican los pasos y cómo implementarlos con Snyk (para npm). Ten en cuenta que, aunque los ejemplos de Snyk se centran en probar aplicaciones con GitHub, también puedes realizar estos pasos con la CLI de Snyk.

Los pasos

Independientemente de las herramientas o el entorno que uses, estos son los pasos que debes seguir para abordar las vulnerabilidades conocidas en tus dependencias:

1. Encuentra las dependencias vulnerables

2. Corrige las vulnerabilidades

3. Evita agregar nuevos paquetes vulnerables

4. Responde con rapidez y eficiencia a las vulnerabilidades recién divulgadas.

Los dos primeros pasos te ayudan a alcanzar un estado sin vulnerabilidades. Ambos son necesarios: encontrar problemas sin abordarlos no sirve de mucho, pero tampoco puedes corregir problemas que desconoces. Facilitar la corrección es fundamental, ya que es muy tentador ignorar las alertas que no se pueden atender fácilmente. Por eso, las herramientas no solo deben permitir corregir los problemas, sino también hacer que sea muy sencillo hacerlo.

Una vez que estés libre de vulnerabilidades, los siguientes 2 pasos te ayudarán a mantenerte así a medida que tu código evoluciona y se divulgan nuevas vulnerabilidades. Tanto tu aplicación como el conocimiento público sobre las vulnerabilidades están en constante evolución, por lo que necesitas una solución continua para este problema.

1) Encuentra vulnerabilidades en tus repositorios

El primer paso es probar todos tus proyectos para detectar vulnerabilidades conocidas.

En Snyk, te ofrecemos una vista única para probar todos tus repositorios. Solo haz clic en “Probar mis repositorios” en esta página del blog o en nuestra página de pruebas para acceder a una página que muestra las vulnerabilidades en todos tus repositorios que usan npm.

Para cada repositorio que usa npm, Snyk identificará las dependencias y las cotejará con nuestra base de datos de vulnerabilidades de código abierto. Las vulnerabilidades se clasifican por nivel de gravedad (alto, medio o bajo) para facilitar la priorización. Además, puedes hacer clic para ver informes detallados de las pruebas.

2) Corrige las vulnerabilidades

Si tus proyectos tienen dependencias vulnerables, el siguiente paso es, claramente, eliminarlas. Encontrar problemas es útil para evaluar tu riesgo actual, pero lo que realmente quieres es corregirlos. Es fundamental invertir en herramientas que simplifiquen la corrección; de lo contrario, pronto te acostumbrarás a estos errores y los ignorarás. Lo mismo ocurre con el linting, las pruebas de rendimiento y otras pruebas de calidad.

En Snyk, nuestro objetivo principal es facilitar la corrección: la simplificamos a un botón que dice “Corregir” y genera automáticamente los cambios de código necesarios para eliminar las vulnerabilidades. Para hacerlo, monitorea un repositorio desde la pantalla mencionada antes y haz clic para ir a la página del proyecto en Snyk (mediante “Ver proyecto”). Allí encontrarás el botón “Corregir vulnerabilidades” en la esquina superior derecha. Al hacer clic, se genera un pull request con los cambios mínimos necesarios para corregir el problema y volver a escribir código.

Para corregir los problemas, Snyk primero buscará la actualización directa mínima que puedas aplicar para obtener una versión no vulnerable del paquete en cuestión. Si no existe una actualización de este tipo, Snyk intentará aplicar un parche a la vulnerabilidad mediante parches de código abierto de nuestra base de datos de vulnerabilidades.

"features-alert.png3) Evita agregar paquetes vulnerables

La seguridad, al igual que la calidad, es un proceso continuo. Una vez que estés libre de vulnerabilidades, debes asegurarte de no agregar nuevas dependencias vulnerables a medida que evoluciona tu proyecto. Y, como con cualquier otro aspecto de calidad, cuanto antes detectes un error de este tipo, más fácil y barato será corregirlo.

Detectar los problemas a tiempo implica agregarlos a tu flujo de pruebas continuas, lo que normalmente significa realizar pruebas durante la integración continua o como parte de un pull request de GitHub.

Cuando integras un proyecto de GitHub con Snyk (al hacer clic en el botón “Monitorear” mencionado antes), Snyk también agrega sus pruebas a los pasos de verificación de tus pull requests. Así, cada vez que un desarrollador crea un pull request, Snyk prueba sus cambios para determinar si volvieron vulnerable la aplicación. Si es así, la prueba falla claramente y ofrece detalles sobre cómo resolver el problema.

Agregar pruebas a los pull requests hace que los paquetes vulnerables sean muy visibles sin interponerse en el trabajo (puedes configurar el umbral). Esto ayuda a los miembros del equipo a detectar errores involuntarios a tiempo y es una buena manera de que los proyectos de código abierto se aseguren de que las contribuciones no incluyan fallas de seguridad. Las pruebas de pull requests normalmente no bloquean el proceso, así que puedes decidir combinar un cambio con vulnerabilidades si tienes prisa y has considerado las consecuencias.

4) Responde a las nuevas vulnerabilidades

Este último paso es donde la seguridad se diferencia un poco de otros aspectos de calidad. En la mayoría de los casos, solo generas errores nuevos cuando modificas tu código. En cambio, las vulnerabilidades conocidas pueden aparecer incluso si tu código no ha cambiado.

Cada cierto tiempo se divulgan nuevas vulnerabilidades que revelan brechas de seguridad hasta entonces desconocidas en tu aplicación. Estas fallas de seguridad siempre estuvieron en tu aplicación (y sus dependencias), pero ahora que se divulgaron, es mucho más probable que los atacantes las aprovechen. Para mantenerte protegido, necesitas una configuración que te permita conocer estas nuevas divulgaciones con rapidez y eficiencia, y corregirlas antes de que los atacantes puedan aprovecharlas.

En Snyk, también buscamos simplificar esta respuesta. Al usar la integración con GitHub, Snyk recuerda las dependencias que usa tu aplicación y también registra los cambios en tu package.json a lo largo del tiempo. Cuando se divulga una nueva vulnerabilidad y se agrega a nuestra base de datos, Snyk verifica si afecta a tu proyecto y, de ser así, notifica por correo electrónico a todas las personas de tu organización de Snyk. Además, enviamos automáticamente un pull request de corrección, para ahorrarte un paso.

Protege todos tus proyectos

Al ejecutar una prueba, es tentador fijarse solo en los proyectos que tienen dependencias vulnerables en ese momento. En efecto, esos son los únicos proyectos que requieren el segundo paso: corregir.

Sin embargo, ten en cuenta que el hecho de que un proyecto no sea vulnerable hoy no significa que no lo será mañana. Asegúrate de monitorear todos tus proyectos para poder evitar y responder adecuadamente cuando surjan nuevas dependencias vulnerables.

Resumen

Eso es todo. Con estos 4 pasos, estarás bien encaminado para abordar las dependencias vulnerables. En el caso de las dependencias de npm, Snyk debería facilitarte mucho el proceso. Para otras plataformas, puedes elegir las herramientas que prefieras (si existen), pero asegúrate de completar los cuatro pasos.

Empieza ahora: solo haz clic en “Probar mis repositorios” y ¡listo!