Sécurité des dépendances et analyse de la composition logicielle

Les Applications modernes sont en grande partie composées de bibliothèques et frameworks open source tiers. Une Application Node.js classique peut avoir plus de 1 000 dependencies Transitive ; un projet Java peut intégrer des centaines d’artefacts Maven. Chaque dependency constitue une surface d’Attack potentielle. La vulnérabilité Log4Shell (CVE-2021-44228) de la bibliothèque Log4j a démontré qu’une seule dependency pouvait rendre des millions d’Applications immédiatement exploitables dans le monde entier, quelques jours après sa divulgation.

Les outils d’analyse de la composition logicielle (SCA) inventorient automatiquement tous les composants open source d’une Application, y compris les dependencies Transitive (les dependencies de vos dependencies), et les vérifient en continu par rapport aux bases de données de vulnérabilités afin de détecter les CVE connues. La SCA produit une nomenclature logicielle (SBOM) répertoriant chaque composant et chaque Version, ce qui permet d’identifier rapidement les systèmes affectés lors de la divulgation de nouvelles vulnérabilités.

Les dependencies Transitive sont des bibliothèques dont dépendent vos dependencies directes, et que vous n’avez pas choisies explicitement. Vous pouvez dépendre directement du Package A, qui dépend du Package B (Version 1.2), qui dépend du Package C (Version 3.0 — une Version vulnérable). Vous ne connaissez pas le Package C, mais votre Application l’exécute. Les outils SCA parcourent l’arbre complet des dependencies afin de révéler ces vulnérabilités cachées, sur lesquelles les développeurs n’ont aucune visibilité directe.

Une nomenclature logicielle (SBOM) est un inventaire formel et lisible par machine de tous les composants d’un produit logiciel, comparable à une liste d’ingrédients alimentaires. Les formats SBOM comprennent SPDX (Linux Foundation) et CycloneDX (OWASP). Le décret présidentiel américain 14028 (2021) a rendu les SBOM obligatoires pour les logiciels vendus au gouvernement fédéral. Avec une SBOM, les équipes de sécurité peuvent immédiatement demander : « lesquels de nos produits contiennent Log4j ? » et obtenir une réponse en quelques minutes plutôt qu’après plusieurs jours de recherche manuelle.

Le verrouillage des dependencies spécifie les Versions exactes des dependencies plutôt que des plages flexibles (^1.2.3 ou *). Les fichiers de verrouillage (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) enregistrent la Version exacte résolue de chaque dependency au moment de l’installation. Ils doivent être validés dans le contrôle du code source afin de garantir que chaque membre de l’équipe et chaque pipeline CI/CD utilisent des Versions de dependencies identiques, ce qui empêche les Attacks de la chaîne d’approvisionnement qui empoisonnent les Versions de packages entre les installations.

Les Attacks de la chaîne d’approvisionnement ciblent l’écosystème des dependencies. Le typosquattage consiste à publier des packages malveillants dont les noms ressemblent à ceux de packages populaires (par exemple, lodahs au lieu de lodash), en espérant que les développeurs saisissent mal le nom. Les Attacks par confusion de dependencies exploitent l’ordre dans lequel les gestionnaires de packages recherchent les registres : un Attacker publie un package malveillant portant le même nom qu’un package privé interne, mais avec un numéro de Version supérieur, ce qui pousse le gestionnaire de packages à installer à la place la Version publique malveillante.

Plusieurs outils SCA sont largement utilisés dans le secteur. Snyk fournit une analyse des dependencies adaptée aux développeurs, avec des demandes de fusion de correction automatiques. OWASP Dependency-Check est un outil gratuit et largement adopté pour Java, .NET, Python et Ruby. GitHub Dependabot ouvre automatiquement des demandes de fusion pour mettre à jour les dependencies vulnérables dans les dépôts GitHub. JFrog Xray et Sonatype Nexus IQ intègrent la SCA aux dépôts d’artefacts afin de bloquer les Builds vulnérables avant leur mise en production.

La SCA est la plus efficace lorsqu’elle est intégrée comme barrière de qualité dans le pipeline CI/CD. À chaque demande de fusion et à chaque Build, le pipeline exécute l’outil SCA et fait échouer le Build si des CVE de gravité CRITICAL ou HIGH sont trouvées dans les dependencies. Cette approche de déplacement vers la gauche détecte les dependencies vulnérables avant leur arrivée en production, et non plusieurs mois plus tard lors d’une Review de sécurité manuelle ou après une compromission. Les équipes doivent définir des seuils clairs de gravité des vulnérabilités qui bloquent le déploiement, ainsi que celles qui génèrent uniquement des avertissements.

Avant d’ajouter une dependency, évaluez sa posture de sécurité à l’aide de plusieurs indicateurs. Activité de maintenance : le projet est-il activement maintenu ? Quand a eu lieu le dernier Commit et la dernière publication ? Historique des vulnérabilités connues : combien de CVE a-t-il connues et à quelle vitesse ont-elles été corrigées ? Volume de téléchargements : les packages largement utilisés font l’objet d’une surveillance de sécurité accrue. Nombre de dependencies : les packages ayant moins de dependencies introduisent un risque Transitive moindre. OpenSSF Scorecard fournit une évaluation automatisée des pratiques de sécurité des projets open source.

Lorsque la SCA identifie une dependency vulnérable, plusieurs stratégies de correction sont possibles. Mettez à niveau vers une Version corrigée : c’est l’option recommandée lorsqu’elle est disponible. L’application virtuelle de correctifs au moyen de règles WAF peut atténuer les chemins d’exploitation connus pendant la préparation d’une mise à niveau. Supprimez la dependency si elle n’est plus nécessaire. Acceptez le risque avec une justification documentée si la vulnérabilité n’est pas exploitable dans le contexte d’utilisation précis (par exemple, une vulnérabilité côté serveur dans une bibliothèque côté client). Ne laissez jamais des vulnérabilités CRITICAL sans traitement ni acceptation documentée.

Les outils SCA ont une double fonction : ils identifient les vulnérabilités de sécurité et signalent les problèmes de conformité des licences dans les dependencies open source. Les licences problématiques courantes comprennent GPL v2/v3 (COPYLEFT : elles obligent à rendre également votre produit open source si vous le distribuez), AGPL (étend la GPL aux services réseau) et SSPL. L’utilisation d’une bibliothèque sous licence GPL dans un logiciel commercial propriétaire sans licence commerciale peut entraîner une grave responsabilité juridique. Les outils SCA comme FOSSA, Black Duck et WhiteSource automatisent l’analyse des licences parallèlement à la détection des vulnérabilités, garantissant le respect des obligations liées à l’open source.

Testez votre compréhension des concepts CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les outils SCA analysent l’arbre complet des dependencies, y compris les dependencies Transitive, à la recherche de CVE connues, que les SBOM fournissent un inventaire lisible par machine permettant une réponse rapide lors de la divulgation de nouvelles vulnérabilités, et que l’intégration de la SCA comme barrière de qualité CI/CD détecte les dependencies vulnérables avant leur arrivée en production. Nous allons maintenant étudier le DevSecOps et la manière de déplacer les contrôles de sécurité vers la gauche dans l’ensemble du pipeline CI/CD.