Améliorer les tests de sécurité des projets Go grâce aux DepGraphs

Nous sommes ravis d’annoncer une nette amélioration des performances des tests de sécurité des projets Go via la CLI Snyk, avec une réduction du temps d’analyse pouvant dépasser 90 % ! Cette amélioration, qui sera bientôt proposée pour d’autres langages, est rendue possible par des changements apportés à notre méthode d’analyse. Snyk peut ainsi gérer d’énormes projets, même de la taille de Kubernetes ! (Nous y reviendrons plus bas.)

Des dépendances, encore des dépendances, toujours plus de dépendances

Les applications et les projets se présentent sous différentes formes, mais ils ont tous un point commun : ils intègrent des dépendances open source. En tant que membre de l’équipe Langages de Snyk, je peux également affirmer en toute confiance que les projets qui démarrent modestement, avec un petit nombre de dépendances, prennent rapidement de l’ampleur et finissent par compter des dizaines, voire des centaines de dépendances directes et transitives.

Le nombre de dépendances d’un projet peut avoir un impact direct sur les performances de l’analyse. Lorsque certains de nos utilisateurs se sont plaints de la lenteur des analyses et de la surveillance de leurs projets Go, nous avons cherché une solution durable, capable d’évoluer avec nos utilisateurs et leurs projets. La solution finalement retenue a consisté à migrer la structure de données de notre application de dependedencyTrees vers dependencyGraphs.

DepTrees ou DepGraphs : améliorer les tests de sécurité

Lors de l’analyse du fichier manifeste d’un projet, un dependencyTree est créé. Il répertorie toutes les dépendances open source utilisées, directes et transitives. Cette méthode convient aux petits projets, mais s’est révélée problématique pour les projets plus importants. Les dependencyTrees devenaient trop volumineux et occupaient beaucoup trop de mémoire.

Pour illustrer le sujet et mieux comprendre, prenons un exemple simple : utilisons un dependencyTree pour gérer un petit projet Go.

Exemple simple d’utilisation d’un arbre de dépendances pour gérer un projet Go

Voici les dépendances résolues de ce petit projet Go à l’aide de dependencyTree :

Même avec seulement trois dépendances open source directes, les dépendances transitives incluses produisent un dependencyTree de 11 Mo. Imaginez un projet comportant plus de 100 dépendances directes. Le dependencyTree obtenu serait énorme et risquerait fort de ralentir les analyses, voire de faire échouer une analyse via la CLI avec une erreur OutOfMemory.

Le modèle de données fourni par dependencyGraph résout ce problème. Grâce aux sommets et aux arêtes, il n’est plus nécessaire d’inclure plusieurs fois une même dépendance. Résultat : une économie de mémoire considérable, comme le montre l’image ci-dessous :

Pour le même petit projet que précédemment, le dependencyGraph ne pèse désormais que 51 Ko. Une réduction considérable par rapport aux 11 Mo !

Des performances accrues pour… l’analyse de sécurité de Kubernetes

La migration de dependencyTree vers dependencyGraph a eu un impact considérable : elle a éliminé les ralentissements que connaissaient les projets Go.

Kubernetes est un exemple de réussite intéressant, et certains de nos lecteurs en ont peut-être déjà entendu parler.

Nous avions rencontré des difficultés pour analyser les vulnérabilités du projet Kubernetes avec Snyk. Elles étaient directement liées à l’ancien modèle de données dependencyTree et à la taille considérable du projet.

Le nouveau dependencyGraph a permis de résoudre ces problèmes. Les tests du dépôt principal de Kubernetes via la CLI Snyk sont désormais rapides et génèrent un fichier de 1,1 Mo, une taille tout à fait acceptable pour un projet aussi vaste et complexe.

Et maintenant ?

Conscients que les performances à grande échelle sont une préoccupation majeure pour nos utilisateurs, nous nous engageons à améliorer continuellement la prise en charge des langages et des écosystèmes. La migration vers dependencyGraph en est un exemple, et les retours de nos utilisateurs à la suite de ce changement ont été extrêmement positifs.

Comme indiqué, ces changements ont récemment été appliqués à la CLI Snyk pour les projets Go. Les utilisateurs de Java seront ravis d’apprendre que nous avons également adopté dependencyGraph pour les projets Java Gradle. Là encore, uniquement dans la CLI.

Mieux encore, nous prévoyons d’accélérer la migration vers cette nouvelle structure de données. Nous commencerons par d’autres langages via la CLI (npm, yarn, maven, sbt), puis nous l’étendrons au-delà de la CLI, à nos intégrations Git.

Nous vous en dirons bientôt plus. Restez à l’écoute et, surtout, restez en sécurité !