Unha parte importante da xestión de vulnerabilidades é comprender e asegurar a fondo a cadea de subministración dos compoñentes de software que compoñen os sistemas modernos. Os equipos Agile e DevOps fan un uso extensivo de bibliotecas e marcos de código aberto para reducir o tempo e o custo de desenvolvemento. Pero esta medalla tamén ten unha desvantaxe: a oportunidade de herdar os erros e as vulnerabilidades doutras persoas.
Obviamente, o equipo debe asegurarse de saber que compoñentes de código aberto están incluídos nas súas aplicacións, asegurarse de que as versións fiables coñecidas se descargan de fontes fiables coñecidas e descargar versións actualizadas dos compoñentes despois de que se parcheen as vulnerabilidades recentemente descubertas.
Nesta publicación, analizaremos o uso de OWASP Dependency Check para abortar unha compilación se detecta problemas graves co teu código.
No libro "Seguridade de desenvolvemento en proxectos áxiles" descríbese do seguinte xeito. OWASP Dependency Check é un escáner gratuíto que cataloga todos os compoñentes de código aberto utilizados nunha aplicación e mostra as vulnerabilidades que conteñen. Hai versións para Java, .NET, Ruby (gemspec), PHP (compositor), Node.js e Python, así como para algúns proxectos C/C++. Dependency Check intégrase con ferramentas de compilación comúns, incluíndo Ant, Maven e Gradle, e con servidores de integración continua como Jenkins.
Dependency Check informa de todos os compoñentes con vulnerabilidades coñecidas da National Vulnerability Database (NVD) do NIST e actualízase cos datos das fontes de noticias do NVD.
Por sorte, todo isto pódese facer automaticamente usando ferramentas como o proxecto OWASP Dependency Check ou programas comerciais como
Estas ferramentas pódense incluír nas canalizacións de compilación para inventariar automaticamente as dependencias de código aberto, identificar versións desactualizadas de bibliotecas e bibliotecas que conteñan vulnerabilidades coñecidas e abortar as compilacións se se detectan problemas graves.
Verificación de dependencia de OWASP
Para probar e demostrar como funciona a comprobación de dependencias, usamos este repositorio
Para ver o informe HTML, debes configurar o servidor web nginx no teu gitlab-runner.
Exemplo dunha configuración mínima de 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 {
}
}
Ao final da montaxe podedes ver esta imaxe:
Siga a ligazón e consulte o informe de comprobación de dependencia.
A primeira captura de pantalla é a parte superior do informe cun resumo.
Detalles da segunda captura de pantalla CVE-2017-5638. Aquí vemos o nivel de CVE e ligazóns a exploits.
A terceira captura de pantalla é detalles de log4j-api-2.7.jar. Vemos que os niveis de CVE son 7.5 e 9.8.
A cuarta captura de pantalla son os detalles de commons-fileupload-1.3.2.jar. Vemos que os niveis de CVE son 7.5 e 9.8.
Se queres usar páxinas de gitlab, non funcionará; unha tarefa fallida non creará un artefacto.
Exemplo aquí
Saída da compilación: sen artefactos, non vexo o informe html. Deberías probar Artifact: sempre
Regulación do nivel de vulnerabilidades CVE
A liña máis importante do ficheiro gitlab-ci.yaml:
mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7
Co parámetro failBuildOnCVSS pode axustar o nivel de vulnerabilidades CVE ás que precisa responder.
Descargando a base de datos de vulnerabilidades do NIST (NVD) de Internet
Observaches que o NIST descarga constantemente as bases de datos de vulnerabilidades NIST (NVD) de Internet:
Para descargar, pode usar a utilidade
Instalémolo e lancémolo.
yum -y install yum-plugin-copr
yum copr enable antonpatsev/nist_data_mirror_golang
yum -y install nist-data-mirror
systemctl start nist-data-mirror
Nist-data-mirror carga o CVE NIST JSON en /var/www/repos/nist-data-mirror/ ao iniciar e actualiza os datos cada 24 horas.
Para descargar CVE JSON NIST, debes configurar o servidor web nginx (por exemplo, no teu gitlab-runner).
Exemplo dunha configuración mínima de 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 {
}
}
Para non facer unha liña longa onde se lance mvn, moveremos os parámetros a unha variable separada DEPENDENCY_OPTS.
A configuración mínima final .gitlab-ci.yml terá o seguinte aspecto:
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: www.habr.com