Ważną częścią zarządzania podatnościami jest dokładne zrozumienie i zabezpieczenie łańcucha dostaw komponentów oprogramowania tworzących nowoczesne systemy. Zespoły Agile i DevOps szeroko korzystają z bibliotek i frameworków open source, aby skrócić czas i koszty programowania. Ale ten medal ma też wadę: możliwość odziedziczenia błędów i słabości innych ludzi.
Oczywiście zespół powinien wiedzieć, które komponenty typu open source znajdują się w jego aplikacjach, upewnić się, że znane i niezawodne wersje są pobierane ze znanych, wiarygodnych źródeł oraz pobierać zaktualizowane wersje komponentów po załataniu nowo wykrytych luk.
W tym poście przyjrzymy się użyciu narzędzia OWASP Depency Check do przerwania kompilacji, jeśli wykryje poważne problemy z kodem.
W książce „Bezpieczeństwo rozwoju w projektach zwinnych” opisano to następująco. OWASP Depency Check to darmowy skaner, który kataloguje wszystkie komponenty open source używane w aplikacji i pokazuje zawarte w nich luki. Istnieją wersje dla Java, .NET, Ruby (gemspec), PHP (composer), Node.js i Python, a także dla niektórych projektów C/C++. Sprawdzanie zależności integruje się z popularnymi narzędziami do kompilacji, w tym Ant, Maven i Gradle, oraz serwerami ciągłej integracji, takimi jak Jenkins.
Kontrola zależności raportuje wszystkie komponenty ze znanymi lukami w zabezpieczeniach z krajowej bazy danych o lukach w zabezpieczeniach (NVD) NIST i jest aktualizowana danymi z kanałów informacyjnych NVD.
Na szczęście wszystko to można zrobić automatycznie za pomocą narzędzi takich jak projekt OWASP Depency Check lub programy komercyjne, takie jak , , , Sonatyp lub .
Narzędzia te można włączyć do potoków kompilacji, aby automatycznie inwentaryzować zależności typu open source, identyfikować nieaktualne wersje bibliotek i bibliotek zawierających znane luki oraz przerywać kompilacje w przypadku wykrycia poważnych problemów.
Kontrola zależności OWASP
Aby przetestować i zademonstrować działanie sprawdzania zależności, używamy tego repozytorium .
Aby wyświetlić raport HTML, musisz skonfigurować serwer WWW 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 koniec montażu możesz zobaczyć ten obrazek:
Kliknij łącze i zobacz raport sprawdzania zależności.
Pierwszy zrzut ekranu to górna część raportu z podsumowaniem.
Szczegóły drugiego zrzutu ekranu CVE-2017-5638. Tutaj widzimy poziom CVE i linki do exploitów.
Trzeci zrzut ekranu przedstawia szczegóły log4j-api-2.7.jar. Widzimy, że poziomy CVE wynoszą 7.5 i 9.8.
Czwarty zrzut ekranu przedstawia szczegóły pliku commons-fileupload-1.3.2.jar. Widzimy, że poziomy CVE wynoszą 7.5 i 9.8.
Jeśli chcesz korzystać ze stron gitlab, to nie zadziała - upadłe zadanie nie utworzy artefaktu.
Przykład tutaj .
Wyniki kompilacji: brak artefaktów, nie widzę raportu HTML. Powinieneś wypróbować Artefakt: zawsze
Regulowanie poziomu podatności CVE
Najważniejsza linia w pliku gitlab-ci.yaml:
mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7Za pomocą parametru FailBuildOnCVSS możesz dostosować poziom podatności CVE, na który musisz zareagować.
Pobieranie bazy danych o lukach w zabezpieczeniach NIST (NVD) z Internetu
Czy zauważyłeś, że NIST stale pobiera bazy danych NIST o lukach w zabezpieczeniach (NVD) z Internetu:
Aby pobrać, możesz skorzystać z narzędzia
Zainstalujmy i uruchommy.
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 przesyła NIST JSON CVE do /var/www/repos/nist-data-mirror/ podczas uruchamiania i aktualizuje dane co 24 godziny.
Aby pobrać CVE JSON NIST, musisz skonfigurować serwer WWW Nginx (na przykład na swoim gitlab-runner).
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 robić długiej kolejki przy uruchomieniu mvn, przeniesiemy parametry do osobnej zmiennej DEPENDENCY_OPTS.
Ostateczna minimalna konfiguracja .gitlab-ci.yml będzie wyglądać następująco:
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
Źródło: www.habr.com