SBOM : inventaire logiciel pour les décisions de risque

Cybersécurité · 3 min

Une *Software Bill of Materials* (SBOM) n'est utile que lorsqu'elle soutient des décisions concrètes. Découvrez comment l'utiliser pour les achats, les vulnérabilités, les incidents et la gestion des fournisseurs.

SBOM : inventaire logiciel pour les décisions de risque

TL;DR

Une SBOM répertorie les composants logiciels, les versions et les dépendances pertinentes.
Sa valeur réside dans la capacité à relier les composants au risque, à l'exposition et à la criticité.
Elle doit être intégrée aux achats, à la gestion des vulnérabilités et à la réponse aux incidents.
Sans processus de mise à jour et de validation, la SBOM devient rapidement obsolète.

Pourquoi la SBOM est entrée dans l'agenda des DSI

La Software Bill of Materials, ou SBOM, est un inventaire structuré des composants qui constituent une application ou un produit numérique. Son utilité ne réside pas seulement dans la connaissance des bibliothèques existantes, mais dans la capacité à répondre rapidement aux questions de risque : quels systèmes utilisent une version affectée, quel fournisseur l'a introduite, quel service métier pourrait être impacté et quelle priorité doit être attribuée à la correction.

De l'inventaire technique à la décision exécutive

Pour les DSI, les CTO et les responsables de la sécurité, la SBOM doit être traitée comme une pièce de gouvernance, et non comme un appendice technique. Dans les processus d'acquisition, elle peut aider à évaluer la transparence du fournisseur, la maturité du développement sécurisé et la capacité de réponse aux vulnérabilités. Cette approche complète la gestion plus large des risques dans la [chaîne d'approvisionnement numérique](/pt/blog/navegar-na-complexidade-gestao-de-riscos-na-supply-chain-digital), surtout lorsque des applications critiques dépendent de bibliothèques tierces, de composants open source ou de services externes. Dans l'Union Européenne, le Cyber Resilience Act renforce également la pertinence de la SBOM en établissant des exigences de documentation des composants et des vulnérabilités pour les fabricants de produits comportant des éléments numériques couverts par le règlement.

Ce qui doit être défini avant de demander une SBOM

Demander une SBOM sans critères clairs a tendance à générer des fichiers difficiles à utiliser. Avant de l'exiger des fournisseurs ou des équipes internes, l'organisation doit définir : le format accepté, la fréquence de mise à jour, le niveau de détail, les responsabilités de validation et l'intégration avec les outils existants. Elle doit également clarifier si la SBOM ne couvre que l'application principale ou si elle inclut les conteneurs, les images, les modules, les bibliothèques transitives et les composants fournis par des tiers. Une architecture de sécurité cohérente, comme celle soutenue par une approche de [Cybersecurity Mesh](/pt/solucoes/cybersecurity-mesh), peut faciliter la corrélation entre l'inventaire, l'identité, l'exposition et les contrôles.

Comment utiliser la SBOM dans la gestion des vulnérabilités

La plus grande valeur opérationnelle apparaît lorsque la SBOM est liée à la gestion des vulnérabilités et à la criticité des actifs. Toutes les vulnérabilités identifiées dans un composant ne représentent pas le même niveau de risque : il est nécessaire de comprendre si le composant affecté est effectivement présent et utilisé, si la fonctionnalité vulnérable est exploitable dans le contexte de l'application, quelle est l'exposition du système et quels contrôles compensatoires existent. Par conséquent, la SBOM doit alimenter les décisions de priorisation, en conjonction avec des pratiques de [gestion des correctifs par risque](/pt/blog/gestao-patches-risco-ambientes-hibridos), au lieu de créer simplement une autre liste d'alertes.

Limites et précautions pratiques

Une SBOM ne prouve pas, à elle seule, que le logiciel est sécurisé. Elle peut être incomplète, obsolète ou ne pas refléter la configuration réelle en production. Elle ne remplace pas non plus les tests de sécurité, la revue de code, la surveillance ou la gestion contractuelle des fournisseurs. Dans les environnements avec de nombreuses applications héritées, la priorité doit être de commencer par les systèmes les plus critiques et les fournisseurs ayant le plus grand impact opérationnel. La [gestion d'infrastructure](/pt/servicos/gestao-infraestrutura) peut aider à maintenir le lien entre les actifs, les versions, les dépendances et les responsabilités d'exploitation.

Conclusion

La SBOM doit être considérée comme un outil de décision et non comme une fin en soi. Lorsqu'elle est intégrée aux achats, aux vulnérabilités, aux incidents et à la gouvernance des fournisseurs, elle peut améliorer la visibilité sur les dépendances logicielles et soutenir des réponses plus rapides. Son succès dépend moins de l'existence du fichier et davantage de la capacité à le maintenir à jour, validé et lié aux processus de risque de l'organisation.