Uma parte importante da gestão de vulnerabilidades é entender bem e garantir a segurança da cadeia de suprimentos dos componentes de software que compõem os sistemas modernos. As equipes que praticam metodologias ágeis e DevOps frequentemente utilizam bibliotecas e frameworks de código aberto para reduzir o tempo e o custo de desenvolvimento. Mas essa medalha tem um lado negativo: a possibilidade de herdar erros e vulnerabilidades de terceiros.
É evidente que a equipe deve saber quais componentes de código aberto estão incluídos em suas aplicações, garantir que versões confiáveis sejam baixadas de fontes seguras e carregar versões atualizadas dos componentes após a correção de vulnerabilidades recém-descobertas.
Neste post, vamos discutir o uso do OWASP Dependency Check para interromper a construção em caso de descoberta de problemas sérios em seu código.
No livro ‘Segurança no Desenvolvimento de Projetos Ágeis’ é descrito da seguinte maneira. O OWASP Dependency Check é um scanner gratuito que catalogará todos os componentes de código aberto utilizados na aplicação e mostrará as vulnerabilidades que eles possuem. Existem versões para Java, .NET, Ruby (gemspec), PHP (composer), Node.js e Python, bem como para alguns projetos em C/C++. O Dependency Check integra-se com ferramentas de construção populares, como Ant, Maven e Gradle, e servidores de integração contínua como Jenkins.
O Dependency Check informa sobre todos os componentes com vulnerabilidades conhecidas da National Vulnerability Database (NVD) do NIST e é atualizado com base em dados de feeds de notícias da NVD.
Felizmente, tudo isso pode ser feito automaticamente com ferramentas como o projeto OWASP Dependency Check ou programas comerciais como , , , da empresa Sonatype ou .
Essas ferramentas podem ser integradas aos pipelines de construção para compilar automaticamente um inventário de dependências de código aberto, identificar versões desatualizadas de bibliotecas e bibliotecas que contêm vulnerabilidades conhecidas, e interromper a construção em caso de problemas sérios.
OWASP Dependency Check
Para testar e demonstrar o funcionamento do Dependency Check, usamos este repositório .
Para visualizar o relatório HTML, é necessário configurar um 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 construção, você pode ver esta imagem:
Vamos ao link e vemos o relatório do Dependency Check.
A primeira captura de tela — a parte superior do relatório com um resumo.
A segunda captura de tela detalha o CVE-2017-5638. Aqui vemos o nível CVE e links para exploits.
A terceira captura de tela — detalhes do log4j-api-2.7.jar. Vemos que os níveis CVE são 7.5 e 9.8.
A quarta captura de tela — detalhes do commons-fileupload-1.3.2.jar. Vemos que os níveis CVE são 7.5 e 9.8.
Se você deseja usar gitlab pages, isso não será possível — uma tarefa falhada não criará um artefato.
Exemplo aqui .
Saída da construção: não há artefatos, não vejo o relatório em html. É necessário tentar Artifact: always.
Regulamentação do nível CVE de vulnerabilidades
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 regular o nível CVE das vulnerabilidades que precisam ser abordadas.
Download da base de dados de vulnerabilidades (NVD) da NIST
Você notou que está constantemente baixando bases de dados de vulnerabilidades (NVD) da NIST da internet:
Para download, você pode usar a ferramenta
Vamos instalar e executá-la.
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 baixa o CVE JSON da NIST para /var/www/repos/nist-data-mirror/ ao iniciar e atualiza os dados a cada 24 horas.
Para baixar o CVE JSON da NIST, é necessário configurar o servidor web nginx (por exemplo, no 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 fazer uma linha longa onde mvn é executado, vamos extrair os parâmetros para uma variável separada DEPENDENCY_OPTS.
O resultado final do mínimo .gitlab-ci.yml será assim:
variáveis:
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
