Ola, agora que já passamos pelo problema do Log4j (CVE-2021-44228) que colocou em evidencia o tema de como uma biblioteca compartilhada pode criar uma vulnerabilidade de alto risco para os sistemas.

Vamos falar de como isso acontece o tempo todo, com exite outras vulnerabilidades iguais ao Log4j, como isso é pior ainda para a modalidade de micro serviços e como minimizar os riscos do seu “ambiente”.

A premissa do Continuous Delivery – Fazer rápido, errar rápido e corrigir rápido, também afeta o mundo Open Source.

Hoje em dia, as empresas estão rumando para essa filosofia do “CD” de fazer rápido, errar rápido e corrigir rápido. Não me entenda mal, eu acredito que este pode ser o caminho correto.

O que a empresas (ou melhor, os profissionais de ti) muitas vezes não levam em consideração é que:

Dá mesma forma que sua empresa tem esse pensamento, os projetos Open Source também tem.

Com isso, não é incomum ver projetos fazendo versões (release) uma vez por mês ou fazendo micro versões 1 vez por semana ou mais.

E a cada nova versão, novas melhorias (features) são colocadas, novos falhas (bugs) são colocadas e “velhas falhas” são corrigidos. ~(a tradução do termo fica bem estranho – Old Bugs)~

Ou seja, ficar estacionado em uma versão de uma biblioteca externa só faz você (empresa) se tornar um alvo de vulnerabilidades. Deve ser parte do processo de desenvolvimento, também fazer as subida (bump) das versões das bibliotecas utilizadas.

Rastreando uma vulnerabilidade

Vou pegar como exemplo a vulnerabilidade CVE-2019-14379 por ser bem simples de rastrear sua utilização em um projeto Open Source.

Pelo link https://nvd.nist.gov/vuln/detail/cve-2019-14379 podemos ver que ela afeta a biblioteca jackson-databind da versão 2.9.0 até a 2.9.9.2

Pegando a versão 2.9.8, sabemos que ela esta afetada:

https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.9.8

E quem usa essa biblioteca? O Spring Boot, mais especificamente a versão 2.1.4

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot/2.1.4.RELEASE

“Ai, mas eu uso a 2.1.5”

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot/2.1.5.RELEASE

Tem vulnerabilidades também.

“Ai, mas eu uso a 2.2.10”

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot/2.2.10.RELEASE

Tem vulnerabilidade também.

O objetivo não é falar mal do Spring, e sim mostrar que vulnerabilidades existem. Qualquer biblioteca / software pode e vai estar sujeito a ter uma falha de segurança.

A ideia deste texto é te mostrar que ficar “amarrado” a uma versão de biblioteca é um serio problema. Não é porque hoje você esta começando um novo projeto, que amanhã ele não vai ter uma vulnerabilidade.

Com muitos micro serviços usando muitas bibliotecas, como analisar tudo?

Isso escala exponencialmente, em uma empresa com pouco mais que 5 aplicações já se torna inviável fazer esse acompanhamento manualmente.

Imagina ter que levantar cada versão de cada biblioteca de cada projeto, ir no CVE e procurar pra saber se tem alguma vulnerabilidade. Só de pensar em fazer isso manualmente, já me da desanimo.

Mas pra todo bom problema sempre tem uma boa solução. E a solução é o Dependency Track.

É uma ferramenta que tem com o objetivo catalogar a sua aplicação / projetos e acompanhar as vulnerabilidades lançadas para te “avisar” quando sua aplicação estiver precisando de atualizar uma biblioteca.

A solução basicamente é divida em 3 partes:

  • Dependency Track (Servidor)

  • Integration Pugins

  • SBOM Reports

Dependency Track (Servidor)

O Servidor é a parte mais simples, ele recebe os SBOM e guarda no banco de dados, faz o download da lista de CVE (Reportes de vulnerabilidade) da internet e compara para saber se bate ou não com a versão em utilização.

Tem uma interface WEB que mostra os dados da sua aplicação / projeto e quais são as biblioteca que tem CVES. Também lista quantas vulnerabilidades existem e suas respectivas criticidades:

Integrations Plugin

Os “Integrations Plugin” são bibliotecas para serem colocadas como dependências das suas aplicações / projetos para que junto com o código fonte seja possível fazer a criação do relatório de SBOM.

O time do cyclonedx.org tem um conjunto enorme de plugins open source para fazer essa integração.

SBOM Reports

O SBOM, as vezes chamados de XBOM ou só BOM, é o relatório criado pelo plugin com a lista de bibliotecas que sua aplicação utiliza.

Este é o arquivo que precisa ser enviado para o servidor do Dependency Track.

A forma mais “simples” é mandar via curl o relatório para o backend.

curl -X “PUT” “http://dtrack.example.com/api/v1/bom” \

-H ‘Content-Type: application/json’ \

-H ‘X-API-Key: LPojpCDSsEd4V9Zi6qCWr4KsiF3Konze’ \

curl -X “PUT” “http://dtrack.example.com/api/v1/bom” \ -H ‘Content-Type: application/json’ \ -H ‘X-API-Key: LPojpCDSsEd4V9Zi6qCWr4KsiF3Konze’ \ -d @payload.json

curl -X "PUT" "http://dtrack.example.com/api/v1/bom" \
     -H 'Content-Type: application/json' \
     -H 'X-API-Key: LPojpCDSsEd4V9Zi6qCWr4KsiF3Konze' \
     -d @payload.json

Incluir na sua pipeline

Você até pode rodar uma vez ou outra esse processo manualmente, só para “ver se funciona”. Mas o correto é incluir na sua pipeline de compilação de código. Assim mapeando qual é o risco que você esta levando para a sua produção.

Esse STEP também faz parte do PCI (mais precisamente item: 6.5.6).

Esse post, é mais um compartilhamento da ferramenta, pra mostrar que não é só de vulnerabilidade de Log4j que a sua aplicação pode estar insegura.

Com os dados da ferramenta, também é possível resolver os argumentos de “está funcionando não encosta” e “não temos tempo para fazer update da versão”. Pois com ela, é possível compartilhar o risco a empresa e deixar os “chefes” escolherem se vão arcar ou não com o risco.

Abraços e até o próximos.

Artigo Original