A importância da análise de componentes de software de terceiros (em inglês, Software Composition Analysis — SCA) no processo de desenvolvimento cresce à medida que novos relatórios anuais sobre vulnerabilidades de bibliotecas open source são publicados por empresas como Synopsys, Sonatype, Snyk e White Source. De acordo com o relatório o número de vulnerabilidades identificadas em open source em 2019 aumentou quase 1,5 vezes em comparação ao ano anterior, enquanto componentes de código aberto são usados em 60% a 80% dos projetos. Se considerarmos a opinião independente, os processos SCA são uma prática separada do OWASP SAMM e do BSIMM como indicador de maturidade, e na primeira metade de 2020, o OWASP lançou um novo padrão, o OWASP Software Component Verification Standard (SCVS), que fornece melhores práticas para a verificação de componentes de terceiros na cadeia de suprimento de software.
Um dos casos mais emblemáticos com a empresa Equifax em maio de 2017. Criminosos desconhecidos obtiveram informações de 143 milhões de americanos, incluindo nomes completos, endereços, números de seguro social e carteiras de motorista. Em 209 mil casos, também havia informações sobre cartões de crédito das vítimas nos documentos. Esse vazamento ocorreu devido à exploração de uma vulnerabilidade crítica no Apache Struts 2 (CVE-2017-5638), enquanto a correção foi lançada em março de 2017. A empresa teve dois meses para implementar a atualização, mas ninguém se preocupou com isso.
Neste artigo, será discutida a escolha da ferramenta para realizar SCA do ponto de vista da qualidade dos resultados da análise. Também será feita uma comparação funcional das ferramentas. O processo de integração em CI/CD e as capacidades de integração serão abordados em publicações futuras. Uma ampla lista de ferramentas foi apresentada pelo OWASP , mas no âmbito da atual revisão, iremos abordar apenas a ferramenta open source mais popular, Dependency Check, a plataforma open source um pouco menos conhecida, Dependency Track, e a solução Enterprise Sonatype Nexus IQ. Também analisaremos como essas soluções funcionam e compararemos os resultados obtidos quanto a falsos positivos.
Princípio de funcionamento
— é uma ferramenta (CLI, módulo maven, jenkins, ant) que analisa os arquivos do projeto, coleta fragmentos de informações sobre dependências (nome do pacote, groupid, título da especificação, versão…), constrói uma string CPE — (Common Platform Enumeration), Package URL (PURL) e identifica vulnerabilidades para CPE/PURL a partir de bancos de dados (NVD, Sonatype OSS Index, NPM Audit API…), após o que gera um relatório único nos formatos HTML, JSON, XML…
Vamos ver como é o CPE:
cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other- Part: Indicação de que o componente se refere a um aplicativo (a), sistema operacional (o), hardware (h) (Item obrigatório)
- Vendor: Nome do fabricante do produto (Item obrigatório)
- Product: Nome do produto (Item obrigatório)
- Version: Versão do componente (Item obsoleto)
- Update: Atualização do pacote
- Edition: Versão herdada (Item obsoleto)
- Language: Idioma definido no RFC-5646
- SW Edition: Versão de software
- Target SW: Ambiente de software em que o produto opera
- Target HW: Ambiente de hardware em que o produto opera
- Other: Informações sobre o fornecedor ou produto
Um exemplo de CPE é o seguinte:
cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:* A string significa que o CPE versão 2.3 descreve um componente de aplicativo do fabricante pivotal_software com o nome spring_framework versão 3.0.0. Se abrirmos a vulnerabilidade no NVD, podemos ver a menção a esse CPE. O primeiro problema ao qual devemos prestar atenção é que o CVE no NVD, de acordo com o CPE, informa sobre uma vulnerabilidade no framework, e não em um componente específico. Ou seja, se os desenvolvedores estão intimamente ligados ao framework e a vulnerabilidade identificada não afeta os módulos que os desenvolvedores utilizam, o especialista em segurança terá que analisar esse CVE e considerar uma atualização.
O URL também é utilizado por ferramentas SCA. O formato do URL do pacote é o seguinte:
scheme:type/namespace/name@version?qualifiers#subpath- Sсheme: Sempre será ‘pkg’, indicando que este é o URL do pacote (Item obrigatório)
- Type: Tipo do pacote ou protocolo do pacote, por exemplo, maven, npm, nuget, gem, pypi etc. (Item obrigatório)
- Namespace: Algum prefixo do nome, como o identificador do grupo Maven, proprietário da imagem Docker, usuário ou organização do GitHub. Opcional e depende do tipo.
- Name: Nome do pacote (Item obrigatório)
- Version: Versão do pacote
- Qualifiers: Dados qualificativos adicionais para o pacote, como sistema operacional, arquitetura, distribuição, etc. Opcional e dependente do tipo de item.
- Subcaminho: Caminho adicional no pacote em relação ao raiz do pacote
Por exemplo:
pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/io@1.3.4
pkg:pypi/django-package@1.11.1.dev1— plataforma web on-premise que aceita Bill of Materials (BOM) prontos e , ou seja, especificações prontas sobre as dependências existentes. Este é um arquivo XML que descreve as dependências — nome, hashes, URL do pacote, editor, licença. Em seguida, o Dependency Track analisa o BOM, verifica as dependências identificadas em busca de CVEs em um banco de dados de vulnerabilidades (NVD, Sonatype OSS Index …), após o que constrói gráficos, calcula métricas, atualizando regularmente as informações sobre o status das vulnerabilidades dos componentes.
Um exemplo de como um BOM pode parecer em formato XML:
Apache
org.apache.tomcat
tomcat-catalina
9.0.14
3942447fac867ae5cdb3229b658f4d48
e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a
f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b
e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282
Apache-2.0
pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14
O BOM pode ser utilizado não apenas como parâmetros de entrada para o Dependency Track, mas também para inventariar componentes de software na cadeia de suprimento, por exemplo, para fornecer ao cliente do software. Em 2014, um projeto de lei foi até proposto nos EUA , que estipulava que ao adquirir software, qualquer órgão público deveria solicitar um BOM para evitar o uso de componentes vulneráveis, no entanto, o ato não foi implementado.
Voltando ao SCA, o Dependency Track tem integrações prontas com Plataformas de Notificação como Slack, sistemas de gerenciamento de vulnerabilidades como Kenna Security. Vale também mencionar que o Dependency Track identifica versões desatualizadas de pacotes e fornece informações sobre licenças (graças ao suporte a SPDX).
Quando se trata de qualidade SCA, há uma diferença fundamental aqui.
O Dependency Track não aceita um projeto como entrada, mas sim um BOM. Isso significa que, se quisermos verificar um projeto, primeiro precisamos gerar um bom.xml, por exemplo, usando o CycloneDX. Assim, o Dependency Track depende diretamente do CycloneDX. Ao mesmo tempo, isso permite personalização. A equipe da OZON escreveu para construir arquivos BOM para projetos em Golang com o objetivo de posterior varredura através do Dependency Track.
é uma solução comercial de SCA da Sonatype, que faz parte do ecossistema Sonatype, que também inclui o Nexus Repository Manager. O Nexus IQ pode aceitar como entrada tanto arquivos war (para projetos Java) através da interface web ou API, quanto BOM, se sua organização não tiver conseguido migrar do CycloneDX para a nova solução. Ao contrário das soluções de código aberto, o IQ não apenas consulta o CP/PURL do componente identificado e a vulnerabilidade correspondente no banco de dados, mas também considera pesquisas próprias, como o nome da função ou classe vulnerável. Os mecanismos do IQ serão discutidos mais tarde ao analisar os resultados.
Vamos resumir algumas conclusões sobre as características funcionais, bem como revisar as linguagens suportadas para análise:
Linguagem
Nexus IQ
Dependency Check
Dependency Track
Java
+
+
+
C/C++
+
+
—
C#
+
+
—
.Net
+
+
+
Erlang
—
—
+
JavaScript (NodeJS)
+
+
+
PHP
+
+
+
Python
+
+
+
Ruby
+
+
+
Perl
—
—
—
Scala
+
+
+
Objective C
+
+
—
Swift
+
+
—
R
+
—
—
Go
+
+
+
Funcionalidades
Funcionalidades
Nexus IQ
Dependency Check
Dependency Track
Capacidade de garantir a verificação de componentes usados no código-fonte quanto à conformidade de licenciamento
+
—
+
Capacidade de escanear e analisar em busca de vulnerabilidades e conformidade de licenciamento para imagens Docker
+ Integração com Clair
—
—
Capacidade de configurar políticas de segurança para o uso de bibliotecas de código aberto
+
—
—
Capacidade de escanear repositórios de código aberto em busca de componentes vulneráveis
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi
Existência de um grupo de pesquisa especializado
+
—
—
Operação em contornos fechados
+
+
+
Uso de bancos de dados de terceiros
+ Banco de dados privado da Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, suporte a banco de dados de vulnerabilidades próprio
Capacidade de filtrar componentes de código aberto ao tentar carregá-los no contorno de desenvolvimento de acordo com as políticas configuradas
+
—
—
Recomendações para corrigir vulnerabilidades, com links para a correção
+
+- (depende da descrição em bases públicas)
+- (depende da descrição em bases públicas)
Classificação das vulnerabilidades detectadas por grau de criticidade
+
+
+
Modelo de acesso baseado em funções
+
—
+
Suporte à interface de linha de comando CLI
+
+
+- (apenas para CycloneDX)
Seleção / ordenação de vulnerabilidades de acordo com critérios definidos
+
—
+
Dashboard do estado das aplicações
+
—
+
Geração de relatórios em formato PDF
+
—
—
Geração de relatórios em formato JSONCSV
+
+
—
Suporte ao idioma russo
—
—
—
Oportunidades de integração
Integração
Nexus IQ
Dependency Check
Dependency Track
Integração com LDAP / Active Directory
+
—
+
Integração com o sistema de integração contínua (continous integration) Bamboo
+
—
—
Integração com o sistema de integração contínua (continous integration) TeamCity
+
—
—
Integração com o sistema de integração contínua (continous integration) GitLab
+
+- (na forma de um plugin para GitLab)
+
Integração com o sistema de integração contínua (continous integration) Jenkins
+
+
+
Disponibilidade de plugins para IDE
+ IntelliJ, Eclipse, Visual Studio
—
—
Suporte à integração personalizada através de web-services (API) da ferramenta
+
—
+
Dependency Check
Primeira execução
Iremos executar o Dependency Check em uma aplicação intencionalmente vulnerável .
Para isso, utilizaremos :
mvn org.owasp:dependency-check-maven:checkComo resultado, o arquivo dependency-check-report.html aparecerá no diretório target.
Abriremos o arquivo. Após as informações gerais sobre o número total de vulnerabilidades, podemos ver informações sobre vulnerabilidades de alto nível de severidade e confiança, indicando pacote, CPE e número CVE.
Em seguida, vem informações mais detalhadas, incluindo a base para a decisão tomada (evidence), ou seja, um BOM.
Depois, temos CPE, PURL e descrição do CVE. As recomendações para correção não estão incluídas, pois não existem na base NVD.
Para uma visualização sistemática dos resultados da varredura, pode-se configurar o Nginx com configurações mínimas ou enviar os defeitos obtidos para um sistema de gerenciamento de defeitos que suporte conectores para o Dependency Check. Por exemplo, o Defect Dojo.
Dependency Track
Instalação
Dependency Track, por sua vez, é uma plataforma web com gráficos, portanto, a questão crítica do armazenamento de defeitos em uma solução externa não é relevante aqui.
Os seguintes cenários suportados estão disponíveis para instalação: Docker, WAR, Executable WAR.
Primeira execução
Acesse a URL do serviço iniciado. Entre com admin/admin, altere o login e senha, após o que você terá acesso ao Dashboard. A próxima ação será criar um projeto para um aplicativo de teste em Java em Home/Projects → Criar Projeto Como exemplo, vamos usar DVJA.
Como o Dependency Track pode aceitar apenas BOM como entrada, precisamos obter esse BOM. Vamos usar :
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBomObtemos bom.xml e carregamos o arquivo no projeto criado DVJA → Dependências → Carregar BOM.
Vamos em Administração → Analisadores. Sabemos que temos apenas o Analisador Interno ativado, que inclui o NVD. Também conectaremos o Sonatype OSS Index.
Assim, teremos a seguinte visão para nosso projeto:
Também na lista podemos encontrar uma vulnerabilidade aplicável ao Sonatype OSS:
A principal decepção foi que o Dependency Track não aceita mais relatórios em xml do Dependency Check. As últimas versões suportadas de integração com o Dependency Check foram 1.0.0 — 4.0.2, enquanto testei a 5.3.2.
Aqui (e ), quando isso ainda era possível.
Nexus IQ
Primeira execução
A instalação do Nexus IQ é feita a partir de arquivos compactados , mas nós, para esses fins, criamos uma imagem Docker.
Após entrar no console, é necessário criar uma Organização e um Aplicativo.
Como podemos ver, a configuração no caso do IQ é um pouco mais complicada, pois também precisamos criar políticas aplicáveis para diferentes “estágios” (dev, build, stage, release). Isso é necessário para bloquear componentes vulneráveis à medida que avançamos pelo pipeline em direção à produção, ou para bloquear assim que eles entram no Nexus Repo ao serem baixados pelos desenvolvedores.
Para sentir a diferença entre open source e enterprise, realizaremos a mesma varredura através do Nexus IQ, de forma semelhante a , criando previamente um aplicativo de teste na interface do NexusIQ dvja-test-and-compare:
mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl= -Dclm.username= -Dclm.password=
Acessamos a URL do relatório gerado na interface web do IQ:
Aqui podemos ver todas as violações de política com diferentes níveis de gravidade (de Info a Security Critical). A letra D ao lado do componente significa que ele é uma Dependência Direta, enquanto a letra T ao lado do componente indica que ele é uma Dependência Transitiva.
Aliás, o relatório da Snyk informa que mais de 70% das vulnerabilidades de open source encontradas em Node.js, Java e Ruby estão em dependências transitivas.
Ao abrir uma das violações da política Nexus IQ, podemos ver a descrição do componente, bem como o Gráfico de Versões, que mostra a localização da versão atual em uma linha do tempo, além de quando a vulnerabilidade deixa de ser vulnerável. A altura das velas no gráfico indica a popularidade do uso deste componente.
Se você acessar a seção de vulnerabilidades e expandir o CVE, pode ler a descrição dessa vulnerabilidade, as recomendações para mitigação e a razão pela qual este componente foi classificado como uma violação, ou seja, a presença do tipo DiskFileitem.class.
Vamos resumir apenas os componentes externos do Java, removendo os componentes js. Entre parênteses, indicaremos o número de vulnerabilidades que foram encontradas fora da NVD.
Total do Nexus IQ:
- Dependências Analisadas: 62
- Dependências Vulneráveis: 16
- Vulnerabilidades Encontradas: 42 (8 banco de dados sonatype)
Total da Verificação de Dependências:
- Dependências Analisadas: 47
- Dependências Vulneráveis: 13
- Vulnerabilidades Encontradas: 91 (14 sonatype oss)
Total do Monitoramento de Dependências:
- Dependências Analisadas: 59
- Dependências Vulneráveis: 10
- Vulnerabilidades Encontradas: 51 (1 sonatype oss)
No próximo passo, analisaremos os resultados obtidos e entenderemos quais dessas vulnerabilidades representam um defeito real e quais são falsos positivos.
Isenção de responsabilidade
Esta revisão não é uma verdade indiscutível. O autor não pretendia destacar uma ferramenta em particular em relação a outras. O objetivo da revisão era mostrar os mecanismos de funcionamento das ferramentas SCA e as maneiras de verificar seus resultados.
Comparação de Resultados
Condições:
Um falso positivo em relação a vulnerabilidades de componentes externos é:
- Incongruência do CVE com o componente identificado
- Por exemplo, se uma vulnerabilidade é identificada no framework struts2 e a ferramenta indica o componente do framework struts-tiles, que não está relacionado a essa vulnerabilidade, isso é um falso positivo.
- Incongruência do CVE com a versão identificada do componente
- Por exemplo, uma vulnerabilidade está associada a versões do python > 3.5 e a ferramenta marca a versão 2.7 como vulnerável — isso é um falso positivo, pois a vulnerabilidade realmente se aplica apenas à linha do produto 3.x.
- Duplicação de CVE
- Por exemplo, se a SCA indicou um CVE que permite a execução remota de código, e depois a SCA indica para o mesmo componente um CVE aplicável a produtos Cisco afetados por esse RCE. Nesse caso, será um falso positivo.
- Por exemplo, uma CVE foi encontrada no componente spring-web, após o qual a SCA indica esta mesma CVE em outros componentes do frameworks Spring Framework, enquanto a CVE não se relaciona com outros componentes. Nesse caso, haverá um falso positivo.
O objeto de estudo escolhido foi o projeto Open Source DVJA. A pesquisa envolveu apenas componentes Java (sem js).
Resultados resumidos
Vamos direto para os resultados da revisão manual das vulnerabilidades identificadas. O relatório completo para cada CVE pode ser consultado no Apêndice.
Resultados resumidos para todas as vulnerabilidades:
Parâmetro
Nexus IQ
Dependency Check
Dependency Track
Total de vulnerabilidades identificadas
42
91
51
Vulnerabilidades erroneamente identificadas (falso positivo)
2(4.76%)
62(68,13%)
29(56.86%)
Vulnerabilidades relevantes não detectadas (falso negativo)
10
20
27
Resultados resumidos por componentes:
Parâmetro
Nexus IQ
Dependency Check
Dependency Track
Total de componentes identificados
62
47
59
Total de componentes vulneráveis
16
13
10
Componentes vulneráveis erroneamente identificados (falso positivo)
1
5
0
Componentes vulneráveis erroneamente identificados (falso positivo)
0
6
6
Vamos construir gráficos visuais para avaliar a relação entre falsos positivos e falsos negativos em relação ao número total de vulnerabilidades. Os componentes estão marcados horizontalmente, e as vulnerabilidades identificadas estão marcadas verticalmente.
Para comparação, uma pesquisa similar foi conduzida pela equipe da Sonatype testando um projeto de 1531 componentes usando o OWASP Dependency Check. Como podemos ver, a proporção de ruído para acertos corretos é equivalente aos nossos resultados.
Fonte:
Vamos examinar algumas CVEs dos resultados da nossa digitalização para entender a razão desses resultados.
Saiba mais
№1
Vamos analisar primeiro alguns pontos interessantes do Sonatype Nexus IQ.
O Nexus IQ indica um problema com a desserialização com a possibilidade de executar RCE no Spring Framework várias vezes. CVE-2016-1000027 em spring-web:3.0.5 pela primeira vez, e CVE-2011-2894 em spring-context:3.0.5 e spring-core:3.0.5. A princípio, parece que há uma duplicação da vulnerabilidade por várias CVEs. Pois, ao olhar CVE-2016-1000027 e CVE-2011-2894 na base NVD, parece tudo claro.
Componente
Vulnerabilidade
spring-web:3.0.5
CVE-2016-1000027
spring-context:3.0.5
CVE-2011-2894
spring-core:3.0.5
CVE-2011-2894
Descrição do NVD:
Descrição do NVD:
A CVE-2011-2894 em si é bastante conhecida. No relatório essa CVE foi reconhecida como uma das mais frequentes. As descrições para a CVE-2016-100027 em princípio são escassas na NVD e parece se aplicar apenas ao Spring Framework 4.1.4. Vamos olhar para e aqui tudo começa a ficar mais ou menos claro. A partir da entendemos que além da vulnerabilidade em RemoteInvocationSerializingExporter na CVE-2011-2894, a vulnerabilidade também é observada em HttpInvokerServiceExporter. É isso que o Nexus IQ nos diz:
No entanto, não há nada semelhante no NVD, o que leva o Dependency Check e o Dependency Track a obter falsos negativos.
A partir da descrição do CVE-2011-2894, podemos entender que a vulnerabilidade realmente está presente tanto em spring-context:3.0.5 quanto em spring-core:3.0.5. A confirmação disso pode ser encontrada em um artigo de quem descobriu essa vulnerabilidade.
№2
Componente
Vulnerabilidade
Resultado
struts2-core:2.3.30
CVE-2016-4003
FALSE
Se analisarmos a vulnerabilidade CVE-2016-4003, entenderemos que ela foi corrigida na versão 2.3.28, no entanto, o Nexus IQ nos informa sobre ela. Na descrição da vulnerabilidade, há um aviso:
Ou seja, a vulnerabilidade existe apenas em conjunto com uma versão desatualizada do JRE, sobre a qual decidiram nos alertar. No entanto, consideramos isso um falso positivo, embora não seja o mais sério.
№ 3
Componente
Vulnerabilidade
Resultado
xwork-core:2.3.30
CVE-2017-9804
TRUE
xwork-core:2.3.30
CVE-2017-7672
FALSE
Se olharmos a descrição do CVE-2017-9804 e do CVE-2017-7672, entenderemos que o problema está na classe URLValidator, sendo que o CVE-2017-9804 decorre do CVE-2017-7672. A presença da segunda vulnerabilidade não traz nenhuma utilidade além do fato de que sua gravidade aumentou para Alta, portanto, podemos considerar isso um ruído desnecessário.
No geral, não foram encontrados outros falsos positivos para o Nexus IQ.
№4
Existem alguns pontos que destacam o IQ em comparação com outras soluções.
Componente
Vulnerabilidade
Resultado
spring-web:3.0.5
CVE-2020-5398
TRUE
O CVE no NVD informa que ele se aplica apenas às versões 5.2.x até 5.2.3, 5.1.x até 5.1.13 e versões 5.0.x até 5.0.16, no entanto, se olharmos a descrição do CVE no Nexus IQ, veremos o seguinte:
Aviso de Desvio de Assessoria: A equipe de pesquisa de segurança da Sonatype descobriu que essa vulnerabilidade foi introduzida na versão 3.0.2.RELEASE e não na 5.0.x, como afirmado na assessoria.
Após isso, segue um PoC para essa vulnerabilidade, que informa que ela está presente na versão 3.0.5.
O falso negativo é enviado para o Dependency Check e o Dependency Track.
№5
Vamos olhar os falsos positivos para o Dependency Check e o Dependency Track.
O Dependency Check se destaca por refletir os CVEs que se aplicam a todo o framework no NVD, em componentes aos quais esses CVEs não se aplicam. Isso se refere a CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, que o Dependency Check "atrelou" ao struts-taglib:1.3.8 e struts-tiles-1.3.8. Esses componentes não têm nada a ver com o que é descrito no CVE — processamento de solicitações, validação de páginas e assim por diante. Isso se deve ao fato de que a única relação entre esses CVEs e os componentes é o framework, pelo que o Dependency Check os considerou uma vulnerabilidade.
A mesma situação ocorre com spring-tx:3.0.5, e uma situação semelhante com struts-core:1.3.8. Para struts-core, o Dependency Check e o Dependency Track encontraram muitas vulnerabilidades que, na verdade, se aplicam ao struts2-core, que é essencialmente um framework separado. Nesse caso, o Nexus IQ compreendeu corretamente a situação e, nos CVEs que emitiu, indicou que o struts-core chegou ao fim da vida útil e é necessário migrar para o struts2-core.
№6
Em algumas situações, interpretar um erro explícito do Dependency Check e do Dependency Track é injusto. Em particular, CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, que o Dependency Check e o Dependency Track atribuíram ao spring-core:3.0.5, na verdade, se referem ao spring-web:3.0.5. Parte desses CVEs foi encontrada pelo Nexus IQ, e mesmo assim o IQ os identificou corretamente como pertencentes a outro componente. O fato de que essas vulnerabilidades não foram encontradas no spring-core não significa que elas não existam no framework como um todo e as ferramentas de código aberto apontaram corretamente essas vulnerabilidades (apenas erraram um pouco).
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
Como podemos ver, a validação da veracidade das vulnerabilidades detectadas por meio de revisões manuais não fornece resultados claros, o que gera momentos de controvérsia. Os resultados são que a solução Nexus IQ apresenta o menor índice de falsos positivos e a maior precisão.
Em primeiro lugar, isso se deve ao fato de que a equipe da Sonatype ampliou a descrição de cada vulnerabilidade CVE do NVD em suas bases, especificando com precisão a classe ou função da vulnerabilidade para cada versão do componente, realizando pesquisas adicionais (por exemplo, testando vulnerabilidades em versões mais antigas de software).
A influência significativa nos resultados também provém das vulnerabilidades que não foram incluídas no NVD, mas que ainda estão presentes na base da Sonatype com a anotação SONATYPE. De acordo com o relatório sobre 45% das vulnerabilidades de código aberto detectadas não são reportadas no NVD. Segundo a base de dados da WhiteSource, apenas 29% de todas as vulnerabilidades de código aberto registradas fora do NVD acabam sendo publicadas nele, portanto, é tão importante buscar vulnerabilidades também em outras fontes.
Como resultado, o Dependency Check gera muito ruído, perdendo parte dos componentes vulneráveis. O Dependency Track gera menos ruído e identifica um maior número de componentes, o que visualmente não é tão impactante na interface web.
No entanto, a prática mostra que o open source deve ser o primeiro passo em direção a um DevSecOps maduro. A primeira coisa a considerar para integrar o SCA no desenvolvimento é a criação de processos, refletindo junto à gestão e aos departamentos relacionados sobre como devem ser os processos ideais dentro da sua organização. Pode ser que, inicialmente, o Dependency Check ou o Dependency Track atendam a todas as necessidades do negócio, enquanto soluções empresariais se tornem uma progressão lógica devido ao aumento da complexidade das aplicações desenvolvidas.
Apêndice A. Resultados relacionados aos componentes
Legendas:
- High — vulnerabilidades de alto e crítico nível no componente
- Medium — vulnerabilidades de nível médio de criticidade no componente
- TRUE — vulnerabilidade corretamente identificada (True positive issue)
- FALSE — falso positivo (False positive issue)
Componente
Nexus IQ
Dependency Check
Dependency Track
Resultado
dom4j: 1.6.1
Alto
Alto
Alto
TRUE
log4j-core: 2.3
Alto
Alto
Alto
TRUE
log4j: 1.2.14
Alto
Alto
—
TRUE
commons-collections:3.1
Alto
Alto
Alto
TRUE
commons-fileupload:1.3.2
Alto
Alto
Alto
TRUE
commons-beanutils:1.7.0
Alto
Alto
Alto
TRUE
commons-codec:1:10
Medium
—
—
TRUE
mysql-connector-java:5.1.42
Alto
Alto
Alto
TRUE
spring-expression:3.0.5
Alto
componente não encontrado
TRUE
spring-web:3.0.5
Alto
componente não encontrado
Alto
TRUE
spring-context:3.0.5
Medium
componente não encontrado
—
TRUE
spring-core:3.0.5
Medium
Alto
Alto
TRUE
struts2-config-browser-plugin:2.3.30
Medium
—
—
TRUE
spring-tx:3.0.5
—
Alto
—
FALSE
struts-core:1.3.8
Alto
Alto
Alto
TRUE
xwork-core: 2.3.30
Alto
—
—
TRUE
struts2-core: 2.3.30
Alto
Alto
Alto
TRUE
struts-taglib:1.3.8
—
Alto
—
FALSE
struts-tiles-1.3.8
—
Alto
—
FALSE
Apêndice B. Resultados relacionados às vulnerabilidades
Legendas:
- High — vulnerabilidades de alto e crítico nível no componente
- Medium — vulnerabilidades de nível médio de criticidade no componente
- TRUE — vulnerabilidade corretamente identificada (True positive issue)
- FALSE — falso positivo (False positive issue)
Componente
Nexus IQ
Dependency Check
Dependency Track
Severidade
Resultado
Comentário
dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Alto
TRUE
CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Alto
TRUE
log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Alto
TRUE
CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Baixo
TRUE
log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Alto
TRUE
—
CVE-2020-9488
—
Baixo
TRUE
SONATYPE-2010-0053
—
—
Alto
TRUE
commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Alto
FALSE
Duplica RCE(OSSINDEX)
—
CVE-2017-15708
CVE-2017-15708
Alto
FALSE
Duplica RCE(OSSINDEX)
SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Alto
TRUE
commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Alto
TRUE
SONATYPE-2014-0173
—
—
Medium
TRUE
commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Alto
TRUE
—
CVE-2019-10086
CVE-2019-10086
Alto
FALSE
A vulnerabilidade é aplicável apenas para versões 1.9.2+
commons-codec:1:10
SONATYPE-2012-0050
—
—
Medium
TRUE
mysql-connector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Alto
TRUE
CVE-2019-2692
CVE-2019-2692
—
Medium
TRUE
—
CVE-2020-2875
—
Medium
FALSE
É a mesma vulnerabilidade que a CVE-2019-2692, mas com a adição "os ataques podem impactar significativamente produtos adicionais"
—
CVE-2017-15945
—
Alto
FALSE
Não se aplica ao mysql-connector-java
—
CVE-2020-2933
—
Baixo
FALSE
Duplicata da CVE-2020-2934
CVE-2020-2934
CVE-2020-2934
—
Medium
TRUE
spring-expression:3.0.5
CVE-2018-1270
componente não encontrado
—
Alto
TRUE
CVE-2018-1257
—
—
Medium
TRUE
spring-web:3.0.5
CVE-2016-1000027
componente não encontrado
—
Alto
TRUE
CVE-2014-0225
—
CVE-2014-0225
Alto
TRUE
CVE-2011-2730
—
—
Alto
TRUE
—
—
CVE-2013-4152
Medium
TRUE
CVE-2018-1272
—
—
Alto
TRUE
CVE-2020-5398
—
—
Alto
TRUE
Um exemplo ilustrativo em prol do IQ: "A equipe de pesquisa de segurança da Sonatype descobriu que essa vulnerabilidade foi introduzida na versão 3.0.2.RELEASE e não na 5.0.x, conforme afirmado no aviso."
CVE-2013-6429
—
—
Medium
TRUE
CVE-2014-0054
—
CVE-2014-0054
Medium
TRUE
CVE-2013-6430
—
—
Medium
TRUE
spring-context:3.0.5
CVE-2011-2894
componente não encontrado
—
Medium
TRUE
spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Alto
TRUE
CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medium
TRUE
—
—
CVE-2013-4152
Medium
FALSE
Duplicata desta mesma vulnerabilidade no spring-web
—
CVE-2013-4152
—
Medium
FALSE
A vulnerabilidade se aplica ao componente spring-web
—
CVE-2013-6429
CVE-2013-6429
Medium
FALSE
A vulnerabilidade se aplica ao componente spring-web
—
CVE-2013-6430
—
Medium
FALSE
A vulnerabilidade se aplica ao componente spring-web
—
CVE-2013-7315
CVE-2013-7315
Medium
FALSE
SPLIT da CVE-2013-4152. + A vulnerabilidade se aplica ao componente spring-web
—
CVE-2014-0054
CVE-2014-0054
Medium
FALSE
A vulnerabilidade se aplica ao componente spring-web
—
CVE-2014-0225
—
Alto
FALSE
A vulnerabilidade se aplica ao componente spring-web
—
—
CVE-2014-0225
Alto
FALSE
Duplicata desta mesma vulnerabilidade no spring-web
—
CVE-2014-1904
CVE-2014-1904
Medium
FALSE
A vulnerabilidade se aplica ao componente spring-web-mvc
—
CVE-2014-3625
CVE-2014-3625
Medium
FALSE
A vulnerabilidade se aplica ao componente spring-web-mvc
—
CVE-2016-9878
CVE-2016-9878
Alto
FALSE
A vulnerabilidade se aplica ao componente spring-web-mvc
—
CVE-2018-1270
CVE-2018-1270
Alto
FALSE
Para spring-expression / spring-messages
—
CVE-2018-1271
CVE-2018-1271
Medium
FALSE
A vulnerabilidade se aplica ao componente spring-web-mvc
—
CVE-2018-1272
CVE-2018-1272
Alto
TRUE
CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Medium
TRUE
SONATYPE-2015-0327
—
—
Baixo
TRUE
struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
—
—
Medium
TRUE
spring-tx:3.0.5
—
CVE-2011-2730
—
Alto
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2011-2894
—
Alto
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2013-4152
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2013-6429
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2013-6430
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2013-7315
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2014-0054
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2014-0225
—
Alto
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2014-1904
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2014-3625
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2016-9878
—
Alto
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2018-1270
—
Alto
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2018-1271
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
—
CVE-2018-1272
—
Medium
FALSE
A vulnerabilidade não se aplica ao spring-tx
struts-core:1.3.8
—
CVE-2011-5057 (OSSINDEX)
Medium
FALSO
Vulnerabilidade para Struts 2
—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Alto
FALSE
Vulnerabilidade para Struts 2
—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
FALSE
Vulnerabilidade para Struts 2
—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Alto
FALSE
Vulnerabilidade para Struts 2
CVE-2016-1182
3VE-2016-1182
—
Alto
TRUE
—
—
CVE-2011-5057
Medium
FALSE
Vulnerabilidade para Struts 2
—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Alto
FALSE
Vulnerabilidade para Struts 2
—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
FALSE
Vulnerabilidade para Struts 2
CVE-2015-0899
CVE-2015-0899
—
Alto
TRUE
—
CVE-2012-0394
CVE-2012-0394
Medium
FALSE
Vulnerabilidade para Struts 2
—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Alto
FALSE
Vulnerabilidade para Struts 2
—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Alto
FALSE
Vulnerabilidade para Struts 2
—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Alto
FALSO
Vulnerabilidade para Struts 2
—
CVE-2013-2115
CVE-2013-2115
Alto
FALSO
Vulnerabilidade para Struts 2
—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Alto
FALSO
Vulnerabilidade para Struts 2
—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Alto
FALSO
Vulnerabilidade para Struts 2
CVE-2014-0114
CVE-2014-0114
—
Alto
TRUE
—
CVE-2015-2992
CVE-2015-2992
Medium
FALSE
Vulnerabilidade para Struts 2
—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Alto
FALSE
Vulnerabilidade para Struts 2
CVE-2016-1181
CVE-2016-1181
—
Alto
TRUE
—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Alto
FALSE
Vulnerabilidade para Struts 2
xwork-core:2.3.30
CVE-2017-9804
—
—
Alto
TRUE
SONATYPE-2017-0173
—
—
Alto
TRUE
CVE-2017-7672
—
—
Alto
FALSE
Duplicado de CVE-2017-9804
SONATYPE-2016-0127
—
—
Alto
TRUE
struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Alto
TRUE
—
CVE-2017-9787
CVE-2017-9787
Alto
TRUE
—
CVE-2017-9791
CVE-2017-9791
Alto
TRUE
—
CVE-2017-9793
—
Alto
FALSE
Duplicado de CVE-2018-1327
—
CVE-2017-9804
—
Alto
TRUE
—
CVE-2017-9805
CVE-2017-9805
Alto
TRUE
CVE-2016-4003
—
—
Medium
FALSE
Aplicável ao Apache Struts 2.x até 2.3.28, mas esta é a versão 2.3.30. No entanto, de acordo com a descrição, o CVE se aplica a todas as versões do Struts 2, se JRE 1.7 ou inferior for utilizado. Parece que aqui decidiram se prevenir, mas parece mais que é um FALSO positivo.
—
CVE-2018-1327
CVE-2018-1327
Alto
TRUE
CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Alto
TRUE
A vulnerabilidade que foi explorada por criminosos na Equifax em 2017
CVE-2017-12611
CVE-2017-12611
—
Alto
TRUE
CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Alto
TRUE
struts-taglib:1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Para struts2-core
—
CVE-2013-2115
—
Alto
FALSE
Para struts2-core
—
CVE-2014-0114
—
Alto
FALSE
Para commons-beanutils
—
CVE-2015-0899
—
Alto
FALSE
Não se aplica a taglib
—
CVE-2015-2992
—
Medium
FALSE
Aplica-se a struts2-core
—
CVE-2016-1181
—
Alto
FALSE
Não se aplica a taglib
—
CVE-2016-1182
—
Alto
FALSE
Não se aplica a taglib
struts-tiles-1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Para struts2-core
—
CVE-2013-2115
—
Alto
FALSE
Para struts2-core
—
CVE-2014-0114
—
Alto
FALSE
Sobre commons-beanutils
—
CVE-2015-0899
—
Alto
FALSE
Não se aplica a tiles
—
CVE-2015-2992
—
Medium
FALSE
Para struts2-core
—
CVE-2016-1181
—
Alto
FALSE
Não se aplica a taglib
—
CVE-2016-1182
—
Alto
FALSE
Não se aplica a taglib
Fonte: habr.com
