Réduisez les risques liés à votre chaîne d’approvisionnement grâce à une nomenclature logicielle (SBOM)

Aujourd’hui, nous sommes ravis de lancer plusieurs nouvelles fonctionnalités dans le cadre de nos efforts continus pour notre solution de sécurité de la chaîne d’approvisionnement logicielle. Ces outils conçus pour les développeurs vous aident à mieux comprendre la chaîne d’approvisionnement de vos applications, à repérer les risques potentiels et à prendre les mesures nécessaires pour les anticiper.

L’essor des SBOM, un élément clé de la sécurité de la chaîne d’approvisionnement

Les applications modernes sont davantage assemblées que développées, et les logiciels libres et open source représentent plus de 70 % des logiciels actuels. L’utilisation de composants open source dans vos applications peut accélérer leur mise sur le marché, mais elle peut aussi complexifier votre chaîne d’approvisionnement et y introduire des risques.

En réponse aux récentes recommandations réglementaires destinées à aider les organisations à se protéger, de nombreuses équipes intègrent désormais la création de nomenclatures logicielles (SBOM) à leur cycle de développement logiciel (SDLC).

Pour rappel, une SBOM est un inventaire des composants qui constituent votre application, ainsi que de leurs dépendances. On peut la comparer à la « nomenclature » utilisée dans l’industrie manufacturière, qui informe les acheteurs des pièces entrant dans la composition d’un produit. Les formats normalisés de SBOM, comme CycloneDX et SPDX, permettent de rendre cet inventaire à la fois lisible par les humains et exploitable par les outils en aval.

Pour les équipes AppSec, cette visibilité sur la composition des applications à l’échelle de l’entreprise est essentielle pour comprendre et atténuer les risques d’attaques visant la chaîne d’approvisionnement, tout en respectant les exigences réglementaires.

Mais comment adopter ces pratiques ? Et quel est leur impact sur les workflows des développeurs ?

Par le passé, l’amélioration de la posture de sécurité pouvait ralentir les équipes de développement. Pourtant, nous sommes convaincus que les développeurs ne devraient pas avoir à choisir entre innovation et sécurité. Snyk facilite la création de SBOM pour vos applications et vous donne de la visibilité sur leurs briques (par exemple, les composants open source, les bibliothèques et les frameworks) et leurs interactions.

Désormais disponible en version générale (GA), Snyk fournit des outils CLI conçus pour les développeurs, qui permettent de générer des SBOM SPDX ou CycloneDX en local ou depuis vos pipelines CI/CD.

snyk sbom --format spdx2.3+json --all-projects

Grâce à l’API Project SBOM, également disponible en version générale (GA), vous pouvez générer une SBOM pour tout projet open source ou de conteneur importé dans Snyk, à partir d’un seul endpoint d’API.

Exemple de package dans une SBOM

1{
2"bom-ref": "35-curl@7.52.1-5",
3"type": "library",
4"name": "curl",
5"version": "7.52.1-5",
6"purl": "pkg:deb/debian/curl@7.52.1-5?distro=stretch"
7}

Utiliser les SBOM pour repérer les risques et agir

La création d’une SBOM est une étape importante pour gagner en visibilité et rester conforme, mais elle ne représente qu’une partie de la solution. Les artefacts SBOM ne fournissent souvent pas d’informations exploitables aux utilisateurs en aval.

En tant que développeur ou professionnel AppSec, vous devez également tester les SBOM et leur contenu afin de repérer les problèmes potentiels et d’agir plus rapidement. À mesure que la génération de SBOM se généralise dans votre organisation et que vous commencez à en recevoir de la part de fournisseurs (par exemple, des solutions SaaS), vous devrez probablement tester différents formats créés avec différents outils.

Vous souhaiterez peut-être même mettre en place une plateforme pour gérer ces opérations au sein de toutes les équipes de votre entreprise.

Au début du troisième trimestre, nous lancerons la version bêta de notre fonctionnalité de test des SBOM. Cette API vous permettra d’analyser et de tester les SBOM CycloneDX et SPDX afin d’y détecter les vulnérabilités connues et les problèmes de licence dans notre base de données de vulnérabilités de référence.

Avec l’API Package Issues, désormais disponible en version générale (GA), vous pouvez rechercher les vulnérabilités au niveau des packages à partir de leur URL (purl), avec une prise en charge de divers écosystèmes de langages de programmation et de systèmes d’exploitation. Cette API granulaire de bas niveau offre aux équipes la flexibilité nécessaire pour adapter les tests à leurs besoins.

Exemple de recherche de problèmes associés à un package

Vous pouvez rechercher un package unique à l’aide d’une requête GET et d’une purl encodée dans l’URL :

https://api.snyk.io/rest/orgs/{{orgId}}/packages/pkg%3Adeb%2Fdebian%2Fcurl%407.52.1-5%3Fdistro%3Dstretch/issues?version=2023-05-10

Exemple de vulnérabilité renvoyée (extrait)

1...
2"id": "SNYK-DEBIAN9-CURL-2936242",
3"type": "issue",
4"attributes": {
5"key": "SNYK-DEBIAN9-CURL-2936242",
6"title": "Out-of-bounds Write",
7"type": "package_vulnerability",
8"created_at": "2022-06-28T02:25:54.487787Z",
9"updated_at": "2023-02-14T13:32:10.421029Z",
10"description": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `curl` package and not the `curl` package as distributed by `Debian:9`._\n_See `How to fix?` for `Debian:9` relevant fixed versions and status._\n\nWhen curl < 7.84.0 does FTP transfers secured by krb5, it handles message verification failures wrongly. This flaw makes it possible for a Man-In-The-Middle attack to go unnoticed 
11...

Accroître la valeur des SBOM

La transparence sur la composition d’une application est précieuse en soi, mais les artefacts SBOM ne contiennent généralement qu’un ensemble limité d’informations.

Ces informations peuvent servir telles quelles de données d’entrée pour les tests de vulnérabilités, mais elles restent insuffisantes : les utilisateurs des artefacts doivent toujours exploiter la SBOM pour obtenir les informations dont ils ont besoin.

Puisque nous pouvons créer des SBOM et les tester, ainsi que leurs composants, pourquoi ne pas intégrer ces informations à l’artefact dès le départ ? Avec Parlay, notre dernière contribution à la communauté open source, nous voulons précisément résoudre ce problème.

Les principaux formats (CycloneDX et SPDX) permettent déjà d’étendre leurs schémas, ce qui permet d’enrichir une SBOM avec des métadonnées supplémentaires, comme les vulnérabilités et la provenance du code source.

C’est un avantage considérable pour les utilisateurs en aval, comme les équipes AppSec, qui reçoivent un instantané de la composition d’une application à un moment donné, accompagné de données détaillées pour automatiser les actions ou éclairer leurs décisions.

Consultez cet article de blog pour en savoir plus sur les possibilités offertes par ce projet, et regardez l’enregistrement à la demande de SnykLaunch pour découvrir tout ce que vous avez manqué.