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 , , , de la société Sonatype ou .
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 .
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 :

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é.

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

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.

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.

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 .
Résultat de la construction : pas d'artefacts, je ne vois pas le rapport html. Il faut essayer Artifact: always

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=7Le 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 :

Pour le téléchargement, vous pouvez utiliser l'utilitaire
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-mirrorNist-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
Source : habr.com
