Les équipes chargées de la cybersécurité doivent faire respecter les mandats du SBOM

Les responsables de la cybersécurité seraient bien avisés d'exiger dès maintenant que chaque application déployée soit assortie d'une nomenclature logicielle (SBOM).

La crise de cybersécurité Log4j, survenue à la suite de la divulgation d'une série de vulnérabilités de type « zero-day » affectant les applications Java, a notamment mis en évidence le fait que de nombreuses entreprises ne savaient pas exactement combien d'instances du code en question étaient utilisées. L'outil open source Log4J permettant la gestion des journaux a été copié et collé dans des milliers d'applications Java. De nombreuses entreprises informatiques ont passé des semaines à chercher un code alors qu'elles auraient pu le corriger en quelques minutes à peine à l'aide d'un correctif de mise à jour. Les choses seraient beaucoup plus simples si les équipes informatiques avaient accès à des nomenclatures indiquant avec certitude quels composants sont inclus dans une application donnée.

Bien sûr, il existe des outils que les équipes informatiques peuvent utiliser pour analyser les codes binaires afin de créer automatiquement un SBOM. Cependant, un SBOM généré au moment du déploiement de l'application est un moyen plus simple de repérer les composants lorsque le temps est compté. Les cybercriminels sont devenus nettement plus habiles quant à l'exploitation des vulnérabilités dans les heures qui suivent leur divulgation. C'est pourquoi le décret publié par l'administration Biden prévoit une disposition exigeant que toute application utilisée par une agence fédérale soit dotée d'un SBOM. La plupart des entreprises informatiques seront probablement amenées à suivre cet exemple. Les équipes informatiques doivent également s'attendre à ce que chaque police d'assurance relative à la cybersécurité prévoie une exigence similaire, le but étant de limiter les risques potentiels en réduisant le temps nécessaire à l'application d'un correctif.La Linux Foundation, la Joint Development Foundation et la communauté open-source SPDX sont à l'origine d'une spécification SPDX (Software Package Data Exchange) visant à la création de nomenclatures logicielles (SBOM), désormais reconnue comme norme internationale ISO/IEC 5962:2021. Il existe également CycloneDX, une norme SBOM légère basée sur un projet open source issu de la communauté Open Web Application Security Project (OWASP) et une norme d'identification logicielle (SWID) applicable aux tags que certaines entreprises utilisent pour créer des SBOM.

Un manifeste pour la cybersécurité moderne affirme que les entreprises devraient généraliser le suivi, car il est impossible de protéger ce que l'on ne voit pas. Les SBOM sont une première étape critique vers la sécurisation de tout environnement applicatif. Aujourd'hui, le défi est d'expliquer aux développeurs qui souhaitent simplement écrire du code pourquoi ils doivent créer un SBOM précis pour leur application. Bien sûr, la chose la plus simple à faire est de dire aux développeurs que leurs applications ne seront pas autorisées à s'exécuter dans un environnement de production sans SBOM. Les équipes de cybersécurité seront étonnées de la rapidité avec laquelle le processus de création d'un SBOM sera ensuite automatisé dans le cadre d'un flux de travail DevOps.

Le meilleur incident de cybersécurité, naturellement, est celui qui ne s'est jamais produit. Un simple SBOM permettra de prévenir le déploiement d'un grand nombre de composants logiciels présentant des vulnérabilités connues. Il est inévitable que des vulnérabilités de type « zero-day » soient découvertes après le déploiement d'une application dans un environnement de production. Cependant, un SBOM peut faire toute la différence entre des vulnérabilités qui restent les derniers avatars d'une série d'événements indésirables et ce qui se révèle bien souvent une véritable catastrophe pour les opérations informatiques.