securite supply chain open source : quels risques et comment agir ?

securite supply chain open source : de quoi parle-t-on ?

La chaîne d’approvisionnement logicielle désigne le parcours d’un logiciel, depuis le code source et ses dépendances jusqu’à la compilation, la distribution et l’exécution. Systematic Paris-Region la décrit comme un ensemble couvrant le développement, la diffusion, l’exploitation et la maintenance des logiciels.

La sécurité cherche donc à préserver la confidentialité, l’intégrité et la disponibilité du logiciel. Elle concerne autant un poste Linux personnel qu’une image de conteneur ou un service déployé en production.

Vulnérabilité open source ou attaque de la supply chain ?

Une vulnérabilité est une faiblesse dans un composant, comme une erreur de validation dans une bibliothèque. Une attaque de supply chain vise le chemin de distribution ou de construction, par exemple en remplaçant un paquet légitime par un paquet malveillant.

Une dépendance vulnérable n’est pas automatiquement exploitable dans votre contexte. À l’inverse, un paquet compromis peut ne présenter aucune vulnérabilité connue et exécuter directement du code hostile.

Les composants concernés : code, dépendances, outils et infrastructures

Élément	Exemple	Risque	Contrôle
Code source	Dépôt Git	Commit frauduleux	Revue, protection des branches
Dépendances	Paquet npm ou Python	Code vulnérable	SCA, versions épinglées
Construction	Pipeline CI/CD	Artefact altéré	Isolation, attestations
Distribution	Registre, miroir	Substitution	Hashes, signatures
Exécution	Serveur, poste, conteneur	Compromission finale	Moindre privilège, journalisation

Pourquoi la supply chain open source est une cible prioritaire

L’open source accélère le développement, mais une seule bibliothèque peut être réutilisée par des milliers d’applications. OpenSSF indique que les incidents de chaîne logicielle peuvent provoquer des pertes de revenus, des coûts de remédiation, une interruption d’accès et une perte de confiance.

Dépendances directes, transitives et peu visibles

Une dépendance directe est déclarée par votre projet. Une dépendance transitive est installée par une autre bibliothèque et peut rester invisible dans un fichier de configuration simple.

Les gestionnaires de paquets résolvent souvent des graphes complexes. Vous devez donc enregistrer l’arbre réellement installé, pas seulement les composants que les développeurs ont ajoutés manuellement.

Impacts pour les entreprises : compromission, interruption et perte de confiance

• Un composant compromis peut exfiltrer des secrets présents dans les variables d’environnement ou les fichiers de configuration.
• Une mise à jour malveillante peut interrompre une chaîne de production ou rendre un service indisponible.
• Une preuve insuffisante sur l’origine d’un artefact complique l’audit, la réponse à incident et la restauration.

Les principales attaques de la supply chain open source

Paquets malveillants, typosquatting et dependency confusion

Le typosquatting imite le nom d’un paquet populaire avec une faute discrète. La dependency confusion exploite un nom interne publié dans un registre public, si le gestionnaire choisit la version publique.

Vérifiez le registre configuré, l’organisation propriétaire, l’historique des versions et les scripts exécutés à l’installation. Un téléchargement réussi ne prouve pas que le paquet est légitime.

Compromission d’un mainteneur ou d’un projet open source

Un compte de mainteneur volé peut publier une version signée avec des identifiants valides. L’authentification multifacteur, la séparation des rôles et la protection des branches limitent ce scénario sans l’éliminer.

Attaques des registres, dépôts et pipelines CI/CD

Un registre ou un pipeline compromis peut servir un artefact différent de celui examiné dans le dépôt. Les jetons à durée courte, les environnements isolés et les permissions minimales réduisent la portée d’un compte volé.

Compromission des outils ou fournisseurs tiers

Un outil d’analyse, une action automatisée ou un service de build possède parfois des droits sur le code et les secrets. Traitez chaque intégration comme une dépendance logicielle et contrôlez ses versions, ses permissions et ses journaux.

Détournement lors de la construction et de la distribution des logiciels

• Le code vérifié peut produire un binaire différent si le serveur de build est compromis.
• Une image peut être remplacée entre le registre et le déploiement si son digest n’est pas contrôlé.
• Un miroir interne peut conserver une version vulnérable après la publication d’un correctif.

Exemples d’attaques et de compromissions marquantes

XZ Utils, Polyfill.io et autres incidents récents

Incident	Période	Mécanisme	Enseignement
XZ Utils	2024	Code malveillant introduit dans une chaîne de versions	Surveiller les mainteneurs et les artefacts
Polyfill.io	2024	Script distribué modifié après changement de contrôle	Contrôler les ressources tierces exécutées
SolarWinds	2020, historique	Compromission du processus de build	Protéger la construction et la publication
Log4Shell	2021, historique	Vulnérabilité dans une dépendance largement utilisée	Maintenir un inventaire exploitable

Ce que ces attaques révèlent des failles de la chaîne

Ces incidents ne montrent pas que l’open source serait intrinsèquement moins sûr. Ils montrent qu’un projet largement réutilisé, un outil de build privilégié ou une ressource distante crée un point d’impact collectif.

Systematic Paris-Region recensait déjà en 2023 les risques liés aux dépendances, aux conteneurs, aux actions GitHub et aux artefacts construits. La réponse doit couvrir le parcours complet, pas uniquement l’analyse du code.

Comment évaluer le risque de ses dépendances open source

Recenser les composants et leurs dépendances transitives

Générez un inventaire depuis les fichiers de verrouillage et l’environnement de build. Conservez le nom, la version, le registre, le hash, la licence et le lien vers le projet source.

Identifier les vulnérabilités, versions obsolètes et paquets abandonnés

Une solution SCA (Software Composition Analysis) compare les versions avec les bases de vulnérabilités. Vérifiez aussi la date de publication, la fréquence des correctifs, les responsables actifs et les scripts d’installation.

Prioriser selon l’exposition, la criticité et l’exploitabilité

Traitez d’abord une dépendance exposée sur Internet, utilisée par un service sensible et associée à une exploitation documentée. Une vulnérabilité théorique dans un outil isolé peut attendre une fenêtre de maintenance.

Vérifier la provenance et la réputation des projets

La réputation seule ne suffit pas. Examinez l’URL officielle, les releases, les signatures, les protections du dépôt et la cohérence entre le code source et l’artefact publié.

Les bonnes pratiques pour sécuriser la supply chain open source

Mettre en place un inventaire SBOM à jour

• Produisez une SBOM à chaque version livrée et après chaque changement de dépendance.
• Incluez les dépendances transitives, les versions exactes et les identifiants de vulnérabilités connus.
• Conservez la SBOM avec l’artefact et définissez une durée de rétention adaptée à votre activité.

Utiliser une solution SCA et analyser chaque nouvelle dépendance

Intégrez l’analyse SCA dans les demandes de modification et bloquez seulement les seuils justifiés par votre risque. Un contrôle trop bruyant finit par être ignoré.

Épingler les versions et vérifier les hashes ou signatures

Évitez les versions flottantes comme latest dans les builds reproductibles. Pour vérifier les signatures GPG des paquets, contrôlez la clé par un canal indépendant, son empreinte et la correspondance entre la signature et le fichier téléchargé.

Sécuriser les comptes, secrets et droits d’accès

Utilisez l’authentification multifacteur, des jetons limités et des comptes de service séparés. Ne placez jamais une clé de production dans un dépôt ou dans les logs du pipeline.

Protéger les pipelines CI/CD et les environnements de build

Isolez les jobs, limitez les runners privilégiés et révisez les actions tierces. Une chaîne de build dédiée réduit le risque qu’un test non fiable accède aux secrets de publication.

Contrôler les artefacts avant leur déploiement

• Comparez le digest de l’artefact à celui approuvé.
• Vérifiez la signature et l’attestation de provenance.
• Analysez les images, binaires et paquets dans un registre contrôlé.

Garantir l’intégrité et la traçabilité des logiciels

SBOM : SPDX et CycloneDX

SPDX et CycloneDX sont deux formats courants pour décrire les composants, leurs relations et leurs licences. Le format importe moins que la fraîcheur de l’inventaire et sa liaison avec une version précise du logiciel.

Signatures, attestations et provenance avec Sigstore

Sigstore, projet soutenu par OpenSSF, fournit des mécanismes pour signer et vérifier des logiciels avec une gestion moderne des identités et des journaux de transparence. Une signature prouve l’association avec une identité, mais ne prouve pas à elle seule que le code est exempt de vulnérabilité.

Niveaux de maturité et exigences du framework SLSA

SLSA (Supply-chain Levels for Software Artifacts) structure les preuves relatives à la construction et à la provenance. Commencez par identifier le processus de build, puis augmentez progressivement l’isolation, la traçabilité et la résistance aux modifications.

Organiser la sécurité dans l’entreprise

Responsabilités des développeurs, de la sécurité et des achats

Les développeurs choisissent et mettent à jour les composants, la sécurité définit les contrôles et les achats évaluent les fournisseurs. Une responsabilité non attribuée transforme chaque alerte en débat sans décision.

Politique d’acceptation, de mise à jour et d’exception

Définissez les registres autorisés, les délais de correction et les conditions d’une exception documentée. Réévaluez la règle quand une vulnérabilité change de gravité ou devient exploitée.

Surveillance continue et réponse à incident

• Abonnez-vous aux alertes des projets et des registres utilisés.
• Préparez le retrait d’une version et le remplacement par une version connue.
• Conservez les journaux de build, les SBOM et les artefacts nécessaires à l’analyse.

Réglementation et initiatives de référence

Cyber Resilience Act et obligations européennes

Le Cyber Resilience Act européen introduit des exigences de cybersécurité pour les produits comportant des éléments numériques. Les dates et obligations applicables varient selon le type d’acteur et de produit, vérifiez le texte officiel et son calendrier avant toute décision de conformité.

NIS2 et exigences de gestion des risques

NIS2 renforce la gestion des risques pour les secteurs concernés, notamment la sécurité de la chaîne d’approvisionnement. Son application dépend de la transposition nationale et du périmètre de votre organisation, à vérifier en 2026 auprès de l’autorité compétente.

OpenSSF, OpenSSF Scorecard et référentiels sectoriels

• OpenSSF propose des projets autour de Sigstore, SLSA, GUAC et l’analyse de paquets.
• Scorecard évalue automatiquement plusieurs pratiques de sécurité d’un dépôt public.
• Un score est un signal de tri, pas une certification ni une preuve d’absence de code malveillant.

Feuille de route pour renforcer sa sécurité open source

Niveau 1 : visibilité et inventaire

Commencez par inventorier les projets, les dépendances transitives, les registres et les pipelines. Produisez une SBOM et attribuez un responsable à chaque composant sensible.

Niveau 2 : contrôles automatisés et réduction du risque

Ajoutez l’analyse SCA, les versions verrouillées, les alertes de vulnérabilités, la protection des branches et des règles de moindre privilège. Mesurez le délai entre la publication d’un correctif et son déploiement.

Niveau 3 : preuves de provenance, signatures et résilience

Niveau	Preuve attendue	Contrôle	Objectif
1	SBOM	Inventaire versionné	Savoir ce qui est utilisé
2	Résultats SCA	Blocage des risques définis	Réduire l’exposition
3	Attestation et signature	Provenance vérifiable	Prouver l’intégrité
4	Plan de remplacement	Build isolé et restauration	Résister à l’incident

Checklist de sécurité de la supply chain open source

• Avez-vous une SBOM complète, datée et associée à chaque version publiée ?
• Les dépendances directes et transitives sont-elles épinglées et téléchargées depuis des registres autorisés ?
• Vérifiez-vous les hashes, les signatures et la provenance des artefacts ?
• Les comptes, secrets, runners et actions CI/CD disposent-ils de permissions minimales ?
• Savez-vous désactiver une version compromise et reconstruire depuis une source fiable ?
• Les règles de correction, d’exception et de notification ont-elles un responsable identifié ?

Pour compléter la protection de l’environnement qui construit et exécute vos logiciels, consultez aussi le guide sur le durcissement système et l’OS hardening, ainsi que les explications sur la gestion des permissions Linux avec chmod et chown.