Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Validação de vulnerabilidades com OWASP Dependency Check
Tags: owasp, dependencycheck, gradle, cve
Published: 2022-12-18 03:05:26

---
title: Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Validação de vulnerabilidades com OWASP Dependency Check
published: true
description: O que aprendi com cursos realizados e como apliquei outras técnicas conhecidas para evoluí-los
tags: owasp, dependencycheck, gradle, cve
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m8uazy3rfnxc4ha6mn6r.jpg
# published_at: 2022-12-17 22:14 +0000
---

> "Mais visibilidade é mais poder, mas mais vulnerabilidade".  Ezra Furman

Nesse sétimo post falaremos sobre vulnerabilidades em bibliotecas. Se você trabalha com Java há algum tempo, creio que a vulnerabilidade do log4j possa ter te dado algumas dores de cabeça.

{% embed https://www.youtube.com/watch?v=RnRXNN6S8XQ %}

{% embed https://www.youtube.com/watch?v=R1m7GHMmUvA %}

Como desenvolvedores, um ponto que falaremos é o que fazer quando descobrirmos um vulnerabilidade. Lembre-se que:

> "Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada". H L Mencken

Esse artigo faz parte de uma série, abaixo é possível encontrar a [lista completa de artigos](#serie_completa).

Estamos nos baseando no curso [Desenvolvimento web com Quarkus](https://www.udemy.com/course/des-web-quarkus) do @viniciusfcf.

O repositório que estamos utilizando é:

{% embed https://gitlab.com/arthurfnsc-udemy/desenvolvimento-web-quarkus/ifood/ %}

---

## Vulnerabilidades

Em TI temos uma máxima de que não existe sistema perfeito! Mesmo soluções que funcionam sem nenhum problema aparente podem apresentar problemas desconhecidos ou novos problemas dado a evolução de outras bibliotecas ou mesmo outros problemas.

O cenário do **Log4J** aconteceu recentemente, e o pessoal do [Coffee and IT](https://www.coffeeandit.store/) até fez um vídeo explicando com um viés de desenvolvimento.

{% embed https://www.youtube.com/watch?v=NHJoy-lVBMg %}

Algumas perguntas podem ficar em nossas cabeça:

* Como saber mais sobre vulnerabilidades de bibliotecas?
* O que fazer quando descobrir uma vulnerabilidade em meu código?
* Será que consigo automatizar de alguma forma a descoberta dessas vulnerabilidades?
* Dentre outras

### OWASP e CVE

Um dos pontos de início pode ser a **OWASP** (The Open Web Application Security Project).

{% embed https://owasp.org/ %}

A **OWASP** é uma fundação sem fins lucrativos que trabalha para melhorar a segurança do software. Eles possuem **Chapters** em vários países, bem como realizam uma série de eventos com esse foco.

Uma de suas publicações mais conhecidas é o **OWASP Top Ten** em que são documentadas as 10 maiores vulnerabilidades dados um período de tempo.

{% embed https://owasp.org/www-project-top-ten/ %}

Outro termo que falaremos também é o [CVE](https://cve.mitre.org/) (Common Vulnerabilities and Exposures). No [Maven Repo](https://mvnrepository.com/) é bem comum ver uma observação quando estamos buscando uma biblioteca.

Note que a [versão 2.15.0.Final do Quarkus JUnit 5](https://mvnrepository.com/artifact/io.quarkus/quarkus-junit5/2.15.0.Final) nos apresenta alguns alertas:

![quarkus-junit5 vulnerabilities](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/daqzo66lahycols05ul0.png)

Olhando um pouco mais para as versões do **quarkus-junit5** podemos ver que para a versão 2 do **Quarkus** ainda não temos nenhuma correção para essas vulnerabilidades.

![quarkus-junit5 versions](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6tmx47okx7um8omaojhp.png)

### Estou vulnerável, e agora?

{% embed https://giphy.com/gifs/dexter-showtime-new-blood-dexter-OjmuV9ZKkM5qoSTQ8c %}

Um insight legal que recomendo a todos desenvolvedores é: converse com pessoas de outras áreas para formar uma opinião.

Como desenvolvedores é bem comum acharmos vulnerabilidades e já pensarmos em subir novas versões ou já colocar a mão no código.

Há uns anos atrás tive uma conversa com o [Bruno Almeida](https://www.linkedin.com/in/brunoslalmeida/) na [ília Digital](https://ilia.digital/); ele por ter um background em segurança me fez exatamente essa pergunta, questionando sobre o que eu faria.

Falei que iria atualizar as bibliotecas, alterar o código e coisas do tipo.

Ele então me trouxe um outro ponto de vista bem interessante: Será que preciso atualizar o código? Será que a vulnerabilidade que tenho é passível de ser explorada? Algumas vezes trabalhamos com APIs e diversas camadas como **microservices**, **API Gateway** dentre outras, e pode ser que uma fez configurado algo em uma camada superior, não seja passível de se explorar a vulnerabilidade.

O ponto então que ficou em minha mente foi: é importante descobrir as vulnerabilidades que estamos expostos, em seguida entender se essas vulnerabilidades são passíveis de serem exploradas, e caso sejam passíveis de serem exploradas, analisar o impacto de correção nos pontos de nossa solução em que tal vulnerabilidade pode ser explorada.

### Automatizando a descoberta de possíveis vulnerabilidades

A **OWASP** tem um projeto bem interessante, o **Dependency-Check**.

{% embed https://owasp.org/www-project-dependency-check/ %}

Ele possui uma série de plugins e integrações que podemos usar para descobrir **CVEs** no nosso projeto.

No arquivo **build.gradle** do nosso projeto podemos ver a primeira parte da configuração do plugin:

```groovy
plugins {
    ...
    id "org.owasp.dependencycheck" version "$dependencyCheckVersion" apply false
}

...

subprojects {
    if (it.name != 'applications') {
        ...
        apply from: "$rootDir/plugins/security.gradle"
    }
}
```

E no arquivo **plugins/security.gradle** podemos ver a segunda parte da configuração:

```groovy
apply plugin: "org.owasp.dependencycheck"

dependencyCheck {
    autoUpdate = true
    format = "ALL"
    outputDirectory = "build/reports/dependencyCheck"
}

```

Para a lista de demais configurações, acesse o [link](https://jeremylong.github.io/DependencyCheck/dependency-check-gradle/configuration.html).

A task que iremos utilizar para executar o plugin será a **dependencyCheckAnalyze**

Essa task busca as vulnerabilidades associadas a nossas dependências e nos da um detalhamento.

![Dependency Check](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eld9te9e6lurdywnvqoz.png)

Abrindo o arquivo **dependency-check-report.html** temos o seguinte:

![dependency-check-report.html](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2qoukrr1n2fp5dvu8m37.png)

Além de informar as bibliotecas que temos vulnerabilidades, o plugin consegue obter mais detalhes sobre o problema, situações em que ele acontece e às vezes até direcionamentos sobre a solução. No caso da venerabilidade no **okhttp-3.14.9.jar** temos:

![okhttp-3.14.9.jar](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kft7u09u2ua96l9bdk5v.png)

> In verifyHostName of OkHostnameVerifier.java, there is a possible way to accept a certificate for the wrong domain due to improperly used crypto. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.1 Android-9 Android-10 Android-11Android ID: A-171980069

### Integração com SonarQube

Outra coisa que podemos fazer é instalar o plugin no nosso [SonarQube](https://www.sonarqube.org/) e assim termos uma rastreabilidade de vulnerabilidades como parte do nosso relatório do projeto.

{% embed https://github.com/dependency-check/dependency-check-sonar-plugin %}

### Ignorando falsos positivos

É possível ainda ignorar falsos positivos através da configuração **suppressionFile**.

{% embed https://jeremylong.github.io/DependencyCheck/general/suppression.html %}

---

## Conclusão

O **OWASP Dependency Check** é um plugin fantástico que pode nos ajudar na descoberta de vulnerabilidades em nossos projetos. Uma consideração é avaliarmos o impacto de tais vulnerabilidades em nossos códigos, além do custo de correção caso seja o nosso caso.

No próximo post falaremos do último plugin utilizado no projeto. Ele será bem importante para formatação do nosso código **Groovy**, **Java**, **SQL**, dentre outros.

---

<a name="serie_completa"></a>

Esse post faz parte de uma série sobre **Cursos que formaram meu caráter: Desenvolvimento web com Quarkus**.

A série completa é:

* [Talk is cheap show me the code](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-talk-is-cheap-show-me-the-code-2k91)
* [Utilizando Gradle ao invés de Maven](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-utilizando-gradle-ao-inves-de-maven-1lcn)
* [Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-gerenciador-de-versoes-de-bibliotecas-com-versions-9na)
* [Plugins do Gradle: Saudades do  Maven, relatórios com Project-report](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-saudades-do-maven-relatorios-com-project-report-51d6)
* [Plugins do Gradle: API First com o OpenAPI Generator](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-api-first-com-o-openapi-generator-42pm)
* [Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-api-first-com-o-openapi-generator-para-apis-reativas-3o9b)
* Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
* Plugins do Gradle: Lint com Spotless [não publicado]
* GitLab: Motivação para a escolha [não publicado]
* GitLab: Considerações sobre o Prettier em pipelines [não publicado]
* Gitmoji [não publicado]
* SDK Man [não publicado]
* Pré commit hook [não publicado]
* application.yml: Utilizando YML em propriedades de aplicação [não publicado]
* application.yml: Utilizando variáveis de ambiente [não publicado]
* application.yml: Sobrescrevendo opções em teste [não publicado]
* Mapstruct: Utilizando expressões para mapeamentos [não publicado]
* Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
* Prometheus: O problema simples que me custou algumas horas [não publicado]
* quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
* Testcontainers: Configuração para projetos reativos [não publicado]