SBOM : peut-on sécuriser un logiciel dont on ignore les composants ?
Publié sur LinkedIn le 17 aout 2026
Lorsqu’une vulnérabilité critique est publiée, la première question devrait être simple :
« Sommes-nous concernés ? »
Et pourtant, dans beaucoup d’organisations, la réponse prend des heures, parfois des jours.
Pourquoi ?
Parce que personne ne sait précisément quelles bibliothèques, versions, dépendances et composants tiers sont embarqués dans les applications.
C’est tout l’intérêt du SBOM : le Software Bill of Materials.
L’idée est comparable à la liste des ingrédients d’un produit alimentaire.
Un SBOM doit permettre de savoir ce que contient réellement un logiciel :
composants open source ;
bibliothèques tierces ;
versions ;
relations de dépendance ;
éléments intégrés lors de la construction.
Ce n’est pas un document décoratif.
C’est un outil de connaissance, de sécurité et de résilience.
Lorsqu’une faille touche un composant largement utilisé, comme Log4j l’a montré, le problème n’est pas seulement de corriger.
Il faut d’abord localiser.
Quels produits embarquent le composant ?
Quelles versions sont vulnérables ?
Quels clients sont exposés ?
Existe-t-il une dépendance indirecte ?
Quel correctif peut être déployé sans casser le service ?
Sans SBOM fiable, chaque réponse devient une enquête.
Avec un SBOM à jour, la qualification peut être beaucoup plus rapide.
Mais attention : générer une liste ne suffit pas.
Elle doit être complète.
Liée à une version précise du produit.
Actualisée à chaque build ou livraison.
Stockée de façon exploitable.
Associée à la gestion des vulnérabilités.
Contrôlée pour éviter les composants inconnus ou non maintenus.
ENISA constate que le Cyber Resilience Act accélère l’adoption des SBOM en Europe.
C’est logique.
Le CRA impose aux fabricants de mieux maîtriser la cybersécurité de leurs produits pendant leur cycle de vie.
Difficile de gérer les vulnérabilités d’un produit si l’on ne sait pas ce qu’il contient.
Le SBOM ne supprime pas le risque.
Il ne garantit pas qu’un composant est sain.
Il ne remplace pas les correctifs.
Il ne corrige pas une mauvaise architecture.
Mais il réduit un risque majeur : l’ignorance.
La vraie question n’est donc pas :
« Avons-nous produit un SBOM ? »
Mais :
« Pouvons-nous utiliser ce SBOM pour identifier, en quelques minutes, tous les produits touchés par une vulnérabilité critique ? »
Une nomenclature inutilisable reste un fichier de plus.
Une nomenclature fiable devient un accélérateur de décision, de correction et de communication.
En cybersécurité, connaître ses composants n’est plus du confort.
C’est le début de la maîtrise.
PS : Si vous découvrez mon contenu (veille CERT, Post), je vous invite à me suivre ici sur LinkedIn
#SBOM #CyberResilienceAct #CRA #Cybersécurité #SécuritéLogicielle #GestionDesVulnérabilités #RésilienceIT #DevSecOps
