Les dépendances tierces représentent en moyenne 80% du code d’une application (Gartner). Au même titre que le code écrit par les développeurs de l’application, une porte d’entrée dans une de ces librairies peut compromettre la sécurité du système. Ainsi, en plus des vulnérabilités présentes dans le code écrit par les développeurs de la dite application, il faut s’assurer que ces dépendances embarquées ne contiennent pas de CVE.
Afin de vérifier ces dépendances, l’outil d’analyse doit les lister et déduire les versions utilisées. Cette tâche peut s’avérer complexe lorsque les versions des librairies ne sont pas définies explicitement dans les fichiers de configurations (packages.json, pom.xml, etc) ou que l’arbre des dépendances inclue plusieurs fois la même librairie avec des versions différentes. Il n’est pas rare de retrouver des versions différentes entre plusieurs outils d’analyse de dépendances.
Une fois cette liste étable, l’outil peut aller interroger des bases de données contenant les CVE (NVD, MITRE, etc.) et faire la correspondance avec la liste définie pour l’application à analyser.
Dependency-check
Probablement l’outil d’analyse de dépendances le plus connu, Dependency-check est un projet proposé par l’OWASP.
Disponible en ligne de commande ou sous forme de plugins Maven, Ant, Jenkins, etc, il permet d’analyser les dépendances des applications développées en Java et .NET. D’autres langages de développement sont disponibles en beta.
Après analyse de l’application et récupération/déduction de la liste des dépendances, le site NVD du NIST est interrogé pour détecter CVE présentes.
Un exemple de rapport est disponible ici.
Plus d’informations sont disponibles sur un précédent article.
Dependency-track
Autre projet de l’OWASP, Dependency-trak est une alternative plus évoluée à Dependency-check offrant un portail web complet de gestion et de suivi des vulnérabilités dans les composants intégrés à une ou plusieurs applications développées en Java, Python, .NET, Javascript, etc. La solution est à installer on-premises via Docker ou WAR.
L’analyse se fait en interrogeant plusieurs bases de données configurables (VulnDB, NVD, NPM Audit et Sonatype OSS Index). En fonction des résultats, des notifications (email, Slack, Teams, etc) peuvent être envoyées. Les résultats peuvent également être intégrés directement dans des outils d’agrégation de vulnérabilités de type ThreadFix, Fortify, DefectDojo, etc. Pour intégrer l’outil dans d’autres solutions non prises en charge, une API REST est fournie.
La partie portail web propose différents points de vue pour analyser les vulnérabilités :
- Un dashboard synthétique offrant une vue globale sur l’ensemble des applications avec un suivi dans le temps :
- Une vue par application :
- Une vue par composant permettant de mettre en évidence tous les projets impactés par une dépendance vulnérable :
En entrée, Dependency-track impose un SBOM (Software Bill of Material) généré par les outils CycloneDX ou SPDX.
A noter également que Dependency Track fournit une gestion des utilisateurs et de leurs autorisations de manière indépendante ou via un annuaire LDAP.
Des fonctionnalités d’analyse des licences et de vérification d’intégrité des dépendances sont annoncées dans les prochaines versions.
Snyk
Snyk est un outil commercial (gratuit mais limité pour les projets open source) offrant la possibilité d’analyser les applications en Java, Javascript, .NET, Python, Ruby, etc. Disponible uniquement en SaaS, Snyk peut se connecter directement à Gitlab, GitHub, Bitbucket, DockerHub, etc ou être utilisé sous forme de plugins IDE (IntelliJ, Eclipse) ou en ligne de commande.
Une fois l’analyse effectuée, Snyk propose différents dashboards d’analyse des résultats :
- Une vue globale des projets avec les vulnérabilités associées
- Une vue par projet
- Des rapports détaillés (uniquement sur les versions payantes)
Une des valeurs ajoutées par rapport à Dependency-check/Dependency-track est la possibilité de corriger directement les vulnérabilités une Merge Request :
Attention tout de même à l’utilisation de cette fonctionnalité qui peut avoir des effets de bord sur le fonctionnement de l’application.
Autre fonctionnalité intéressante, Snyk peut analyser l’application de manière périodique et envoyer des notifications (mail, Slack, etc.) à la découverte de nouveaux problèmes de sécurité :
Dernier point fort de Snyk, il est possible d’installer un agent Snyk qui instrumente l’application et remonte sur la plateforme les méthodes vulnérables appelées dans les dépendances vulnérables. Cette fonctionnalité permet de prioriser les actions correctives vers les risques les plus probables. Attention, cet agent remonte à Snyk des informations sur l’environnement d’exécution de l’application (OS, Version ,etc.). Plus de détails sont disponibles ici.
En annexe, Snyk propose une liste des licences utilisées par les dépendances ainsi qu’une fonctionnalité d’analyse des images Docker.
Retire.js
Spécialisé dans l’analyse des dépendances Javascript, Retire.js est disponible sous forme de ligne de commande, via Gulp, Grunt, extensions Chrome/Firefox ou via Zap et Burp. Contrairement aux autres outils qui interrogent des bases de données externes dédiés aux CVE, Retire.js embarque sa propre liste de CVE. En cas de nouvelle CVE, il faut donc attendre la mise à jour de l’outil.
Les rapports émis sont disponibles sous plusieurs formats: json, texte et CycloneDX, ce qui permet d’intégrer les résultats directement dans Dependency-track.
Conclusion
Snyk et Dependency-track fournissent plus de fonctionnalités que Dependency-check et retire.js. L’aspect SaaS de Snyk peut être un frein pour certains projets mais les fonctionnalités à forte valeur ajoutée apporte un gain de productivité intéressant. Dependency-track semble être un bon compromis à moindre coût pour la plupart des projets.