Surveiller vos dépendances avec Dependency Check de l'OWASP
Selon le Gartner, dans une application, 80% du code est fourni par des dépendances (spring, ORM, parsing de XML/JSON, etc.). Sur 95% des applications qui contiennent des dépendances opensource, 65% contiennent des dépendances vulnérables.
Malheureusement, lorsqu’une dépendance est installée pour un besoin spécifique, le suivi est rarement fait pour se tenir à jour des nouvelles versions et encore moins des vulnérabilités qui pouvant l’affecter.
Dependency Check
L’OWASP propose un outil nommé Dependency Check permettant de lister et vérifier automatiquement pour toutes les dépendances d’une application si une CVE (Common Vulnerabilities and Exposures) a été publiée pour la version utilisée. La base de données utilisée par Dependency Check est le NVD Data Feeds proposée par le NIST.
Dependency Check est actuellement mature pour Java, .NET et expérimental pour Ruby, Node.js, Python et C/C++. Il est disponible sur la forme d’un plugin Maven, un plugin Gradle, une tâche Ant, un plugin Jenkins ou un executable en ligne de commande. Il existe également un plugin Sonarqube permettant d’intégrer directement les résultats dans les “issues” et les “measures”.
Glossaire
CVE (Common Vulnerabilities and Exposures)
Dictionnaire public maintenu par le MITRE et permettant d’identifier des vulnérabilités sur des composants logiciel
Exemple :
CVE-2017-9787 - When using a Spring AOP functionality to secure Struts actions it is possible to perform a DoS attack when user was properly authenticated. Solution is to upgrade to Apache Struts version 2.5.12 or 2.3.33.
CWE (Common Weakness Enumeration)
Classe de vulnérabilités
Exemple : SQL Injection
- CPE Confidence : Indice de confiance sur la reconnaissance d’une dépendance et de sa version
- Evidence : Preuve permettant de déterminer le nom et la version d’une dépendance
Exécution via Jenkins
En intégrant le plugin Jenkins (mode job et pipleline disponibles), Dependency Check peut être exécuté à chaque fois qu’une build est déclenchée.
Les résultats sont ensuite mis à disposition via un lien sur la page “status” de la build :
L’intégration peut être directement faite dans Sonarqube via un plugin :
Les métriques sont disponibles dans l’onglet “Measures” de chaque projet. Suite aux changements intervenus sur Sonarqube 6.x, le détail des vulnérabilités ne peut pas être consulté directement en cliquant sur les liens proposés mais doit être accédé depuis l’onglet “Issues”.
Les métriques Dependency Check peuvent également être intégrées dans le calcul des “quality gates”.
Ligne de commande
Pour télécharger l’exécutable, rendez-vous ici.
Pour lancer une analyse sur une application java, utilisez la commande suivante :
$ ./bin/dependency-check.sh --project Testing --out . --scan [path to jar files to be scanned]
Le résultat est un fichier HTML. Exemple : dependency-check-report
On retrouve une vue un peu plus détaillée que dans les rapports Jenkins ou Sonarqube avec notamment la notion de “confiance” dans l’analyse d’une dépendance.
Pour déterminer qu’un projet utilise ou non une dépendance dans une version donnée, Dependency Check va analyser certains éléments de l’application (pom.xml, Manifest, nom des jars, etc.) et récolter des preuves (evidence) permettant de dresser une liste des dépendances avec leurs versions.
Le nombre de preuves (Evidence Count) est donc mentionné dans les rapports ainsi qu’un indice de confiance dans l’identification de la dépendance et de sa version.
Conclusion
La mise en place d’un outil comme Dependency Check dans une plateforme d’intégration continue permet d’être alertée sans effort sur la présence de vulnérabilités liées à des dépendances au sein d’un application. N’oubliez pas qu’environ 80% du code de votre application n’a pas été écrit par vous.