Ein wichtiger Aspekt des Schwachstellenmanagements besteht darin, die Sicherheit der Lieferkette der Softwarekomponenten, die moderne Systeme bilden, gut zu verstehen und zu gewährleisten. Teams, die agile Methoden und DevOps praktizieren, nutzen häufig Bibliotheken und Frameworks mit offenem Quellcode, um die Entwicklungszeit und -kosten zu reduzieren. Doch diese Medaille hat auch eine Kehrseite: die Möglichkeit, sich fremde Fehler und Schwachstellen einzuverleiben.
Offensichtlich muss das Team unbedingt wissen, welche Open-Source-Komponenten in seinen Anwendungen enthalten sind, darauf achten, dass nur sichere Versionen aus vertrauenswürdigen Quellen heruntergeladen werden, und aktualisierte Versionen der Komponenten nach der Behebung neu entdeckter Schwachstellen hochladen.
In diesem Beitrag betrachten wir die Verwendung von OWASP Dependency Check, um den Build zu stoppen, falls schwerwiegende Probleme mit Ihrem Code entdeckt werden.
Im Buch „Sicherheit von Softwareentwicklungen in Agile-Projekten“ wird folgendes beschrieben: OWASP Dependency Check ist ein kostenloser Scanner, der alle zur Anwendung verwendeten Open-Source-Komponenten katalogisiert und ihre Schwachstellen aufzeigt. 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 mit Continuous Integration-Servern wie Jenkins.
Dependency Check informiert über alle Komponenten mit bekannten Schwachstellen aus der National Vulnerability Database (NVD) des 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 Sonatype oder .
Diese Tools können in Build-Pipelines integriert werden, um automatisch eine Auflistung von Open-Source-Abhängigkeiten zu erstellen, veraltete Versionen von Bibliotheken sowie Bibliotheken mit bekannten Schwachstellen zu identifizieren und den Build im Falle schwerwiegender Probleme abzubrechen.
OWASP Dependency Check
Für Tests und Demonstrationen der Funktionalität von Dependency Check verwenden wir dieses Repository. .
Um den HTML-Bericht anzuzeigen, muss ein Webserver nginx auf Ihrem gitlab-runner eingerichtet werden.
Beispiel für eine minimalen 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 dem Link nach und sehen den Bericht von Dependency Check.
Der erste Screenshot zeigt den oberen Teil des Berichts mit einer kurzen Zusammenfassung.
Der zweite Screenshot zeigt die Details zu CVE-2017-5638. Hier sehen wir das CVE-Level und Links zu Exploits.
Der dritte Screenshot zeigt die Details zu log4j-api-2.7.jar. Wir sehen, dass die CVE-Werte 7.5 und 9.8 sind.
Der vierte Screenshot zeigt die Details zu commons-fileupload-1.3.2.jar. Wir sehen, dass die CVE-Werte 7.5 und 9.8 sind.
Wenn Sie gitlab pages verwenden möchten, wird das nicht funktionieren — ein fehlgeschlagener Task erstellt kein Artefakt.
Beispiel hier .
Build-Ausgabe: keine Artefakte, HTML-Bericht nicht sichtbar. Es sollte Artifact: always ausprobiert werden.
Regulierung des CVE-Einstiegs von Sicherheitsanfälligkeiten
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 den CVE-Sicherheitsniveau einstellen, auf das reagiert werden soll.
Herunterladen der Schwachstellendatenbank (NVD) NIST aus dem Internet
Sie haben bemerkt, dass ständig Schwachstellendatenbanken (NVD) NIST aus dem Internet heruntergeladen werden:
Zum Herunterladen kann das Dienstprogramm verwendet werden
Lassen Sie uns das installieren und starten.
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 die CVE JSON NIST in /var/www/repos/nist-data-mirror/ beim Start und aktualisiert die Daten alle 24 Stunden.
Um die CVE JSON NIST herunterzuladen, muss ein Webserver nginx konfiguriert werden (zum Beispiel auf Ihrem gitlab-runner).
Beispiel für eine minimalen 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 die lange Zeile, in der mvn gestartet wird, zu vermeiden, geben wir die Parameter in einer separaten Variablen DEPENDENCY_OPTS an.
Die endgültige 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:
Stufe: 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
