Mejorar las pruebas de seguridad de proyectos Go con DepGraphs

Nos complace anunciar una mejora considerable en el rendimiento de las pruebas de seguridad de proyectos Go mediante Snyk CLI. En algunos casos, el tiempo de análisis se redujo en más de un 90 %. Esta mejora, que pronto llegará a otros lenguajes, fue posible gracias a cambios en nuestro método de análisis que permiten a Snyk procesar proyectos enormes, ¡incluso del tamaño de Kubernetes! (Más información a continuación).

Dependencias, dependencias y más dependencias

Las aplicaciones y los proyectos pueden tener distintas formas y tamaños, pero todos comparten algo: incluyen dependencias de código abierto. Como miembro del equipo de Lenguajes de Snyk, también puedo afirmar con seguridad que los proyectos que comienzan siendo pequeños y tienen pocas dependencias crecen rápidamente hasta convertirse en proyectos más grandes, con decenas o incluso cientos de dependencias directas y transitivas.

La cantidad de dependencias de un proyecto puede afectar directamente el rendimiento del análisis. Cuando algunos usuarios nos comentaron que sus proyectos Go se analizaban o monitoreaban con lentitud, empezamos a buscar una solución duradera que pudiera crecer junto con nuestros usuarios y sus proyectos. Finalmente, optamos por migrar la estructura de datos de nuestra aplicación de dependedencyTrees a dependencyGraphs.

DepTrees vs. DepGraphs: cómo mejorar las pruebas de seguridad

Al analizar el archivo de manifiesto de un proyecto, se crea un dependencyTree que enumera todas las dependencias de código abierto que utiliza, tanto directas como transitivas. Aunque este método funciona bien para proyectos pequeños, resultó problemático con los proyectos más grandes. Los dependencyTrees crecían demasiado y terminaban ocupando mucha memoria.

Para ilustrarlo y tener una referencia, veamos un ejemplo básico del uso de un dependencyTree para procesar un proyecto Go pequeño.

Ejemplo básico del uso de un árbol de dependencias para procesar un proyecto Go

Las dependencias resueltas de este pequeño proyecto Go con dependencyTree se ven así:

Aunque solo tiene tres dependencias directas de código abierto, las dependencias transitivas incluidas generan un dependencyTree de 11 MB. Imagina un proyecto con más de 100 dependencias directas. El dependencyTree resultante sería enorme y probablemente ralentizaría los análisis e incluso provocaría que un análisis con CLI fallara con un error OutOfMemory.

El modelo de datos que ofrece dependencyGraph resuelve este problema. Gracias a los vértices y las aristas, ya no es necesario incluir varias veces la misma dependencia. Esto permite ahorrar mucha memoria, como se muestra en la siguiente imagen:

Para el mismo proyecto básico que vimos antes, ahora tenemos un dependencyGraph de 51 KB. ¡Una gran reducción frente a los 11 MB!

Más rendimiento para... los análisis de seguridad de Kubernetes

La migración de dependencyTree a dependencyGraph tuvo un impacto enorme y eliminó la lentitud que antes se experimentaba con los proyectos Go.

Una historia de éxito interesante fue la de un proyecto que quizá algunos lectores ya conozcan: Kubernetes.

Tuvimos algunas dificultades al intentar analizar el proyecto Kubernetes en busca de vulnerabilidades con Snyk. Esto se debía directamente al modelo de datos anterior, dependencyTree, y al enorme tamaño del proyecto.

El nuevo dependencyGraph ayudó a resolver estos problemas. Ahora, las pruebas del repositorio principal de Kubernetes mediante Snyk CLI son rápidas y generan un archivo de 1,1 MB, un tamaño totalmente aceptable para un proyecto tan grande y con tantas capas.

¿Qué sigue?

Sabemos que el rendimiento a escala es una preocupación clave para nuestros usuarios y nos comprometemos a mejorar continuamente la compatibilidad con lenguajes y ecosistemas. La migración a dependencyGraph es un ejemplo de ello, y los comentarios de nuestros usuarios tras este cambio han sido muy positivos.

Como mencionamos, estos cambios se aplicaron recientemente a Snyk CLI para proyectos Go. Los usuarios de Java se alegrarán de saber que también migramos a dependencyGraph para los proyectos Java Gradle. Una vez más, solo en CLI.

La mejor noticia es que planeamos acelerar la migración a la nueva estructura de datos. Primero, la llevaremos a otros lenguajes mediante CLI (npm, yarn, maven, sbt) y, después, también fuera de CLI, a nuestras integraciones basadas en Git.

Pronto compartiremos más novedades. ¡Mantente al tanto y, más importante aún, mantente seguro!