Chaîne d’approvisionnement logicielle : SBOM, signatures et dépendances
Un logiciel moderne est fait en grande partie de composants écrits par d'autres. La sécurité de la chaîne logicielle consiste à savoir ce qu'on embarque, à prouver ce qu'on livre et à réagir vite quand une dépendance est compromise.
En décembre 2021, la vulnérabilité Log4Shell, dans une bibliothèque de journalisation Java très répandue, a mis des milliers d’organisations face à une question à laquelle elles ne savaient pas répondre : « Utilisons-nous Log4j, et où ? » En mars 2024, la découverte d’une porte dérobée introduite patiemment dans l’outil de compression XZ Utils a montré une autre facette du problème : un composant libre peut être compromis à la source, par quelqu’un qui a gagné la confiance de ses mainteneurs. La sécurité de la chaîne logicielle traite ces deux risques : ne pas savoir ce qu’on utilise, et ne pas pouvoir prouver ce qu’on livre.
Trois risques distincts
On parle de chaîne d’approvisionnement parce qu’un logiciel passe par plusieurs mains avant d’arriver en production : les auteurs des composants libres ou commerciaux, les dépôts qui les distribuent, les outils de construction, l’éditeur ou l’équipe qui assemble le tout, puis l’exploitant. Chaque maillon peut être le point faible.
- Composantsvulnérabilité connue ou code malveillant introduit
- Dépôtspaquet piégé, nom presque identique, compte de mainteneur volé
- Constructionchaîne d’intégration compromise, secrets exposés
- Livraisonbinaire modifié entre la construction et l’installation
- Exploitationcomposants jamais mis à jour
Les réponses sont différentes pour chaque maillon. On peut les regrouper en trois pratiques : inventorier, prouver, surveiller.
Inventorier : la nomenclature logicielle
La nomenclature logicielle, ou SBOM (Software Bill of Materials), est la liste structurée des composants d’un logiciel, avec leurs versions, leurs fournisseurs, leurs licences et leurs relations. Elle se génère automatiquement à partir du code source, des fichiers de dépendances ou de l’image finale, avec des outils libres ou commerciaux intégrés à la chaîne de construction.
Deux formats dominent. SPDX, porté par la Linux Foundation, est devenu une norme internationale (ISO/IEC 5962:2021). CycloneDX, porté par la fondation OWASP, a été normalisé par Ecma International. Les deux sont lisibles par machine et largement outillés ; le choix compte moins que la régularité de la production.
| Question | Ce que la SBOM permet | Ce qu’elle ne permet pas seule |
|---|---|---|
| Sommes-nous touchés par cette vulnérabilité ? | Retrouver en minutes les logiciels qui contiennent le composant | Savoir si la partie vulnérable est réellement utilisée |
| Quelles licences embarquons-nous ? | Lister les licences et repérer les incompatibilités | Trancher les cas juridiques douteux |
| Nos composants sont-ils maintenus ? | Repérer les versions anciennes | Évaluer la santé d’un projet libre |
| Que contient le logiciel d’un fournisseur ? | Disposer d’une vue de ses composants | Garantir que la liste est complète et exacte |
Une SBOM n’est utile que si elle est exploitée. Rapprochée automatiquement des bases de vulnérabilités, elle alerte quand un composant devient vulnérable. Le format VEX (Vulnerability Exploitability eXchange) permet à un éditeur d’indiquer, pour une vulnérabilité donnée, si son produit est réellement exploitable, ce qui évite des alertes inutiles.
Prouver : signatures et traçabilité de la construction
Savoir ce qu’il y a dans un logiciel ne dit pas si ce qu’on installe est bien ce qui a été construit. Deux pratiques y répondent.
Signer les livrables. Chaque binaire, paquet ou image de conteneur est signé au moment de la construction, et la signature est vérifiée avant l’installation. Le projet libre Sigstore, soutenu par l’OpenSSF, a rendu cette signature beaucoup plus simple, sans gestion lourde de clés à longue durée de vie.
Attester de la construction. Le cadre SLSA (Supply-chain Levels for Software Artifacts), également porté par l’OpenSSF, définit des niveaux d’exigence pour la chaîne de construction : construction scriptée, plateforme de construction protégée, provenance signée décrivant d’où vient le code et comment il a été construit. Il permet de progresser par paliers plutôt que de viser tout de suite le niveau le plus élevé.
La chaîne d’intégration continue est elle-même un système sensible : elle détient des secrets, des droits de publication et la confiance des utilisateurs. La protéger (accès restreints, secrets à durée courte, revue des modifications de configuration) fait partie de la sécurité du logiciel.
Surveiller : les dépendances dans la durée
Un logiciel livré continue de vieillir. Ses composants reçoivent des correctifs, certains sont abandonnés, d’autres changent de mainteneur. La surveillance repose sur quelques gestes simples :
Choisir ses dépendances. Avant d’ajouter une bibliothèque, regarder son activité, le nombre de mainteneurs, sa politique de sécurité. L’OpenSSF publie un outil d’évaluation automatique de ces critères (Scorecard).
Figer et vérifier les versions. Fichiers de verrouillage, empreintes des paquets, dépôt interne ou miroir pour les composants critiques. Cela réduit le risque des paquets piégés et des noms trompeurs.
Mettre à jour régulièrement. Des mises à jour fréquentes et petites coûtent moins cher qu’une migration en urgence d’une version très ancienne, le jour où une vulnérabilité grave est publiée.
Ce que change le Cyber Resilience Act
Le règlement européen sur la cyber-résilience, entré en vigueur le 10 décembre 2024, transforme ces bonnes pratiques en obligations pour les fabricants de produits comportant des éléments numériques mis sur le marché de l’Union. Il impose notamment l’identification et la documentation des composants, y compris par une nomenclature logicielle lisible par machine, la gestion des vulnérabilités pendant la durée de support annoncée, et la diffusion de mises à jour de sécurité. Le signalement des vulnérabilités activement exploitées et des incidents graves s’applique à partir du 11 septembre 2026 ; l’ensemble des obligations à partir du 11 décembre 2027.
Le règlement prévoit un régime particulier pour les logiciels libres développés hors activité commerciale, et un rôle de « gestionnaire de logiciels libres » aux obligations allégées. Une organisation qui intègre des composants libres dans un produit qu’elle commercialise reste responsable de leur sécurité dans ce produit.
Par où commencer
- Générer une SBOM pour chaque logiciel livréAutomatiquement, à chaque construction, dans un format standard, conservée avec la version.
- Rapprocher les SBOM des avis de vulnérabilitéAvec un outil qui alerte l’équipe responsable, et une règle de délai de correction selon la gravité.
- Signer les livrables et vérifier les signaturesD’abord pour ce qui est publié à l’extérieur, puis pour les déploiements internes.
- Protéger la chaîne de constructionAccès, secrets, revue des changements de configuration, provenance des constructions.
- Exiger la même chose des fournisseursSBOM, politique de vulnérabilités, durée de support, délais de correction, inscrits dans les contrats.
Notre article sur l’entrée en vigueur du Cyber Resilience Act détaille le calendrier et le périmètre. L’expertise cybersécurité et conformité de DOSOBE aide à mettre en place ces pratiques et à les inscrire dans les achats.
Pour approfondir : Gouvernance & traçabilité
Questions fréquentes
Qu'est-ce qu'une SBOM ?
Une nomenclature logicielle (Software Bill of Materials) est la liste structurée des composants d'un logiciel : bibliothèques, versions, fournisseurs, licences, relations de dépendance. Elle permet de savoir, quand une vulnérabilité est publiée sur un composant, quels logiciels sont concernés.
Le Cyber Resilience Act impose-t-il une SBOM ?
Oui. Le règlement demande aux fabricants de produits comportant des éléments numériques de recenser les composants, notamment en établissant une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. L'essentiel des obligations s'applique à partir de décembre 2027, le signalement des vulnérabilités exploitées dès septembre 2026.
Un acheteur doit-il exiger une SBOM de ses fournisseurs ?
C'est de plus en plus courant, et c'est utile si l'acheteur sait en faire quelque chose : la rapprocher des avis de vulnérabilité, suivre les mises à jour. Exiger une SBOM qu'on ne lira jamais apporte peu ; l'exiger avec un engagement de mise à jour et de délai de correction apporte beaucoup.