Introduction
La version 4.0 du PCI DSS (Payment Card Industry Data Security Standard) voit apparaître une exigence (6.3.2) sur l’inventaire des bibliothèques tierces dans le code des applications développées en interne, afin d’améliorer les processus de veille et de mise à jour. Nous allons voir dans cet article les différentes solutions qui permettent d’automatiser ceci.
Cette exigence, bien que présente dans la v4.0, est considérée comme une bonne pratique (donc facultative) jusqu’au 31 mars 2025. Néanmoins, mettre en place un outil de ce genre peut prendre du temps si la liste des applications interne est grande et que de nombreux langages différents sont utilisés.
Software component analysis
Les principaux outils permettant de répondre à ce problème rentrent dans la catégorie des SCA (Software Component Analysis), qui fonctionnent globalement tous de la même manière : lors du pipeline de déploiement d’une nouvelle version d’un projet, l’outil va générer un SBOM (Software Bill Of Material) c’est-à-dire un inventaire de toutes les bibliothèques tierces ayant été trouvées dans le code (dans le pom.xml pour du Java par exemple).
Cet inventaire convient pour respecter l’exigence 6.3.2, à condition d’être complet. Mais sous ce format, il ne sera pas utilisable dans la pratique pour gérer le cycle de vie des composants. C’est pourquoi l’ajout d’un outil de SCA permet de gérer de façon complète les bibliothèques tierces, et notamment leurs vulnérabilités et fins de vie. En bonus, la plupart des outils peuvent vérifier la conformité des licences des bibliothèques tierces, voire noter la qualité de leur code source.
Fonctionnalités recherchées
Les fonctionnalités classiques d’un outil de type SCA sont la génération d’un inventaire des bibliothèques utilisées par les applications, leur version, leur licence, les vulnérabilités connues les affectant. Un point important à vérifier avant de choisir quel outil utiliser est les langages de programmation qu’il supporte.
En plus de ces fonctionnalités de base, d’autres peuvent faciliter l’intégration dans le processus de développement en limitant les contraintes imposées aux développeurs. En effet, ce sont eux qui seront les premiers impactés par l’ajout et l’utilisation de l’outil. Certaines solutions proposent notamment d’intégrer directement un plugin dans l’IDE (Integrated Development Environment) des développeurs, afin que ceux-ci puissent s’assurer dès la première étape du cycle de développement que les bibliothèques utilisées sont bien à jour et non vulnérables.
Certaines solutions proposent directement aux développeurs des manières de corriger les vulnérabilités identifiées, et vont jusqu’à proposer des Merge requests automatiques dans les dépôts de code source.
Solutions open source
Dependency-Check
Dependency-Check est un outil développé par la fondation OWASP (Open Web Application Security Project). Il se présente comme un outil d’analyse statique, qui va analyser le code source d’une application afin d’identifier de potentielles vulnérabilités dans les bibliothèques tierces utilisées.
Bien que prévu pour être utilisé de façon autonome, il est le plus souvent intégré en tant qu’extension de SonarQube. Cela permet aux développeurs de ne pas avoir à exécuter manuellement l’outil. Dans ce mode d’utilisation, il génère un rapport lorsque le pipeline d’intégration continue fait appel à SonarQube, qui peut être consulté dans un onglet spécifique sur l’interface de gestion. Ce rapport va contenir la liste des bibliothèques n’étant pas à jour et étant potentiellement vulnérables à des CVE.
Dependency-Track et CycloneDX
Dependency-Track est aussi un outil développé par la fondation OWASP, qui permet de lister les bibliothèques tierces utilisées par ses projets et d’effectuer au même endroit le processus de veille en vulnérabilité sur ces dernières. Dependency-Track partage des fonctionnalités avec Dependency-Check, mais il permet en plus une gestion complète du cycle de vie des applications.
Ce logiciel est constitué de deux parties :
- Un générateur de SBOM (CycloneDX), qui peut s’intégrer soit manuellement, soit automatiquement dans un processus de CI/CD existant (Jenkins par exemple)
- Un serveur web, qui permet de traiter les SBOMs, d’obtenir l’inventaire complet des bibliothèques utilisées, de vérifier leurs vulnérabilités / CVE (Common Vulnerabilities and Exposures : https://cve.mitre.org/), etc.
L’interface web dispose de nombreuses fonctionnalités supplémentaires, comme un système de traitement des corrections, un système de notification basé sur une intégration à différents canaux de communication (Email, Microsoft Teams, Slack, etc.), une gestion des droits fine pour les utilisateurs, une connexion via LDAP/OpenID, une liaison à d’autres sources externes de vulnérabilités.
OSV-Scanner
OSV-Scanner est un outil développé par Google pour analyser les vulnérabilités dans les dépendances des projets en s’appuyant sur la base osv.dev. Celui-ci s’utilise de manière autonome en ligne de commande et permet de scanner des dépôts de code source ou directement des SBOM (générées préalablement avec un autre outil, par exemple CycloneDX) afin de vérifier qu’aucune vulnérabilité n’est présente.
Renovate
Même si Renovate n’est pas à proprement parler un outil de SCA, ce bot qui s’ajoute aux dépôts de code source permet d’automatiser la création de Merge requests pour mettre à jour les bibliothèques tierces. Il ne répond pas directement à l’exigence d’inventaire, mais permet de s’assurer qu’aucune vulnérabilité n’est présente dans ses projets. Si votre choix se porte sur cet outil, il faudra donc gérer l’inventaire d’une autre manière, ce qui est une solution acceptable.
Solutions propriétaires
De nombreux acteurs proposent des solutions clés en main, à des prix très variables. Les solutions propriétaires proposent notamment des fonctionnalités que l’on ne retrouve pas dans les solutions open source, et de la facilité de déploiement (car celles-ci fonctionnent le plus souvent en mode SaaS).
Par exemple : Snyk, Nessus Lifecycle, Whitesource, Fossa…
Conclusion
Cet article n’a pas vocation à être exhaustif, mais vise à fournir des pistes et des exemples pour démarrer la mise en place des processus et outils permettant de mettre en œuvre l’exigence 6.3.2 de PCI DSS v4.0 avant qu’elle ne devienne obligatoire.
