Dependency-Track : centraliser la gestion des SBOM

Dependency-Track est une plateforme open-source qui centralise l’analyse des vulnérabilités de tous vos projets. Vous uploadez des SBOM (Software Bill of Materials), et Dependency-Track les corrèle automatiquement avec les bases de vulnérabilités (NVD, GitHub Advisories, OSS Index). Contrairement aux scanners ponctuels, il surveille en continu : une vulnérabilité découverte demain sur une dépendance présente dans 50 projets vous alertera automatiquement.

Ce guide couvre l’installation (Docker, Kubernetes), la configuration des sources de vulnérabilités, l’API REST, l’intégration CI/CD et les alertes (Slack, Teams, email).

Ce que vous allez apprendre

Comprendre le rôle d’un SBOM et pourquoi centraliser leur analyse
Installer Dependency-Track avec Docker Compose ou Kubernetes
Configurer les sources de vulnérabilités (NVD, GitHub Advisories, OSS Index)
Uploader des SBOM via l’API REST et automatiser dans vos pipelines CI/CD
Créer des alertes pour être notifié des nouvelles vulnérabilités
Définir des politiques pour bloquer les composants non conformes

Pourquoi centraliser la gestion des SBOM ?

Vous utilisez peut-être déjà Trivy ou Grype pour scanner vos images. Ces outils sont excellents pour détecter les vulnérabilités à un instant T. Mais que se passe-t-il quand :

Une nouvelle CVE est publiée pour Log4j, et vous ne savez pas quels projets l’utilisent ?
Vous devez prouver à un auditeur que vous avez corrigé une vulnérabilité sur tous vos projets ?
Votre équipe sécurité veut un tableau de bord de toutes les vulnérabilités de l’entreprise ?

Dependency-Track résout ces problèmes en centralisant les SBOM de tous vos projets et en les corrélant en continu avec les bases de vulnérabilités.

Approche	Scanner ponctuel (Trivy, Grype)	Dependency-Track
Quand ?	À chaque build/scan	En continu (24/7)
Scope	1 projet à la fois	Tous les projets
Nouvelles CVE	Détectées au prochain scan	Alertes immédiates
Vue d’ensemble	Non	Tableau de bord global
Historique	Non	Oui, avec métriques dans le temps

Concepts clés

SBOM (Software Bill of Materials)

Un SBOM est la liste complète des composants qui constituent votre logiciel. Comme la liste d’ingrédients sur un emballage alimentaire, il permet de savoir exactement ce que contient votre application.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21"
    },
    {
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2"
    }
  ]
}

Formats supportés par Dependency-Track :

Format	Description	Outils générateurs
CycloneDX	Standard OWASP, recommandé	Trivy, Syft, cdxgen
SPDX	Standard Linux Foundation	Syft, tern

PURL (Package URL)

Le PURL (Package URL) est un identifiant universel pour les packages. Il permet à Dependency-Track de retrouver un composant dans les bases de vulnérabilités.

pkg:npm/lodash@4.17.21
pkg:maven/org.apache.logging.log4j/log4j-core@2.17.0
pkg:apk/alpine/openssl@3.0.8-r0
pkg:deb/debian/openssl@1.1.1n-0+deb10u3

Sources de vulnérabilités

Dependency-Track consulte plusieurs bases de données pour détecter les vulnérabilités :

Source	Description	Configuration
NVD	National Vulnerability Database (NIST)	Activée par défaut, API key recommandée
GitHub Advisories	Vulnérabilités GitHub	Token GitHub requis
OSS Index	Sonatype, gratuit	Activée par défaut
OSV	Open Source Vulnerabilities (Google)	Optionnelle
Snyk	Base commerciale	Token Snyk requis
VulnDB	Base commerciale (Risk Based Security)	Abonnement requis

Analyseurs intégrés

En plus des bases de vulnérabilités, Dependency-Track utilise des analyseurs pour enrichir les données :

Analyseur	Fonction
Internal Analyzer	Corrèle les composants avec la base interne
NPM Audit	Vulnérabilités npm spécifiques
OSS Index	Analyse via API Sonatype
Trivy	Intégration avec un serveur Trivy (v4.13+)
Snyk	Analyse via API Snyk

Installation

Prérequis

Docker et Docker Compose (méthode recommandée)
4 Go de RAM minimum (8 Go recommandés pour la production)
PostgreSQL (H2 déprécié depuis v4.13)

Installation avec Docker Compose

Créer le fichier docker-compose.yml

services:
  dtrack-apiserver:
    image: dependencytrack/apiserver:4.13.6
    depends_on:
      - postgres
    environment:
      # Base de données PostgreSQL
      - ALPINE_DATABASE_MODE=external
      - ALPINE_DATABASE_URL=jdbc:postgresql://postgres:5432/dtrack
      - ALPINE_DATABASE_DRIVER=org.postgresql.Driver
      - ALPINE_DATABASE_USERNAME=dtrack
      - ALPINE_DATABASE_PASSWORD=dtrack
      # Synchronisation initiale (optionnel, améliore le démarrage)
      - ALPINE_DATABASE_POOL_ENABLED=true
      - ALPINE_DATABASE_POOL_MAX_SIZE=20
    volumes:
      - dtrack-data:/data
    ports:
      - "8081:8080"
    restart: unless-stopped

  dtrack-frontend:
    image: dependencytrack/frontend:4.13.6
    depends_on:
      - dtrack-apiserver
    environment:
      - API_BASE_URL=http://localhost:8081
    ports:
      - "8080:8080"
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=dtrack
      - POSTGRES_USER=dtrack
      - POSTGRES_PASSWORD=dtrack
    volumes:
      - postgres-data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  dtrack-data:
  postgres-data:

Démarrer les services

docker compose up -d

Sortie attendue :

[+] Running 4/4
 ✔ Network dependency-track_default  Created
 ✔ Container postgres                Started
 ✔ Container dtrack-apiserver        Started
 ✔ Container dtrack-frontend         Started

Vérifier le démarrage

# Attendre que l'API soit prête (30-60 secondes)
curl -s http://localhost:8081/api/version | jq .

Sortie attendue :

{
  "version": "4.13.6",
  "timestamp": "2025-11-17T08:44:22Z",
  "framework": {
    "name": "Alpine",
    "version": "3.4.0"
  },
  "database": {
    "productVersion": "16.11",
    "productName": "PostgreSQL"
  }
}

Accéder à l’interface

Ouvrez http://localhost:8080 dans votre navigateur.
- Identifiant : admin
- Mot de passe : admin (à changer immédiatement)

Installation avec Kubernetes (Helm)

Pour un déploiement Kubernetes, utilisez le chart Helm officiel :

# Ajouter le repository
helm repo add dependencytrack https://dependencytrack.github.io/helm-charts
helm repo update

# Installer avec PostgreSQL externe
helm install dependency-track dependencytrack/dependency-track \
  --namespace dependency-track \
  --create-namespace \
  --set apiserver.database.url=jdbc:postgresql://postgres:5432/dtrack \
  --set apiserver.database.username=dtrack \
  --set apiserver.database.password=dtrack \
  --set frontend.env.API_BASE_URL=https://dtrack.example.com/api

Configuration initiale

Changer le mot de passe admin

Se connecter à l’interface avec admin / admin
Aller dans Administration → Access Management → Managed Users
Cliquer sur admin puis Change Password

Ou via l’API :

# Obtenir un token (vous serez forcé de changer le mot de passe)
curl -X POST "http://localhost:8081/api/v1/user/login" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d 'username=admin&password=admin'

# Réponse si changement requis
# FORCE_PASSWORD_CHANGE

# Changer le mot de passe
curl -X POST "http://localhost:8081/api/v1/user/forceChangePassword" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d 'username=admin&password=admin&newPassword=VotreNouveauMotDePasse123&confirmPassword=VotreNouveauMotDePasse123'

Configurer les sources de vulnérabilités

Par défaut, seules NVD et OSS Index sont activées. Pour de meilleurs résultats, configurez des sources supplémentaires.

La synchronisation NVD initiale prend plusieurs heures sans clé API. Avec une clé API gratuite, elle prend environ 30 minutes.

Obtenir une clé API NVD : https://nvd.nist.gov/developers/request-an-api-key
Configurer dans Administration → Analyzers → National Vulnerability Database
Coller votre clé API

# Via variables d'environnement dans docker-compose.yml
environment:
  - ALPINE_VULNERABILITY_SOURCE_NVD_API_KEY=votre-cle-api-nvd

GitHub Advisories est excellent pour les vulnérabilités des écosystèmes npm, PyPI, Maven, etc.

Créer un token GitHub avec le scope read:packages
Configurer dans Administration → Analyzers → GitHub Advisories
Activer et coller le token

Créer une équipe et un API key

Pour intégrer Dependency-Track dans vos pipelines CI/CD, vous avez besoin d’un API key avec les bonnes permissions.

Créer une équipe

# S'authentifier
TOKEN=$(curl -s -X POST "http://localhost:8081/api/v1/user/login" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d 'username=admin&password=VotreMotDePasse' )

# Créer l'équipe
curl -s -X PUT "http://localhost:8081/api/v1/team" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"name":"CI-CD-Integration"}' | jq .

Sortie :

{
  "uuid": "ec9f8bc4-8953-4c57-beed-62fb189960ec",
  "name": "CI-CD-Integration",
  "apiKeys": [],
  "permissions": []
}

Ajouter les permissions

TEAM_UUID="ec9f8bc4-8953-4c57-beed-62fb189960ec"

# Permissions nécessaires pour le CI/CD
for PERM in BOM_UPLOAD PROJECT_CREATION_UPLOAD VIEW_VULNERABILITY; do
  curl -s -X POST "http://localhost:8081/api/v1/permission/${PERM}/team/${TEAM_UUID}" \
       -H "Authorization: Bearer $TOKEN"
done

Générer un API key

curl -s -X PUT "http://localhost:8081/api/v1/team/${TEAM_UUID}/key" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" | jq -r '.key'

Sortie :

odt_2d7FSPVR_wypkOzMckIbjsNkUcahyYA5XqrqhYPOr

Permissions disponibles

Permission	Description
`BOM_UPLOAD`	Uploader des SBOM
`PROJECT_CREATION_UPLOAD`	Créer des projets automatiquement lors de l’upload
`VIEW_VULNERABILITY`	Voir les vulnérabilités
`VULNERABILITY_ANALYSIS`	Modifier l’analyse des vulnérabilités
`PORTFOLIO_MANAGEMENT`	Gérer les projets et composants
`POLICY_MANAGEMENT`	Gérer les politiques
`SYSTEM_CONFIGURATION`	Configuration système

Uploader un SBOM

Générer un SBOM avec Trivy

# Scanner une image Docker
trivy image --format cyclonedx nginx:1.25 > nginx-sbom.json

# Scanner un projet local
trivy fs --format cyclonedx . > project-sbom.json

# Scanner avec les vulnérabilités incluses
trivy image --format cyclonedx --scanners vuln python:3.12 > python-sbom.json

Générer un SBOM avec Syft

# Scanner une image
syft nginx:1.25 -o cyclonedx-json > nginx-sbom.json

# Scanner un répertoire
syft dir:. -o cyclonedx-json > project-sbom.json

API_KEY="odt_votre_api_key"
BOM_BASE64=$(base64 -w 0 nginx-sbom.json)

curl -X PUT "http://localhost:8081/api/v1/bom" \
     -H "X-Api-Key: $API_KEY" \
     -H "Content-Type: application/json" \
     -d "{
       \"projectName\": \"nginx\",
       \"projectVersion\": \"1.25\",
       \"autoCreate\": true,
       \"bom\": \"$BOM_BASE64\"
     }"

Sortie :

{
  "token": "9f4c18b6-e20c-44e6-8710-f332a53a6275"
}

Pour les fichiers > 100 KB, utilisez la méthode multipart :

API_KEY="odt_votre_api_key"

curl -X POST "http://localhost:8081/api/v1/bom" \
     -H "X-Api-Key: $API_KEY" \
     -F "autoCreate=true" \
     -F "projectName=mon-projet" \
     -F "projectVersion=1.0.0" \
     -F "bom=@mon-sbom.json"

Vérifier le traitement

L’upload est asynchrone. Utilisez le token pour vérifier le statut :

curl -s "http://localhost:8081/api/v1/bom/token/9f4c18b6-e20c-44e6-8710-f332a53a6275" \
     -H "X-Api-Key: $API_KEY" | jq .

Sortie pendant le traitement :

{
  "processing": true
}

Sortie après traitement :

{
  "processing": false
}

Consulter les résultats

Lister les projets

curl -s "http://localhost:8081/api/v1/project" \
     -H "X-Api-Key: $API_KEY" | jq '.[] | {name, version, metrics}'

Sortie :

{
  "name": "nginx",
  "version": "1.25",
  "metrics": {
    "critical": 2,
    "high": 5,
    "medium": 12,
    "low": 3,
    "components": 45,
    "vulnerableComponents": 8
  }
}

Lister les vulnérabilités d’un projet

PROJECT_UUID="fe281b4c-347c-45ed-9911-b2bc26245fc1"

curl -s "http://localhost:8081/api/v1/vulnerability/project/${PROJECT_UUID}" \
     -H "X-Api-Key: $API_KEY" | jq '.[] | {vulnId, severity, source, cvssV3BaseScore}'

Sortie :

{
  "vulnId": "CVE-2024-12345",
  "severity": "CRITICAL",
  "source": "NVD",
  "cvssV3BaseScore": 9.8
}

Métriques du portfolio

curl -s "http://localhost:8081/api/v1/metrics/portfolio/current" \
     -H "X-Api-Key: $API_KEY" | jq '{projects, vulnerableProjects, critical, high, medium, low}'

Sortie :

{
  "projects": 15,
  "vulnerableProjects": 8,
  "critical": 12,
  "high": 45,
  "medium": 128,
  "low": 67
}

Intégration CI/CD

GitLab CI

stages:
  - build
  - security

variables:
  DTRACK_URL: "https://dependency-track.example.com"
  DTRACK_API_KEY: $DTRACK_API_KEY  # Secret CI/CD

generate_sbom:
  stage: build
  image: aquasec/trivy:latest
  script:
    - trivy fs --format cyclonedx --output sbom.json .
  artifacts:
    paths:
      - sbom.json
    expire_in: 1 week

upload_sbom:
  stage: security
  image: curlimages/curl:latest
  needs:
    - generate_sbom
  script:
    - |
      BOM_BASE64=$(base64 -w 0 sbom.json)
      curl -X PUT "${DTRACK_URL}/api/v1/bom" \
           -H "X-Api-Key: ${DTRACK_API_KEY}" \
           -H "Content-Type: application/json" \
           -d "{
             \"projectName\": \"${CI_PROJECT_NAME}\",
             \"projectVersion\": \"${CI_COMMIT_REF_NAME}\",
             \"autoCreate\": true,
             \"bom\": \"${BOM_BASE64}\"
           }"

GitHub Actions

name: SBOM Upload

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.json

      - name: Upload to Dependency-Track
        run: |
          BOM_BASE64=$(base64 -w 0 sbom.json)
          curl -X PUT "${{ secrets.DTRACK_URL }}/api/v1/bom" \
               -H "X-Api-Key: ${{ secrets.DTRACK_API_KEY }}" \
               -H "Content-Type: application/json" \
               -d "{
                 \"projectName\": \"${{ github.repository }}\",
                 \"projectVersion\": \"${{ github.ref_name }}\",
                 \"autoCreate\": true,
                 \"bom\": \"${BOM_BASE64}\"
               }"

Jenkins

// Jenkinsfile
pipeline {
    agent any

    environment {
        DTRACK_URL = 'https://dependency-track.example.com'
        DTRACK_API_KEY = credentials('dtrack-api-key')
    }

    stages {
        stage('Generate SBOM') {
            steps {
                sh 'docker run --rm -v $(pwd):/app aquasec/trivy fs --format cyclonedx /app > sbom.json'
            }
        }

        stage('Upload SBOM') {
            steps {
                sh '''
                    BOM_BASE64=$(base64 -w 0 sbom.json)
                    curl -X PUT "${DTRACK_URL}/api/v1/bom" \
                         -H "X-Api-Key: ${DTRACK_API_KEY}" \
                         -H "Content-Type: application/json" \
                         -d "{
                           \\"projectName\\": \\"${JOB_NAME}\\",
                           \\"projectVersion\\": \\"${BUILD_NUMBER}\\",
                           \\"autoCreate\\": true,
                           \\"bom\\": \\"${BOM_BASE64}\\"
                         }"
                '''
            }
        }
    }
}

Notifications et alertes

Configurer les notifications

Dependency-Track peut vous alerter via plusieurs canaux. Depuis v4.13, les notifications programmées (résumé quotidien/hebdomadaire) sont disponibles.

Aller dans Administration → Notifications → Alerts
Créer un nouveau publisher (Slack, Teams, Email, Webhook…)
Créer une règle de notification :
- Sélectionner les événements (nouvelles vulnérabilités, violations de politique…)
- Assigner le publisher
- Optionnel : filtrer par projet ou sévérité

Types de notifications

Événement	Description
`NEW_VULNERABILITY`	Nouvelle vulnérabilité détectée
`NEW_VULNERABLE_DEPENDENCY`	Nouveau composant vulnérable ajouté
`ANALYSIS_DECISION_CHANGE`	Changement de statut d’analyse
`POLICY_VIOLATION`	Violation d’une politique
`BOM_CONSUMED`	SBOM uploadé avec succès
`BOM_PROCESSING_FAILED`	Échec de traitement d’un SBOM
`VEX_CONSUMED`	VEX importé

Notifications programmées (v4.13+)

Les nouveaux types de notifications en mode résumé permettent de recevoir une synthèse plutôt qu’une alerte par vulnérabilité :

Type	Description
`NEW_VULNERABILITIES_SUMMARY`	Résumé des nouvelles vulnérabilités
`NEW_POLICY_VIOLATIONS_SUMMARY`	Résumé des violations de politique

Configuration via expression cron dans l’interface ou l’API.

Exemple Slack

{
  "name": "Slack Alerts",
  "publisherClass": "org.dependencytrack.notification.publisher.SlackPublisher",
  "templateMimeType": "application/json",
  "template": "{\"text\": \"Nouvelle vulnérabilité ${vulnerability.vulnId} (${vulnerability.severity}) détectée dans ${project.name}\"}",
  "destination": "https://hooks.slack.com/services/XXX/YYY/ZZZ"
}

Politiques

Les politiques permettent de définir des règles automatiques pour détecter les composants non conformes.

Types de conditions

Condition	Description
Severity	Niveau de sévérité (CRITICAL, HIGH, MEDIUM, LOW)
License	Licences interdites (GPL, AGPL…)
Component Age	Âge du composant
Coordinates	Package spécifique (name, version, purl)
SWID Tag ID	Identifiant SWID
CWE	Catégorie de faiblesse (CWE-79, CWE-89…)

Créer une politique

Aller dans Policies → Create Policy
Définir les conditions :

Sujet Opérateur Valeur
Severity IS CRITICAL
Assigner aux projets (tous ou sélection)
Choisir le niveau de violation :
- Fail : Bloquant (affichage rouge)
- Warn : Avertissement (affichage orange)
- Info : Information (affichage bleu)

Sujet	Opérateur	Valeur
Severity	IS	CRITICAL

Exemple : bloquer Log4j vulnérable

curl -X PUT "http://localhost:8081/api/v1/policy" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "name": "Block Log4j < 2.17.1",
       "violationState": "FAIL",
       "policyConditions": [
         {
           "subject": "COORDINATES",
           "operator": "MATCHES",
           "value": "{\"group\":\"org.apache.logging.log4j\",\"name\":\"log4j-core\",\"version\":\"<2.17.1\"}"
         }
       ]
     }'

Collection Projects (v4.13+)

Les Collection Projects permettent d’organiser vos projets de manière hiérarchique.

Cas d’usage

Regrouper les microservices d’une même application
Créer une vue “équipe” avec tous les projets d’une équipe
Agréger les métriques de plusieurs projets

Créer une collection

curl -X PUT "http://localhost:8081/api/v1/project" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "name": "Platform E-Commerce",
       "version": "1.0",
       "collectionLogic": "AGGREGATE_DIRECT_CHILDREN"
     }'

Logiques de collection :

Logique	Description
`NONE`	Projet standard (défaut)
`AGGREGATE_DIRECT_CHILDREN`	Agrège les enfants directs
`AGGREGATE_ALL_CHILDREN`	Agrège tous les descendants

Dépannage

Problèmes d’installation

Symptôme	Cause probable	Solution
API ne répond pas	Container non démarré	`docker compose logs dtrack-apiserver`
Erreur database	PostgreSQL non prêt	Attendre ou vérifier `docker compose logs postgres`
Frontend erreur API	URL API incorrecte	Vérifier `API_BASE_URL` dans la config frontend
Synchronisation lente	Pas de clé API NVD	Obtenir une clé gratuite sur nvd.nist.gov

Problèmes d’upload

Symptôme	Cause probable	Solution
401 Unauthorized	API key invalide	Vérifier l’API key, régénérer si nécessaire
403 Forbidden	Permissions manquantes	Ajouter `BOM_UPLOAD` et `PROJECT_CREATION_UPLOAD`
Processing=true indéfiniment	Serveur surchargé	Vérifier les ressources (RAM, CPU)
0 vulnérabilités	Bases non synchronisées	Attendre la sync NVD (plusieurs heures)

Commandes de diagnostic

# Vérifier l'état des services
docker compose ps

# Logs de l'API server
docker compose logs -f dtrack-apiserver

# Vérifier la version
curl -s http://localhost:8081/api/version | jq .

# Vérifier la santé
curl -s http://localhost:8081/api/v1/health | jq .

# Statistiques de la base
curl -s "http://localhost:8081/api/v1/metrics/portfolio/current" \
     -H "X-Api-Key: $API_KEY" | jq .

À retenir

Dependency-Track centralise l’analyse des SBOM de tous vos projets et corrèle en continu avec les bases de vulnérabilités
Utilisez PostgreSQL (H2 déprécié depuis v4.13) et obtenez une clé API NVD gratuite pour accélérer la synchronisation
Les API keys sont hachées depuis v4.13 : sauvegardez-les immédiatement après génération
L’upload est asynchrone : utilisez le token retourné pour vérifier le statut de traitement
Configurez des notifications pour être alerté des nouvelles vulnérabilités critiques
Créez des politiques pour détecter automatiquement les composants non conformes
Collection Projects (v4.13+) permet d’organiser et d’agréger les métriques de plusieurs projets
Intégrez dans votre CI/CD : générez les SBOM avec Trivy/Syft et uploadez automatiquement

Prochaines étapes

Générer des SBOM avec Trivy Scanner et générer des SBOM pour vos images et projets

Sécuriser la supply chain Comprendre les enjeux de la chaîne d'approvisionnement logicielle

Grype : scanner de vulnérabilités Alternative légère pour l'analyse de vulnérabilités

Renovate : mise à jour automatique Automatiser les mises à jour de dépendances

Ressources

Site officiel : https://dependencytrack.org/
Documentation : https://docs.dependencytrack.org/
GitHub : https://github.com/DependencyTrack/dependency-track
Releases : https://github.com/DependencyTrack/dependency-track/releases
API OpenAPI : https://docs.dependencytrack.org/integrations/rest-api/