Les nomenclatures logicielles (SBOM) sont comme les étiquettes d’ingrédients sur les aliments. Ils sont essentiels pour assurer la sécurité et la santé des consommateurs, ils sont quelque peu standardisés, mais il est beaucoup plus excitant de cultiver ou de fabriquer les aliments plutôt que l’étiquette.

Qu’est-ce qu’un SBOM ?

Qu’est-ce qu’un SBOM ? En bref, c’est un moyen de dire à une autre partie tous les logiciels qui sont utilisés dans la pile qui compose une application. L’un des avantages d’avoir un SBOM est que vous savez ce qu’il contient lorsqu’une vulnérabilité survient. Vous pouvez facilement déterminer si vous êtes vulnérable et où.

Comme les logiciels modernes sont construits en utilisant une base de logiciels déjà écrits (cela n’a aucun sens de recréer la roue), il est important que tous les composants ne se perdent pas dans le mélange. Il n’est pas évident de savoir ce qu’un logiciel particulier utilise. Donc, si une vulnérabilité pour le logiciel A survient, vous devez savoir si j’ai ce logiciel quelque part dans mon écosystème et, si oui, où. Ensuite, vous pouvez corriger si vous en avez besoin.

Je ne peux pas m’attribuer le mérite de l’analogie de l’étiquette alimentaire utilisée dans mon introduction. je l’ai entendu de Allan Friedmannconseiller principal et stratège à la Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) et un défenseur clé des SBOM, lorsqu’il a présenté les SBOM à la conférence RSA 2022 avec Kate Stewart, le vice-président des systèmes embarqués fiables ici à la Linux Foundation. Allan a fait remarquer que les étiquettes des aliments ne fournissent que des informations. Le consommateur doit les lire et les comprendre et prendre les mesures appropriées. Par exemple, s’ils sont allergiques aux arachides, ils peuvent consulter une étiquette d’ingrédients et déterminer s’ils peuvent manger les aliments en toute sécurité.

Les SBOM sont similaires – ils indiquent à une personne quel logiciel est utilisé comme « ingrédient » afin que quelqu’un puisse déterminer s’il doit prendre des mesures en cas de vulnérabilité. Ce n’est pas une solution miracle, mais c’est un outil essentiel. Sans les SBOM, personne ne peut suivre les « ingrédients » des composants dans leurs applications logicielles.

Les SBOM et la chaîne d’approvisionnement logicielle

Les chaînes d’approvisionnement ont plus d’impact sur nos vies que la simple restriction de la disponibilité des biens de consommation. Les chaînes d’approvisionnement en logiciels sont immensément plus compliquées maintenant, car les logiciels sont construits avec des composants préexistants. Cela rend les logiciels meilleurs, plus efficaces, plus puissants, etc. Mais cela introduit également des risques car de plus en plus de parties touchent à un logiciel particulier. Tout comme notre monde est devenu si interdépendant, nos logiciels aussi.

Comprendre ce qui se passe dans la chaîne d’approvisionnement de nos logiciels nous aide à les sécuriser efficacement. Lorsqu’un nouveau risque apparaît, nous savons ce que nous devons faire.

SBOM et sécurité logicielle

Les SBOM sont de plus en plus reconnus comme un pilier important de tout plan de sécurité logicielle complet. Un mondial enquête menée au troisième trimestre 2021 par la Fondation Linux ont constaté que 78 % des organisations ayant répondu prévoient d’utiliser les SBOM en 2022. De plus, le rapport récemment publié Plan de mobilisation de la sécurité des logiciels open source recommande que les SBOM soient universels et que Décret exécutif américain sur l’amélioration de la cybersécurité de la nation exige que des SBOM soient fournis pour les logiciels achetés par le gouvernement américain. Et, comme le souligne Allan dans son discours, « Nous achetons tout. » L’EO présente en fait un bon résumé des SBOM et de leurs avantages :

Le terme « nomenclature logicielle » ou « SBOM » désigne un enregistrement formel contenant les détails et les relations de la chaîne d’approvisionnement des divers composants utilisés dans le logiciel de construction. Les développeurs et les fournisseurs de logiciels créent souvent des produits en assemblant des composants logiciels open source et commerciaux existants. Le SBOM énumère ces composants dans un produit. C’est analogue à une liste d’ingrédients sur les emballages alimentaires. Un SBOM est utile à ceux qui développent ou fabriquent des logiciels, à ceux qui sélectionnent ou achètent des logiciels et à ceux qui exploitent des logiciels. Les développeurs utilisent souvent des composants logiciels open source et tiers disponibles pour créer un produit ; un SBOM permet au constructeur de s’assurer que ces composants sont à jour et de réagir rapidement aux nouvelles vulnérabilités. Les acheteurs peuvent utiliser un SBOM pour effectuer une analyse de vulnérabilité ou de licence, qui peuvent toutes deux être utilisées pour évaluer les risques d’un produit. Ceux qui exploitent des logiciels peuvent utiliser les SBOM pour déterminer rapidement et facilement s’ils courent un risque potentiel d’une vulnérabilité nouvellement découverte. Un format SBOM largement utilisé et lisible par machine offre de plus grands avantages grâce à l’automatisation et à l’intégration d’outils. Les SBOM gagnent en valeur lorsqu’ils sont stockés collectivement dans un référentiel qui peut être facilement interrogé par d’autres applications et systèmes. Comprendre la chaîne d’approvisionnement des logiciels, obtenir un SBOM et l’utiliser pour analyser les vulnérabilités connues sont essentiels à la gestion des risques.

Allan et Kate ont passé du temps dans leur conversation à se pencher sur l’état actuel des SBOM, les défis, les avantages, les outils disponibles pour créer et partager des SBOM, ce qu’est un SBOM minimum, les normes en cours d’élaboration, les rendant entièrement automatisées, et plus encore. Recherchez de futurs articles sur le blog LF qui les approfondiront.

Mais il y a des choses que vous pouvez faire maintenant.

Que pouvez-vous faire, vous et votre organisation, maintenant ?

Allan et Kate ont expliqué plusieurs choses que vous et votre organisation pouvez faire dès maintenant. Au sein de votre organisation :

Mais il y a aussi des étapes que vous pouvez suivre en tant qu’individu :

Comment pouvez-vous façonner l’avenir des SBOM ?

Tout d’abord, je veux souligner certaines opportunités à venir qu’ils ont partagées pour aider à façonner l’avenir des SBOM. CISA organise des discussions publiques sur les flux de travail sur l’outillage et la mise en œuvre en juillet 2022. Ils sont identiques, mais se produisent à des moments différents pour aider à s’adapter à plus de fuseaux horaires :

13 juillet 2022 – 15h00-16h30 HE
21 juillet 2022 – 9h30-11h00 HE

Si vous souhaitez participer, envoyez un e-mail SBOM@cisa.dhs.gov.

De plus, il y aura «plugfests» qui sera annoncé prochainement, et ils ont suggéré aux organisations qui adoptent déjà les SBOM de publier des études de cas et des workflows d’outillage de référence pour aider les autres.

Conclusion

Les SBOM sont là pour rester. Si vous ne l’êtes pas déjà, montez dans le train maintenant. Il se retire de la gare, mais vous avez toujours la possibilité d’aider à déterminer où il va et dans quelle mesure le voyage se déroule.

Les diapositives d’Allan et de Kate sont disponibles ici. Si vous vous êtes inscrit pour assister à la conférence RSA, vous pouvez maintenant regarder leur présentation complète sur demande ici.

Le progiciel Data ExchangeⓇ (SPDXⓇ)

La Fondation Linux héberge SPDX, qui est une norme ouverte pour la communication d’informations sur la nomenclature des logiciels, y compris les composants, les licences, les droits d’auteur et les références de sécurité. SPDX réduit le travail redondant en fournissant un format commun permettant aux entreprises et aux communautés de partager des données importantes, rationalisant et améliorant ainsi la conformité. La spécification SPDX est une norme ouverte internationale (ISO/IEC 5962:2021). En savoir plus sur spdx.dev.