Kluczowym aspektem zarządzania podatnościami jest dobre zrozumienie i zabezpieczenie łańcucha dostaw komponentów oprogramowania, z których budowane są nowoczesne systemy. Zespoły, które stosują zwinne metodyki i DevOps, szeroko wykorzystują biblioteki i ramy o otwartym kodzie źródłowym, aby skrócić czas i koszty rozwoju. Jednak ta medale ma także drugą stronę: możliwość odziedziczenia cudzych błędów i podatności.
Oczywiste jest, że zespół musi być świadomy, jakie komponenty o otwartym kodzie źródłowym są włączone do jego aplikacji, monitorować, aby pobierać zaufane wersje z zaufanych źródeł, oraz wgrywać zaktualizowane wersje komponentów po naprawie nowo odkrytych podatności.
W tym wpisie omówimy użycie OWASP Dependency Check do przerywania budowy w przypadku wykrycia poważnych problemów z twoim kodem.
W książce "Bezpieczeństwo rozwoju w projektach Agile" opisano to w ten sposób. OWASP Dependency Check to darmowy skaner, który katalogizuje wszystkie komponenty o otwartym kodzie źródłowym używane w aplikacji i wskazuje na istnienie w nich podatności. Dostępne są wersje dla Java, .NET, Ruby (gemspec), PHP (composer), Node.js i Pythona, a także dla niektórych projektów w C/C++. Dependency Check integruje się z popularnymi narzędziami budowlanymi, w tym Ant, Maven i Gradle oraz z serwerami ciągłej integracji takimi jak Jenkins.
Dependency Check zgłasza wszystkie komponenty z znanymi podatnościami z Krajowej Bazy Danych Podatności (NVD) NIST i jest aktualizowany na podstawie danych z kanałów informacyjnych NVD.
Na szczęście, wszystko to można robić automatycznie z pomocą takich narzędzi, jak projekt OWASP Dependency Check lub komercyjnych programów takich jak , , , kompanie Sonatype lub .
Te narzędzia można zintegrować z pipeline’ami budowlanymi, aby automatycznie tworzyć wykaz zależności z otwartym kodem źródłowym, identyfikować przestarzałe wersje bibliotek oraz biblioteki zawierające znane podatności, a także przerywać budowę w przypadku wykrycia poważnych problemów.
OWASP Dependency Check
Do testowania i demonstrowania działania Dependency Check użyjemy tego repozytorium .
Aby wyświetlić raport HTML, należy skonfigurować serwer web nginx na swoim gitlab-runner.
Przykład minimalnej konfiguracji nginx:
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 {
}
}Na końcu budowy możesz zobaczyć coś takiego:
Przechodzimy pod link i widzimy raport Dependency Check.
Pierwszy zrzut ekranu — górna część raportu z krótkim podsumowaniem.
Drugi zrzut ekranu szczegóły CVE-2017-5638. Tutaj widzimy poziom CVE oraz linki do exploitów.
Trzeci zrzut ekranu — szczegóły log4j-api-2.7.jar. Widać, że poziomy CVE wynoszą 7.5 i 9.8.
Czwarty zrzut ekranu — szczegóły commons-fileupload-1.3.2.jar. Widać, że poziomy CVE wynoszą 7.5 i 9.8.
Jeśli chcesz używać gitlab pages, niestety to nie zadziała — zakończone zadanie nie stworzy artefaktu.
Przykład tutaj .
Wynik budowy: brak artefaktów, nie widzę raportu HTML. Muszę spróbować Artifact: always.
Regulacja poziomu CVE podatności
Najważniejsza linia w pliku gitlab-ci.yaml:
mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7Parametrem failBuildOnCVSS możesz regulować poziom CVE podatności, na które należy reagować.
Pobieranie z internetu bazy danych podatności (NVD) NIST
Zauważyłeś, że ciągle pobiera bazy danych podatności (NVD) NIST z internetu:
Do pobierania możesz użyć narzędzia
Zainstalujemy i uruchomimy je.
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 pobiera CVE JSON NIST do /var/www/repos/nist-data-mirror/ przy uruchomieniu i aktualizuje dane co 24 godziny.
Aby pobrać CVE JSON NIST, należy skonfigurować serwer web nginx (na przykład na swoim gitlab-runnerze).
Przykład minimalnej konfiguracji nginx:
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 {
}
}Aby nie tworzyć długiej linii z parametrami uruchamiania mvn, przeniesiemy je do osobnej zmiennej DEPENDENCY_OPTS.
Ostateczna minimalna konfiguracja .gitlab-ci.yml będzie wyglądać tak:
zmienne:
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:
ścieżki:
- .m2/repository
weryfikacja:
etap: test
skrypt:
- 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}
tagi:
- shell
Źródło: habr.com
