Les logiciels modernes reposent sur un ensemble de composants qui dépassent largement le code métier. Frameworks, dépendances open source, scripts d’installation, environnements de compilation et services d’intégration continue participent tous à la création du logiciel livré aux utilisateurs.
Cette organisation accélère les développements, mais elle élargit également la surface d’attaque. Un composant compromis peut affecter plusieurs applications, parfois sans modification visible du code principal.
La sécurité de la chaîne d’approvisionnement logicielle, ou software supply chain security, consiste précisément à maîtriser ces risques. Elle vise à vérifier l’origine des composants, protéger les processus de construction et renforcer la confiance dans les artefacts déployés en production.
À retenir : comment sécuriser une supply chain logicielle ?
Sécuriser une chaîne d’approvisionnement logicielle consiste à contrôler les composants utilisés par une application, les outils qui la construisent et les processus qui assurent sa livraison.
Une démarche efficace repose sur l’inventaire des dépendances, l’analyse des vulnérabilités connues, la limitation des permissions CI/CD, la protection des secrets et la vérification de l’intégrité des artefacts.
Elle peut également s’appuyer sur une nomenclature logicielle (Software Bill of Materials, ou SBOM), des signatures numériques et des mécanismes de traçabilité des compilations.
La sécurité d’une application ne dépend pas uniquement de son code source : elle dépend aussi de la fiabilité de tous les composants et processus nécessaires à sa production.
Qu’est-ce que la chaîne d’approvisionnement logicielle ?
La chaîne d’approvisionnement logicielle désigne l’ensemble des éléments qui interviennent dans la conception, la construction, la distribution et la maintenance d’une application.
Elle comprend le code développé en interne, mais aussi les bibliothèques externes, les frameworks, les outils de compilation, les services CI/CD, les images de conteneurs et les infrastructures de déploiement.
Prenons l’exemple d’une application web développée avec Symfony et Angular. Le projet peut utiliser Composer pour les dépendances PHP, npm pour les composants JavaScript, Docker pour l’environnement d’exécution et GitLab CI/CD pour automatiser les tests et les déploiements.
Chacun de ces éléments apporte des fonctionnalités utiles. Mais chacun constitue également une dépendance technique dont la sécurité doit être maîtrisée.
Une vulnérabilité peut provenir d’une bibliothèque connue, d’un paquet téléchargé depuis un registre compromis ou d’un script de construction exécutant des commandes non prévues.
Le risque concerne donc l’ensemble du cycle de livraison, et non uniquement l’application une fois déployée.
Pourquoi les attaques sur les dépendances logicielles sont-elles dangereuses ?
Les bibliothèques open source permettent aux équipes de réutiliser des fonctionnalités existantes et de concentrer leurs efforts sur les besoins métier.
Cette pratique est indispensable dans la majorité des projets modernes. Elle crée toutefois une dépendance envers les mainteneurs, les registres de paquets et les mécanismes de publication de ces composants.
Lorsqu’un paquet contient une vulnérabilité ou qu’une version malveillante est distribuée, les applications qui l’utilisent peuvent être exposées.
Certaines attaques cherchent à exploiter une faiblesse technique connue. D’autres reposent sur la compromission d’un compte de publication, l’introduction d’un paquet portant un nom trompeur ou la modification d’une dépendance légitime.
Le problème est particulièrement sensible lorsque les mises à jour sont récupérées automatiquement sans contrôle suffisant.
Une version compromise peut alors être intégrée dans un environnement de construction et se retrouver dans l’application livrée.
Il est donc nécessaire de vérifier non seulement la présence de vulnérabilités connues, mais aussi les mécanismes qui déterminent quelles versions sont effectivement installées.
GitHub Actions : pourquoi les dépendances des workflows doivent-elles être protégées ?
Les pipelines CI/CD utilisent eux aussi des composants externes. Dans GitHub Actions, un workflow peut appeler des actions réutilisables pour installer un environnement, exécuter des tests ou publier un artefact.
Ces actions facilitent l’automatisation, mais elles peuvent disposer de permissions sensibles : lecture du dépôt, accès à certains secrets, publication de paquets ou interaction avec une infrastructure externe.
Si une action externe est compromise, son exécution dans un workflow peut présenter un risque pour le projet.
C’est pourquoi GitHub recommande notamment de limiter les permissions des workflows et de référencer les actions tierces par un identifiant de commit complet lorsque cela est adapté.
Le 14 octobre 2026, GitHub a annoncé la disponibilité en préversion publique des fichiers de verrouillage des dépendances de workflows GitHub Actions.
Cette évolution vise à améliorer la maîtrise des versions des dépendances utilisées dans les workflows et à rendre leur résolution plus prévisible.
Elle illustre une tendance importante : les composants d’automatisation doivent bénéficier de contrôles comparables à ceux appliqués aux bibliothèques de l’application.
Comment sécuriser les dépendances d’un projet PHP, JavaScript ou Python ?
La première étape consiste à disposer d’un inventaire fiable des dépendances utilisées par le projet.
Dans un environnement PHP, Composer permet de déclarer les bibliothèques nécessaires et d’enregistrer les versions résolues dans le fichier composer.lock.
Pour les projets JavaScript, npm dispose notamment de package-lock.json, qui décrit l’arbre de dépendances résolu. Des mécanismes équivalents existent dans d’autres écosystèmes.
Ces fichiers contribuent à la reproductibilité des installations, à condition d’être utilisés correctement dans les environnements de développement et de CI/CD.
Ils ne garantissent toutefois pas que les composants installés soient exempts de vulnérabilités.
Une analyse de composition logicielle, appelée SCA, peut compléter ce dispositif en recherchant les vulnérabilités connues associées aux versions utilisées.
Lorsqu’un problème est identifié, les équipes doivent évaluer l’exposition réelle de l’application, la disponibilité d’une version corrigée et les conséquences possibles d’une mise à jour.
Une correction précipitée peut entraîner une incompatibilité. À l’inverse, le maintien prolongé d’une dépendance vulnérable peut augmenter les risques de sécurité.
L’enjeu est donc de mettre en place un processus régulier d’analyse, de qualification et de mise à jour.
Qu’est-ce qu’un SBOM et pourquoi est-il utile ?
Un Software Bill of Materials, généralement abrégé SBOM, est une nomenclature des composants logiciels utilisés dans une application.
Il permet d’identifier les bibliothèques, leurs versions et certaines relations de dépendance au sein d’un logiciel.
Le principe est comparable à une nomenclature de fabrication : pour comprendre les composants d’un produit, il faut pouvoir déterminer ce qui entre dans sa composition.
Dans le domaine logiciel, cette visibilité devient particulièrement utile lorsqu’une vulnérabilité importante est rendue publique.
Une entreprise disposant d’un inventaire fiable peut rechercher plus rapidement quelles applications utilisent le composant concerné.
Les formats SPDX et CycloneDX font partie des standards utilisés pour représenter ces informations.
Un SBOM ne constitue cependant pas un certificat de sécurité. Il ne démontre pas que les composants sont fiables et ne garantit pas que toutes les dépendances ont été identifiées.
Sa valeur dépend de son exactitude, de sa fraîcheur et de son intégration aux processus de gestion des vulnérabilités.
Comment protéger les pipelines GitLab CI/CD ?
Dans GitLab CI/CD, la sécurité de la chaîne d’approvisionnement repose notamment sur la maîtrise des runners, des permissions, des variables sensibles et des artefacts.
Un runner exécute les jobs définis dans les pipelines. Selon sa configuration, il peut accéder au code source, installer des dépendances, construire des images et communiquer avec des services externes.
Il est donc important de limiter les privilèges de ces environnements et de maîtriser les projets autorisés à les utiliser.
Les secrets nécessaires aux déploiements doivent être protégés et accessibles uniquement aux jobs qui en ont réellement besoin.
Les branches protégées, les validations de merge requests et les règles d’accès contribuent également à réduire les possibilités de modification non autorisée des processus de livraison.
Enfin, les artefacts produits par les pipelines doivent être conservés et distribués selon des règles adaptées à leur sensibilité.
Pour les entreprises qui souhaitent renforcer leur dispositif, une démarche de modernisation applicative peut inclure l’amélioration des pipelines CI/CD, la gestion des dépendances et la sécurisation des processus de déploiement.
Docker : comment éviter les images vulnérables ?
Les conteneurs simplifient le déploiement des applications en regroupant les composants nécessaires à leur exécution.
Cependant, une image Docker peut contenir un système de base, des bibliothèques et des outils qui présentent eux-mêmes des vulnérabilités.
L’utilisation d’une image populaire ou officielle ne suffit pas à garantir sa sécurité.
Il faut notamment examiner la provenance de l’image, sa version, les composants installés et les permissions accordées au conteneur.
Les images de base doivent être régulièrement réévaluées afin de prendre en compte les correctifs disponibles.
Il est également préférable de limiter les composants inutiles et d’éviter l’exécution des applications avec des privilèges excessifs lorsque cela n’est pas nécessaire.
L’analyse automatisée des images avant leur publication permet d’identifier certaines vulnérabilités connues et de renforcer les contrôles de livraison.
Pourquoi la gestion des secrets est-elle essentielle ?
Les pipelines CI/CD utilisent souvent des identifiants techniques pour accéder aux registres de paquets, aux environnements cloud ou aux serveurs de déploiement.
Ces identifiants peuvent prendre la forme de jetons d’accès, de clés API, de certificats ou de mots de passe.
Lorsqu’ils sont exposés dans un dépôt, un journal de pipeline ou un artefact, ils peuvent être utilisés pour accéder à des ressources sensibles.
La sécurité repose donc sur plusieurs principes : limiter les permissions, éviter les secrets enregistrés directement dans le code, contrôler leur exposition et prévoir leur rotation.
Lorsque l’infrastructure le permet, l’utilisation d’identités temporaires et de mécanismes de fédération peut réduire la dépendance aux identifiants permanents.
Il faut également surveiller les permissions accordées aux outils externes et aux agents d’automatisation.
Un pipeline peut être correctement configuré sur le plan fonctionnel tout en présentant un risque important si ses identifiants disposent d’autorisations trop étendues.
Comment vérifier l’intégrité des artefacts logiciels ?
Après la compilation et les tests, le pipeline produit généralement un artefact destiné à être livré : paquet applicatif, archive, image de conteneur ou exécutable.
La question de sécurité est alors de savoir si cet artefact correspond réellement au code et au processus de construction attendus.
Des mécanismes de signature numérique et de vérification d’intégrité peuvent contribuer à répondre à cette question.
Les attestations de provenance permettent également de documenter certaines informations relatives à la construction d’un logiciel : source utilisée, processus exécuté et environnement de production de l’artefact.
Des initiatives comme SLSA, pour Supply-chain Levels for Software Artifacts, proposent un cadre pour améliorer progressivement la sécurité des processus de construction.
Ces mécanismes doivent être adaptés à l’architecture de l’entreprise. Leur présence ne dispense pas de vérifier les dépendances, les permissions et les contrôles de sécurité exécutés pendant la construction.
Applications legacy : comment maîtriser les dépendances anciennes ?
Les applications historiques présentent souvent une difficulté particulière : leurs dépendances ne sont pas toujours documentées.
Un logiciel métier développé il y a quinze ans peut utiliser des bibliothèques qui ne sont plus maintenues, des composants installés manuellement ou des outils de compilation devenus difficiles à reproduire.
Dans certains cas, la version exacte d’une dépendance n’est connue que parce qu’elle est encore présente sur le serveur de production.
Cette situation complique les mises à jour et augmente les risques lors d’une migration.
Un audit applicatif permet de cartographier les composants, d’identifier les dépendances critiques et de déterminer les mesures nécessaires pour sécuriser les évolutions.
La modernisation peut ensuite être organisée progressivement : documentation de l’environnement, remplacement des bibliothèques obsolètes, automatisation des constructions et introduction de tests.
Cette approche évite de dépendre durablement d’une infrastructure difficile à maintenir ou à reconstruire.
Les applications WinDev et WebDev sont-elles concernées ?
Oui. Même si les technologies et les mécanismes de construction diffèrent de ceux des applications web modernes, les logiciels WinDev et WebDev utilisent eux aussi des composants et des dépendances.
Une application peut reposer sur des bibliothèques externes, des pilotes de bases de données, des composants ActiveX ou des services complémentaires.
La sécurité de sa chaîne d’approvisionnement nécessite donc d’identifier ces éléments, de vérifier leur origine et d’évaluer leur niveau de maintenance.
Les outils conçus pour les gestionnaires de paquets les plus courants ne couvrent pas nécessairement ces dépendances de manière automatique.
Une migration d’application WinDev peut ainsi être l’occasion de rationaliser les composants externes, de documenter les versions utilisées et de moderniser les processus de livraison.
L’objectif n’est pas de reproduire artificiellement un pipeline standard, mais de mettre en place des contrôles adaptés à l’environnement réel du logiciel.
Comment démarrer une démarche de sécurité de la supply chain logicielle ?
La première étape consiste à identifier les applications et les processus de livraison les plus critiques.
Il faut ensuite inventorier les dépendances, les registres de paquets, les images de conteneurs, les outils CI/CD et les comptes techniques utilisés.
Cette cartographie permet de repérer les zones présentant les risques les plus importants : composants obsolètes, permissions excessives, secrets exposés ou processus de construction insuffisamment maîtrisés.
L’entreprise peut alors introduire progressivement des contrôles automatisés, en commençant par l’analyse des dépendances et la protection des pipelines.
Les mécanismes de génération de SBOM, de signature des artefacts et d’attestation de provenance peuvent être ajoutés selon les besoins et le niveau de maturité de l’organisation.
Il est préférable de mesurer l’efficacité de ces contrôles plutôt que de multiplier les outils sans stratégie.
Une démarche durable repose sur des responsabilités claires, des procédures de mise à jour et un suivi régulier des vulnérabilités.
Conclusion : sécuriser le code ne suffit plus
La sécurité des applications modernes dépend d’un écosystème de composants, de services et d’outils qui interviennent bien avant la mise en production.
Une bibliothèque vulnérable, un workflow CI/CD compromis ou une image de conteneur mal maîtrisée peut fragiliser un logiciel dont le code métier a pourtant été soigneusement audité.
La sécurité de la chaîne d’approvisionnement logicielle permet d’élargir les contrôles à l’ensemble de ces dépendances.
L’inventaire des composants, la protection des secrets, la limitation des permissions et la vérification des artefacts constituent des étapes importantes pour renforcer la fiabilité des livraisons.
Pour les entreprises qui maintiennent des applications historiques, cette démarche peut également accompagner un projet plus large de modernisation technique.
Une application sécurisée ne repose pas uniquement sur un code fiable, mais aussi sur une chaîne de construction et de livraison maîtrisée.
