Dependency-Check

Dependency-Check est un outil d'analyse de composition logicielle (SCA) qui tente de détecter les vulnérabilités publiquement divulguées contenues dans les dépendances d'un projet. Pour ce faire, il détermine s'il existe un identifiant Common Platform Enumeration (CPE) pour une dépendance donnée. S'il en trouve un, il génère un rapport contenant des liens vers les entrées CVE associées.

La documentation et les liens vers les versions binaires de production sont disponibles sur les pages github. De plus, des informations complémentaires sur l'architecture et les moyens d'étendre dependency-check sont disponibles sur le wiki.

Avis

Ce produit utilise l'API NVD mais n'est ni approuvé ni certifié par la NVD.

Mise à niveau obligatoire vers 12.1.0+

En raison de changements de compatibilité de l'API NVD, une mise à niveau est obligatoire. Voir #7463 pour plus d'informations.

Changements de rupture dans 11.0.0

• Java 11 est désormais requis pour exécuter dependency-check 11.0.0 ou une version supérieure

• Mise à niveau de la base de données H2

  11.0.0 contient des changements de rupture concernant l'utilisation de la base de données H2 locale. Un téléchargement complet des données NVD sera effectué. Notez que si vous utilisez un répertoire de données partagé, le fichier de base de données h2 n'est pas compatible avec les versions antérieures de dependency-check. Si vous rencontrez des problèmes, vous devrez peut-être exécuter une purge :

  • gradle : ./gradlew dependencyCheckPurge
  • maven : mvn org.owasp:dependency-check-maven:11.0.0:purge
  • cli : dependency-check.sh --purge

Autres avis

Clé API NVD fortement recommandée

Dependency-check est passé de l'utilisation du flux de données NVD à l'API NVD depuis 9.0.0+ (janvier 2024). Les utilisateurs de dependency-check sont fortement encouragés à obtenir une clé API NVD ; voir https://nvd.nist.gov/developers/request-an-api-key Sans clé API NVD, les mises à jour de dependency-check seront extrêmement lentes. Veuillez consulter la documentation des intégrations cli, maven, gradle ou ant pour savoir comment définir la clé API NVD.

La clé API NVD, le CI et la limitation de débit

L'API NVD applique des limites de débit. Si vous utilisez une seule clé API et que plusieurs builds se produisent, vous pourriez atteindre la limite de débit et recevoir des erreurs 403. Dans un environnement CI, il faut utiliser une stratégie de mise en cache.

Authentification obligatoire Sonatype OSS Index et migration vers Sonatype Guide

En septembre 2025, Sonatype OSS Index a commencé à imposer l'utilisation de jetons API pour l'authentification. En avril 2026, une migration ultérieure vers Sonatype Guide a débuté, lançant une transition vers l'utilisation de jetons API Sonatype Guide, qui doivent remplacer les anciennes clés/jetons API OSS Index avant la fin de 2026.

Sans identifiants, Dependency Check désactivera automatiquement l'analyseur OSS Index. Veuillez consulter la documentation des intégrations CLI, Maven, Gradle ou Ant pour savoir comment définir les identifiants de l'analyseur afin d'utiliser un jeton Sonatype Guide ou une ancienne clé API OSS Index.

Si vous souhaitez utiliser Sonatype OSS Index (via Guide), vous devez configurer Dependency-Check et prendre en compte les implications de la migration vers Sonatype Guide, dont le modèle commercial/d'utilisation a changé. Consultez la documentation de l'analyseur pour plus d'informations.

Environnement de build Gradle

Avec 9.0.0+, les utilisateurs peuvent rencontrer des problèmes avec les exceptions NoSuchMethodError en raison de la résolution des dépendances. Si vous rencontrez ce problème, vous devrez épingler certaines des dépendances transitives de dependency-check à des versions spécifiques. Par exemple :

/buildSrc/build.gradle

dependencies {
    constraints {
        // org.owasp.dependencycheck needs at least this version of jackson. Other plugins pull in older versions..
        add("implementation", "com.fasterxml.jackson:jackson-bom:2.21.2")

        // org.owasp.dependencycheck needs these versions. Other plugins pull in older versions..
        add("implementation", "org.apache.commons:commons-lang3:3.20.0")
        add("implementation", "org.apache.commons:commons-text:1.15.0")
    }
}

Prérequis

Version de Java

Version minimale de Java : Java 11

Accès Internet

OWASP dependency-check nécessite l'accès à plusieurs ressources hébergées en externe. Pour plus d'informations, voir Accès Internet requis.

Outils de build

Afin d'analyser certaines piles technologiques, dependency-check peut nécessiter l'installation d'autres outils de développement. Certaines des analyses listées ci-dessous peuvent être expérimentales et nécessitent l'activation des analyseurs expérimentaux.

1. Pour analyser les assemblies .NET, le runtime dotnet 8 ou le SDK doit être installé.
   • Les assemblies ciblant d'autres runtimes peuvent être analysées - mais 8 est requis pour exécuter l'analyse.
2. Si vous analysez des projets GoLang, go doit être installé.
3. L'analyse des projets Elixir nécessite mix_audit.
4. L'analyse des projets npm, pnpm et yarn nécessite l'installation de npm, pnpm ou yarn.
   • Les analyses effectuées utilisent la fonctionnalité audit respective de chacun.
5. L'analyse de Ruby est un wrapper autour de bundle-audit, qui doit être installé.

Versions actuelles

Plugin Jenkins

Pour des instructions sur l'utilisation du plugin Jenkins, veuillez consulter la page du plugin OWASP Dependency-Check.

Ligne de commande

Des instructions plus détaillées sont disponibles sur les pages github de dependency-check. La dernière CLI peut être téléchargée depuis github dans la section des versions.

Téléchargement de la dernière version :

$ VERSION=$(curl -s https://dependency-check.github.io/DependencyCheck/current.txt)
$ curl -Ls "https://github.com/dependency-check/DependencyCheck/releases/download/v$VERSION/dependency-check-$VERSION-release.zip" --output dependency-check.zip

Sur *nix

$ ./bin/dependency-check.sh -h
$ ./bin/dependency-check.sh --out . --scan [path to jar files to be scanned]

Sur Windows

> .\bin\dependency-check.bat -h
> .\bin\dependency-check.bat --out . --scan [path to jar files to be scanned]

Sur Mac avec Homebrew Remarque - les utilisateurs de homebrew qui passent de 5.x à 6.0.0 devront exécuter dependency-check.sh --purge.

$ brew update && brew install dependency-check
$ dependency-check -h
$ dependency-check --out . --scan [path to jar files to be scanned]

Plugin Maven

Des instructions plus détaillées sont disponibles sur les pages github de dependency-check-maven. Par défaut, le plugin est lié à la phase verify (c'est-à-dire mvn verify). Il est également possible d'invoquer directement le plugin via mvn org.owasp:dependency-check-maven:check.

Le plugin dependency-check peut être configuré comme suit :

<project>
    <build>
        <plugins>
            ...
            <plugin>
              <groupId>org.owasp</groupId>
              <artifactId>dependency-check-maven</artifactId>
              <executions>
                  <execution>
                      <goals>
                          <goal>check</goal>
                      </goals>
                  </execution>
              </executions>
            </plugin>
            ...
        </plugins>
        ...
    </build>
    ...
</project>

Plugin Gradle

Pour des instructions sur l'utilisation du plugin Gradle, veuillez consulter la page github de dependency-check-gradle.

Tâche Ant

Pour des instructions sur l'utilisation de la tâche Ant, veuillez consulter la page github de dependency-check-ant.

Prérequis de développement

Pour que l'installation réussisse, vous devez avoir les composants suivants installés :

• Java : java -version 25.0
• Maven : mvn -version 3.6.3 et supérieur

Les cas de test nécessitent :

• dotnet core version 8.0
• Go : go version 1.12 et supérieur
• Ruby bundler-audit
• Yarn
• pnpm

Utilisation en développement

Les instructions suivantes décrivent comment compiler et utiliser l'instantané actuel. Bien que l'intention soit de maintenir un instantané stable, il est recommandé d'utiliser les versions de publication listées ci-dessus.

Le dépôt contient de gros fichiers en raison des ressources de test. L'équipe a essayé de nettoyer l'historique autant que possible. Cependant, il est recommandé d'effectuer un clone superficiel (shallow clone) pour gagner du temps :

git clone --depth 1 https://github.com/dependency-check/DependencyCheck.git

Sur *nix

$ mvn -s settings.xml install
$ ./cli/target/release/bin/dependency-check.sh -h
$ ./cli/target/release/bin/dependency-check.sh --out . --scan ./src/test/resources

Sur Windows

> mvn -s settings.xml install
> .\cli\target\release\bin\dependency-check.bat -h
> .\cli\target\release\bin\dependency-check.bat --out . --scan ./src/test/resources

Chargez ensuite le fichier 'dependency-check-report.html' résultant dans votre navigateur préféré.

Compilation sans exécuter les tests

Pour accélérer vos cycles de développement, vous pouvez également compiler sans exécuter les tests à chaque fois :
mvn -s settings.xml install -DskipTests=true

N'oubliez pas d'exécuter les tests au moins une fois avant d'ouvrir la PR. :)

IntelliJ Idea

Pour pouvoir déboguer vos tests dans IntelliJ Idea, vous pouvez introduire une configuration maven qui exécute votre test et active le débogage avec des points d'arrêt, etc.
En gros, vous faites ce qui est décrit sur https://www.jetbrains.com/help/idea/work-with-tests-in-maven.html#run_single_test et vous définissez forkCount à 0, sinon le débogage ne fonctionnera pas.

Étape par étape :

• Run -> Edit Configurations
• + (Add new configuration) -> Maven
• Donnez un nom à la configuration, par ex. Run tests
• Choisissez le répertoire de travail, par ex. core
• Dans command line, saisissez -DforkCount=0 -f pom.xml -s ../settings.xml test
• Appuyez sur OK
• Run -> Debug, puis choisissez la configuration d'exécution nouvellement créée

IntelliJ exécutera maintenant la série de tests pour le sous-projet core avec le débogage activé. Les points d'arrêt définis n'importe où dans le code devraient fonctionner.

Tester uniquement une fonction ou une classe

Si vous souhaitez accélérer vos cycles de développement, vous pouvez également tester une seule fonction ou une seule classe de test.
Cela fonctionne en ajoutant -Dtest=MyTestClass ou -Dtest=MyTestClass#myTestFunction à la configuration d'exécution. La ligne de commande complète dans la configuration d'exécution serait alors :

-Dtest=MyTestClass#myTestFunction -DforkCount=0 -f pom.xml -s ../settings.xml test

Docker

Dans l'exemple suivant, il est supposé que la source à analyser se trouve dans le répertoire de travail actuel et que les rapports seront écrits dans $(pwd)/odc-reports. Des répertoires de données et de cache persistants sont utilisés, ce qui vous permet de détruire le conteneur après l'exécution.

Pour Linux :

#!/bin/sh

DC_VERSION="latest"
DC_DIRECTORY=$HOME/OWASP-Dependency-Check
DC_PROJECT="dependency-check scan: $(pwd)"
DATA_DIRECTORY="$DC_DIRECTORY/data"
CACHE_DIRECTORY="$DC_DIRECTORY/data/cache"

if [ ! -d "$DATA_DIRECTORY" ]; then
    echo "Initially creating persistent directory: $DATA_DIRECTORY"
    mkdir -p "$DATA_DIRECTORY"
fi
if [ ! -d "$CACHE_DIRECTORY" ]; then
    echo "Initially creating persistent directory: $CACHE_DIRECTORY"
    mkdir -p "$CACHE_DIRECTORY"
fi

# Make sure we are using the latest version
docker pull owasp/dependency-check:$DC_VERSION

docker run --rm \
    -e user=$USER \
    -u $(id -u ${USER}):$(id -g ${USER}) \
    --volume $(pwd):/src:z \
    --volume "$DATA_DIRECTORY":/usr/share/dependency-check/data:z \
    --volume $(pwd)/odc-reports:/report:z \
    owasp/dependency-check:$DC_VERSION \
    --scan /src \
    --format "ALL" \
    --project "$DC_PROJECT" \
    --out /report
    # Use suppression like this: (where /src == $pwd)
    # --suppression "/src/security/dependency-check-suppression.xml"

Pour Windows :

@echo off

set DC_VERSION="latest"
set DC_DIRECTORY=%USERPROFILE%\OWASP-Dependency-Check
SET DC_PROJECT="dependency-check scan: %CD%"
set DATA_DIRECTORY="%DC_DIRECTORY%\data"
set CACHE_DIRECTORY="%DC_DIRECTORY%\data\cache"

IF NOT EXIST %DATA_DIRECTORY% (
    echo Initially creating persistent directory: %DATA_DIRECTORY%
    mkdir %DATA_DIRECTORY%
)
IF NOT EXIST %CACHE_DIRECTORY% (
    echo Initially creating persistent directory: %CACHE_DIRECTORY%
    mkdir %CACHE_DIRECTORY%
)

rem Make sure we are using the latest version
docker pull owasp/dependency-check:%DC_VERSION%

docker run --rm ^
    --volume %CD%:/src ^
    --volume %DATA_DIRECTORY%:/usr/share/dependency-check/data ^
    --volume %CD%/odc-reports:/report ^
    owasp/dependency-check:%DC_VERSION% ^
    --scan /src ^
    --format "ALL" ^
    --project "%DC_PROJECT%" ^
    --out /report
    rem Use suppression like this: (where /src == %CD%)
    rem --suppression "/src/security/dependency-check-suppression.xml"

Compilation à partir des sources

Pour compiler dependency-check (avec Java 11), exécutez la commande :

mvn -s settings.xml install

Exécution de dependency-check sur dependency-check

Dependency-check référence plusieurs dépendances vulnérables qui ne sont jamais utilisées sauf comme ressources de test. Toutes ces dépendances de test optionnelles sont incluses dans le profil test-dependencies. Pour exécuter dependency-check sur lui-même, excluez simplement le profil test-dependencies :

mvn org.owasp:dependency-check-maven:aggregate -P-test-dependencies -DskipProvidedScope=true

Compilation de la documentation

La documentation sur les pages github est générée à partir de ce dépôt :

mvn -s settings.xml site site:stage

Une fois terminé, pointez votre navigateur vers ./target/staging/index.html.

Construction de l'image Docker

Pour construire l'image Docker de dependency-check, exécutez la commande :

mvn -s settings.xml install
./docker-build.sh

Licence

La permission de modifier et de redistribuer est accordée selon les termes de la licence Apache 2.0. Consultez le fichier LICENSE.txt pour la licence complète.

Dependency-Check utilise plusieurs autres bibliothèques open source. Veuillez consulter le fichier NOTICE.txt pour plus d'informations.

Ce produit utilise l'API NVD mais n'est ni approuvé ni certifié par la NVD.

Copyright (c) 2012-2025 Jeremy Long. Tous droits réservés.