DevSecOps: Princípios e comparação de SCA. Parte um

A importância da análise de componentes de software de terceiros (Software Composition Analysis - SCA) no processo de desenvolvimento está crescendo à medida que os relatórios anuais sobre vulnerabilidades de bibliotecas de código aberto são lançados, os quais são publicados pela Synopsys, Sonatype, Snyk, White Source. De acordo com o The State of Open Source Security Vulnerabilities 2020O 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 ​​de 60% a 80% dos projetos. Se você recorrer a uma opinião independente, os processos SCA são uma prática separada do OWASP SAMM e do BSIMM como um indicador de maturidade e, no primeiro semestre de 2020, o OWASP lançou um novo padrão, OWASP Software Component Verification Standard (SCVS), que fornece as melhores práticas para verificar os componentes de terceiros na cadeia de abastecimento. POR.







Um dos casos mais reveladores aconteceu com a Equifax em maio de 2017. Atacantes desconhecidos apreenderam informações sobre 143 milhões de americanos, incluindo nomes completos, endereços, números de previdência social e carteiras de motorista. Em 209.000 casos, os documentos também incluíam informações sobre os cartões bancários das vítimas. Esse vazamento foi 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 instalar a atualização, mas ninguém se preocupou com isso.



Este artigo irá discutir a questão da escolha de uma ferramenta para conduzir SCA em termos de qualidade dos resultados da análise. Haverá também uma comparação funcional das ferramentas. O processo de incorporação em CI / CD e as possibilidades de integração serão deixados para futuras publicações. Uma ampla lista de ferramentas foi apresentada pelo OWASP em seu site , mas como parte da revisão atual, vamos apenas abordar 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 Sonatype Nexus IQ Enterprise. Também descobriremos como essas soluções funcionam e compararemos os resultados obtidos para falsos positivos.

Princípio da Operação

Dependency Check é um utilitário (CLI, maven, jenkins module, ant) ​​que analisa arquivos de projeto, coleta informações de dependência (nome do pacote, groupid, título de especificação, versão ...), cria uma linha CPE - (Common Platform Enumeration), Package URL (PURL) e detecta vulnerabilidades para CPE / PURL de bancos de dados (NVD, Sonatype OSS Index, NPM Audit API ...) e, em seguida, cria um relatório único em formato HTML, JSON, XML ...



Vamos ver como o CPE se parece:

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

• Parte: Uma indicação de que o componente pertence ao aplicativo (a), sistema operacional (o), hardware (h) (item obrigatório)
• Fornecedor: Nome do fabricante do produto (obrigatório)
• Produto: Nome do produto (item obrigatório)
• Versão: versão do componente (obsoleta)
• Atualização: Atualize o pacote
• Edição: versão herdada (obsoleta)
• Idioma: o idioma conforme definido no RFC-5646
• SW Edition: versão do software
• Target SW: O ambiente de software no qual o produto é executado
• HW de destino: o ambiente de hardware no qual o produto é executado
• Outro: informações do fornecedor ou do produto

Um exemplo de CPE se parece com este:

cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*

A linha significa que o CPE versão 2.3 descreve um componente do aplicativo do fabricante pivotal_software com o nome de spring_frameworkversão 3.0.0. Se abrirmos a vulnerabilidade CVE-2014-0225 no NVD , podemos ver uma menção a este CPE. O primeiro problema que deve ser notado de imediato é que o CVE no NVD, segundo o CPE, relata que existe um problema no framework, e não em um componente específico. Ou seja, se os desenvolvedores estiverem fortemente ligados à estrutura e a vulnerabilidade identificada não se aplicar aos módulos que os desenvolvedores usam, o especialista em segurança terá de desmontar este CVE e pensar em atualizá-lo.



A URL também é usada por ferramentas SCA. O formato do URL do pacote é o seguinte:

scheme:type/namespace/name@version?qualifiers#subpath

• Esquema: Sempre haverá 'pkg' indicando que este é o URL do pacote (obrigatório)
• Tipo: O "tipo" do pacote ou o "protocolo" do pacote, como maven, npm, nuget, gem, pypi, etc. (Cláusula obrigatória)
• Namespace: algum prefixo de nome, como ID do 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
• Qualificadores: qualificações adicionais para o pacote, como SO, arquitetura, distribuição, etc. Item opcional e específico do tipo.
• Subcaminho: caminho adicional no pacote em relação à 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

Dependency Track é uma plataforma web local que aceita listas de materiais (BOM) prontas geradas por CycloneDX e SPDX , ou seja, especificações prontas sobre dependências existentes. Este é um arquivo XML com uma descrição das dependências - nome, hashes, url do pacote, editor, licença. Em seguida, o Dependency Track analisa o BOM, olha os CVEs disponíveis para as dependências identificadas do banco de dados de vulnerabilidade (NVD, Sonatype OSS Index ...), então constrói gráficos, calcula métricas, atualizando regularmente os dados de status de vulnerabilidade do componente.



Um exemplo de como um BOM pode se parecer 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/tomcat-catalina@9.0.14</purl>
    </component>
      <!-- More components here -->
  </components>
</bom>

O BOM pode ser usado não apenas como parâmetros de entrada para o Rastreamento de dependência, mas também para inventariar componentes de software na cadeia de suprimentos, por exemplo, para fornecer software ao cliente. Em 2014, a Lei de Transparência e Gestão da Cadeia de Abastecimento Cibernético de 2014 foi até proposta para consideração nos Estados Unidos , que afirmava que, ao comprar software, qualquer estado. a instituição deve solicitar um BOM para evitar a exploração de componentes vulneráveis, mas o ato nunca entrou em vigor.



Voltando ao SCA, o Dependency Track tem integrações prontas para uso com plataformas de notificação como Slack, sistemas de gerenciamento de vulnerabilidade como Kenna Security. Também deve ser dito que Dependency Track, entre outras coisas, detecta versões desatualizadas de pacotes e fornece informações sobre licenças (devido ao suporte para SPDX).



Se falarmos especificamente sobre a qualidade do SCA, então há uma diferença fundamental.



O Dependency Track não aceita o projeto como entrada, mas o BOM. Isso significa que se quisermos verificar o projeto, primeiro precisamos gerar bom.xml, por exemplo, usando CycloneDX. Portanto, Dependency Track é diretamente dependente do CycloneDX. Ao mesmo tempo, permite a personalização. Portanto, a equipe OZON escreveu o módulo CycloneDX para construir arquivos BOM para projetos Golang para varredura adicional através do Dependency Track.



Nexus IQÉ uma solução SCA comercial 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 de guerra (para projetos java) por meio da interface web ou API, quanto BOM, se sua organização não conseguiu reconstruir 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 CPE / PURL para o componente identificado e a 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 de QI serão discutidos posteriormente na análise dos resultados.



Vamos resumir alguns dos recursos funcionais e também considerar os idiomas suportados para análise:





Funcionalidade





Oportunidades de integração

Verificação de Dependência

Primeira partida

Vamos executar a verificação de dependência em um aplicativo DVJA deliberadamente vulnerável .



Para fazer isso, usaremos o plug - in Maven de verificação de dependência :

mvn org.owasp:dependency-check-maven:check

Como resultado, dependency-check-report.html aparecerá no diretório de destino.







Vamos abrir o arquivo. Após as informações resumidas sobre o número total de vulnerabilidades, podemos ver informações sobre vulnerabilidades com alto nível de Severidade e Confiança, indicando o pacote, CPE, número CVE.



Isso é seguido por informações mais detalhadas, em particular em que a evidência se baseou, ou seja, uma determinada BOM.







Em seguida, vem a descrição de CPE, PURL e CVE. A propósito, as recomendações de correção não foram anexadas devido à sua ausência no banco de dados NVD.







Para revisar 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 aos conectores de verificação de dependência. Por exemplo, Defect Dojo.

Rastreamento de Dependência

Instalação

O Dependency Track, por sua vez, é uma plataforma da web com gráficos de exibição, portanto, não há problemas graves de armazenamento de defeitos em uma solução de terceiros.

Existem os seguintes scripts com suporte para instalação: Docker, WAR, Executable WAR.

Primeira partida

Vá para a URL do serviço em execução. Entramos através de admin / admin, mudamos o nome de usuário e senha, e então chegamos ao Dashboard. A próxima coisa que faremos é criar um projeto para o aplicativo de teste Java em Home / Projects → Create Project . Vamos tomar DVJA como exemplo.







Visto que o Rastreamento de dependência só pode aceitar um BOM como entrada, este BOM deve ser recuperado. Vamos usar o plug - in CycloneDX Maven :

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Obtenha bom.xml e carregue o arquivo no projeto DVJA criado → Dependências → Carregar BOM .



Vamos para Administração → Analisadores. Entendemos que temos apenas o analisador interno habilitado, incluindo NVD. Também conectaremos o índice Sonatype OSS.







Assim, teremos a seguinte imagem para 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 últimas versões suportadas da integração do Dependency Check foram 1.0.0 - 4.0.2, enquanto eu testei 5.3.2.



Aqui está um vídeo (e agora ) quando ainda era possível.

Nexus IQ

Primeira partida

O Nexus IQ é instalado a partir dos arquivos de documentação , mas compilamos uma imagem Docker para esse propósito.



Depois de 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 aplicáveis ​​a diferentes “estágios” (dev, build, stage, release). Isso é necessário para bloquear componentes vulneráveis ​​à medida que eles se movem ao longo do pipeline mais perto do produto ou para bloquear assim que entram no Nexus Repo quando baixados pelos desenvolvedores.



Para sentir a diferença entre open source e enterprise, vamos realizar a mesma varredura por meio do Nexus IQ da mesma forma por meio do plugin Maven , tendo criado anteriormente 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 para o relatório gerado na interface da web do IQ:







Aqui você pode ver todas as violações de política com diferentes níveis de significância (de Informações a Crítico de segurança). A letra D próxima ao componente significa que o componente é Dependência Direta, e a letra T próxima ao componente significa que o componente é Dependência Transitiva, ou seja, é transitivo.



A propósito, o Relatório de Segurança do Estado de Código Aberto 2020 de Snyk relata que mais de 70% das vulnerabilidades de código aberto encontradas em Node.js, Java e Ruby estão em dependências transitivas.



Se abrirmos uma das violações de política do Nexus IQ, podemos ver a descrição do componente, bem como o gráfico da versão, que mostra a localização da versão atual na linha do tempo, bem como em que ponto a vulnerabilidade não é mais vulnerável. A altura das velas no gráfico mostra a popularidade deste componente.







Se você for até a seção de vulnerabilidade e divulgar o CVE, poderá ler uma descrição dessa vulnerabilidade, recomendações para eliminação, bem como o motivo da violação desse componente, ou seja, a presença de uma classe DiskFileitem.class.











Vamos resumir apenas os componentes Java de terceiros, removendo os componentes js. Entre parênteses, indicamos o número de vulnerabilidades que foram encontradas fora do NVD.



Nexus IQ total:

• 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 sistemas de sonatipo)

Controle de dependência total:

• Dependências verificadas: 59
• Dependências vulneráveis: 10
• Vulnerabilidades encontradas: 51 (1 sistema de sonatipo)

Nas próximas etapas, analisaremos os resultados e descobriremos qual dessas vulnerabilidades é um defeito real e qual é um falso positivo.

aviso Legal

Esta revisão não é uma verdade inegável. O autor não tinha como objetivo distinguir um instrumento separado do background de outros. O objetivo da revisão era mostrar como as ferramentas SCA funcionam e como verificar seus resultados.

Comparação de resultados

Condições: um



falso positivo em relação a vulnerabilidades em componentes de terceiros é:

• CVE incompatível para o componente identificado
• , struts2, struts-tiles, , false positive
• CVE
• , python > 3.5 2.7 — false positive, 3.x
• CVE
• , SCA CVE, RCE, SCA CVE, Cisco, RCE. false positive.
• Por exemplo, CVE foi encontrado em um componente spring-web, após o qual SCA aponta para o mesmo CVE em outros componentes do Spring Framework, enquanto CVE não tem nada a ver com outros componentes. Nesse caso, será um falso positivo.

O projeto de código aberto DVJA foi escolhido como objeto de pesquisa. A pesquisa envolveu apenas componentes java (sem js).

Resultados resumidos

Vamos direto ao resultado 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:



Resultados resumidos por componente:



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.















Em comparação, um estudo semelhante foi conduzido pela equipe da Sonatype para testar um projeto de componente 1.531 usando a verificação de dependência OWASP. Como podemos ver, a proporção de ruído para gatilhos corretos é comparável aos nossos resultados.





Fonte: www.sonatype.com/why-precision-matters-ebook



Vamos dar uma olhada em alguns CVEs de nossos resultados de varredura para entender o motivo desses resultados.

Mais detalhes

# 1

Vamos dar uma olhada em alguns pontos interessantes do Sonatype Nexus IQ primeiro.



O Nexus IQ aponta para um problema de 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. A princípio, parece que há uma duplicação da vulnerabilidade em vários CVEs. Pois se você olhar para CVE-2016-1000027 e CVE-2011-2894 no banco de dados NVD, então parece que tudo é óbvio





Descrição do CVE-2011-2894 do NVD :





Descrição do CVE-2016-1000027 do NVD : o próprio





CVE-2011-2894 é bastante famoso. O relatório da White Source de 2011 classificou este CVE como um dos mais encontrados. As descrições para CVE-2016-100027 são, em princípio, um pouco em NVD, e parece ser aplicável apenas para Spring Framework 4.1.4. Dê uma olhada na referência e aqui fica mais ou menos claro. Entendemos com base no artigo da Tenable que, além da vulnerabilidade RemoteInvocationSerializingExporterem CVE-2011-2894, a vulnerabilidade é observada em HttpInvokerServiceExporter. Isso é 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 falso negativo.



Além disso, a partir da descrição de CVE-2011-2894, você pode entender que a vulnerabilidade está realmente presente no contexto do spring: 3.0.5 e do spring-core: 3.0.5. A confirmação disso pode ser encontrada em um artigo da pessoa que descobriu essa vulnerabilidade.

# 2

Se estudarmos a vulnerabilidade CVE-2016-4003, entenderemos que ela foi corrigida na versão 2.3.28, porém o Nexus IQ nos informa sobre isso. Há uma observação na descrição da vulnerabilidade:







Ou seja, a vulnerabilidade existe apenas em conjunto com uma versão desatualizada do JRE, sobre a qual eles decidiram nos avisar. No entanto, consideramos que este é um Falso Positivo, embora não seja o pior.

Número 3

Se olharmos as descrições para CVE-2017-9804 e CVE-2017-7672, entenderemos que o problema é URLValidator class, e CVE-2017-9804 segue de CVE-2017-7672. A presença da segunda vulnerabilidade não carrega nenhuma carga útil, exceto que sua gravidade cresceu para Alta, então isso pode ser considerado ruído desnecessário.



No geral, nenhum outro falso positivo foi encontrado para o Nexus IQ.

# 4

Existem várias coisas que diferenciam o QI de outras decisões.





O CVE no NVD diz que é aplicável apenas para as 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 CVE no Nexus IQ, veremos o seguinte:

Aviso de desvio de aviso: 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 declarado no aviso.



Isso é seguido por uma PoC para esta vulnerabilidade, que relata 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 o falso positivo para Verificação de dependência e Rastreamento de dependência.



A Verificação de Dependência se destaca por refletir aqueles CVEs que se aplicam a toda a estrutura do NVD para aqueles componentes aos quais esses CVEs não são aplicáveis. 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 "aparafusada" 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 em CVE - processamento de solicitação, validação de página e assim por diante. Isso se deve ao fato de que o comum entre esses CVEs e os componentes é apenas o framework, por isso a Verificação de Dependência o considerou uma vulnerabilidade.



A mesma situação com spring-tx: 3.0.5, e uma situação semelhante com struts-core: 1.3.8. Para struts-core, Dependency Check e 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 a imagem e nos CVEs que emitiu indicou que o struts-core chegou ao fim da vida útil e era necessário ir para o struts2-core.

# 6

Em algumas situações, é injusto interpretar um erro explícito 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 são Verificação de Dependência e Rastreamento de Dependência referido a spring-core: 3.0.5 na verdade referem-se a spring-web: 3.0.5. Ao mesmo tempo, alguns desses CVEs foram encontrados e o Nexus IQ, no entanto, o IQ os identificou corretamente para outro componente. Uma vez que essas vulnerabilidades não foram encontradas no spring-core, não se pode argumentar que elas não estão no framework, em princípio, e as ferramentas de código aberto apontaram corretamente essas vulnerabilidades (elas apenas perderam um pouco).

conclusões

Como podemos ver, determinar a confiabilidade das vulnerabilidades identificadas pela revisão manual não fornece resultados inequívocos, o que leva a questões controversas. Os resultados são tais que a solução Nexus IQ tem a menor taxa de falsos positivos e a maior precisão.



Em primeiro lugar, isso se deve ao fato de que a equipe da Sonatype expandiu a descrição de cada vulnerabilidade CVE do NVD em seus bancos de dados, especificando, com precisão para a classe ou função da vulnerabilidade para uma determinada versão do componente, conduzindo pesquisas adicionais (por exemplo, verificação de vulnerabilidades em versões de software).



Uma influência importante nos resultados é exercida por aquelas vulnerabilidades que não foram incluídas no NVD, mas, no entanto, estão presentes no banco de dados Sonatype com a marca SONATYPE. De acordo com o The State of Open Source Security Vulnerabilities 202045% 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 sendo publicadas lá, por isso é importante procurar vulnerabilidades em outro lugar também.



Como resultado, a verificação de dependência gera muito ruído, faltando alguns componentes vulneráveis. Dependency Track produz menos ruído e revela um grande número de componentes, que visualmente não prejudicam os olhos na interface da web.



No entanto, a prática mostra que o código-fonte aberto deve ser o primeiro passo para amadurecer o DevSecOps. A primeira coisa a pensar para incorporar a SCA no desenvolvimento são os processos, nomeadamente, pensar em conjunto com a gestão e departamentos relacionados sobre como devem ser os processos ideais na sua organização. Pode acontecer que, para sua organização, a princípio, a Verificação de dependência ou Rastreamento de dependência abranja todas as necessidades de negócios e as soluções corporativas sejam uma continuação lógica devido à complexidade crescente dos aplicativos desenvolvidos.