Comment transférer un SBOM vers Dependency Track SaaS ?

Les conteneurs sont la norme pour exécuter des applications serveur de nos jours, aussi vous avez probablement de très nombreux SBOM à transférer vers Dependency Track SaaS. Heureusement, l’extraction de logiciels pacakagés sous forme de conteneurs ou de conteneurs Docker est à la fois rapide et très facile.

Dans l’exemple ci-dessous, nous illustrerons la génération de SBOM à partir d’une image Docker et son transfert vers Dependency Track SaaS. Pour générer le SBOM à partir de n’importe quel logiciel, utilisez l’une des approches décrites dans cette fiche de triche.

Transfert d’un SBOM Docker

Afin d’automatiser le transfert, nous devons associer le fichier SBOM à un projet dans Dependency Track. Il existe pour cela plusieurs méthodes, y compris la création automatique d’un nouveau projet.

Dans le scénario le plus probable, nous supposerons que vous avez déjà un projet dans Dependency Track et que vous souhaitez mettre à jour sa liste de composants. Pour cela, le plus simple est de lier le SBOM avec l’UUID du projet de Dependency Track.

Le script ci-dessous extraira le SBOM à partir d’un registre Docker local et le transférera vers votre instance Dependency Track. Vous pouvez le lancer avec la commande extract-sbom.sh alpine:latest 29cd2fb7-db8c-4513-8c6c-ffb4443be67f. L’UUID du projet Dependency Track à utiliser se trouve dans l’identifiant d’objet des détails du projet.

De toute évidence, vous devriez modifier le script et remplacer votre <YourPrefixDomain> et <YourApiKey> aux lignes 9 et 10 par les valeurs que vous avez reçues lors de votre commande de notre service SaaS.

#!/bin/bash

if [ "$#" -ne 2 ]; then
  echo "$0 <dockerImage> <depTrackProjectUuid>"
  exit -1
fi

# REPLACER ICI-------------------------
prefixDomain=<YourPrefixDomain>
apiKey=<YourApiKey>
# FIN DU REMPLACEMENT------------------

SCRIPT_PATH=$(dirname -- "$(readlink -f "${BASH_SOURCE}")")
project="$2"
sbom="$(uuidgen).sbom"

echo -n "Extracting SBOM..." 
 && $SCRIPT_PATH/syft.sh scan "registry:$1" -o cyclonedx-json > $sbom 
 && echo -ne " done\nSending SBOM..." 
 && curl -X POST -H "X-API-Key: $apiKey" 
         -H 'Content-Type: multipart/form-data; boundary=__X_BOM__' 
         -F "bom=@$sbom" 
         -F "project=$project" 
         "https://$companyPrefix.deptrack.yoursky.blue/api/v1/bom" 
 && echo -e " sent\n\nCleaning..." 
 && rm $sbom

Le script ci-dessus n’utilise pas la commande expérimentale docker sbom mais notre script syft.sh qui fait la même chose de manière beaucoup plus durable.

Plugins CI/CD

Dans votre CI/CD, vous pouvez facilement réutiliser la partie de transfert curl du script ci-dessus. Le transfert du SBOM peut même être encore simplifié avec l’un des plugins open-source suivants:

• Azure pipelines
• GitHub Action
• Jenkins
• dtrack-audit un assistant générique de transfert et d'audit écrit en Go, avec une compatibilité spéciale pour TeamCity CI

De plus, les plugins suivants peuvent être utiles pour d’autres scénarios d’automatisation, par exemple pour mettre en œuvre des politiques basées sur l’analyse des vulnérabilités :

• dtapac audite les résultats de Dependency Track et les violations via des policy en tant que code
• DTrackAuditor pour faire échouer la build CI selon la gravité des vulnérabilités ou des violations détectées

Autres scénarios possibles

Avec l’exemple de Docker SBOM présenté ci-dessus, nous avons à peine effleuré la surface, de très nombreux autres scénarios d’automatisation sont possibles. Utiliser cette page comme modèle pour faciliter vos recherches. Avec quelques adaptations, vous pouvez générer le SBOM à partir d’autres sources comme décrit dans la fiche de triche.

D’autres options de transfert sont possibles, veuillez vous référer à notre documentation API.