Déployer OWASP Dependency-Track 5 avec PostgreSQL via Docker Compose

Ce que fait Dependency-Track

OWASP Dependency-Track suit les composants tiers de tout ce que vous livrez. Votre pipeline de build envoie une nomenclature logicielle (SBOM) après chaque build. Dependency-Track la stocke, compare chaque composant aux bases de vulnérabilités comme la NVD, GitHub Advisories et OSV, et continue de vérifier longtemps après la fin du build. Lorsqu’une nouvelle vulnérabilité est publiée pour un composant que vous utilisez, votre équipe reçoit une notification par e-mail, Slack, Microsoft Teams, Mattermost ou webhook.

C’est ce dernier point qui en fait plus qu’un scanner. Un scan vous dit ce qui était vulnérable le jour du build. Dependency-Track vous dit ce qui l’est devenu depuis, pour chaque produit et chaque version que vous maintenez encore.

Pour les fabricants qui se préparent au Cyber Resilience Act, c’est directement utile. Le CRA exige une SBOM couvrant au moins les dépendances de premier niveau, la surveillance des vulnérabilités connues dans les composants tiers et des corrections sans délai pendant toute la période de support. Dependency-Track couvre l’inventaire et la surveillance. Notre guide du CRA pour les PME détaille ces obligations.

Ce qui a changé dans Dependency-Track 5

Dependency-Track 5 est disponible en version stable depuis juin 2026. Si vous utilisiez la version 4, voici les changements qui touchent le déploiement :

• La v5 fonctionne uniquement avec PostgreSQL. La prise en charge de H2, MySQL et Microsoft SQL Server disparaît, y compris la base H2 intégrée qui rendait la v4 facile à essayer.
• Les images proviennent désormais du registre de GitHub, ghcr.io/dependencytrack/. L’image tout-en-un et le fichier WAR ne sont plus publiés.
• Les paramètres de base de données passent de ALPINE_DATABASE_* à DT_DATASOURCE_*.
• Les health checks et les métriques Prometheus ont leur propre port, 9000, distinct de l’API REST sur le port 8080.
• Plusieurs instances du serveur d’API peuvent partager une base de données et se coordonner via PostgreSQL. Une seule instance suffit pour la plupart des petites et moyennes équipes.

Dependency-Track 4.14 reçoit des correctifs de sécurité jusqu’au 9 décembre 2026. Planifiez votre mise à niveau avant cette date ; le guide de migration du projet explique comment transférer vos données.

Ce dont vous avez besoin

• Un hôte Linux avec Docker Engine et le plugin Docker Compose. Voir Install Docker Engine.
• Pour le serveur d’API : au moins 2 Go de mémoire et idéalement 4 cœurs. En dessous de 1 Go, il ne suit pas une charge réelle.
• Pour PostgreSQL : le projet recommande 8 Go de mémoire et 4 cœurs sur un hôte dédié avec stockage SSD ou NVMe, et pas moins de 4 Go et 2 cœurs, même pour une évaluation. Le même hôte convient pour commencer ; déplacez la base vers un hôte dédié ou un service PostgreSQL managé quand votre portefeuille grandit.
• Deux noms d’hôte si vous l’exposez au-delà de localhost, par exemple dtrack.example.com pour le frontend et dtrack-api.example.com pour le serveur d’API.

Le fichier Docker Compose

Le fichier ci-dessous exécute trois services : PostgreSQL, le serveur d’API et le frontend. Par rapport au fichier de démarrage rapide du projet, il lit le mot de passe de la base dans un secret Docker, fige les versions des images et limite les ressources du serveur d’API.

Télécharger compose.yaml

name: dependency-track

services:
  postgres:
    image: postgres:18-alpine
    environment:
      POSTGRES_DB: dtrack
      POSTGRES_USER: dtrack
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 5
    volumes:
      - postgres-data:/var/lib/postgresql
    restart: unless-stopped

  apiserver:
    image: ghcr.io/dependencytrack/apiserver:5.1.0
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DT_DATASOURCE_URL: jdbc:postgresql://postgres:5432/dtrack
      DT_DATASOURCE_USERNAME: dtrack
      DT_DATASOURCE_PASSWORD: "$${file::/run/secrets/db_password}"
    secrets:
      - db_password
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "4"
    ports:
      - "127.0.0.1:8080:8080" # REST API
      - "127.0.0.1:9000:9000" # health checks and metrics
    volumes:
      - apiserver-data:/data
    restart: unless-stopped

  frontend:
    image: ghcr.io/dependencytrack/frontend:5.1.0
    environment:
      API_BASE_URL: http://localhost:8080
    ports:
      - "127.0.0.1:8081:8080"
    restart: unless-stopped

secrets:
  db_password:
    file: ./secrets/db_password.txt

volumes:
  apiserver-data: {}
  postgres-data: {}

Quelques choix de ce fichier sont délibérés :

• La base de données n’expose aucun port. Seul le serveur d’API communique avec PostgreSQL, via le réseau interne de Compose. Publier le port 5432 ou ajouter un outil d’administration web comme Adminer ne fait qu’augmenter la surface d’attaque.
• Tous les ports sont liés à 127.0.0.1 : rien n’est joignable depuis le réseau tant que vous n’avez pas placé de reverse proxy devant.
• Le mot de passe de la base est dans un fichier. PostgreSQL le lit via POSTGRES_PASSWORD_FILE, Dependency-Track via la référence ${file::...}. Le double $$ empêche Compose de le traiter comme l’une de ses propres variables.
• Les versions des images sont figées. Avec latest, le prochain docker compose pull pourrait mettre à niveau Dependency-Track ou PostgreSQL sans que personne ne l’ait décidé. Consultez la page des versions pour le dernier correctif 5.x et lisez ses notes de mise à niveau avant de changer l’étiquette.
• Le frontend ne sert que des fichiers statiques : API_BASE_URL doit donc être l’adresse par laquelle les navigateurs de vos utilisateurs joignent le serveur d’API, pas un nom de conteneur interne.

Démarrage

Créez le fichier de mot de passe, sans saut de ligne final, et démarrez la pile :

mkdir -p secrets
printf '%s' "$(openssl rand -base64 32)" > secrets/db_password.txt
chmod 600 secrets/db_password.txt

docker compose up -d
docker compose logs -f apiserver

Le premier démarrage crée le schéma de la base et les équipes par défaut, ce qui prend une minute. Vérifiez que le serveur d’API est prêt :

curl -s http://localhost:9000/health/ready

Ouvrez ensuite http://localhost:8081 et connectez-vous avec admin / admin. Dependency-Track vous demande aussitôt de définir un nouveau mot de passe.

Les comptes locaux suffisent pour une évaluation. En production, le projet recommande de connecter OpenID Connect ou LDAP/Active Directory pour que chacun se connecte avec son compte d’entreprise.

Le placer derrière TLS

Terminez TLS sur un reverse proxy et laissez les conteneurs en HTTP simple. Le proxy doit transmettre les en-têtes X-Forwarded-Proto et X-Forwarded-For pour que les journaux d’audit et les liens des notifications affichent l’URL publique. Avec Caddy, qui gère pour vous les certificats et ces en-têtes, la configuration tient en quatre lignes par hôte :

dtrack.example.com {
	reverse_proxy 127.0.0.1:8081
}

dtrack-api.example.com {
	reverse_proxy 127.0.0.1:8080
}

Définissez ensuite API_BASE_URL: https://dtrack-api.example.com dans le fichier Compose et relancez docker compose up -d. Nginx, Traefik ou votre répartiteur de charge existant fonctionnent de la même façon.

Activer les sources de vulnérabilités

Allez dans Administration › Vulnerability Sources et activez les sources souhaitées :

• La NVD ne demande pas d’identifiants. Sa première synchronisation télécharge l’ensemble des données et prend un moment.
• GitHub Advisories demande un personal access token ou une GitHub App. Cela vaut la peine, car ses avis paraissent souvent plus tôt et se rattachent plus précisément aux noms de paquets que les entrées de la NVD.
• OSV ne demande pas d’identifiants. Activez les écosystèmes que vous utilisez réellement.

Depuis la version 5.1, Dependency-Track synchronise aussi par défaut les catalogues de vulnérabilités activement exploitées de la CISA et de l’ENISA. Vous pouvez utiliser ce statut dans les politiques et les filtres de notification, pour qu’une vulnérabilité exploitée ne se noie pas dans une liste de vulnérabilités théoriques.

Créer un projet et envoyer une SBOM

Dans Dependency-Track, un projet représente un produit, une bibliothèque ou un service, généralement avec une version par release maintenue. Créez-en un via Projects › Create Project, puis envoyez une SBOM CycloneDX dans l’onglet Components du projet pour voir le résultat.

Il vous faut d’abord une SBOM CycloneDX. La plupart des écosystèmes de build disposent d’un générateur : les plugins CycloneDX pour Maven et Gradle, cdxgen pour de nombreux langages ou Syft pour les images de conteneurs. Le CycloneDX Tool Center les recense tous. Dependency-Track 5.1 accepte CycloneDX jusqu’à la version 1.7.

L’envoi manuel suffit pour essayer. En pratique, votre pipeline devrait s’en charger après chaque build.

Envoyer les SBOM depuis votre pipeline CI/CD

Votre pipeline a besoin d’une clé d’API disposant de la permission BOM_UPLOAD. L’équipe par défaut Automation la possède, avec PROJECT_CREATION_UPLOAD, qui permet à un envoi de créer le projet s’il n’existe pas encore. Générez une clé pour cette équipe via Administration › Access Management › Teams, ou créez une équipe par pipeline pour pouvoir révoquer les clés une à une.

Stockez la clé comme secret dans votre système de CI. Ne la mettez jamais dans le fichier du pipeline ni dans le dépôt.

Envoyez ensuite la SBOM après chaque build :

curl -sSf -X POST "https://dtrack-api.example.com/api/v1/bom" \
  -H "X-Api-Key: ${DT_API_KEY}" \
  -F "autoCreate=true" \
  -F "projectName=my-product" \
  -F "projectVersion=${VERSION}" \
  -F "[email protected]"

Avec autoCreate=true, Dependency-Track crée le projet et la version lors du premier envoi. Si vous préférez gérer les projets à la main, retirez ce paramètre et identifiez le projet par son UUID, avec -F "project=<uuid>". Vous trouverez l’UUID sous View Details du projet.

Envoyez une version par release maintenue, pas seulement la branche principale. Quand une nouvelle vulnérabilité paraît, vous voulez savoir quelles versions livrées sont touchées, car ce sont celles qu’utilisent vos clients et celles que le CRA vous demande de corriger.

Sauvegarde et mise à niveau

Toutes les données persistantes sont dans PostgreSQL : une sauvegarde de la base est donc une sauvegarde complète.

docker compose exec -T postgres pg_dump -U dtrack -Fc dtrack > dtrack-$(date +%F).dump

Planifiez-la, copiez les sauvegardes hors de l’hôte et testez au moins une restauration. Si vous devez consulter la base, utilisez docker compose exec postgres psql -U dtrack dtrack plutôt que d’exposer un outil d’administration web.

Pour mettre à niveau, lisez les notes de la version, faites une sauvegarde, modifiez les étiquettes d’image dans compose.yaml et lancez :

docker compose pull
docker compose up -d

Prochaines étapes

Une fois les SBOM reçues, la valeur vient de ce que vous faites des constats. Configurez des notifications pour les nouvelles vulnérabilités critiques et activement exploitées, créez des politiques de composants pour les licences et les composants obsolètes, et décidez qui trie les constats pour chaque produit. La documentation de Dependency-Track couvre chacun de ces points.

Si vous souhaitez de l’aide pour intégrer Dependency-Track à votre cycle de développement sécurisé ou à votre préparation au CRA, réservez un appel gratuit.