Les nomenclatures logicielles (SBOD) – une liste détaillée des composants, modules et bibliothèques utilisés pour créer des produits – sont approuvées par le National Institute of Standards and Technology (NIST) et les régulateurs américains comme moyen de réduire les risques de cybersécurité de la chaîne d’approvisionnement pour les consommateurs.

Mais l’équipe de sécurité Open Source de Google souligne dans un article de blog aujourd’hui que Utilisation de SBOM seul n’est pas un outil efficace pour évaluer l’exposition. La documentation doit plutôt être comparée à une base de données de vulnérabilités connues pour identifier les failles logicielles connues.

« En reliant ces deux sources de
information, les consommateurs sauront non seulement ce qu’il y a dedans… leurs logiciels,
mais aussi ses risques et s’ils doivent remédier à des problèmes », explique l’équipe.

Les analystes de Google détaillent comment ils ont pu mapper un document Kubernetes SBOM à l’aide de la base de données Open Source Vulnerabilities (OSV). La base de données OSV offre à la fois un format standardisé pour la comparaison entre plusieurs bases de données, y compris la base de données Github Advisory Database (GHSA) et la base de données de sécurité mondiale (GSD), ainsi que des données agrégées sur plusieurs écosystèmes, allant de Python et Golang à Rust, selon le post.

« Notre exemple a interrogé la base de données OSV, mais nous verrons bientôt le
même succès dans le mappage des données SBOM à d’autres bases de données de vulnérabilité et même
les utiliser avec de nouvelles normes comme VEX (Vulnerability-Exploitability eXchange), qui
fournit un contexte supplémentaire quant à savoir si les vulnérabilités dans les logiciels ont
ont été atténués », indique le blog.

Pour permettre aux équipes de sécurité d’évaluer plus facilement l’ensemble des risques, les chercheurs de Google recommandent aux créateurs de SBOM de commencer à inclure une référence à l’aide d’une convention de dénomination telle qu’une URL Purl pour tous les packages du chaîne d’approvisionnement de logiciels.

« Ce type de schéma d’identification spécifie à la fois l’écosystème et facilite également l’identification des emballages, car le schéma est plus résistant aux petits écarts dans les descripteurs d’emballage comme l’exemple de suffixe ci-dessus », disent-ils.

Évolution SBOM
Les étapes visant à marier les composants logiciels avec des failles connues aideront les SBOM à atteindre leur objectif : aider à gérer la perspective d’une cyberattaque, le Blog sur la sécurité Google États.

« En continuant sur cette voie d’adoption généralisée de SBOM et d’amélioration de l’outillage, nous espérons pouvoir bientôt non seulement demander et télécharger des SBOM pour chaque logiciel, mais aussi les utiliser pour comprendre les vulnérabilités affectant tout logiciel que nous consommons », ont-ils déclaré.