Une nomenclature logicielle (SBOM) devient de plus en plus importante dans la chaîne d’approvisionnement logicielle. Dans ce blog, vous apprendrez ce qu’est un SBOM et comment construire le SBOM de manière automatisée. Apprécier!
1. Introduction
Un SBOM est une liste de composants logiciels qui composent un produit logiciel. De cette façon, il devient transparent quelles bibliothèques logicielles, composants, etc., et leurs versions sont utilisées dans le produit logiciel. En conséquence, vous serez en mesure de réagir plus adéquatement lorsqu’une faille de sécurité est signalée. Il vous suffit de vérifier les SBOM de la bibliothèque vulnérable et vous saurez immédiatement quelles applications sont affectées par la vulnérabilité. Le SBOM d’une bibliothèque ou d’une application que vous souhaitez utiliser peut également vous aider dans votre prise de décision. Il deviendra de plus en plus courant que les fournisseurs de logiciels seront obligés de fournir un SBOM à jour avec chaque livraison de logiciel. Sur la base de ces informations, vous pouvez effectuer une évaluation des risques pour savoir si vous souhaitez utiliser la bibliothèque ou l’application.
Lorsque vous êtes un fournisseur de logiciels, vous devez vous assurer que vous fournissez un SBOM avec chaque version de logiciel. Cela signifie en fait que vous devez créer le SBOM de manière automatisée, de préférence dans votre pipeline de build. Comme écrit précédemment, le SBOM peut vous aider à vérifier si une bibliothèque utilisée dans votre application contient des failles de sécurité. Avec l’outillage approprié, cette vérification peut être effectuée de manière automatisée dans votre pipeline de build. Lorsque des failles de sécurité sont détectées, vous pouvez faire échouer le pipeline de build. L’un de ces outils est grype, qui peut prendre un SBOM en entrée et vérifier si des composants sont utilisés avec des vulnérabilités de sécurité connues. Dans un post précédent, il est expliqué comment grype peut être utilisé. Dans le message, une image Docker est entrée pour grype, mais il est encore mieux de créer d’abord un SBOM, puis de le fournir à grype. Comment créer le SBOM sera expliqué dans ce post.
Lorsque vous commencerez à lire sur les SBOM, vous remarquerez que deux normes sont couramment utilisées :
- CycloneDX : un projet open-source né au sein de la communauté OWASP ;
- SPDX (The Software Package Data Exchange) : format standard ouvert international, également open source et hébergé par la fondation Linux.
Alors, quelle norme utiliser ? C’est une question difficile à répondre. En règle générale, il est indiqué que les deux normes continueront d’exister l’une à côté de l’autre et il est conseillé d’utiliser des outils pour prendre en charge les deux normes. SPDX est initialement configuré pour la gestion des licences, tandis que CycloneDX se concentrait principalement sur la sécurité. En lisant plusieurs ressources, le format préféré est CycloneDX lorsque vous vous concentrez sur la sécurité. Les lectures intéressantes sont les formats SBOM SPDX et CycloneDX comparés et la publication Using the Software Bill of Materials for Enhancing Cybersecurity du National Cyber Security Center du ministère de la Justice et de la Sécurité des Pays-Bas. Ce dernier est une lecture incontournable.
Dans le reste de ce blog, vous apprendrez à utiliser syft pour créer un SBOM. Syft est également un produit d’Anchore, tout comme grype, et s’intègre donc bien avec grype, l’outil d’analyse des vulnérabilités. Syft prend en charge de nombreux écosystèmes et dispose de plusieurs formats d’exportation. Il prend définitivement en charge CycloneDX et SPDX. CycloneDX dispose également d’outils pour créer des SBOM, mais Syft est un outil qui prend en charge de nombreux écosystèmes, ce qui est un avantage par rapport à plusieurs outils.
Les sources utilisées dans cet article sont disponibles sur GitHub.
2. Prérequis
Les prérequis nécessaires pour ce blog sont :
- Connaissance de base de Linux ;
- Connaissance de base de Java ;
- Connaissance de base de JavaScript ;
- Connaissance de base de Spring Boot.
3. Application en cours de test
Avant de continuer, vous avez besoin d’une application pour construire le SBOM. Il s’agit d’une application de base composée d’un backend Spring Boot et d’un frontend Vue.js. L’application peut être construite avec Maven et contient deux modules Maven, un pour le backend et un pour le frontend. Plus d’informations sur la configuration peuvent être lues dans un article précédent. Il est toutefois important de commencer par créer l’application. Cela peut être fait avec la commande suivante :
4. Mise en place
L’installation de syft peut se faire en exécutant le script suivant :
$ curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sudo sh -s -- -b /usr/local/binVérifiez l’installation en exécutant la commande suivante :
$ syft --version
syft 0.64.05. Construire le SBOM principal
Accédez au répertoire backend et exécutez la commande suivante :
$ syft dir:. --exclude ./**/sbom.*.json --output cyclonedx-json=sbom.cyclonedx.build-complete-dir.jsonLes paramètres feront ce qui suit :
- rép :.: Analysez tout le répertoire afin de trouver les dépendances ;
- -exclure: exclure les fichiers SBOM déjà présents car vous souhaitez générer le fichier SBOM à chaque fois en fonction de l’état actuel du référentiel ;
- -sortir: Ici, vous définissez le format de sortie à utiliser, et vous définissez le nom de fichier du fichier SBOM.
Le fichier SBOM sbom.cyclonedx.build-complete-dir.json est créé dans le répertoire backend. Examinez de plus près le format SBOM.
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:afbe7b48-b376-40fb-a0d4-6a16fda38a0f",
"version": 1,
"metadata": {
"timestamp": "2023-01-14T16:35:35+01:00",
"tools": [
{
"vendor": "anchore",
"name": "syft",
"version": "0.64.0"
}
],
"component": {
"bom-ref": "af63bd4c8601b7f1",
"type": "file",
"name": "."
}
},
"components": [
...
]
}La partie supérieure se compose de métadonnées : le format du SBOM, les versions utilisées, quel outil est utilisé, etc. La partie composant consiste en une liste de tous les composants que syft a trouvés. La spécification complète de CycloneDX peut être trouvée ici.
La liste des composants est la suivante et correspond à la liste des bibliothèques que l’on peut trouver dans le target/backend-0.0.1-SNAPSHOT.jar déposer. Les bibliothèques se trouvent dans le répertoire /BOOT-INF/lib/ dans le fichier jar (le fichier jar est juste un fichier zip et peut être ouvert avec n’importe quel outil d’archivage).
backend
jackson-annotations
jackson-core
jackson-databind
jackson-datatype-jdk8
jackson-datatype-jsr310
jackson-module-parameter-names
jakarta.annotation-api
jul-to-slf4j
log4j-api
log4j-to-slf4j
logback-classic
logback-core
micrometer-commons
micrometer-observation
slf4j-api
snakeyaml
spring-aop
spring-beans
spring-boot
spring-boot-autoconfigure
spring-boot-jarmode-layertools
spring-boot-starter-test
spring-boot-starter-web
spring-context
spring-core
spring-expression
spring-jcl
spring-web
spring-webmvc
tomcat-embed-core
tomcat-embed-el
tomcat-embed-websocketMaintenant, regardez de plus près le jackson-annotations composant dans le fichier SBOM. Dans le propriétés section, vous pouvez voir que ce composant a une propriété syft:package:foundBy avec la valeur java-cataloger. Cela signifie que ce composant a été trouvé dans le fichier jar.
{
"bom-ref": "pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.14.1?package-id=9cdc3a1e17ebbb68",
"type": "library",
"group": "com.fasterxml.jackson.core",
"name": "jackson-annotations",
"version": "2.14.1",
"cpe": "cpe:2.3:a:jackson-annotations:jackson-annotations:2.14.1:*:*:*:*:*:*:*",
"purl": "pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.14.1",
"externalReferences": [
{
"url": "",
"hashes": [
{
"alg": "SHA-1",
"content": "2a6ad504d591a7903ffdec76b5b7252819a2d162"
}
],
"type": "build-meta"
}
],
"properties": [
{
"name": "syft:package:foundBy",
"value": "java-cataloger"
},
{
"name": "syft:package:language",
"value": "java"
},
{
"name": "syft:package:metadataType",
"value": "JavaMetadata"
},
{
"name": "syft:package:type",
"value": "java-archive"
},
...
]
}Lorsque vous examinez le composant spring-boot-starter-webil mentionne que ce composant a été trouvé par java-pom-cataloger. Cela signifie que ce composant a été trouvé dans le fichier pom.
Ceci est assez intéressant car cela signifierait que syft ne peut pas trouver de dépendances transitives basées uniquement sur les sources. Exécutez la commande suivante où le target répertoire est exclu de l’analyse.
$ syft dir:. --exclude ./**/sbom.*.json --exclude ./**/target --output cyclonedx-json=sbom.cyclonedx.build-sources.jsonLe résultat se trouve dans le fichier sbom.cyclonedx.build-sources.json et l’hypothèse faite précédemment semble être la bonne. Seulement le spring-boot-starter-web et spring-boot-starter-test des dépendances sont trouvées. Ce n’est, après tout, pas un gros problème, mais vous devez en être conscient.
6. Créer un SBOM frontal
Accédez au répertoire frontend et exécutez la commande suivante :
$ syft dir:. --exclude ./**/sbom.*.json --output cyclonedx-json=sbom.cyclonedx.build-complete-dir.jsonCette analyse prend un peu plus de temps que l’analyse backend, mais après quelques secondes, le sbom.cyclonedx.build-complete-dir.json fichier est créé. Encore une fois, des informations similaires peuvent être trouvées dans le SBOM. L’information est maintenant disponible auprès du javascript-lock-cataloger. Cela signifie qu’il provient de la package-lock.json déposer.
Une autre différence est que les composants contiennent également des informations de licence.
"components": [
{
"bom-ref": "pkg:npm/%40babel/parser@7.20.7?package-id=ca6a526d8a318088",
"type": "library",
"name": "@babel/parser",
"version": "7.20.7",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
...Les informations de licence sont incluses et peuvent être utilisées pour vérifier les politiques d’entreprise autorisées. Ces informations ne sont toutefois pas encore disponibles pour les packages Java.
7. Conclusion
SBOM…