Sécuriser la chaine d'approvisionnement logicielle

Mise à jour : 19/09/2024

Introduction

La sécurisation de la chaîne d’approvisionnement logicielle est devenue un enjeu central pour les équipes DevOps et SecOps. Avec l’augmentation des attaques ciblant les composants tiers et les outils d’intégration continue, garantir la sécurité de chaque maillon est indispensable pour éviter des compromissions majeures. Des incidents récents, comme les attaques contre SolarWinds et la faille critique dans Jenkins, ont démontré que les attaquants exploitent les faiblesses de la supply chain pour pénétrer profondément dans les systèmes critiques.

Comprendre les composants de la chaîne d’approvisionnement logicielle

Pour sécuriser la supply chain logicielle, il est essentiel de comprendre ses principaux composants. La chaîne inclut le code source, souvent stocké sur des plateformes comme GitHub ou GitLab, les dépendances tierces (bibliothèques open-source), les pipelines CI/CD utilisés pour automatiser le déploiement, ainsi que les conteneurs et artefacts (images Docker, paquets). Chaque élément présente des risques spécifiques. Par exemple, un code source mal protégé ou des dépendances vulnérables peuvent devenir des portes d’entrée pour des cyberattaques, exposant l’ensemble de l’infrastructure.

Les outils de gestion des dépendances, tels que npm, pip, ou Maven, ajoutent des dépendances externes au projet, qui peuvent introduire des vulnérabilités si elles ne sont pas régulièrement auditées. Un autre aspect critique concerne les pipelines CI/CD, où des erreurs de configuration ou des accès non sécurisés peuvent permettre à des attaquants d’injecter du code malveillant directement dans le processus de production.

Les conteneurs, quant à eux, sont des environnements portables qui encapsulent le code et ses dépendances. Mal sécurisés, ils peuvent être manipulés, notamment en compromettant les images de base téléchargées depuis des registres publics. L’ajout d’une couche de sécurité, comme la signature des images, est souvent une mesure indispensable.

Finalement, le bon fonctionnement de la chaîne d’approvisionnement repose sur des outils d’orchestration et de distribution, tels que les répertoires d’artefacts (comme JFrog ou Nexus), qui doivent être également protégés afin d’éviter la contamination de l’ensemble du pipeline.

L’objectif ici est de bien identifier les composants critiques pour ensuite mettre en place les mesures de sécurité adéquates à chaque niveau.

Risques liés à la chaîne d’approvisionnement

Empoisonnement des dépendances

L’empoisonnement des dépendances est un risque majeur où des bibliothèques open-source ou des paquets sont volontairement ou accidentellement corrompus. Cela expose des milliers de projets, car ces dépendances sont massivement utilisées dans le développement logiciel.

Compromission des outils CI/CD

Les pipelines CI/CD automatisent la livraison de code, mais s’ils sont mal sécurisés, ils deviennent des cibles privilégiées pour les attaquants. Une faille dans ces systèmes permettrait d’injecter du code malveillant directement en production.

Attaques contre les fournisseurs tiers

Les services tiers intégrés (API, services cloud) représentent une autre surface d’attaque. Un fournisseur compromis, comme ce fut le cas avec SolarWinds, peut entraîner une infiltration massive chez de nombreux clients.

Vulnérabilités des environnements de développement et de test

Les environnements de test ou de développement, souvent moins surveillés que la production, peuvent être des points d’entrée pour des attaques. Une mauvaise configuration ou une absence de contrôle d’accès peut permettre aux attaquants de pénétrer dans le réseau et d’escalader leurs privilèges.

Exploitation des infrastructures de conteneurs

Les conteneurs, bien que très pratiques pour l’isolation des applications, peuvent être vulnérables si des images compromises sont déployées sans vérification. Une mauvaise configuration des registres ou l’utilisation d’images non signées peuvent exposer des systèmes critiques.

Utilisation de services cloud non sécurisés

Le recours à des services cloud sans contrôle de sécurité approprié expose les infrastructures à des risques importants, notamment à travers des erreurs de configuration ou des accès non autorisés à des données sensibles. Une mauvaise gestion des clés API ou des permissions d’accès peut conduire à des fuites de données.

Exemples d’attaques sur la supply chain

Attaque contre SolarWinds

En 2020, des attaquants ont compromis une mise à jour logicielle de la plateforme SolarWinds Orion, utilisée par des milliers d’organisations, y compris des agences gouvernementales. Ils ont injecté un malware appelé SUNBURST dans une mise à jour distribuée à des clients, leur permettant de voler des données sensibles et d’espionner plusieurs cibles pendant des mois. Cette attaque est un exemple frappant de la manière dont la compromission d’un fournisseur tiers peut avoir un impact global.

Exploit de Jenkins (CVE-2024-23897)

La vulnérabilité dans Jenkins liée à une faille de type path traversal a été exploitée par des attaquants pour exécuter du code à distance et déployer des ransomwares. Cette faille dans l’outil CI/CD a été rendue publique par la CISA et a entraîné des compromissions de plusieurs infrastructures critiques.

Attaque par empoisonnement de dépendances sur Event-Stream

En 2018, la bibliothèque JavaScript Event-Stream, largement utilisée dans des projets Node.js, a été compromise par un contributeur malveillant qui a introduit un backdoor dans le code. Ce code malveillant visait des portefeuilles de crypto-monnaies, montrant comment une simple dépendance non surveillée peut devenir une faille critique dans une application.

Compromission de la chaîne d’approvisionnement sur Kaseya

En 2021, un fournisseur de gestion des services informatiques, Kaseya, a été compromis, permettant aux attaquants de distribuer des ransomwares à des milliers de clients à travers une mise à jour logicielle infectée. Ce type d’attaque montre que les solutions de gestion à distance sont des cibles privilégiées pour les ransomwares, qui peuvent se propager massivement via des réseaux d’entreprise.

Faille dans la chaîne de conteneurs Docker

Des registres publics de conteneurs Docker ont été ciblés par des attaquants qui ont injecté des images contenant des malwares ou des outils de cryptojacking. Les entreprises utilisant ces conteneurs non sécurisés ont ensuite vu leurs ressources détournées pour miner des crypto-monnaies ou pour exécuter d’autres codes malveillants. Cela met en lumière les risques de ne pas vérifier l’intégrité des conteneurs avant leur déploiement.

Ces exemples montrent comment la chaîne d’approvisionnement logicielle peut être attaquée à différents niveaux, de la gestion des dépendances à la distribution de logiciels et des conteneurs. La prévention passe par des audits rigoureux et des mesures de sécurité à chaque étape du cycle de développement.

Plus d’infos

Stratégies de gestion des dépendances

La gestion des dépendances open-source est un aspect clé de la sécurité de la chaîne d’approvisionnement. Ces bibliothèques tierces, bien qu’utiles pour accélérer le développement, peuvent introduire des vulnérabilités critiques. Une bonne pratique consiste à automatiser la surveillance des dépendances avec des outils comme Dependabot ou Snyk, qui détectent les versions obsolètes et les failles connues. L’utilisation de solutions telles que OWASP Dependency-Check permet de scanner les bibliothèques pour des vulnérabilités.

Par exemple, l’empoisonnement de la bibliothèque Event-Stream montre que même les projets populaires peuvent être compromis. En réponse, il est essentiel de limiter l’utilisation de dépendances inutiles et de choisir des bibliothèques activement maintenues et auditées.

Un autre point critique est d’établir des politiques de contrôle pour chaque dépendance importée, en effectuant des audits réguliers et en imposant la mise à jour immédiate des composants vulnérables. Pour garantir une traçabilité complète, l’intégration de SCA (Software Composition Analysis) dans les pipelines CI/CD est également recommandée.

En plus de la surveillance des dépendances open-source avec des outils comme Snyk et OWASP Dependency-Check, l’utilisation d’un SBOM (Software Bill of Materials) devient incontournable. Un SBOM est une liste détaillée de toutes les dépendances utilisées dans un projet, incluant les bibliothèques tierces et leurs versions.

Le SBOM permet une traçabilité complète en cas de vulnérabilités découvertes, facilitant l’identification rapide des composants affectés. Des outils comme CycloneDX ou Syft génèrent automatiquement ces rapports et peuvent être intégrés dans les pipelines CI/CD. Ils assurent que chaque version du logiciel dispose d’un inventaire documenté et à jour, améliorant la transparence et la gestion proactive des risques liés aux dépendances.

Enfin, les développeurs doivent toujours vérifier les licences des bibliothèques et éviter celles qui imposent des contraintes légales ou commerciales susceptibles de compliquer la conformité.

Sécurisation des pipelines CI/CD

Les pipelines CI/CD (Intégration continue et Déploiement continu) sont des cibles privilégiées pour les attaques, car ils orchestrent l’ensemble du cycle de développement, de la compilation à la mise en production. Une compromission de ces pipelines peut avoir des conséquences graves, permettant aux attaquants d’injecter du code malveillant directement dans les applications.

Contrôles d’accès stricts et authentification

La première étape pour sécuriser un pipeline CI/CD est de renforcer les contrôles d’accès. Limiter l’accès aux pipelines aux seuls utilisateurs et rôles qui en ont besoin réduit la surface d’attaque. Une politique de moindre privilège doit être mise en place, où chaque acteur du processus a uniquement les permissions nécessaires pour accomplir ses tâches. Par exemple, un développeur pourrait uniquement avoir l’autorisation de déclencher des builds, sans pouvoir modifier le pipeline lui-même.

L’utilisation d’une authentification multifactorielle (MFA) est indispensable pour empêcher les accès non autorisés, même en cas de compromission des identifiants. Les outils de gestion des identités, tels que Okta ou Azure AD, peuvent être intégrés aux pipelines CI/CD pour offrir un niveau de protection supplémentaire.

Protection contre les modifications non autorisées

Les pipelines doivent être protégés contre les modifications non autorisées qui pourraient permettre à des attaquants de modifier les scripts d’automatisation ou les configurations de déploiement. Pour cela, l’activation d’un suivi d’audit complet de chaque modification des pipelines et la validation par des pairs avant tout changement critique permettent de garantir l’intégrité des pipelines.

Un exemple d’outil pouvant aider dans ce domaine est GitLab CI, qui permet de définir des pipelines avec des review apps, limitant les modifications jusqu’à validation par un relecteur.

Isolation des environnements

L’isolation des différents environnements (développement, test, production) est essentielle pour réduire les risques de contamination croisée en cas de compromission. Par exemple, les secrets ou tokens utilisés dans le pipeline de développement ne doivent jamais être réutilisés dans l’environnement de production.

Les outils comme HashiCorp Vault ou AWS Secrets Manager facilitent la gestion sécurisée des secrets en stockant et en injectant des clés d’accès et des variables d’environnement sans exposer directement les informations sensibles dans les pipelines.

Surveillance et journalisation

La surveillance continue des pipelines CI/CD permet de détecter des comportements anormaux ou des accès non autorisés. Des outils comme Prometheus et Grafana peuvent être utilisés pour monitorer les ressources et les processus CI/CD en temps réel.

La journalisation est un autre aspect clé. En cas d’incident, les journaux doivent permettre d’identifier les actions ayant conduit à la compromission. Pour ce faire, des outils tels que Splunk ou ELK Stack sont utilisés pour agréger les logs des différentes étapes du pipeline.

Intégration de la sécurité dans les conteneurs

Les conteneurs, tels que Docker et Kubernetes, sont au cœur des pipelines DevOps modernes, mais ils présentent des risques spécifiques. Pour sécuriser l’utilisation des conteneurs, il est essentiel de suivre des pratiques rigoureuses de gestion des images, de configuration et d’accès.

Scan et gestion des images de conteneurs

Un conteneur repose sur une image de base, souvent téléchargée depuis des registres publics comme Docker Hub. Ces images peuvent contenir des vulnérabilités. Il est donc primordial de les scanner avant utilisation à l’aide d’outils comme Clair, Trivy, ou Anchore. Ces outils permettent d’identifier les vulnérabilités connues dans les images et de vérifier leur conformité avant de les intégrer dans un environnement de production.

Signatures et validation des images

Une autre mesure de sécurité essentielle est la signature des images. Cette pratique garantit que seules des images approuvées et sécurisées peuvent être déployées. Outils comme Docker Content Trust (DCT) ou Notary permettent de signer et de vérifier l’intégrité des images. Cela empêche les images non signées ou altérées d’être utilisées dans les pipelines CI/CD.

Limitation des privilèges des conteneurs

Les conteneurs doivent toujours être exécutés avec les moindres privilèges possibles. Un conteneur exécuté en tant que root présente un risque important, car une compromission pourrait donner à l’attaquant un accès privilégié au système hôte. Des options comme --user ou --cap-drop dans Docker permettent de limiter les capacités des conteneurs.

Isolation réseau des conteneurs

La sécurité des conteneurs ne se limite pas à leur image, il faut aussi s’assurer qu’ils sont correctement isolés au niveau du réseau. Les conteneurs ne doivent pas avoir un accès réseau plus large que nécessaire. Des solutions comme Cilium ou Calico offrent des politiques de sécurité réseau pour limiter la communication entre les conteneurs et assurer une micro-segmentation.

Mise à jour et maintenance régulière

Les images de conteneurs doivent être régulièrement mises à jour pour corriger les vulnérabilités et maintenir un niveau de sécurité élevé. La mise à jour continue des images doit être intégrée dans le processus CI/CD pour automatiser les tests et les déploiements de nouvelles versions sécurisées.

Conclusion

La sécurisation de la chaîne d’approvisionnement logicielle est un processus complexe mais essentiel pour protéger les infrastructures DevOps des menaces croissantes. De la gestion des dépendances open-source à la sécurisation des pipelines CI/CD et des conteneurs, chaque étape nécessite des contrôles rigoureux pour prévenir les vulnérabilités. L’adoption de bonnes pratiques, telles que l’utilisation d’un SBOM pour une traçabilité complète, et l’automatisation des audits de sécurité renforcent la résilience des systèmes. En investissant dans ces stratégies, les équipes peuvent réduire les risques et maintenir un développement sécurisé et fluide.