Una parte fondamentale della gestione delle vulnerabilità è comprendere bene e garantire la sicurezza della catena di approvvigionamento dei componenti software da cui sono costruiti i sistemi moderni. I team che adottano metodologie agili e DevOps utilizzano ampiamente librerie e framework open source per ridurre il tempo e i costi di sviluppo. Tuttavia, questa medaglia ha un rovescio: la possibilità di ereditare errori e vulnerabilità altrui.
È evidente che il team deve assolutamente sapere quali componenti open source sono inclusi nelle proprie applicazioni, assicurarsi che versioni note per essere sicure siano scaricate da fonti affidabili, e caricare versioni aggiornate dei componenti dopo aver corretto eventuali vulnerabilità recentemente scoperte.
In questo post esamineremo l'utilizzo di OWASP Dependency Check per interrompere la build in caso vengano rilevati problemi gravi con il tuo codice.
Nel libro "Sicurezza nello sviluppo di progetti Agile" si descrive così. OWASP Dependency Check è uno scanner gratuito che cataloga tutti i componenti open source utilizzati nell'applicazione e mostra le vulnerabilità presenti. Sono disponibili versioni per Java, .NET, Ruby (gemspec), PHP (composer), Node.js e Python, oltre a vari progetti in C/C++. Dependency Check si integra con gli strumenti di build più comuni, tra cui Ant, Maven e Gradle, e con server di integrazione continua come Jenkins.
Dependency Check riporta tutti i componenti con vulnerabilità note dalla National Vulnerability Database (NVD) del NIST e viene aggiornato sulla base dei dati provenienti dai feed di notizie NVD.
Fortunatamente, tutto questo può essere fatto automaticamente utilizzando strumenti come il progetto OWASP Dependency Check o software commerciali come , , , dell'azienda Sonatype o .
Questi strumenti possono essere integrati nei processi di build per generare automaticamente un inventario delle dipendenze open source, identificare versioni obsolete di librerie e librerie contenenti vulnerabilità note, e interrompere la build nel caso vengano rilevati problemi seri.
OWASP Dependency Check
Per testare e dimostrare il funzionamento di Dependency Check utilizziamo questo repository .
Per visualizzare il rapporto HTML è necessario configurare un server web nginx sul tuo gitlab-runner.
Esempio di configurazione minima di 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 {
}
}Alla fine della build puoi vedere un risultato simile:
Andiamo al link e vediamo il rapporto di Dependency Check.
Il primo screenshot mostra la parte superiore del rapporto con un riepilogo.
Il secondo screenshot fornisce dettagli su CVE-2017-5638. Qui vediamo il livello CVE e i link agli exploit.
Il terzo screenshot mostra i dettagli di log4j-api-2.7.jar. Mostriamo i livelli CVE 7.5 e 9.8.
Il quarto screenshot mostra i dettagli di commons-fileupload-1.3.2.jar. Mostriamo i livelli CVE 7.5 e 9.8.
Se vuoi usare gitlab pages, non è possibile: un task fallito non creerà artefatti.
Esempio qui .
Output della build: nessun artefatto, non vedo il rapporto HTML. Devi provare Artifact: always
Regolazione del livello CVE delle vulnerabilità
La riga più importante nel file gitlab-ci.yaml:
mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7Con il parametro failBuildOnCVSS puoi regolare il livello delle vulnerabilità CVE a cui rispondere.
Download dal web del database delle vulnerabilità (NVD) NIST
Hai notato che scarica continuamente i database delle vulnerabilità (NVD) NIST da internet:
Puoi utilizzare l'utilità per il download
Installiamola e avviamola.
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 scarica i CVE JSON NIST in /var/www/repos/nist-data-mirror/ all'avvio e aggiorna i dati ogni 24 ore.
Per scaricare i CVE JSON NIST devi configurare il server web nginx (ad esempio sul tuo gitlab-runner).
Esempio di configurazione minima di 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 {
}
}Per evitare di avere una lunga riga dove viene eseguito mvn, estraiamo i parametri in una variabile separata DEPENDENCY_OPTS.
Il risultato finale del file .gitlab-ci.yml sarà così:
variabili:
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:
percorsi:
- .m2/repository
verifica:
fase: 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
Fonte: habr.com
