Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

Une partie importante de la gestion des vulnérabilités consiste à bien comprendre et à sécuriser la chaîne d'approvisionnement des composants logiciels dont sont constitués les systèmes modernes. Les équipes utilisant des méthodes agiles et DevOps recourent largement aux bibliothèques et frameworks open source pour réduire le temps et le coût de développement. Mais cette médaille a son revers : la possibilité d'hériter des erreurs et vulnérabilités des autres.

Il est évident que l'équipe doit savoir quels composants open source sont inclus dans ses applications, veiller à ce que des versions réputées sûres soient téléchargées à partir de sources fiables, et charger des versions mises à jour des composants après la correction des vulnérabilités nouvellement découvertes.

Dans cet article, nous examinerons l'utilisation d'OWASP Dependency Check pour interrompre le processus de construction en cas de détection de problèmes graves dans votre code.

Le livre « Sécurité du développement dans les projets Agile » le décrit ainsi. OWASP Dependency Check est un scanner gratuit qui catalogue tous les composants open source utilisés dans l'application et indique les vulnérabilités qu'ils présentent. Il existe des versions pour Java, .NET, Ruby (gemspec), PHP (composer), Node.js et Python, ainsi que pour certains projets en C/C++. Dependency Check s'intègre avec des outils de construction courants, tels qu'Ant, Maven et Gradle, ainsi qu'avec des serveurs d'intégration continue comme Jenkins.

Dependency Check signale tous les composants présentant des vulnérabilités connues à partir de la base de données nationale des vulnérabilités (NVD) de NIST et est mis à jour sur la base des données provenant des canaux d'actualités de la NVD.

Heureusement, tout cela peut être fait automatiquement à l'aide d'outils tels que le projet OWASP Dependency Check ou des programmes commerciaux comme Black Duck, JFrog Xray, Snyk, Nexus Lifecycle de la société Sonatype ou SourceClear.

Ces outils peuvent être intégrés dans les pipelines de construction pour établir automatiquement un inventaire des dépendances open source, identifier les bibliothèques obsolètes et celles contenant des vulnérabilités connues, et interrompre la construction en cas de détection de problèmes graves.

OWASP Dependency Check

Pour tester et démontrer le fonctionnement de Dependency Check, nous utilisons ce dépôt dependency-check-example.

Pour visualiser le rapport HTML, vous devez configurer le serveur web nginx sur votre gitlab-runner.

Exemple de configuration minimale pour nginx :

serveur {
    écouter       9999;
    écouter       [::]:9999;
    nom_de_serveur  _;
    racine         /home/gitlab-runner/builds;

    emplacement / {
        autoindex activé;
    }

    page_d_erreur 404 /404.html;
        emplacement = /40x.html {
    }

    page_d_erreur 500 502 503 504 /50x.html;
        emplacement = /50x.html {
    }
}

À la fin de la construction, vous pouvez voir ceci :

Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

Nous cliquons sur le lien et voyons le rapport Dependency Check.

La première capture d'écran — la partie supérieure du rapport avec un résumé.

Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

La deuxième capture d'écran détaille le CVE-2017-5638. Ici, nous voyons le niveau CVE et des liens vers des exploits.

Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

La troisième capture d'écran — détails de log4j-api-2.7.jar. Nous voyons que les niveaux CVE sont 7.5 et 9.8.

Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

La quatrième capture d'écran — détails de commons-fileupload-1.3.2.jar. Nous voyons que les niveaux CVE sont 7.5 et 9.8.

Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

Si vous souhaitez utiliser gitlab pages, cela ne sera pas possible — une tâche échouée ne créera pas d'artefact.

Un exemple ici https://gitlab.com/anton_patsev/dependency-check-example-gitlab-pages.

Résultat de la construction : pas d'artefacts, je ne vois pas le rapport html. Il faut essayer Artifact: always

https://gitlab.com/anton_patsev/dependency-check-example-gitlab-pages/-/jobs/400004246

Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

Régulation du niveau CVE des vulnérabilités

La ligne la plus importante dans le fichier gitlab-ci.yaml :

mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7

Le paramètre failBuildOnCVSS vous permet de réguler le niveau CVE des vulnérabilités auxquelles il faut réagir.

Télécharger depuis internet la base de données de vulnérabilités (NVD) NIST

Vous avez remarqué qu'il télécharge constamment les bases de données de vulnérabilités (NVD) NIST depuis internet :

Utilisation d'un scanner de vulnérabilités dans les bibliothèques utilisées Dependency-Check dans GitlabCI

Pour le téléchargement, vous pouvez utiliser l'utilitaire nist_data_mirror_golang

Installons et exécutons-le.

yum -y install yum-plugin-copr
yum copr enable antonpatsev/nist_data_mirror_golang
yum -y install nist-data-mirror
systemctl start nist-data-mirror

Nist-data-mirror télécharge le CVE JSON NIST dans /var/www/repos/nist-data-mirror/ au démarrage et met à jour les données toutes les 24 heures.

Pour télécharger le CVE JSON NIST, vous devez configurer le serveur web nginx (par exemple sur votre gitlab-runner).

Exemple de configuration minimale pour nginx :

serveur {
    écouter       12345;
    écouter       [::]:12345;
    nom_de_serveur  _;
    racine         /var/www/repos/nist-data-mirror/;

    emplacement / {
        autoindex activé;
    }

    page_d_erreur 404 /404.html;
        emplacement = /40x.html {
    }

    page_d_erreur 500 502 503 504 /50x.html;
        emplacement = /50x.html {
    }

}

Pour ne pas créer une longue ligne où mvn est lancé, extrayons les paramètres dans une variable distincte DEPENDENCY_OPTS.

La configuration minimale finale de .gitlab-ci.yml sera comme ça :

variables:
  MAVEN_OPTS: "-Dhttps.protocols=TLSv1.2 -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"
  DEPENDENCY_OPTS: "-DfailBuildOnCVSS=7 -DcveUrlModified=http://localhost:12345/nvdcve-1.1-modified.json.gz -DcveUrlBase=http://localhost:12345/nvdcve-1.1-%d.json.gz"

cache:
  paths:
    - .m2/repository

verify:
  stage: test
  script:
    - set +e
    - mvn $MAVEN_CLI_OPTS install org.owasp:dependency-check-maven:check $DEPENDENCY_OPTS || EXIT_CODE=$?
    - export PATH_WITHOUT_HOME=$(pwd | sed -e "s//home/gitlab-runner/builds//g")
    - echo "************************* URL Dependency-check-report.html *************************"
    - echo "http://$HOSTNAME:9999$PATH_WITHOUT_HOME/target/dependency-check-report.html"
    - set -e
    - exit ${EXIT_CODE}
  tags:
    - shell

Chat Telegram sur DevOps et Sécurité
Canal Telegram DevSecOps / SSDLC - Développement sécurisé

Source : habr.com

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster