Uma parte importante do gerenciamento de vulnerabilidades é compreender e proteger completamente a cadeia de fornecimento dos componentes de software que compõem os sistemas modernos. As equipes Agile e DevOps fazem uso extensivo de bibliotecas e estruturas de código aberto para reduzir o tempo e o custo de desenvolvimento. Mas esta medalha também tem uma desvantagem: a oportunidade de herdar os erros e vulnerabilidades de outras pessoas.
Obviamente, a equipe deve saber quais componentes de código aberto estão incluídos em seus aplicativos, garantir que versões confiáveis conhecidas sejam baixadas de fontes confiáveis conhecidas e baixar versões atualizadas dos componentes após as vulnerabilidades recém-descobertas serem corrigidas.
Nesta postagem, veremos como usar o OWASP Dependency Check para abortar uma compilação se ela detectar problemas sérios com seu código.
No livro “Segurança de Desenvolvimento em Projetos Ágeis” é descrito a seguir. OWASP Dependency Check é um scanner gratuito que cataloga todos os componentes de código aberto usados em um aplicativo e mostra as vulnerabilidades que eles contêm. Existem versões para Java, .NET, Ruby (gemspec), PHP (composer), Node.js e Python, bem como para alguns projetos C/C++. Dependency Check integra-se com ferramentas de construção comuns, incluindo Ant, Maven e Gradle, e servidores de integração contínua como Jenkins.
O Dependency Check relata todos os componentes com vulnerabilidades conhecidas do National Vulnerability Database (NVD) do NIST e é atualizado com dados dos feeds de notícias do NVD.
Felizmente, tudo isso pode ser feito automaticamente usando ferramentas como o projeto OWASP Dependency Check ou programas comerciais como , , , Sonatipo ou .
Essas ferramentas podem ser incluídas em pipelines de build para inventariar automaticamente dependências de código aberto, identificar versões desatualizadas de bibliotecas e bibliotecas contendo vulnerabilidades conhecidas e abortar builds se problemas sérios forem detectados.
Verificação de dependência do OWASP
Para testar e demonstrar como funciona a Verificação de Dependência, usamos este repositório .
Para visualizar o relatório HTML, você precisa configurar o servidor web nginx em seu gitlab-runner.
Exemplo de configuração mínima do 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 {
}
}No final da montagem você pode ver esta foto:
Siga o link e veja o relatório de verificação de dependência.
A primeira captura de tela é a parte superior do relatório com um resumo.
A segunda captura de tela detalha CVE-2017-5638. Aqui vemos o nível CVE e links para explorações.
A terceira captura de tela contém detalhes de log4j-api-2.7.jar. Vemos que os níveis de CVE são 7.5 e 9.8.
A quarta captura de tela contém os detalhes de commons-fileupload-1.3.2.jar. Vemos que os níveis de CVE são 7.5 e 9.8.
Se você quiser usar páginas do gitlab, isso não funcionará - uma tarefa perdida não criará um artefato.
Exemplo aqui .
Resultado da compilação: sem artefatos, não vejo o relatório HTML. Você deveria tentar Artefato: sempre
Regulando o nível de vulnerabilidades CVE
A linha mais importante no arquivo gitlab-ci.yaml:
mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7Com o parâmetro failBuildOnCVSS você pode ajustar o nível de vulnerabilidades CVE às quais você precisa responder.
Baixando o banco de dados de vulnerabilidades do NIST (NVD) da Internet
Você notou que o NIST baixa constantemente os bancos de dados de vulnerabilidades do NIST (NVD) da Internet:
Para fazer o download, você pode usar o utilitário
Vamos instalar e iniciá-lo.
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 carrega o NIST JSON CVE para /var/www/repos/nist-data-mirror/ na inicialização e atualiza os dados a cada 24 horas.
Para baixar CVE JSON NIST, você precisa configurar o servidor web nginx (por exemplo, em seu gitlab-runner).
Exemplo de configuração mínima do 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 não formar uma longa fila onde o mvn é iniciado, moveremos os parâmetros para uma variável separada DEPENDENCY_OPTS.
A configuração mínima final .gitlab-ci.yml ficará assim:
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