Les SBOM deviennent un élément essentiel de la sécurité de la chaîne d’approvisionnement logicielle

SCSW L’analogie courante lorsque l’on parle de nomenclatures logicielles (SBOM) est la liste des ingrédients figurant sur les emballages alimentaires qui permet aux consommateurs de savoir ce qu’il y a dans les chips qu’ils sont sur le point de manger.

De même, un SBOM est un inventaire des composants d’un logiciel, un outil crucial à une époque où les applications sont une collection de code provenant de plusieurs sources, dont beaucoup proviennent de l’extérieur de l’équipe de développement d’une organisation.

“Quand il s’agit d’un SBOM, c’est tout aussi important [as the nutrition labels on food] parce que le risque n’est pas pour votre santé physique mais pour votre entreprise », a déclaré Mark Lambert, vice-président des produits chez ArmorCode. Le registre. “Le risque auquel vous exposez potentiellement votre entreprise lorsque vous utilisez un logiciel est que vous ne comprenez pas ce qu’il contient.”

Lorsque cela se produit, “vous vous exposez à une vulnérabilité qui est hors de votre contrôle. Si vous n’avez pas de visibilité sur cela, vous ne pouvez pas prendre de précautions pour vous assurer que vous n’êtes pas trop exposé.”

C’est pourquoi, au cours des dernières années, les SBOM sont devenus au cœur de l’image croissante de la gestion de la chaîne d’approvisionnement logicielle à mesure que les niveaux de menace augmentent. Grâce à l’utilisation croissante de logiciels open source et de composants logiciels réutilisables, aux contributions de plusieurs sources, à l’accélération du rythme de publication du code et aux pipelines d’intégration et de livraison continues (CI/CD), le développement moderne est devenu plus rapide et plus complexe.

“Alors que la chaîne d’approvisionnement des logiciels se complique, il est essentiel de savoir quelle source ouverte vous utilisez indirectement dans le cadre de bibliothèques, services, API ou outils tiers”, a déclaré Lambert.

Les malfaiteurs savent qu’en injectant du code malveillant à n’importe quel moment du processus de développement ou en exploitant les vulnérabilités d’un composant, ils peuvent se déplacer en amont et infecter plusieurs systèmes, comme on l’a vu dans la faille SolarWinds en 2020 et l’abus de la faille Log4j.

Le besoin de savoir

Les SBOM sont également un point clé du plan national de cybersécurité élaboré par l’administration Biden et publié cette semaine. Ils indiquent non seulement aux organisations quels composants composent le logiciel qu’ils apportent, mais également quel code s’y trouve.

Les SBOM garantissent que “vous connaissez non seulement les ingrédients de votre logiciel, mais également les ingrédients de ces ingrédients, parfois appelés dépendances transitives”, a déclaré Donald Fischer, co-fondateur et PDG de Tidelift. Le registre. “En open source, de nombreux packages font appel à d’autres packages, que vous pouvez ou non savoir utiliser, et les SBOM peuvent vous aider à bien comprendre ces relations.”

La découverte de la faille Apache Log4j en décembre 2021 a envoyé une onde de choc dans le monde de la technologie car l’outil de journalisation largement utilisé était largement exploité pour compromettre les systèmes vulnérables via une seule injection de code malveillant.

Son utilisation était si large qu’elle touchait la plupart des organisations, dont beaucoup ne savaient pas qu’elles étaient concernées. Quelques semaines après la découverte de la vulnérabilité, 10 millions de tentatives d’exploitation Log4j par heure ont été signalées.

“Log4j est utilisé dans la grande majorité des logiciels”, a déclaré Lambert d’ArmorCode, ajoutant que cela soulignait le besoin de SBOM. “Quand [the flaw in] Log4j a été identifié, nous avons tous été instantanément exposés à la vulnérabilité. Log4j a tout mis en valeur. Le problème est là depuis un moment.”

Les SBOM entrent en scène

L’idée du SBOM est relativement nouvelle. Il est apparu en 2018 avec la National Telecommunications and Information Administration, une division du département américain de l’Agriculture, avec des normes publiées trois ans plus tard. Le décret du président Biden en mai 2021 a appelé le gouvernement fédéral à améliorer sa sécurité informatique à la suite de SolarWinds et de Log4j, qui ont tous deux eu un impact sur les agences gouvernementales.

“Comme pour ce qui se produit généralement, l’EO a fait passer le SBOM d’une fonctionnalité intéressante à une solution semi-obligatoire qui est actuellement en cours d’évaluation dans la plupart des agences gouvernementales et des grandes entreprises”, écrit John Masserini, analyste principal de la recherche chez TAG Cyber. article de blog pour ReversingLabs.

Un défi est que la mise en œuvre et la gestion des SBOM sont très manuelles, ce qui est une mauvaise nouvelle pour les administrateurs et les développeurs. Une tension constante lorsque l’on parle de sécurité de la chaîne d’approvisionnement logicielle consiste à s’assurer que les exigences de sécurité n’entravent pas la vitesse croissante du développement de logiciels modernes.

L’automatisation est la clé

C’est pourquoi l’automatisation du processus SBOM est importante. La norme du NIST comprend plusieurs éléments, du composant logiciel utilisé et de son fournisseur aux numéros de version et à l’accès au référentiel du composant. Les niveaux de version doivent être évalués par rapport aux niveaux de version, aux menaces potentielles détectées et aux risques déterminés.

“Le déroulement de grandes applications, des systèmes d’exploitation open source aux applications développées en interne, en passant par les piles tierces” rétractables”, est semé d’embûches contextuelles, de méthodes d’inventaire et de vérification manuelle, qui sont toutes sujettes à l’erreur, ” écrit Masserini.

Bien que le processus d’identification et de signalement des problèmes soit codifié, “il ne résout pas le problème de la maintenance manuelle d’un tel inventaire et de la validation constante de son contenu”, a-t-il déclaré.

L’automatisation doit être intégrée à chaque étape du processus, de la génération et de la publication des SBOM à leur ingestion, puis intégrer la correction des vulnérabilités dans leurs programmes de sécurité des applications actuels sans avoir à adopter de nouveaux flux de travail, déclare Lambert.

Que faire des SBOM

Il y a d’autres considérations. Les SBOM fournissent beaucoup d’informations, mais les organisations doivent décider comment elles vont les utiliser. “SBOM” est un acronyme fourre-tout pratique pour un ensemble plus large de problèmes de chaîne d’approvisionnement logicielle, a déclaré Fischer de Tidelift.

Ils font également partie d’un plus grand cache de technologies de sécurité de la chaîne d’approvisionnement, telles que SLSA (Supply chain Levels for Software Artifacts), un cadre pour garantir l’intégrité des artefacts logiciels tout au long de la chaîne d’approvisionnement qui est né d’un outil interne de Google et est maintenant un projet industriel qui comprend des organisations telles qu’Intel, VMware, The Linux Foundation et Cloud Native Computing Foundation.

“Les SBOM en eux-mêmes ne sont pas une solution miracle”, a-t-il déclaré. “Nous devons comprendre en quoi ils sont bons et où ils sont moins utiles. Ils sont bons pour vous aider à comprendre les composants qui entrent dans votre logiciel. Ils sont beaucoup moins utiles pour réellement améliorer le profil de sécurité de ces composants.”

Il existe quelques formats SBOM standard clés – Software Packet Data Exchange (SPDX), CycloneDX et Software Identification (SWID) Tagging.

Ce qu’il faut maintenant, c’est un échange de vulnérabilités sécurisé et centralisé où les entreprises peuvent partager des informations sur les failles, a déclaré Lambert. Disposer des données SBOM est utile, mais si une vulnérabilité est découverte, la communication à ce sujet est toujours point à point et cette information doit être partagée plus rapidement et plus largement, a-t-il déclaré.

Payer les mainteneurs

Un autre problème émergent est que les SBOM et autres signifient plus de travail pour ceux qui maintiennent le logiciel open source utilisé dans la plupart des applications, a déclaré Fischer. Et la plupart des responsables – 60 %, selon Fischer – ne sont pas rémunérés, essentiellement des bénévoles.

Ils “manquent généralement de l’alignement, et encore moins de l’incitation, pour traiter de longues listes de contrôle de pratiques de développement sécurisées”, a-t-il déclaré. “Dans un contexte d’attention croissante du gouvernement et de l’industrie à la cybersécurité à la suite de vulnérabilités très médiatisées comme celles qui ont affecté SolarWinds et Log4j, les demandes adressées à ces mainteneurs bénévoles augmentent de façon exponentielle.”

L’amélioration de la sécurité nécessite des outils – comme les SBOM – et des personnes. Il est temps de commencer à payer les responsables de l’open source comme les entreprises le font pour quiconque est responsable de la sécurité des logiciels.

Les SBOM, comme de nombreux outils utilisés pour la sécurité de la chaîne d’approvisionnement, sont encore relativement nouveaux et doivent mûrir. Étant donné la vitesse à laquelle les mécréants trouvent des moyens d’attaquer la chaîne d’approvisionnement, plus la maturation est rapide, mieux c’est.

“SBOM a du chemin à parcourir, mais c’est une bonne solution”, a déclaré Lambert. “Avoir une norme n’est pas mauvais. N’avoir aucune norme est un problème.” ®