Faire progresser les normes SBOM : Snyk et SPDX

Beaucoup connaissent le projet SPDX grâce aux travaux sur la liste des licences SPDX. Cette liste d’identifiants canoniques pour différentes licences logicielles est utilisée dans de nombreux logiciels destinés aux développeurs, de Snyk à GitHub. Mais le projet SPDX, qui fait partie de la Linux Foundation, a un objectif bien plus large : fournir une norme ouverte pour communiquer des informations sur les nomenclatures logicielles.

Une nomenclature logicielle, ou SBOM, est une liste des composants d’un logiciel donné. On la compare souvent à la liste des ingrédients figurant sur les emballages alimentaires. Les logiciels sont de plus en plus complexes et composés d’un nombre croissant de composants. Il ne s’agit pas seulement de bibliothèques et de frameworks open source : une application logicielle moderne peut comprendre plusieurs services, chacun doté de sa propre SBOM, regroupés avec des outils susceptibles d’introduire encore d’autres dépendances.

SPDX vise à normaliser la définition des SBOM et à fournir un format lisible par machine, autour duquel l’ensemble du secteur logiciel pourra créer des outils pour résoudre les nombreux problèmes liés à la chaîne d’approvisionnement.

Cette approche contribue de plus en plus à relever les défis actuels de la sécurité logicielle. Le mois dernier, le président américain Joe Biden a publié un décret sur l’amélioration de la cybersécurité nationale, qui mentionne explicitement l’adoption des SBOM et la formalisation de normes SBOM parmi ses objectifs. Découvrez plus en détail notre point de vue sur ce décret dans notre article de blog sur les exigences de sécurité de la chaîne d’approvisionnement logicielle.

Snyk et les SBOM

Les fichiers manifestes utilisés par les gestionnaires de paquets contiennent bien des listes de logiciels, mais ils ne sont généralement pas considérés comme des SBOM. Leur portée est plus restreinte et répond à un cas d’utilisation précis : ils ne contiennent que les informations nécessaires à l’installation des logiciels répertoriés.

Snyk s’intègre à de nombreux gestionnaires de paquets et outils de développement afin de vous aider à détecter les vulnérabilités dans les composants logiciels utilisés. Pour cela, nous devons générer une SBOM en arrière-plan, normaliser la liste des logiciels et l’enrichir de métadonnées supplémentaires provenant d’autres sources. Les outils Snyk servent principalement à présenter ces informations avec celles sur les vulnérabilités, mais les clients Snyk peuvent accéder à la SBOM brute grâce à nos rapports intégrés ou à notre puissante API.

En fait, vous pouvez considérer les outils clients Snyk, comme l’interface de ligne de commande et les plug-ins CI/CD, comme des générateurs de SBOM. Le backend de Snyk, lui, reçoit une SBOM et renvoie des données sur les vulnérabilités, ou automatise leur traitement pour vous aider à corriger les problèmes. C’est cette vaste expérience qui explique notre intérêt pour les nouvelles normes dans ce domaine.

Snyk et SPDX

Bien que SPDX existe depuis plusieurs années comme norme SBOM, les travaux récents sur le projet de spécification 3.0 sont très prometteurs. Nous avons étudié de près le projet de profil de vulnérabilité pour SPDX, qui permet d’ajouter des données sur les vulnérabilités (parfois désignées dans le domaine des SBOM par le terme VEX, ou exploitabilité des vulnérabilités) aux informations sur les composants logiciels.

Pour contribuer à la validation de la spécification, nous avons créé un outil simple appelé snyk2spdx. snyk2spdx a un objectif unique : il récupère les données de test sous-jacentes de Snyk (qui incluent les informations de la SBOM) et les exporte au format SPDX 3.0, avec le profil de vulnérabilité. Voici un exemple de son résultat.

1$ snyk test --json | npx snyk2spdx | jq
2{
3  "id": "SPDXRef-todo-list",
4  "name": "todo-list",
5  "specVersion": "SPDX-3.0",
6  "profile": [
7    "base",
8    "vulnerabilities"
9  ],
10  "dataLicense": "CC0-1.0",
11  "creator": "Organization: Snyk Ltd",
12  "documentNamespace": "spdx.org/spdxdocs/todo-list-2bd968c5-d497-41ec-83d7-5ee652720c53",
13  "description": "Snyk test result for project todo-list in SPDX SBOM format",
14  "created": "2021-05-05T16:20:28Z",
15  "vulnerabilities": [
16

Il ne s’agit ici que de l’en-tête. Voici un lien vers la SBOM complète générée pour celles et ceux qui souhaitent découvrir le format plus en détail.

Nous avons créé cet outil pour mener nos expérimentations et faire part de nos commentaires sur le projet de spécification actuel. SPDX 3.0 évolue encore et n’est pas encore largement pris en charge par les outils ni accompagné de schémas publiés. Ces éléments finiront sans aucun doute par arriver et, le moment venu, nous intégrerons probablement ce type de fonctionnalité au cœur de l’interface de ligne de commande Snyk, et prendrons en charge SPDX dans d’autres parties de Snyk.

Si les SBOM en général, et VEX en particulier, vous intéressent, snyk2spdx peut vous aider à vous lancer. Vous pourriez même décider de contribuer aux travaux sur la spécification, ou à l’effort plus vaste de sensibilisation et de création d’outils logiciels autour de celle-ci.

L’avenir

À mesure que SPDX gagne en visibilité, Snyk travaille en étroite collaboration avec la Linux Foundation pour améliorer la norme et développer l’écosystème d’outils. Ce récent article de blog de la Linux Foundation explique pourquoi et comment la communauté open source a identifié, il y a plus de dix ans, la nécessité de relever le défi des SBOM.

Au bon moment et au bon endroit, les normes peuvent faire progresser des secteurs entiers. Le décret Biden souligne clairement le rôle essentiel des SBOM pour renforcer la sécurité de la chaîne d’approvisionnement logicielle. Chez Snyk, nous sommes impatients de continuer à contribuer aux initiatives dans ce domaine.