Ein wichtiger Teil des Schwachstellenmanagements besteht darin, die Sicherheitskette der Softwarekomponenten, aus denen moderne Systeme bestehen, gut zu verstehen und zu sichern. Teams, die agile Methoden und DevOps praktizieren, nutzen häufig Open-Source-Bibliotheken und -Frameworks, um Entwicklungszeit und -kosten zu reduzieren. Aber diese Medaille hat eine Kehrseite: die Möglichkeit, die Fehler und Schwachstellen anderer zu erben.
Offensichtlich muss das Team unbedingt wissen, welche Open-Source-Komponenten in seinen Anwendungen enthalten sind, darauf achten, dass bewährte Versionen aus vertrauenswürdigen Quellen heruntergeladen werden, und aktualisierte Versionen von Komponenten nach der Behebung neu entdeckter Schwachstellen bereitstellen.
In diesem Beitrag betrachten wir die Verwendung von OWASP Dependency Check, um den Build bei der Entdeckung ernsthafter Probleme mit Ihrem Code zu unterbrechen.
Im Buch «Sicherheit in der Entwicklung von Agile-Projekten» wird es so beschrieben. OWASP Dependency Check ist ein kostenloser Scanner, der alle in der Anwendung verwendeten Open-Source-Komponenten katalogisiert und die vorhandenen Schwachstellen anzeigt. Es gibt Versionen für Java, .NET, Ruby (gemspec), PHP (composer), Node.js und Python sowie für einige Projekte in C/C++. Dependency Check integriert sich mit gängigen Build-Tools wie Ant, Maven und Gradle sowie CI-Servern wie Jenkins.
Dependency Check informiert über alle Komponenten mit bekannten Schwachstellen aus der National Vulnerability Database (NVD) von NIST und wird auf Basis von Daten aus NVD-Nachrichtendiensten aktualisiert.
Glücklicherweise kann all dies automatisch mit Hilfe von Tools wie dem OWASP Dependency Check-Projekt oder kommerziellen Programmen wie , , , von der Firma Sonatype oder .
Diese Werkzeuge können in Build-Pipelines integriert werden, um automatisch Bestandsverzeichnisse von Open-Source-Abhängigkeiten zu erstellen, veraltete Versionen von Bibliotheken und Bibliotheken mit bekannten Schwachstellen zu identifizieren und den Build bei der Entdeckung ernsthafter Probleme zu unterbrechen.
OWASP Dependency Check
Zur Testung und Demonstration der Funktionsweise von Dependency Check verwenden wir dieses Repository .
Um den HTML-Bericht anzuzeigen, müssen Sie den Webserver Nginx auf Ihrem GitLab-Runner konfigurieren.
Beispiel für eine minimale Nginx-Konfiguration:
server {
listen 9999;
listen [::]:9999;
server_name _;
root /home/gitlab-runner/builds;
location / {
autoindex on;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}Am Ende des Builds können Sie folgendes Bild sehen:
Wir gehen auf den Link und sehen den Bericht über den Dependency Check.
Der erste Screenshot zeigt den oberen Teil des Berichts mit einer kurzen Zusammenfassung.
Der zweite Screenshot gibt Details zu CVE-2017-5638. Hier sehen wir die CVE-Stufe und Links zu Exploits.
Der dritte Screenshot zeigt Details zu log4j-api-2.7.jar. Wir sehen eine CVE-Stufe von 7.5 und 9.8.
Der vierte Screenshot zeigt Details zu commons-fileupload-1.3.2.jar. Wir sehen eine CVE-Stufe von 7.5 und 9.8.
Wenn Sie GitLab Pages verwenden möchten, wird das nicht funktionieren — ein fehlgeschlagener Task wird kein Artefakt erstellen.
Beispiel hier .
Build-Ausgabe: keine Artefakte, HTML-Bericht nicht sichtbar. Es muss Artifact: always probiert werden.
Regulierung der CVE-Stufen von Verwundbarkeiten
Die wichtigste Zeile in der Datei gitlab-ci.yaml:
mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7Mit dem Parameter failBuildOnCVSS können Sie die CVE-Stufen von Verwundbarkeiten steuern, auf die reagiert werden soll.
Herunterladen der Verwundbarkeitsdatenbank (NVD) NIST aus dem Internet
Sie haben bemerkt, dass ständig die Verwundbarkeitsdatenbank (NVD) NIST aus dem Internet heruntergeladen wird:
Für den Download kann das Tool
installiert und gestartet werden.
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 lädt beim Start die CVE-JSON-NIST in /var/www/repos/nist-data-mirror/ herunter und aktualisiert die Daten alle 24 Stunden.
Um die CVE-JSON-NIST herunterzuladen, muss der Webserver Nginx (z.B. auf Ihrem GitLab-Runner) konfiguriert werden.
Beispiel für eine minimale Nginx-Konfiguration:
server {
listen 12345;
listen [::]:12345;
server_name _;
root /var/www/repos/nist-data-mirror/;
location / {
autoindex on;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}Um keine lange Zeile zu haben, in der mvn ausgeführt wird, ziehen wir die Parameter in eine separate Variable DEPENDENCY_OPTS.
Die resultierende minimale Konfiguration .gitlab-ci.yml sieht so aus:
Variablen:
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:
Pfade:
- .m2/repository
Überprüfung:
Phase: Test
Skript:
- 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
Quelle: habr.com
