SBOM : essentiel et facile à mettre en œuvre

Des exigences légales croissantes

Les législateurs de plusieurs pays ont reconnu la valeur des SBOM et commencent à les rendre obligatoires. Deux cadres juridiques promeuvent l’utilisation des SBOM : les directives de la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis et le Cyber Resilience Act (CRA) de l’Union européenne. 

Aux États-Unis, un SBOM peut être exigé dans certains cas et est déjà obligatoire pour les logiciels de dispositifs médicaux. En Europe, le CRA définit clairement les exigences : l’article 37 et l’annexe 1, paragraphe 2 stipulent que les fabricants doivent documenter leurs produits dans un format couramment utilisé et lisible, y compris un SBOM. La conformité à ces réglementations est surveillée par la Commission européenne, et les infractions peuvent entraîner des amendes significatives.

Un inventaire logiciel complet

Un SBOM inventorie donc les logiciels, enregistrant le code écrit par les utilisateurs, les composants open source, les lignes de code de fournisseurs tiers et d’autres éléments d’une solution logicielle. Cela produit une documentation claire qui met en lumière les vulnérabilités. Maintenir un SBOM permet aussi d’identifier rapidement les problèmes de licence. Un SBOM protège les entreprises contre les réclamations de licence non conformes et contre les attaques de malware dues aux vulnérabilités des composants. Les systèmes affectés peuvent être rapidement identifiés et sécurisés. Un SBOM accompagne le logiciel tout au long de son cycle de vie, documentant toutes les informations pertinentes de manière claire et compréhensible.

Peu d’entreprises utilisent des SBOM malgré les avantages

Malgré les nombreux avantages, beaucoup d’entreprises n’utilisent pas de SBOM. Selon une étude de l’institut Ponemon, en 2023, plus de la moitié des entreprises interrogées avaient subi une attaque sur leur chaîne d’approvisionnement logicielle. Près d’un tiers de ces attaques étaient dues à des vulnérabilités dans des composants open source non mis à jour. 

De plus, plus de 60 % des répondants estimaient que leurs entreprises n’avaient pas suffisamment protégé leurs chaînes d’approvisionnement contre les attaques de malware. Moins de la moitié des entreprises disposaient de process pour se protéger contre les logiciels open source malveillants, et la moitié d’entre elles prenaient en moyenne plus d’un mois pour identifier et éliminer les malwares. 

Les conséquences peuvent être catastrophiques, allant jusqu’à menacer la viabilité financière de l’entreprise, avec une perte de confiance et de réputation, ainsi que des commandes et/ou des clients. En résumé, ne pas maintenir un SBOM, c’est comme ne pas avoir de protection générale contre les malwares ou de pare-feu.

Créer un SBOM est plus facile qu’on ne le pense

Beaucoup de responsables hésitent à mettre en place un SBOM, craignant une complexité excessive. Ces craintes sont infondées. Créer et maintenir un SBOM est bien plus simple qu’on ne le pense. Si le processus de développement logiciel inclut déjà la maintenance d’un SBOM, cela facilite encore plus la gestion des composants. Les développeurs peuvent enregistrer les hachages et les fichiers des produits dans le cadre du processus de développement, permettant ainsi une gestion efficace des vulnérabilités, la documentation et le suivi des dépendances. Les solutions SBOM peuvent utiliser ces informations pour créer des listes complètes des dépendances des applications, identifiant rapidement les vulnérabilités potentielles dans une chaîne d’approvisionnement logicielle.

Les SBOM sont donc étroitement liés aux activités du cycle de développement des systèmes (SDLC). Les données nécessaires peuvent être facilement extraites du SBOM et importées pour optimiser ses fonctionnalités. Les sources, les dépendances, les fichiers binaires et les artefacts peuvent être identifiés via des analyses multi-facteurs. Les informations du SBOM peuvent également être utilisées par les autorités réglementaires et les clients, et via le Vulnerability Exploitability eXchange (VEX) pour échanger des vulnérabilités.

Une demande croissante des entreprises

De nombreuses entreprises demandent déjà un SBOM et la preuve d’un SDLC sécurisé. De plus, beaucoup de clients d’entreprise s’attendent à ce que leurs fournisseurs les informent rapidement de toute vulnérabilité et les aident à y remédier. Sans un SBOM, cela est difficile à réaliser. Idéalement, un SBOM doit être directement intégré au processus de développement. Les SBOM se fondent dans le processus de développement, enregistrant précisément les informations nécessaires à la gestion des logiciels. À une époque de cyberattaques croissantes, il devient de plus en plus inacceptable de ne pas avoir d’informations sur les composants utilisés, que ce soit pour les réseaux ou pour les applications qui y sont exécutées.