Améliorez votre cybersécurité avec la nomenclature des logiciels

Les vulnérabilités Log4j de 2021 ont alimenté une vague d’activités malveillantes sur l’Internet. Dans la semaine qui a suivi la divulgation, les chercheurs en sécurité ont recensé plus de 100 attaques Log4j par minute. Les équipes informatiques se sont empressées de déployer des correctifs et d’autres mesures visant à atténuer les risques, mais trois mois plus tard, près de 40 % des déploiements étaient encore vulnérables aux attaques. Le Data Breach Investigation Report (DBIR) de Verizon pour l’année 2023 révèle que 8 % des entreprises participant à l’étude ont encore une ou plusieurs installations vulnérables de Log4j.

Il n’est pas rare que d’anciennes vulnérabilités ne soient pas corrigées, en particulier lorsqu’elles sont intégrées à l’infrastructure. Log4j est un code de journalisation open-source que les développeurs utilisent dans leurs applications. Les correctifs apportés aux composants d’application de ce type nécessitent souvent une mise à jour complète de l’application, ce qui signifie que les équipes informatiques doivent attendre que les développeurs fournissent leurs solutions de sécurité. Il y a aussi d’autres défis, comme les logiciels hérités qui ne peuvent pas être mis à jour, ou les vulnérabilités d’applications inconnues de l’administrateur du système. Le DBIR susmentionné indique que le délai moyen de correction des vulnérabilités critiques est de 49 jours, et ce chiffre n’a pas beaucoup évolué au cours des dernières années. Les pirates n’ont besoin que de quelques heures après la découverte pour lancer une attaque. Dans certains cas, les attaques sont déjà en cours avant même que la vulnérabilité ne soit connue.

Pour les consultants et les informaticiens, les concepts de référence sont l’application et la plateforme. Certaines vulnérabilités et expositions courantes (CVE) attireront immédiatement leur attention, d’autres non. Les équipes techniques qui manquent de personnel et/ou d’outils pour soutenir la stratégie de sécurité auront plus de difficultés que les autres.  

The Software Bill of Materials (SBOM)

Une nomenclature des logiciels (SBOM) offre aux équipes techniques un moyen rapide d’identifier les vulnérabilités qui existent dans leurs plateformes et leurs infrastructures. La SBOM énumère les composants logiciels open-source et commerciaux existants qui sont inclus dans une application. Ce document facilite l’évaluation et la gestion des risques tout au long de la chaîne d’approvisionnement des logiciels. Si vous ne savez pas à quoi il peut ressembler, en voici un exemple :

Image tirée de The Software BOM Squad, DevOps.com

Software Security in Supply Chains (NIST) contient plus d’informations, des exemples et des normes minimales pour les SBOM dans les agences fédérales. Ce document définit un cadre que les entreprises peuvent utiliser pour leurs propres activités.

Qui est à l'origine de cette SBOM ?

Le décret 14028 du président Biden impose aux vendeurs de logiciels de fournir une SBOM à l’acheteur ou de la publier sur un site web pour y être consultée. Ce décret ne s’applique qu’au gouvernement fédéral américain et à ses fournisseurs. La création d’une SBOM est une bonne pratique, même si elle n’est pas obligatoire. Les développeurs peuvent intégrer les SBOM dans leur cycle de développement logiciel, parallèlement à d’autres initiatives de sécurité mises en œuvre par les équipes DevSecOps.

Il existe également des outils tels que Syft, qui peuvent créer des SBOM d’applications déjà en cours d’exécution dans l’environnement. Ces outils créent un inventaire des composants logiciels, des bibliothèques et des dépendances de l’application, même lorsque celle-ci est en production ou qu’elle n’est plus en phase de développement. Gardez à l’esprit que la SBOM ainsi créée peut ne pas être aussi complète qu’une SBOM générée pendant le processus de développement ou de création.

Le Gartner prévoit que le nombre d’entreprises qui ont besoin de SBOM passera de moins de 20 % en 2022 à 60 % en 2025.

Si vous souhaitez en savoir plus sur les SBOM et la manière de les utiliser, veuillez consulter ces ressources :

• Software Security in Supply Chains: Software Bill of Materials (SBOM)
  
• Les équipes chargées de la cybersécurité doivent faire respecter les mandats du SBOM
• National Telecommunications and Information Administration (NTIA), Département du Commerce des États-Unis
• NTIA - Software Identification Challenges and Guidance
• What are the Best Tools for Generating SBOM (Software Bill Of Materials)? (Mergebase)