Les 5 problèmes les plus courants dans les SBOM
Interlynk
Le Bill of Materials (SBOM) aide à construire et à communiquer l'inventaire des composants logiciels et les risques associés. Les besoins réglementaires et de surveillance des SBOM sont bien compris. Cependant, la construction d'un « bon » SBOM nécessite toujours d'éviter plusieurs pièges, car certains constructeurs populaires de SBOM sont encore en maturation.
Voici les cinq problèmes les plus courants auxquels nous sommes confrontés lors de la gestion des SBOM.
1. Mélanges de Spécifications
Les cas les plus courants apparaissent dans les outils qui prennent en charge plus d'une spécification. Nous constatons systématiquement que l'implémentation du traitement d'une spécification conduit à des valeurs non valides pour l'autre.
2. Identifiants mal identifiés
CPE et PURL sont deux des moyens les plus courants d'identifier globalement des composants, en particulier dans la gestion des vulnérabilités. De plus, à la fois CycloneDX et SPDX exigent des identifiants uniques internes spécifiques au document ( bom-ref et SPDXID respectivement). Cela aide à suivre des informations supplémentaires sur les composants, telles que la relation entre les composants.
Mais ces exigences concernant les identifiants peuvent entraîner deux types courants de défis :
2.1 CPE/PURL manquant ou invalide
Un SBOM vide pour CPE ou PURL n'est pas utile pour le suivi des vulnérabilités. Il peut néanmoins servir de liste d'ingrédients et d'inventaire de licences lorsque des informations sur les licences sont présentes.
2.2 Identifiant unique incohérent
Le problème le plus courant est un SBOM contenant des identifiants invalides ou dupliqués présents dans le SBOM. Le bom-ref et SPDXID sont censés être uniques dans le document et ont des restrictions spécifiques à la norme (par exemple, le SPDXID ne doit pas inclure de caractères spéciaux).
3. Licence de créer la confusion
La spécification et le suivi des licences de logiciels open-source étaient l'un des premiers cas d'utilisation de la spécification SPDX. Depuis lors, les expressions de licence SPDX ont amélioré la liste des licences et la capacité d'exprimer plusieurs licences ou des exceptions spécifiques à celles-ci.
CycloneDX 1.5 et SPDX 2.3 et supérieur prennent en charge la spécification des licences commerciales aux côtés de ses textes et de liens vers des documents externes.
Malheureusement, il est tout aussi courant de rencontrer des IDs de licence ou des expressions de licence invalides dans les SBOM.
4. SBOM sans visage
Le SBOM existe dans le contexte d'un composant logiciel ou matériel d'un système. Par conséquent, sans identification appropriée du composant lui-même, le reste du SBOM devient une liste d'ingrédients pour un inconnu. Éléments minimaux NTIA suggère d'identifier le composant avec Nom, Version, et Autres identifiants uniques pour soutenir des recherches spécifiques telles que la recherche dans des bases de données de vulnérabilités.
Cependant, il est courant de trouver des SBOM sans cet ensemble de données minimales.
Un exemple :
Notez qu'aucune version n'est spécifiée dans le composant principal, et aucune identification de vulnérabilité n'est présente. Cela rend le SBOM inutilisable pour le suivi des vulnérabilités à travers les versions et la collecte des SBOM dans l'ordre des versions de produit. Déchiffrer la version 6.2.12-rc230906104347 nécessite des personnalisations spécifiques au produit, sujettes à des erreurs.
5. Burrito SBOM
Les spécifications SBOM les plus couramment utilisées, CycloneDX et SPDX, offrent une certaine flexibilité. Malheureusement, certains constructeurs de SBOM prennent un détour pour envelopper le contenu SBOM avec des données supplémentaires.
Un exemple :
Cela ne suit aucune des spécifications, et une intervention humaine est requise pour comprendre que le véritable SBOM commence au nœud « sbom ».
Les appID, scanId, type et repo:id sont tous des détails non applicables en dehors du champ d'application de cet outil. Cela rend l'automatisation de la consommation de tels SBOM un exercice de bricolage.
De plus, l'enveloppe burrito n'a pas de version et peut casser toute automatisation en aval sans avertissement.
Interlynk s'efforce de rendre la divulgation de sécurité facile, évidente et automatisée. L'outil Open Source d'Interlynk, sbomqs, peut identifier les problèmes les plus courants avec les SBOM et est ouvert au suivi d'autres erreurs courantes que vous pourriez rencontrer. N'hésitez pas à nous contacter à hello@interlynk.io