A importância da análise de componentes de software de terceiros (Software Composition Analysis - SCA) no processo de desenvolvimento é crescente com a divulgação de relatórios anuais sobre vulnerabilidades de bibliotecas de código aberto, publicados pela Synopsys, Sonatype, Snyk, White Source. De acordo com o relatório o número de vulnerabilidades de código aberto identificadas em 2019 aumentou quase 1.5 vezes em comparação com o ano anterior, enquanto os componentes de código aberto são usados por 60% a 80% dos projetos. De forma independente, os processos SCA são uma prática separada do OWASP SAMM e BSIMM como um indicador de maturidade e, no primeiro semestre de 2020, a OWASP lançou o novo OWASP Software Component Verification Standard (SCVS), fornecendo melhores práticas para verificação de terceiros. componentes do partido na cadeia de abastecimento POR.
Um dos casos mais ilustrativos com Equifax em maio de 2017. Atacantes desconhecidos obtiveram informações sobre 143 milhões de americanos, incluindo nomes completos, endereços, números de Seguro Social e carteiras de motorista. Em 209 mil casos, os documentos também incluíam informações sobre os cartões bancários das vítimas. Esse vazamento ocorreu como resultado da exploração de uma vulnerabilidade crítica no Apache Struts 000 (CVE-2-2017), enquanto a correção foi lançada em março de 5638. A empresa teve dois meses para instalar a atualização, mas ninguém se preocupou com isso.
Este artigo discutirá a questão da escolha de uma ferramenta para a realização da SCA do ponto de vista da qualidade dos resultados da análise. Uma comparação funcional das ferramentas também será fornecida. O processo de integração em CI/CD e os recursos de integração serão deixados para publicações subsequentes. Uma ampla gama de ferramentas foi apresentada pela OWASP , mas na revisão atual abordaremos apenas a ferramenta de código aberto mais popular Dependency Check, a plataforma de código aberto um pouco menos conhecida Dependency Track e a solução empresarial Sonatype Nexus IQ. Também entenderemos como funcionam essas soluções e compararemos os resultados obtidos para falsos positivos.
Como funciona
é um utilitário (CLI, maven, módulo jenkins, ant) que analisa arquivos de projeto, coleta informações sobre dependências (nome do pacote, groupid, título da especificação, versão...), constrói uma linha CPE (Common Platform Enumeration) , URL do pacote (PURL) e identifica vulnerabilidades para CPE/PURL de bancos de dados (NVD, Sonatype OSS Index, NPM Audit API...), após o que constrói um relatório único em formato HTML, JSON, XML...
Vejamos como é o CPE:
cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other- Parte: Indicação de que o componente está relacionado à aplicação (a), sistema operacional (o), hardware (h) (Obrigatório)
- Vendedor: Nome do fabricante do produto (obrigatório)
- Produto: Nome do produto (obrigatório)
- Versão: Versão do componente (item obsoleto)
- Update: Atualização de pacote
- Edição: Versão legada (item obsoleto)
- Idioma: Idioma definido em RFC-5646
- Edição SW: Versão do software
- SW alvo: Ambiente de software no qual o produto opera
- Hardware alvo: O ambiente de hardware no qual o produto opera
- De outros: Informações sobre fornecedor ou produto
Um exemplo de CPE é assim:
cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*
A linha significa que o CPE versão 2.3 descreve o componente de aplicação do fabricante pivotal_software com o título spring_framework versão 3.0.0. Se abrirmos uma vulnerabilidade no NVD, podemos ver uma menção a este CPE. O primeiro problema ao qual você deve prestar atenção imediatamente é que o CVE no NVD, segundo o CPE, relata um problema no framework, e não em um componente específico. Ou seja, se os desenvolvedores estiverem fortemente vinculados ao framework e a vulnerabilidade identificada não afetar os módulos que os desenvolvedores usam, um especialista em segurança terá, de uma forma ou de outra, que desmontar esse CVE e pensar em atualizar.
A URL também é usada pelas ferramentas SCA. O formato do URL do pacote é o seguinte:
scheme:type/namespace/name@version?qualifiers#subpath- Esquema: Sempre haverá 'pkg' indicando que este é um URL de pacote (obrigatório)
- Tipo: O "tipo" do pacote ou o "protocolo" do pacote, como maven, npm, nuget, gem, pypi, etc. (Item obrigatório)
- Domínio: Algum prefixo de nome, como ID de grupo Maven, proprietário da imagem Docker, usuário GitHub ou organização. Opcional e depende do tipo.
- Nome: Nome do pacote (obrigatório)
- Versão: Versão do pacote
- Qualificação: Dados adicionais de qualificação para o pacote, como sistema operacional, arquitetura, distribuição, etc. Opcionais e específicos do tipo.
- Subcaminho: Caminho adicional no pacote relativo à raiz do pacote
Por exemplo:
pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/[email protected]
pkg:pypi/[email protected]— uma plataforma web local que aceita listas de materiais (BOM) prontas geradas и , isto é, especificações prontas sobre dependências existentes. Este é um arquivo XML que descreve as dependências – nome, hashes, URL do pacote, editor, licença. Em seguida, Dependency Track analisa o BOM, analisa os CVEs disponíveis para as dependências identificadas no banco de dados de vulnerabilidade (NVD, Sonatype OSS Index...), após o que constrói gráficos, calcula métricas, atualizando regularmente dados sobre o status de vulnerabilidade dos componentes .
Um exemplo da aparência de uma BOM no formato XML:
<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">
<components>
<component type="library">
<publisher>Apache</publisher>
<group>org.apache.tomcat</group>
<name>tomcat-catalina</name>
<version>9.0.14</version>
<hashes>
<hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>
<hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>
<hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>
<hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>
</hashes>
<licenses>
<license>
<id>Apache-2.0</id>
</license>
</licenses>
<purl>pkg:maven/org.apache.tomcat/[email protected]</purl>
</component>
<!-- More components here -->
</components>
</bom>A BOM pode ser usada não apenas como parâmetros de entrada para o Dependency Track, mas também para inventariar componentes de software na cadeia de suprimentos, por exemplo, para fornecer software a um cliente. Em 2014, chegou a ser proposta uma lei nos Estados Unidos , que afirmava que na compra de software, qualquer estado. A instituição deve solicitar um BOM para evitar o uso de componentes vulneráveis, mas a lei ainda não entrou em vigor.
Voltando ao SCA, o Dependency Track possui integrações prontas com plataformas de notificação como Slack, sistemas de gerenciamento de vulnerabilidades como Kenna Security. Vale dizer também que o Dependency Track, entre outras coisas, identifica versões desatualizadas de pacotes e fornece informações sobre licenças (devido ao suporte SPDX).
Se falarmos especificamente sobre a qualidade da SCA, então há uma diferença fundamental.
O Dependency Track não aceita o projeto como entrada, mas sim a BOM. Isso significa que se quisermos testar o projeto, primeiro precisamos gerar o bom.xml, por exemplo usando o CycloneDX. Assim, o Dependency Track depende diretamente do CycloneDX. Ao mesmo tempo, permite personalização. Isto é o que a equipe OZON escreveu para montar arquivos BOM para projetos Golang para verificação adicional por meio do Dependency Track.
é uma solução comercial SCA da Sonatype, que faz parte do ecossistema Sonatype, que também inclui o Nexus Repository Manager. O Nexus IQ pode aceitar como dados de entrada tanto arquivos war (para projetos java) por meio da interface web ou API, quanto BOM, caso sua organização não tenha tido tempo de mudar do CycloneDX para uma nova solução. Ao contrário das soluções de código aberto, o IQ não se refere apenas ao CP/PURL ao componente identificado e à vulnerabilidade correspondente no banco de dados, mas também leva em consideração sua própria pesquisa, por exemplo, o nome da função ou classe vulnerável. Os mecanismos do QI serão discutidos posteriormente na análise dos resultados.
Vamos resumir alguns dos recursos funcionais e também considerar as linguagens suportadas para análise:
Linguagem
QI Nexus
Verificação de dependência
Acompanhamento de Dependência
Java
+
+
+
C / C ++
+
+
-
C#
+
+
-
. Net
+
+
+
Erlang
-
-
+
JavaScript (NodeJS)
+
+
+
PHP
+
+
+
Python
+
+
+
Ruby
+
+
+
Perl
-
-
-
Scala
+
+
+
Objetivo C
+
+
-
rápido
+
+
-
R
+
-
-
Go
+
+
+
Funcionalidade
Funcionalidade
QI Nexus
Verificação de dependência
Acompanhamento de Dependência
A capacidade de garantir que os componentes usados no código-fonte sejam verificados quanto à pureza licenciada
+
-
+
Capacidade de verificar e analisar vulnerabilidades e limpeza de licenças para imagens Docker
+ Integração com Clair
-
-
Capacidade de configurar políticas de segurança para usar bibliotecas de código aberto
+
-
-
Capacidade de verificar 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
Disponibilidade de grupo de pesquisa especializado
+
-
-
Operação em circuito fechado
+
+
+
Usando bancos de dados de terceiros
+ Banco de dados Sonatype fechado
+ Sonatype OSS, consultores públicos NPM
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, suporte para seu próprio banco de dados de vulnerabilidades
Capacidade de filtrar componentes de código aberto ao tentar carregar no loop de desenvolvimento de acordo com políticas configuradas
+
-
-
Recomendações para correção de vulnerabilidades, disponibilidade de links para correções
+
+- (depende da descrição em bancos de dados públicos)
+- (depende da descrição em bancos de dados públicos)
Classificação de vulnerabilidades detectadas por gravidade
+
+
+
Modelo de acesso baseado em funções
+
-
+
Suporte CLI
+
+
+- (apenas para CycloneDX)
Amostragem/classificação de vulnerabilidades de acordo com critérios definidos
+
-
+
Painel por status do aplicativo
+
-
+
Gerando relatórios em formato PDF
+
-
-
Gerando relatórios no formato JSONCSV
+
+
-
Suporte ao idioma russo
-
-
-
Capacidades de integração
integração
QI Nexus
Verificação de dependência
Acompanhamento de Dependência
Integração LDAP/Active Directory
+
-
+
Integração com sistema de integração contínua Bamboo
+
-
-
Integração com sistema de integração contínua TeamCity
+
-
-
Integração com sistema de integração contínua GitLab
+
+- (como um plugin para GitLab)
+
Integração com sistema de integração contínua Jenkins
+
+
+
Disponibilidade de plugins para IDE
+ IntelliJ, Eclipse, Visual Studio
-
-
Suporte para integração customizada via web-services (API) da ferramenta
+
-
+
Verificação de dependência
Primeiro começo
Vamos executar a verificação de dependência em um aplicativo deliberadamente vulnerável .
Para isso usaremos :
mvn org.owasp:dependency-check-maven:checkComo resultado, dependency-check-report.html aparecerá no diretório de destino.
Vamos abrir o arquivo. Após informações resumidas sobre o número total de vulnerabilidades, podemos ver informações sobre vulnerabilidades com alto nível de Gravidade e Confiança, indicando o pacote, CPE e número de CVEs.
Em seguida vêm informações mais detalhadas, principalmente a base sobre a qual a decisão foi tomada (evidência), ou seja, uma determinada lista técnica.
Em seguida vem a descrição do CPE, PURL e CVE. A propósito, as recomendações para correção não estão incluídas devido à sua ausência na base de dados do NVD.
Para visualizar sistematicamente os resultados da verificação, você pode configurar o Nginx com configurações mínimas ou enviar os defeitos resultantes para um sistema de gerenciamento de defeitos que ofereça suporte a conectores para verificação de dependência. Por exemplo, Defeito Dojo.
Acompanhamento de Dependência
Instalação
O Dependency Track, por sua vez, é uma plataforma baseada na web com gráficos de exibição, portanto a questão urgente de armazenar defeitos em uma solução de terceiros não surge aqui.
Os scripts suportados para instalação são: Docker, WAR, Executable WAR.
Primeiro começo
Vamos para a URL do serviço em execução. Efetuamos login via admin/admin, alteramos o login e a senha e depois acessamos o Dashboard. A próxima coisa que faremos é criar um projeto para uma aplicação de teste em Java em Home/Projetos → Criar Projeto . Tomemos o DVJA como exemplo.
Como o Dependency Track só pode aceitar BOM como entrada, esse BOM deve ser recuperado. Vamos aproveitar :
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBomPegamos bom.xml e carregamos o arquivo no projeto criado DVJA → Dependências → Carregar BOM.
Vamos para Administração → Analisadores. Entendemos que só temos o Analisador Interno habilitado, que inclui o NVD. Vamos também conectar o Índice Sonatype OSS.
Assim, obtemos a seguinte imagem para o nosso projeto:
Também na lista você pode encontrar uma vulnerabilidade aplicável ao Sonatype OSS:
A principal decepção foi que o Dependency Track não aceita mais relatórios XML de Verificação de Dependência. As versões mais recentes com suporte da integração do Dependency Check foram 1.0.0 - 4.0.2, enquanto testei 5.3.2.
aqui é (e ) quando ainda era possível.
QI Nexus
Primeiro começo
A instalação do Nexus IQ vem dos arquivos de , mas construímos uma imagem Docker para esses fins.
Após fazer login no console, você precisa criar uma Organização e um Aplicativo.
Como você pode ver, a configuração no caso do IQ é um pouco mais complicada, porque também precisamos criar políticas que sejam aplicáveis a diferentes “estágios” (dev, build, stage, release). Isso é necessário para bloquear componentes vulneráveis à medida que eles se movem pelo pipeline mais perto da produção ou para bloqueá-los assim que entram no Nexus Repo quando baixados pelos desenvolvedores.
Para sentir a diferença entre código aberto e corporativo, vamos realizar a mesma verificação por meio do Nexus IQ da mesma forma por meio de , tendo previamente criado um aplicativo de teste na interface NexusIQ dvja-test-and-compare:
mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>
Siga a URL do relatório gerado na interface web do IQ:
Aqui você pode ver todas as violações de política indicando diferentes níveis de significância (de Info a Segurança Crítica). A letra D ao lado do componente significa que o componente é Dependência Direta, e a letra T ao lado do componente significa que o componente é Dependência Transitiva, ou seja, é transitivo.
A propósito, o relatório da Snyk relata que mais de 70% das vulnerabilidades de código aberto descobertas em Node.js, Java e Ruby estão em dependências transitivas.
Se abrirmos uma das violações da política do Nexus IQ, podemos ver uma descrição do componente, bem como um Gráfico de Versão, que mostra a localização da versão atual no gráfico de tempo, bem como em que ponto a vulnerabilidade deixa de existir. ser vulnerável. A altura das velas no gráfico mostra a popularidade do uso deste componente.
Se você for até a seção de vulnerabilidades e expandir o CVE, poderá ler uma descrição desta vulnerabilidade, recomendações para eliminação, bem como o motivo pelo qual este componente foi violado, ou seja, a presença da classe DiskFileitem.class.
Vamos resumir apenas aqueles relacionados a componentes Java de terceiros, removendo os componentes js. Entre parênteses indicamos o número de vulnerabilidades encontradas fora do NVD.
QI total do Nexus:
- Dependências verificadas: 62
- Dependências Vulneráveis: 16
- Vulnerabilidades encontradas: 42 (8 sonatype db)
Verificação de dependência total:
- Dependências verificadas: 47
- Dependências Vulneráveis: 13
- Vulnerabilidades encontradas: 91 (14 sonatype oss)
Acompanhamento de Dependência Total:
- Dependências verificadas: 59
- Dependências Vulneráveis: 10
- Vulnerabilidades encontradas: 51 (1 sonatype oss)
Nas próximas etapas analisaremos os resultados obtidos e descobriremos qual dessas vulnerabilidades é um defeito real e qual é um falso positivo.
Isenção de responsabilidade
Esta revisão não é uma verdade indiscutível. O autor não teve como objetivo destacar um instrumento separado em relação a outros. O objetivo da revisão foi mostrar os mecanismos de funcionamento das ferramentas SCA e formas de verificar seus resultados.
Comparação de resultados
Os termos e condições:
Um falso positivo para vulnerabilidades de componentes de terceiros é:
- Incompatibilidade de CVE com componente identificado
- Por exemplo, se uma vulnerabilidade for identificada na estrutura struts2, e a ferramenta apontar para um componente da estrutura struts-tiles, ao qual esta vulnerabilidade não se aplica, então este é um falso positivo
- Incompatibilidade de CVE com a versão identificada do componente
- Por exemplo, a vulnerabilidade está vinculada à versão python > 3.5 e a ferramenta marca a versão 2.7 como vulnerável - isso é um falso positivo, pois na verdade a vulnerabilidade se aplica apenas ao ramo do produto 3.x
- CVE duplicado
- Por exemplo, se o SCA especifica um CVE que permite um RCE, então o SCA especifica um CVE para esse mesmo componente que se aplica aos produtos Cisco afetados por esse RCE. Neste caso será falso positivo.
- Por exemplo, um CVE foi encontrado em um componente spring-web, após o qual o SCA aponta para o mesmo CVE em outros componentes do Spring Framework, enquanto o CVE não tem nada a ver com outros componentes. Neste caso será falso positivo.
O objeto do estudo foi o projeto Open Source DVJA. O estudo envolveu apenas componentes java (sem js).
Resultados resumidos
Vamos direto aos resultados de uma revisão manual das vulnerabilidades identificadas. O relatório completo de cada CVE pode ser encontrado no Apêndice.
Resultados resumidos para todas as vulnerabilidades:
Parâmetro
QI Nexus
Verificação de dependência
Acompanhamento de Dependência
Total de vulnerabilidades identificadas
42
91
51
Vulnerabilidades identificadas incorretamente (falso positivo)
2 (4.76%)
62 (68,13%)
29 (56.86%)
Nenhuma vulnerabilidade relevante encontrada (falso negativo)
10
20
27
Resultados resumidos por componente:
Parâmetro
QI Nexus
Verificação de dependência
Acompanhamento de Dependência
Total de componentes identificados
62
47
59
Total de componentes vulneráveis
16
13
10
Componentes vulneráveis identificados incorretamente (falso positivo)
1
5
0
Componentes vulneráveis identificados incorretamente (falso positivo)
0
6
6
Vamos construir gráficos visuais para avaliar a proporção de falsos positivos e falsos negativos em relação ao número total de vulnerabilidades. Os componentes são marcados horizontalmente e as vulnerabilidades identificadas neles são marcadas verticalmente.
Para efeito de comparação, um estudo semelhante foi conduzido pela equipe Sonatype testando um projeto de 1531 componentes usando OWASP Dependency Check. Como podemos ver, a proporção entre ruído e respostas corretas é comparável aos nossos resultados.
Fonte:
Vejamos alguns CVEs dos resultados da nossa verificação para entender o motivo desses resultados.
Mais
№ 1
Vejamos primeiro alguns pontos interessantes sobre o Sonatype Nexus IQ.
Nexus IQ aponta um problema com a desserialização com a capacidade 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. À primeira vista, parece que há duplicação de vulnerabilidade em vários CVEs. Porque, se você olhar CVE-2016-1000027 e CVE-2011-2894 no banco de dados NVD, parece que tudo é óbvio
Componente
Vulnerabilidade
teia de primavera: 3.0.5
CVE-2016-1000027
contexto de primavera: 3.0.5
CVE-2011-2894
núcleo de mola: 3.0.5
CVE-2011-2894
descrição do NVD:
descrição do NVD:
O próprio CVE-2011-2894 é bastante famoso. No relatório este CVE foi reconhecido como um dos mais comuns. As descrições para CVE-2016-100027, em princípio, são poucas no NVD e parece ser aplicável apenas para Spring Framework 4.1.4. Vamos dar uma olhada e aqui tudo fica mais ou menos claro. De Entendemos que além da vulnerabilidade em RemoteInvocationSerializingExporter no CVE-2011-2894, a vulnerabilidade é observada em HttpInvokerServiceExporter. Isto é o que o Nexus IQ nos diz:
No entanto, não há nada parecido com isso no NVD, e é por isso que a Verificação de Dependência e o Rastreamento de Dependência recebem falsos negativos.
Também pela descrição do CVE-2011-2894 pode-se entender que a vulnerabilidade está de fato presente tanto no spring-context:3.0.5 quanto no spring-core:3.0.5. A confirmação disso pode ser encontrada em um artigo da pessoa que encontrou esta vulnerabilidade.
№ 2
Componente
Vulnerabilidade
resultado
suportes2-core:2.3.30
CVE-2016-4003
FALSE
Se estudarmos a vulnerabilidade CVE-2016-4003, entenderemos que ela foi corrigida na versão 2.3.28, porém, o Nexus IQ nos reporta. Há uma nota na descrição da vulnerabilidade:
Ou seja, a vulnerabilidade existe apenas em conjunto com uma versão desatualizada do JRE, sobre a qual decidimos nos alertar. No entanto, consideramos este falso positivo, embora não seja o pior.
número 3
Componente
Vulnerabilidade
resultado
xwork-core:2.3.30
CVE-2017-9804
VERDADEIRO
xwork-core:2.3.30
CVE-2017-7672
FALSE
Se olharmos as descrições do CVE-2017-9804 e CVE-2017-7672, entenderemos que o problema é URLValidator class, sendo CVE-2017-9804 decorrente de CVE-2017-7672. A presença da segunda vulnerabilidade não carrega nenhuma carga útil além do fato de sua gravidade ter aumentado para Alta, portanto podemos considerá-la um ruído desnecessário.
No geral, nenhum outro falso positivo foi encontrado para o Nexus IQ.
№ 4
Existem várias coisas que diferenciam o IQ de outras soluções.
Componente
Vulnerabilidade
resultado
teia de primavera: 3.0.5
CVE-2020-5398
VERDADEIRO
O CVE no NVD afirma que se aplica apenas às versões 5.2.x antes de 5.2.3, 5.1.x antes de 5.1.13 e versões 5.0.x antes de 5.0.16, no entanto, se olharmos a descrição do CVE no Nexus IQ , então veremos o seguinte:
Aviso de desvio do comunicado: A equipe de pesquisa de segurança da Sonatype descobriu que esta vulnerabilidade foi introduzida na versão 3.0.2.RELEASE e não na 5.0.x conforme declarado no comunicado.
Isto é seguido por um PoC para esta vulnerabilidade, que afirma que ela está presente na versão 3.0.5.
O falso negativo é enviado para Verificação de Dependência e Rastreamento de Dependência.
№ 5
Vejamos os falsos positivos para Verificação de Dependência e Rastreamento de Dependência.
A Verificação de Dependência se destaca porque reflete os CVEs que se aplicam a toda a estrutura do NVD para os componentes aos quais esses CVEs não se aplicam. Isso se aplica a CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, cuja Verificação de Dependência “fixada” para struts-taglib:1.3.8 e struts-tiles-1.3.8. Esses componentes não têm nada a ver com o que está descrito no CVE - processamento de solicitação, validação de página e assim por diante. Isso se deve ao fato de que o que esses CVEs e componentes têm em comum é apenas o framework, por isso o Dependency Check o 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 o struts-core, o Dependency Check e o Dependency Track encontraram muitas vulnerabilidades que são realmente aplicáveis ao struts2-core, que é essencialmente uma estrutura separada. Neste caso, o Nexus IQ entendeu corretamente o quadro e nos CVEs que emitiu indicou que o struts-core havia chegado ao fim da vida útil e era necessário passar para o struts2-core.
№ 6
Em algumas situações, é injusto interpretar um erro óbvio de Verificação de Dependência e Rastreamento de Dependência. Em particular CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, que verificam dependências e rastreiam dependências atribuído a spring-core:3.0.5 na verdade pertence a spring-web:3.0.5. Ao mesmo tempo, alguns desses CVEs também foram encontrados pelo Nexus IQ, no entanto, o IQ os identificou corretamente como outro componente. Como essas vulnerabilidades não foram encontradas no spring-core, não se pode argumentar que elas não estão na estrutura em princípio e as ferramentas de código aberto apontaram corretamente essas vulnerabilidades (elas apenas perderam um pouco).
Descobertas
Como podemos ver, determinar a confiabilidade das vulnerabilidades identificadas por meio de revisão manual não fornece resultados inequívocos, razão pela qual surgem questões controversas. Os resultados são que a solução Nexus IQ tem a menor taxa de falsos positivos e a maior precisão.
Em primeiro lugar, isto se deve ao fato de que a equipe Sonatype expandiu a descrição de cada vulnerabilidade CVE do NVD em seus bancos de dados, indicando as vulnerabilidades para uma versão específica dos componentes até a classe ou função, conduzindo pesquisas adicionais (por exemplo , verificando vulnerabilidades em versões de software mais antigas).
Uma influência importante nos resultados também é desempenhada pelas vulnerabilidades que não foram incluídas no NVD, mas que estão presentes no banco de dados Sonatype com a marca SONATYPE. De acordo com o relatório 45% das vulnerabilidades de código aberto descobertas não são relatadas ao NVD. De acordo com o banco de dados WhiteSource, apenas 29% de todas as vulnerabilidades de código aberto relatadas fora do NVD acabam publicadas lá, por isso é importante procurar vulnerabilidades em outras fontes também.
Como resultado, a Verificação de Dependência produz muito ruído, faltando alguns componentes vulneráveis. Dependency Track produz menos ruído e detecta um grande número de componentes, o que não prejudica visualmente os olhos na interface web.
No entanto, a prática mostra que o código aberto deve se tornar o primeiro passo em direção ao DevSecOps maduro. A primeira coisa que você deve pensar ao integrar o SCA ao desenvolvimento são os processos, ou seja, pensar em conjunto com a gestão e departamentos relacionados sobre como deveriam ser os processos ideais em sua organização. Pode acontecer que, para a sua organização, a princípio, o Dependency Check ou o Dependency Track cubram todas as necessidades de negócios, e as soluções corporativas sejam uma continuação lógica devido à crescente complexidade dos aplicativos que estão sendo desenvolvidos.
Apêndice A: Resultados dos Componentes
Símbolos:
- Vulnerabilidades de nível alto – alto e crítico no componente
- Médio — Vulnerabilidades de nível de criticidade médio no componente
- VERDADEIRO - questão verdadeiramente positiva
- FALSO — Problema de falso positivo
Componente
QI Nexus
Verificação de dependência
Acompanhamento de Dependência
resultado
dom4j: 1.6.1
Alta
Alta
Alta
VERDADEIRO
log4j-core: 2.3
Alta
Alta
Alta
VERDADEIRO
log4j: 1.2.14
Alta
Alta
-
VERDADEIRO
coleções comuns:3.1
Alta
Alta
Alta
VERDADEIRO
upload de arquivo comum: 1.3.2
Alta
Alta
Alta
VERDADEIRO
commons-beanutils:1.7.0
Alta
Alta
Alta
VERDADEIRO
codec comum: 1:10
Médio
-
-
VERDADEIRO
conector mysql-java:5.1.42
Alta
Alta
Alta
VERDADEIRO
expressão de primavera: 3.0.5
Alta
componente não encontrado
VERDADEIRO
teia de primavera: 3.0.5
Alta
componente não encontrado
Alta
VERDADEIRO
contexto de primavera: 3.0.5
Médio
componente não encontrado
-
VERDADEIRO
núcleo de mola: 3.0.5
Médio
Alta
Alta
VERDADEIRO
struts2-config-browser-plugin:2.3.30
Médio
-
-
VERDADEIRO
primavera-tx:3.0.5
-
Alta
-
FALSE
núcleo de suporte: 1.3.8
Alta
Alta
Alta
VERDADEIRO
núcleo xwork: 2.3.30
Alta
-
-
VERDADEIRO
struts2-core: 2.3.30
Alta
Alta
Alta
VERDADEIRO
suportes-taglib:1.3.8
-
Alta
-
FALSE
suportes-tiles-1.3.8
-
Alta
-
FALSE
Apêndice B: Resultados de Vulnerabilidade
Símbolos:
- Vulnerabilidades de nível alto – alto e crítico no componente
- Médio — Vulnerabilidades de nível de criticidade médio no componente
- VERDADEIRO - questão verdadeiramente positiva
- FALSO — Problema de falso positivo
Componente
QI Nexus
Verificação de dependência
Acompanhamento de Dependência
Gravidade
resultado
comentário
dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Alta
VERDADEIRO
CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Alta
VERDADEIRO
log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Alta
VERDADEIRO
CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Baixo
VERDADEIRO
log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
-
Alta
VERDADEIRO
-
CVE-2020-9488
-
Baixo
VERDADEIRO
SONATYPE-2010-0053
-
-
Alta
VERDADEIRO
coleções comuns:3.1
-
CVE-2015-6420
CVE-2015-6420
Alta
FALSE
Duplicatas RCE(OSSINDEX)
-
CVE-2017-15708
CVE-2017-15708
Alta
FALSE
Duplicatas RCE(OSSINDEX)
SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Alta
VERDADEIRO
upload de arquivo comum: 1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Alta
VERDADEIRO
SONATYPE-2014-0173
-
-
Médio
VERDADEIRO
commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Alta
VERDADEIRO
-
CVE-2019-10086
CVE-2019-10086
Alta
FALSE
A vulnerabilidade se aplica apenas às versões 1.9.2+
codec comum: 1:10
SONATYPE-2012-0050
-
-
Médio
VERDADEIRO
conector mysql-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Alta
VERDADEIRO
CVE-2019-2692
CVE-2019-2692
-
Médio
VERDADEIRO
-
CVE-2020-2875
-
Médio
FALSE
A mesma vulnerabilidade da CVE-2019-2692, mas com a nota “os ataques podem impactar significativamente produtos adicionais”
-
CVE-2017-15945
-
Alta
FALSE
Não relevante para mysql-connector-java
-
CVE-2020-2933
-
Baixo
FALSE
Duplicado de CVE-2020-2934
CVE-2020-2934
CVE-2020-2934
-
Médio
VERDADEIRO
expressão de primavera: 3.0.5
CVE-2018-1270
componente não encontrado
-
Alta
VERDADEIRO
CVE-2018-1257
-
-
Médio
VERDADEIRO
teia de primavera: 3.0.5
CVE-2016-1000027
componente não encontrado
-
Alta
VERDADEIRO
CVE-2014-0225
-
CVE-2014-0225
Alta
VERDADEIRO
CVE-2011-2730
-
-
Alta
VERDADEIRO
-
-
CVE-2013-4152
Médio
VERDADEIRO
CVE-2018-1272
-
-
Alta
VERDADEIRO
CVE-2020-5398
-
-
Alta
VERDADEIRO
Um exemplo ilustrativo a favor do IQ: “A equipe de pesquisa de segurança da Sonatype descobriu que esta vulnerabilidade foi introduzida na versão 3.0.2.RELEASE e não na 5.0.x conforme declarado no comunicado.”
CVE-2013-6429
-
-
Médio
VERDADEIRO
CVE-2014-0054
-
CVE-2014-0054
Médio
VERDADEIRO
CVE-2013-6430
-
-
Médio
VERDADEIRO
contexto de primavera: 3.0.5
CVE-2011-2894
componente não encontrado
-
Médio
VERDADEIRO
núcleo de mola: 3.0.5
-
CVE-2011-2730
CVE-2011-2730
Alta
VERDADEIRO
CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Médio
VERDADEIRO
-
-
CVE-2013-4152
Médio
FALSE
Duplicado da mesma vulnerabilidade no spring-web
-
CVE-2013-4152
-
Médio
FALSE
A vulnerabilidade está relacionada ao componente spring-web
-
CVE-2013-6429
CVE-2013-6429
Médio
FALSE
A vulnerabilidade está relacionada ao componente spring-web
-
CVE-2013-6430
-
Médio
FALSE
A vulnerabilidade está relacionada ao componente spring-web
-
CVE-2013-7315
CVE-2013-7315
Médio
FALSE
DIVISÃO de CVE-2013-4152. + A vulnerabilidade está relacionada ao componente spring-web
-
CVE-2014-0054
CVE-2014-0054
Médio
FALSE
A vulnerabilidade está relacionada ao componente spring-web
-
CVE-2014-0225
-
Alta
FALSE
A vulnerabilidade está relacionada ao componente spring-web
-
-
CVE-2014-0225
Alta
FALSE
Duplicado da mesma vulnerabilidade no spring-web
-
CVE-2014-1904
CVE-2014-1904
Médio
FALSE
A vulnerabilidade está relacionada ao componente spring-web-mvc
-
CVE-2014-3625
CVE-2014-3625
Médio
FALSE
A vulnerabilidade está relacionada ao componente spring-web-mvc
-
CVE-2016-9878
CVE-2016-9878
Alta
FALSE
A vulnerabilidade está relacionada ao componente spring-web-mvc
-
CVE-2018-1270
CVE-2018-1270
Alta
FALSE
Para expressão de primavera/mensagens de primavera
-
CVE-2018-1271
CVE-2018-1271
Médio
FALSE
A vulnerabilidade está relacionada ao componente spring-web-mvc
-
CVE-2018-1272
CVE-2018-1272
Alta
VERDADEIRO
CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Médio
VERDADEIRO
SONATYPE-2015-0327
-
-
Baixo
VERDADEIRO
struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
-
-
Médio
VERDADEIRO
primavera-tx:3.0.5
-
CVE-2011-2730
-
Alta
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2011-2894
-
Alta
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2013-4152
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2013-6429
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2013-6430
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2013-7315
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2014-0054
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2014-0225
-
Alta
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2014-1904
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2014-3625
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2016-9878
-
Alta
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2018-1270
-
Alta
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2018-1271
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
-
CVE-2018-1272
-
Médio
FALSE
A vulnerabilidade não é específica do spring-tx
núcleo de suporte: 1.3.8
-
CVE-2011-5057 (OSSINDEX)
Médio
FASLE
Vulnerabilidade ao Struts 2
-
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Alta
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Médio
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Alta
FALSE
Vulnerabilidade ao Struts 2
CVE-2016-1182
3VE-2016-1182
-
Alta
VERDADEIRO
-
-
CVE-2011-5057
Médio
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Alta
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Médio
FALSE
Vulnerabilidade ao Struts 2
CVE-2015-0899
CVE-2015-0899
-
Alta
VERDADEIRO
-
CVE-2012-0394
CVE-2012-0394
Médio
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Alta
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Alta
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Alta
FASLE
Vulnerabilidade ao Struts 2
-
CVE-2013-2115
CVE-2013-2115
Alta
FASLE
Vulnerabilidade ao Struts 2
-
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Alta
FASLE
Vulnerabilidade ao Struts 2
-
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Alta
FASLE
Vulnerabilidade ao Struts 2
CVE-2014-0114
CVE-2014-0114
-
Alta
VERDADEIRO
-
CVE-2015-2992
CVE-2015-2992
Médio
FALSE
Vulnerabilidade ao Struts 2
-
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Alta
FALSE
Vulnerabilidade ao Struts 2
CVE-2016-1181
CVE-2016-1181
-
Alta
VERDADEIRO
-
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Alta
FALSE
Vulnerabilidade ao Struts 2
xwork-core:2.3.30
CVE-2017-9804
-
-
Alta
VERDADEIRO
SONATYPE-2017-0173
-
-
Alta
VERDADEIRO
CVE-2017-7672
-
-
Alta
FALSE
Duplicado de CVE-2017-9804
SONATYPE-2016-0127
-
-
Alta
VERDADEIRO
suportes2-core:2.3.30
-
CVE-2016-6795
CVE-2016-6795
Alta
VERDADEIRO
-
CVE-2017-9787
CVE-2017-9787
Alta
VERDADEIRO
-
CVE-2017-9791
CVE-2017-9791
Alta
VERDADEIRO
-
CVE-2017-9793
-
Alta
FALSE
Duplicado de CVE-2018-1327
-
CVE-2017-9804
-
Alta
VERDADEIRO
-
CVE-2017-9805
CVE-2017-9805
Alta
VERDADEIRO
CVE-2016-4003
-
-
Médio
FALSE
Aplicável ao Apache Struts 2.x até 2.3.28, que é a versão 2.3.30. Entretanto, com base na descrição, o CVE é válido para qualquer versão do Struts 2 se o JRE 1.7 ou inferior for usado. Aparentemente eles decidiram nos ressegurar aqui, mas parece mais FALSO
-
CVE-2018-1327
CVE-2018-1327
Alta
VERDADEIRO
CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Alta
VERDADEIRO
A mesma vulnerabilidade que os hackers da Equifax exploraram em 2017
CVE-2017-12611
CVE-2017-12611
-
Alta
VERDADEIRO
CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Alta
VERDADEIRO
suportes-taglib:1.3.8
-
CVE-2012-0394
-
Médio
FALSE
Para struts2-core
-
CVE-2013-2115
-
Alta
FALSE
Para struts2-core
-
CVE-2014-0114
-
Alta
FALSE
Para commons-beanutils
-
CVE-2015-0899
-
Alta
FALSE
Não se aplica ao taglib
-
CVE-2015-2992
-
Médio
FALSE
Refere-se a struts2-core
-
CVE-2016-1181
-
Alta
FALSE
Não se aplica ao taglib
-
CVE-2016-1182
-
Alta
FALSE
Não se aplica ao taglib
suportes-tiles-1.3.8
-
CVE-2012-0394
-
Médio
FALSE
Para struts2-core
-
CVE-2013-2115
-
Alta
FALSE
Para struts2-core
-
CVE-2014-0114
-
Alta
FALSE
Sob commons-beanutils
-
CVE-2015-0899
-
Alta
FALSE
Não se aplica a azulejos
-
CVE-2015-2992
-
Médio
FALSE
Para struts2-core
-
CVE-2016-1181
-
Alta
FALSE
Não se aplica ao taglib
-
CVE-2016-1182
-
Alta
FALSE
Não se aplica ao taglib
Fonte: habr.com