Una parte importante della gestione delle vulnerabilità è comprendere a fondo e proteggere la catena di fornitura dei componenti software che compongono i sistemi moderni. I team Agile e DevOps fanno ampio uso di librerie e framework open source per ridurre tempi e costi di sviluppo. Ma questa medaglia ha anche uno svantaggio: l’opportunità di ereditare gli errori e le vulnerabilità di altre persone.
Ovviamente, il team dovrebbe essere sicuro di sapere quali componenti open source sono inclusi nelle sue applicazioni, assicurarsi che le versioni affidabili conosciute vengano scaricate da fonti affidabili conosciute e scaricare versioni aggiornate dei componenti dopo che le vulnerabilità appena scoperte sono state risolte.
In questo post esamineremo l'utilizzo del controllo delle dipendenze OWASP per interrompere una build se rileva problemi seri con il codice.
Nel libro “Sicurezza dello sviluppo nei progetti agili” viene descritto come segue. OWASP Dependency Check è uno scanner gratuito che cataloga tutti i componenti open source utilizzati in un'applicazione e mostra le vulnerabilità in essi contenute. Esistono versioni per Java, .NET, Ruby (gemspec), PHP (compositore), Node.js e Python, nonché per alcuni progetti C/C++. Dependency Check si integra con strumenti di creazione comuni, tra cui Ant, Maven e Gradle, e server di integrazione continua come Jenkins.
Il controllo delle dipendenze segnala tutti i componenti con vulnerabilità note dal National Vulnerability Database (NVD) del NIST e viene aggiornato con i dati provenienti dai feed di notizie NVD.
Fortunatamente, tutto questo può essere fatto automaticamente utilizzando strumenti come il progetto OWASP Dependency Check o programmi commerciali come , , , Sonatipo o .
Questi strumenti possono essere inclusi nelle pipeline di build per inventariare automaticamente le dipendenze open source, identificare versioni obsolete di librerie e librerie contenenti vulnerabilità note e interrompere le build se vengono rilevati problemi gravi.
Controllo delle dipendenze OWASP
Per testare e dimostrare come funziona il controllo delle dipendenze, utilizziamo questo repository .
Per visualizzare il report HTML, devi configurare il server web nginx sul tuo gitlab-runner.
Esempio di configurazione nginx minima:
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 {
}
}Al termine dell’assemblea potete vedere questa immagine:
Segui il collegamento e visualizza il rapporto Controllo dipendenze.
Il primo screenshot è la parte superiore del report con un riepilogo.
Dettagli della seconda schermata CVE-2017-5638. Qui vediamo il livello CVE e i collegamenti agli exploit.
Il terzo screenshot mostra i dettagli di log4j-api-2.7.jar. Vediamo che i livelli CVE sono 7.5 e 9.8.
Il quarto screenshot contiene i dettagli di commons-fileupload-1.3.2.jar. Vediamo che i livelli CVE sono 7.5 e 9.8.
Se desideri utilizzare le pagine gitlab, non funzionerà: un'attività interrotta non creerà un artefatto.
Esempio qui .
Output di build: nessun artefatto, non vedo il report html. Dovresti provare Artifact: sempre
Regolamentazione del livello di vulnerabilità CVE
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 di vulnerabilità CVE a cui devi rispondere.
Download del database delle vulnerabilità del NIST (NVD) da Internet
Hai notato che il NIST scarica costantemente i database delle vulnerabilità NIST (NVD) da Internet:
Per scaricare è possibile utilizzare l'utility
Installiamolo e avviamolo.
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 carica il NIST JSON CVE su /var/www/repos/nist-data-mirror/ all'avvio e aggiorna i dati ogni 24 ore.
Per scaricare CVE JSON NIST, è necessario configurare il server web nginx (ad esempio, sul tuo gitlab-runner).
Esempio di configurazione nginx minima:
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 non creare una lunga fila in cui viene lanciato mvn, sposteremo i parametri in una variabile separata DEPENDENCY_OPTS.
La configurazione minima finale .gitlab-ci.yml sarà simile a questa:
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
Fonte: habr.com