DevSecOps: principios de funcionamento e comparación de SCA. Primeira parte

A importancia da análise de compoñentes de software de terceiros (Software Composition Analysis - SCA) no proceso de desenvolvemento está crecendo coa publicación de informes anuais sobre as vulnerabilidades das bibliotecas de código aberto, que son publicados por Synopsys, Sonatype, Snyk e White Source. . Segundo o informe O estado das vulnerabilidades de seguridade de código aberto 2020 o número de vulnerabilidades de código aberto identificadas en 2019 aumentou case 1.5 veces en comparación co ano anterior, mentres que os compoñentes de código aberto son utilizados polo 60% ao 80% dos proxectos. De xeito independente, os procesos SCA son unha práctica separada de OWASP SAMM e BSIMM como indicador de madurez e, no primeiro semestre de 2020, OWASP lanzou o novo Estándar de verificación de compoñentes de software (SCVS) OWASP, que ofrece as mellores prácticas para verificar terceiros. compoñentes do partido na cadea de subministración BY.

Un dos casos máis ilustrativos pasou con Equifax en maio de 2017. Os atacantes descoñecidos obtiveron información sobre 143 millóns de estadounidenses, incluíndo nomes completos, enderezos, números da Seguridade Social e carnés de conducir. En 209 casos, os documentos tamén incluíron información sobre as tarxetas bancarias das vítimas. Esta fuga produciuse como resultado da explotación dunha vulnerabilidade crítica en Apache Struts 000 (CVE-2-2017), mentres que a corrección foi lanzada en marzo de 5638. A empresa tiña dous meses para instalar a actualización, pero ninguén se molestou con ela.

Neste artigo analizarase a cuestión da elección dunha ferramenta para a realización de SCA desde o punto de vista da calidade dos resultados da análise. Tamén se ofrecerá unha comparación funcional das ferramentas. O proceso de integración en CI/CD e as capacidades de integración quedará para publicacións posteriores. OWASP presentou unha ampla gama de ferramentas no seu sitio web, pero na revisión actual só tocaremos a ferramenta de código aberto máis popular Dependency Check, a plataforma de código aberto un pouco menos coñecida Dependency Track e a solución empresarial Sonatype Nexus IQ. Tamén comprenderemos como funcionan estas solucións e compararemos os resultados obtidos para falsos positivos.

Principio de funcionamento

Verificación de dependencia é unha utilidade (CLI, maven, módulo jenkins, ant) ​​que analiza ficheiros de proxecto, recolle información sobre dependencias (nome do paquete, groupid, título da especificación, versión...), constrúe unha liña CPE (Common Platform Enumeration) , URL do paquete (PURL) e identifica vulnerabilidades para CPE/PURL a partir de bases de datos (NVD, Sonatype OSS Index, NPM Audit API...), despois de que crea un informe único en formato HTML, JSON, XML...

Vexamos como é o CPE:

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

• Parte: Indicación de que o compoñente se relaciona coa aplicación (a), sistema operativo (o), hardware (h) (obrigatorio)
• Vendedor: Nome do fabricante do produto (obrigatorio)
• Produto: Nome do produto (obrigatorio)
• Versión: Versión do compoñente (elemento obsoleto)
• Actualización: Actualización do paquete
• edición: Versión antiga (elemento obsoleto)
• Idioma: Linguaxe definida en RFC-5646
• Edición SW: Versión de software
• SW obxectivo: Contorno de software no que opera o produto
• HW obxectivo: O contorno de hardware no que opera o produto
• outros: Información do provedor ou do produto

Un exemplo de CPE é o seguinte:

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

A liña significa que a versión 2.3 de CPE describe o compoñente da aplicación do fabricante pivotal_software co título spring_framework versión 3.0.0. Se abrimos unha vulnerabilidade CVE-2014-0225 en NVD, podemos ver unha mención deste CPE. O primeiro problema ao que debes prestar atención inmediatamente é que CVE en NVD, segundo CPE, informa dun problema no marco, e non nun compoñente específico. É dicir, se os desenvolvedores están estreitamente ligados ao marco e a vulnerabilidade identificada non afecta a aqueles módulos que usan os desenvolvedores, un especialista en seguridade terá que desmontar este CVE e pensar en actualizalo.

O URL tamén é usado polas ferramentas SCA. O formato do URL do paquete é o seguinte:

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

• Esquema: Sempre haberá 'pkg' que indica que este é un URL do paquete (obrigatorio)
• tipo: O "tipo" do paquete ou o "protocolo" do paquete, como maven, npm, nuget, gem, pypi, etc. (Elemento obrigatorio)
• Dominio: Algún prefixo de nome, como un ID de grupo Maven, propietario da imaxe de Docker, usuario de GitHub ou organización. Opcional e depende do tipo.
• nome: Nome do paquete (obrigatorio)
• Versión: Versión do paquete
• Eliminatorias: Datos de cualificación adicionais para o paquete, como SO, arquitectura, distribución, etc. Opcional e específico de tipo.
• Subruta: Ruta adicional no paquete en relación á raíz do paquete

Por exemplo:

pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/[email protected]
pkg:pypi/[email protected]

Pista de dependencia — unha plataforma web local que acepta listas de materiais (BOM) xeradas CycloneDX и SPDX, é dicir, especificacións preparadas sobre dependencias existentes. Este é un ficheiro XML que describe as dependencias: nome, hash, URL do paquete, editor, licenza. A continuación, Dependency Track analiza a BOM, analiza os CVE dispoñibles para as dependencias identificadas a partir da base de datos de vulnerabilidades (NVD, Sonatype OSS Index...), despois de que constrúe gráficos, calcula métricas, actualizando regularmente os datos sobre o estado de vulnerabilidade dos compoñentes. .

Un exemplo de como pode ser unha lista de materiales en 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 usarse non só como parámetros de entrada para Dependency Track, senón tamén para inventariar compoñentes de software na cadea de subministración, por exemplo, para proporcionar software a un cliente. En 2014, incluso se propuxo unha lei nos Estados Unidos "Lei de xestión e transparencia da cadea de subministración cibernética de 2014", que afirmou que ao comprar software, calquera estado. A institución debe solicitar unha BOM para evitar o uso de compoñentes vulnerables, pero a lei aínda non entrou en vigor.

Volvendo a SCA, Dependency Track ten integracións preparadas con plataformas de notificación como Slack, sistemas de xestión de vulnerabilidades como Kenna Security. Tamén cabe dicir que Dependency Track, entre outras cousas, identifica versións desactualizadas dos paquetes e ofrece información sobre licenzas (debido ao soporte de SPDX).

Se falamos específicamente da calidade do SCA, entón hai unha diferenza fundamental.

Dependency Track non acepta o proxecto como entrada, senón a BOM. Isto significa que se queremos probar o proxecto, primeiro necesitamos xerar bom.xml, por exemplo usando CycloneDX. Así, Dependency Track depende directamente de CycloneDX. Ao mesmo tempo, permite a personalización. Isto é o que escribiu o equipo de OZON Módulo CycloneDX para ensamblar ficheiros BOM para proxectos Golang para analizar máis a través da pista de dependencia.

Nexus IQ é unha solución SCA comercial de Sonatype, que forma parte do ecosistema Sonatype, que tamén inclúe Nexus Repository Manager. Nexus IQ pode aceptar como entrada tanto arquivos de guerra (para proxectos Java) a través da interface web ou API, como BOM, se a súa organización aínda non cambiou de CycloneDX a unha nova solución. A diferenza das solucións de código aberto, IQ refírese non só a CP/PURL ao compoñente identificado e á vulnerabilidade correspondente na base de datos, senón que tamén ten en conta a súa propia investigación, por exemplo, o nome da función ou clase vulnerable. Os mecanismos do coeficiente intelectual serán discutidos máis adiante na análise dos resultados.

Resumimos algunhas das características funcionais e consideremos tamén as linguaxes admitidas para a análise:

Linguaxe
Nexus IQ
Verificación de dependencia
Pista de dependencia

Java
+
+
+

C / C ++
+
+
-

C#
+
+
-

.Net
+
+
+

Erlang
-
-
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Pitão
+
+
+

Rubio
+
+
+

Perl
-
-
-

Scala
+
+
+

Obxectivo C
+
+
-

Rápido
+
+
-

R
+
-
-

Go
+
+
+

Funcionalidade

Funcionalidade
Nexus IQ
Verificación de dependencia
Pista de dependencia

A capacidade de garantir que os compoñentes utilizados no código fonte se comproben a pureza con licenza
+
-
+

Capacidade de dixitalizar e analizar vulnerabilidades e limpeza da licenza para imaxes de Docker
+ Integración con Clair
-
-

Capacidade de configurar políticas de seguridade para usar bibliotecas de código aberto
+
-
-

Capacidade de escanear repositorios de código aberto en busca de compoñentes vulnerables
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
-
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Dispoñibilidade dun grupo de investigación especializado
+
-
-

Operación en bucle pechado
+
+
+

Uso de bases de datos de terceiros
+ Base de datos Sonatype pechada
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, soporte para a súa propia base de datos de vulnerabilidades

Capacidade de filtrar compoñentes de código aberto cando se intenta cargar no bucle de desenvolvemento segundo as políticas configuradas
+
-
-

Recomendacións para solucionar vulnerabilidades, dispoñibilidade de ligazóns a correccións
+
+- (depende da descrición nas bases de datos públicas)
+- (depende da descrición nas bases de datos públicas)

Clasificación das vulnerabilidades detectadas segundo a gravidade
+
+
+

Modelo de acceso baseado en roles
+
-
+

Soporte CLI
+
+
+- (só para CycloneDX)

Mostraxe/clasificación de vulnerabilidades segundo criterios definidos
+
-
+

Panel de control por estado da aplicación
+
-
+

Xeración de informes en formato PDF
+
-
-

Xeración de informes en formato JSONCSV
+
+
-

Apoio á lingua rusa
-
-
-

Capacidades de integración

Integración
Nexus IQ
Verificación de dependencia
Pista de dependencia

Integración LDAP/Active Directory
+
-
+

Integración con sistema de integración continua Bamboo
+
-
-

Integración co sistema de integración continua TeamCity
+
-
-

Integración co sistema de integración continua GitLab
+
+- (como complemento para GitLab)
+

Integración co sistema de integración continua Jenkins
+
+
+

Dispoñibilidade de complementos para IDE
+ IntelliJ, Eclipse, Visual Studio
-
-

Soporte para a integración personalizada mediante servizos web (API) da ferramenta
+
-
+

Verificación de dependencia

Primeiro comezo

Imos executar a comprobación de dependencia nunha aplicación deliberadamente vulnerable DVJA.

Para iso utilizaremos Complemento Maven de verificación de dependencia:

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

Como resultado, dependency-check-report.html aparecerá no directorio de destino.

Imos abrir o ficheiro. Despois da información resumida sobre o número total de vulnerabilidades, podemos ver información sobre vulnerabilidades cun alto nivel de Gravidade e Confianza, indicando o paquete, CPE e número de CVE.

A continuación vén información máis detallada, en particular a base sobre a que se tomou a decisión (evidencia), é dicir, unha determinada lista de materiales.

A continuación vén a descrición CPE, PURL e CVE. Por certo, non se inclúen recomendacións de corrección debido á súa ausencia na base de datos NVD.

Para ver de forma sistemática os resultados da exploración, pode configurar Nginx cunha configuración mínima ou enviar os defectos resultantes a un sistema de xestión de defectos que admita conectores para Comprobación de dependencia. Por exemplo, Defect Dojo.

Pista de dependencia

Instalación

Dependency Track, pola súa banda, é unha plataforma baseada na web con gráficos de visualización, polo que aquí non xorde o problema urgente de almacenar defectos nunha solución de terceiros.
Os scripts compatibles para a instalación son: Docker, WAR, Executable WAR.

Primeiro comezo

Imos á URL do servizo en execución. Iniciamos sesión mediante admin/admin, cambiamos o inicio de sesión e o contrasinal e, a continuación, accedemos ao panel. O seguinte que faremos é crear un proxecto para unha aplicación de proba en Java Inicio/Proxectos → Crear proxecto . Poñamos como exemplo o DVJA.

Dado que Dependency Track só pode aceptar BOM como entrada, esta BOM debe ser recuperada. Aproveitemos Complemento CycloneDX Maven:

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

Conseguimos bom.xml e cargamos o ficheiro no proxecto creado DVJA → Dependencias → Cargar BOM.

Imos a Administración → Analizadores. Entendemos que só temos o Analizador interno activado, que inclúe NVD. Conectemos tamén Sonatype OSS Index.

Así, obtemos a seguinte imaxe para o noso proxecto:

Tamén na lista podes atopar unha vulnerabilidade aplicable a Sonatype OSS:

A principal decepción foi que Dependency Track xa non acepta informes XML de Dependency Check. As últimas versións compatibles da integración de comprobación de dependencia foron 1.0.0 - 4.0.2, mentres que eu probei a 5.3.2.

Aquí video (e velaquí) cando aínda era posible.

Nexus IQ

Primeiro comezo

A instalación de Nexus IQ procede dos arquivos de documentación, pero creamos unha imaxe de Docker para estes propósitos.

Despois de iniciar sesión na consola, cómpre crear unha organización e unha aplicación.

Como podes ver, a configuración no caso de IQ é algo máis complicada, porque tamén necesitamos crear políticas que sexan aplicables para diferentes "etapas" (desenvolvemento, compilación, etapa, lanzamento). Isto é necesario para bloquear os compoñentes vulnerables a medida que se moven pola canalización máis preto da produción ou para bloquealos tan pronto como entren no repositorio de Nexus cando os desenvolvedores os descarguen.

Para notar a diferenza entre o código aberto e o empresarial, realicemos a mesma exploración a través de Nexus IQ do mesmo xeito que Complemento Maven, tendo creado previamente unha aplicación de proba 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 o URL do informe xerado na interface web de IQ:

Aquí podes ver todas as infraccións das políticas que indican diferentes niveis de importancia (desde Información ata Crítico de seguridade). A letra D xunto ao compoñente significa que o compoñente é Dependencia Directa, e a letra T ao lado do compoñente significa que o compoñente é Dependencia Transitiva, é dicir, é transitiva.

Por certo, o informe Informe sobre o estado da seguridade de código aberto 2020 de Snyk informa que máis do 70% das vulnerabilidades de código aberto descubertas en Node.js, Java e Ruby están en dependencias transitivas.

Se abrimos unha das infraccións da política de Nexus IQ, poderemos ver unha descrición do compoñente, así como un gráfico de versións, que mostra a localización da versión actual no gráfico de tempo, así como en que momento deixa de ser a vulnerabilidade. ser vulnerable. A altura das velas no gráfico mostra a popularidade do uso deste compoñente.

Se vai á sección de vulnerabilidades e amplía o CVE, pode ler unha descrición desta vulnerabilidade, recomendacións para a súa eliminación, así como o motivo polo que se violou este compoñente, é dicir, a presenza da clase. DiskFileitem.class.

Sintetizamos só os relacionados con compoñentes Java de terceiros, eliminando os compoñentes js. Entre parénteses indicamos o número de vulnerabilidades que se atoparon fóra de NVD.

Total Nexus IQ:

• Dependencias escaneadas: 62
• Dependencias vulnerables: 16
• Vulnerabilidades atopadas: 42 (8 sonatype db)

Comprobación de dependencia total:

• Dependencias escaneadas: 47
• Dependencias vulnerables: 13
• Vulnerabilidades atopadas: 91 (14 sonatype oss)

Pista de dependencia total:

• Dependencias escaneadas: 59
• Dependencias vulnerables: 10
• Vulnerabilidades atopadas: 51 (1 sonatype oss)

Nos próximos pasos, analizaremos os resultados obtidos e descubriremos cal destas vulnerabilidades é un defecto real e cal é un falso positivo.

Exención de responsabilidade

Esta revisión non é unha verdade indiscutible. O autor non tiña como obxectivo destacar un instrumento separado sobre o fondo doutros. O propósito da revisión foi mostrar os mecanismos de funcionamento das ferramentas SCA e as formas de comprobar os seus resultados.

Comparación de resultados

Os termos e condicións:

Un falso positivo para as vulnerabilidades de compoñentes de terceiros é:

• Desaxuste CVE co compoñente identificado
• Por exemplo, se se identifica unha vulnerabilidade no marco struts2 e a ferramenta apunta a un compoñente do marco struts-tiles, ao que non se aplica esta vulnerabilidade, entón este é un falso positivo
• O CVE non coincide coa versión identificada do compoñente
• Por exemplo, a vulnerabilidade está ligada á versión de Python > 3.5 e a ferramenta marca a versión 2.7 como vulnerable; este é un falso positivo, xa que de feito a vulnerabilidade só se aplica á rama do produto 3.x.
• CVE duplicado
• Por exemplo, se o SCA especifica un CVE que habilita un RCE, entón o SCA especifica un CVE para ese mesmo compoñente que se aplica aos produtos de Cisco afectados por ese RCE. Neste caso será falso positivo.
• Por exemplo, atopouse un CVE nun compoñente spring-web, despois de que SCA sinala o mesmo CVE noutros compoñentes do Spring Framework, mentres que o CVE non ten nada que ver con outros compoñentes. Neste caso será falso positivo.

O obxecto do estudo foi o proxecto Open Source DVJA. O estudo incluíu só compoñentes java (sen js).

Resultados resumidos

Imos directamente aos resultados dunha revisión manual das vulnerabilidades identificadas. O informe completo de cada CVE pódese consultar no anexo.

Resultados resumidos para todas as vulnerabilidades:

Parámetro
Nexus IQ
Verificación de dependencia
Pista de dependencia

Total de vulnerabilidades identificadas
42
91
51

Vulnerabilidades identificadas incorrectamente (falsos positivos)
2 (4.76%)
62 (68,13%)
29 (56.86%)

Non se atoparon vulnerabilidades relevantes (falso negativo)
10
20
27

Resultados resumidos por compoñente:

Parámetro
Nexus IQ
Verificación de dependencia
Pista de dependencia

Total de compoñentes identificados
62
47
59

Total de compoñentes vulnerables
16
13
10

Compoñentes vulnerables identificados incorrectamente (falsos positivos)
1
5
0

Compoñentes vulnerables identificados incorrectamente (falsos positivos)
0
6
6

Imos construír gráficos visuais para avaliar a proporción de falsos positivos e falsos negativos co número total de vulnerabilidades. Os compoñentes están marcados horizontalmente e as vulnerabilidades identificadas neles están marcadas verticalmente.

A modo de comparación, o equipo de Sonatype realizou un estudo similar para probar un proxecto de 1531 compoñentes mediante OWASP Dependency Check. Como podemos ver, a relación entre o ruído e as respostas correctas é comparable aos nosos resultados.

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

Vexamos algúns CVE dos nosos resultados de exploración para comprender o motivo destes resultados.

Máis

№ 1

Vexamos primeiro algúns puntos interesantes sobre o Sonatype Nexus IQ.

Nexus IQ sinala un problema coa deserialización coa capacidade de realizar RCE no Spring Framework varias veces. CVE-2016-1000027 en spring-web:3.0.5 por primeira vez, e CVE-2011-2894 en spring-context:3.0.5 e spring-core:3.0.5. Ao principio, parece que hai duplicación da vulnerabilidade en varios CVE. Porque, se miras CVE-2016-1000027 e CVE-2011-2894 na base de datos NVD, parece que todo é obvio

Compoñente
Vulnerabilidade

primavera-web: 3.0.5
CVE-2016-1000027

primavera-contexto:3.0.5
CVE-2011-2894

núcleo de resorte: 3.0.5
CVE-2011-2894

Descrición CVE-2011-2894 de NVD:


Descrición CVE-2016-1000027 de NVD:


O propio CVE-2011-2894 é bastante famoso. No informe Fonte Branca 2011 este CVE foi recoñecido como un dos máis comúns. As descricións para CVE-2016-100027, en principio, son poucas en NVD, e parece que só é aplicable para Spring Framework 4.1.4. Botámoslle unha ollada referencia e aquí todo queda máis ou menos claro. Desde Artigos sostibles Entendemos que ademais da vulnerabilidade en RemoteInvocationSerializingExporter en CVE-2011-2894, a vulnerabilidade obsérvase en HttpInvokerServiceExporter. Isto é o que nos di Nexus IQ:

Non obstante, non hai nada como isto en NVD, polo que a comprobación de dependencia e o seguimento de dependencia reciben un falso negativo.

Tamén a partir da descrición do CVE-2011-2894 pódese entender que a vulnerabilidade está realmente presente tanto en spring-context:3.0.5 como en spring-core:3.0.5. A confirmación diso pódese atopar nun artigo da persoa que atopou esta vulnerabilidade.

№ 2

Compoñente
Vulnerabilidade
Resultado

puntales 2 núcleos: 2.3.30
CVE-2016-4003
FALSE

Se estudamos a vulnerabilidade CVE-2016-4003, entenderemos que foi corrixida na versión 2.3.28, non obstante, Nexus IQ infórmao. Hai unha nota na descrición da vulnerabilidade:

É dicir, a vulnerabilidade só existe en conxunto cunha versión obsoleta do JRE, da que decidiron advertirnos. Non obstante, consideramos este falso positivo, aínda que non é o peor.

# 3

Compoñente
Vulnerabilidade
Resultado

xwork-core: 2.3.30
CVE-2017-9804
TRUE

xwork-core: 2.3.30
CVE-2017-7672
FALSE

Se observamos as descricións de CVE-2017-9804 e CVE-2017-7672, entenderemos que o problema é URLValidator class, con CVE-2017-9804 derivado de CVE-2017-7672. A presenza da segunda vulnerabilidade non leva ningunha carga útil que non sexa o feito de que a súa gravidade aumentou a Alta, polo que podemos considerala un ruído innecesario.

En xeral, non se atoparon outros falsos positivos para Nexus IQ.

№ 4

Hai varias cousas que fan que IQ destaque doutras solucións.

Compoñente
Vulnerabilidade
Resultado

primavera-web: 3.0.5
CVE-2020-5398
TRUE

O CVE do NVD indica que só se aplica ás versións 5.2.x anteriores á 5.2.3, 5.1.x anteriores á 5.1.13 e ás versións 5.0.x anteriores á 5.0.16, porén, se observamos a descrición do CVE en Nexus IQ , entón veremos o seguinte:
Aviso de desviación do aviso: o equipo de investigación de seguranza de Sonatype descubriu que esta vulnerabilidade foi introducida na versión 3.0.2.RELEASE e non na 5.0.x como se indica no aviso.

A continuación segue un PoC para esta vulnerabilidade, que indica que está presente na versión 3.0.5.

O falso negativo envíase a Comprobación de dependencias e Seguimento de dependencias.

№ 5

Vexamos os falsos positivos para a comprobación de dependencia e a pista de dependencia.

Dependency Check destaca por que reflicte aqueles CVE que se aplican a todo o marco en NVD a aqueles compoñentes aos que non se aplican estes CVE. Trátase de CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, que depende ” a struts-taglib:1.3.8 e struts-tiles-1.3.8. Estes compoñentes non teñen nada que ver co que se describe no CVE: procesamento de solicitudes, validación de páxinas, etc. Isto débese a que o que teñen en común estes CVE e compoñentes é só o framework, polo que Dependency Check considerouno unha vulnerabilidade.

A mesma situación é con spring-tx:3.0.5, e unha situación similar con struts-core:1.3.8. Para struts-core, Dependency Check e Dependency Track atoparon moitas vulnerabilidades que son realmente aplicables a struts2-core, que é esencialmente un marco separado. Neste caso, Nexus IQ entendeu correctamente a imaxe e nos CVE que emitiu indicaba que struts-core chegara ao final da súa vida útil e era necesario pasar a struts2-core.

№ 6

Nalgunhas situacións, é inxusto interpretar un erro obvio de verificación de dependencia e seguimento de dependencia. En particular CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, que dependen de verificación de seguimento e dependencia. atribuído a spring-core:3.0.5 realmente pertence a spring-web:3.0.5. Ao mesmo tempo, algúns destes CVE tamén foron atopados por Nexus IQ, porén, IQ identificounos correctamente con outro compoñente. Debido a que estas vulnerabilidades non se atoparon en spring-core, non se pode argumentar que non estean no marco en principio e as ferramentas de código aberto sinalaron con razón estas vulnerabilidades (só perderon un pouco).

Descubrimentos

Como podemos ver, determinar a fiabilidade das vulnerabilidades identificadas mediante a revisión manual non dá resultados inequívocos, polo que xorden cuestións controvertidas. Os resultados son que a solución Nexus IQ ten a taxa de falsos positivos máis baixa e a maior precisión.

En primeiro lugar, isto débese ao feito de que o equipo de Sonatype ampliou a descrición de cada vulnerabilidade CVE de NVD nas súas bases de datos, indicando as vulnerabilidades para unha versión particular dos compoñentes ata a clase ou función, realizando investigacións adicionais (por exemplo , comprobando vulnerabilidades en versións de software máis antigas).

Tamén teñen unha importante influencia nos resultados aquelas vulnerabilidades que non foron incluídas en NVD, pero que, con todo, están presentes na base de datos Sonatype coa marca SONATYPE. Segundo o informe O estado das vulnerabilidades de seguridade de código aberto 2020 O 45% das vulnerabilidades de código aberto descubertas non se informan a NVD. Segundo a base de datos WhiteSource, só o 29% de todas as vulnerabilidades de código aberto informadas fóra de NVD acaban publicadas alí, polo que é importante buscar vulnerabilidades tamén noutras fontes.

Como resultado, a comprobación de dependencia produce moito ruído e faltan algúns compoñentes vulnerables. Dependency Track produce menos ruído e detecta un gran número de compoñentes, o que non prexudica visualmente os ollos na interface web.

Non obstante, a práctica mostra que o código aberto debería converterse nos primeiros pasos cara a DevSecOps madura. O primeiro no que debes pensar ao integrar SCA no desenvolvemento son os procesos, é dicir, pensar xunto coa dirección e os departamentos relacionados sobre como deberían ser os procesos ideais na túa organización. Pode resultar que para a súa organización, nun principio, Dependency Check ou Dependency Track cubrirá todas as necesidades empresariais, e as solucións Enterprise serán unha continuación lóxica debido á crecente complexidade das aplicacións que se están a desenvolver.

Apéndice A: Resultados dos compoñentes
Símbolos:

• Alto: vulnerabilidades de nivel alto e crítico no compoñente
• Medio — Vulnerabilidades de nivel de criticidade medio no compoñente
• VERDADEIRO: verdadeiro problema positivo
• FALSO - Problema falso positivo

Compoñente
Nexus IQ
Verificación de dependencia
Pista de dependencia
Resultado

dom4j: 1.6.1
Alto
Alto
Alto
TRUE

Núcleo log4j: 2.3
Alto
Alto
Alto
TRUE

log4j: 1.2.14
Alto
Alto
-
TRUE

coleccións-común:3.1
Alto
Alto
Alto
TRUE

subida de ficheiros comúns: 1.3.2
Alto
Alto
Alto
TRUE

commons-beanutils: 1.7.0
Alto
Alto
Alto
TRUE

commons-codec: 1:10
medio
-
-
TRUE

mysql-connector-java:5.1.42
Alto
Alto
Alto
TRUE

primavera-expresión:3.0.5
Alto
compoñente non atopado

TRUE

primavera-web: 3.0.5
Alto
compoñente non atopado
Alto
TRUE

primavera-contexto:3.0.5
medio
compoñente non atopado
-
TRUE

núcleo de resorte: 3.0.5
medio
Alto
Alto
TRUE

struts2-config-browser-plugin:2.3.30
medio
-
-
TRUE

primavera-tx: 3.0.5
-
Alto
-
FALSE

puntas-núcleo: 1.3.8
Alto
Alto
Alto
TRUE

xwork-core: 2.3.30
Alto
-
-
TRUE

puntales 2 núcleos: 2.3.30
Alto
Alto
Alto
TRUE

struts-taglib:1.3.8
-
Alto
-
FALSE

puntales-tellas-1.3.8
-
Alto
-
FALSE

Anexo B: Resultados da vulnerabilidade
Símbolos:

• Alto: vulnerabilidades de nivel alto e crítico no compoñente
• Medio — Vulnerabilidades de nivel de criticidade medio no compoñente
• VERDADEIRO: verdadeiro problema positivo
• FALSO - Problema falso positivo

Compoñente
Nexus IQ
Verificación de dependencia
Pista de dependencia
Gravidade
Resultado
Comentario

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

Núcleo log4j: 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

coleccións-común:3.1
-
CVE-2015-6420
CVE-2015-6420
Alto
FALSE
Duplicados RCE(OSSINDEX)

-
CVE-2017-15708
CVE-2017-15708
Alto
FALSE
Duplicados RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Alto
TRUE

subida de ficheiros comúns: 1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Alto
TRUE

SONATYPE-2014-0173
-
-
medio
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 só se aplica ás versións 1.9.2+

commons-codec: 1:10
SONATYPE-2012-0050
-
-
medio
TRUE

mysql-connector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Alto
TRUE

CVE-2019-2692
CVE-2019-2692
-
medio
TRUE

-
CVE-2020-2875
-
medio
FALSE
A mesma vulnerabilidade que CVE-2019-2692, pero coa nota "os ataques poden afectar significativamente a produtos adicionais"

-
CVE-2017-15945
-
Alto
FALSE
Non relevante para mysql-connector-java

-
CVE-2020-2933
-
Baixo
FALSE
Duplicado do CVE-2020-2934

CVE-2020-2934
CVE-2020-2934
-
medio
TRUE

primavera-expresión:3.0.5
CVE-2018-1270
compoñente non atopado
-
Alto
TRUE

CVE-2018-1257
-
-
medio
TRUE

primavera-web: 3.0.5
CVE-2016-1000027
compoñente non atopado
-
Alto
TRUE

CVE-2014-0225
-
CVE-2014-0225
Alto
TRUE

CVE-2011-2730
-
-
Alto
TRUE

-
-
CVE-2013-4152
medio
TRUE

CVE-2018-1272
-
-
Alto
TRUE

CVE-2020-5398
-
-
Alto
TRUE
Un exemplo ilustrativo a favor de IQ: "O equipo de investigación de seguridade de Sonatype descubriu que esta vulnerabilidade foi introducida na versión 3.0.2.RELEASE e non na 5.0.x como se indica no aviso".

CVE-2013-6429
-
-
medio
TRUE

CVE-2014-0054
-
CVE-2014-0054
medio
TRUE

CVE-2013-6430
-
-
medio
TRUE

primavera-contexto:3.0.5
CVE-2011-2894
compoñente non atopado
-
medio
TRUE

núcleo de resorte: 3.0.5
-
CVE-2011-2730
CVE-2011-2730
Alto
TRUE

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
medio
TRUE

-
-
CVE-2013-4152
medio
FALSE
Duplicado da mesma vulnerabilidade en spring-web

-
CVE-2013-4152
-
medio
FALSE
A vulnerabilidade está relacionada co compoñente spring-web

-
CVE-2013-6429
CVE-2013-6429
medio
FALSE
A vulnerabilidade está relacionada co compoñente spring-web

-
CVE-2013-6430
-
medio
FALSE
A vulnerabilidade está relacionada co compoñente spring-web

-
CVE-2013-7315
CVE-2013-7315
medio
FALSE
SPLIT de CVE-2013-4152. + A vulnerabilidade refírese ao compoñente spring-web

-
CVE-2014-0054
CVE-2014-0054
medio
FALSE
A vulnerabilidade está relacionada co compoñente spring-web

-
CVE-2014-0225
-
Alto
FALSE
A vulnerabilidade está relacionada co compoñente spring-web

-
-
CVE-2014-0225
Alto
FALSE
Duplicado da mesma vulnerabilidade en spring-web

-
CVE-2014-1904
CVE-2014-1904
medio
FALSE
A vulnerabilidade está relacionada co compoñente spring-web-mvc

-
CVE-2014-3625
CVE-2014-3625
medio
FALSE
A vulnerabilidade está relacionada co compoñente spring-web-mvc

-
CVE-2016-9878
CVE-2016-9878
Alto
FALSE
A vulnerabilidade está relacionada co compoñente spring-web-mvc

-
CVE-2018-1270
CVE-2018-1270
Alto
FALSE
Para expresión-primavera/mensaxes-primavera

-
CVE-2018-1271
CVE-2018-1271
medio
FALSE
A vulnerabilidade está relacionada co compoñente spring-web-mvc

-
CVE-2018-1272
CVE-2018-1272
Alto
TRUE

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
medio
TRUE

SONATYPE-2015-0327
-
-
Baixo
TRUE

struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
-
-
medio
TRUE

primavera-tx: 3.0.5
-
CVE-2011-2730
-
Alto
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2011-2894
-
Alto
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2013-4152
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2013-6429
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2013-6430
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2013-7315
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2014-0054
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2014-0225
-
Alto
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2014-1904
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2014-3625
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2016-9878
-
Alto
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2018-1270
-
Alto
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2018-1271
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

-
CVE-2018-1272
-
medio
FALSE
A vulnerabilidade non é específica de spring-tx

puntas-núcleo: 1.3.8
-
CVE-2011-5057 (OSSINDEX)

medio
FASLE
Vulnerabilidade a Struts 2

-
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Alto
FALSE
Vulnerabilidade a Struts 2

-
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
medio
FALSE
Vulnerabilidade a Struts 2

-
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Alto
FALSE
Vulnerabilidade a Struts 2

CVE-2016-1182
3VE-2016-1182
-
Alto
TRUE

-
-
CVE-2011-5057
medio
FALSE
Vulnerabilidade a Struts 2

-
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Alto
FALSE
Vulnerabilidade a Struts 2

-
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
medio
FALSE
Vulnerabilidade a Struts 2

CVE-2015-0899
CVE-2015-0899
-
Alto
TRUE

-
CVE-2012-0394
CVE-2012-0394
medio
FALSE
Vulnerabilidade a Struts 2

-
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Alto
FALSE
Vulnerabilidade a Struts 2

-
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Alto
FALSE
Vulnerabilidade a Struts 2

-
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Alto
FASLE
Vulnerabilidade a Struts 2

-
CVE-2013-2115
CVE-2013-2115
Alto
FASLE
Vulnerabilidade a Struts 2

-
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Alto
FASLE
Vulnerabilidade a Struts 2

-
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Alto
FASLE
Vulnerabilidade a Struts 2

CVE-2014-0114
CVE-2014-0114
-
Alto
TRUE

-
CVE-2015-2992
CVE-2015-2992
medio
FALSE
Vulnerabilidade a Struts 2

-
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Alto
FALSE
Vulnerabilidade a Struts 2

CVE-2016-1181
CVE-2016-1181
-
Alto
TRUE

-
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Alto
FALSE
Vulnerabilidade a Struts 2

xwork-core: 2.3.30
CVE-2017-9804
-
-
Alto
TRUE

SONATYPE-2017-0173
-
-
Alto
TRUE

CVE-2017-7672
-
-
Alto
FALSE
Duplicado do CVE-2017-9804

SONATYPE-2016-0127
-
-
Alto
TRUE

puntales 2 núcleos: 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 do CVE-2018-1327

-
CVE-2017-9804
-
Alto
TRUE

-
CVE-2017-9805
CVE-2017-9805
Alto
TRUE

CVE-2016-4003
-
-
medio
FALSE
Aplicable a Apache Struts 2.x ata 2.3.28, que é a versión 2.3.30. Non obstante, segundo a descrición, o CVE é válido para calquera versión de Struts 2 se se usa JRE 1.7 ou inferior. Ao parecer decidiron reasegurarnos aquí, pero parece máis que FALSO

-
CVE-2018-1327
CVE-2018-1327
Alto
TRUE

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Alto
TRUE
A mesma vulnerabilidade que os hackers de Equifax explotaron en 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
-
medio
FALSE
Para puntales de 2 núcleos

-
CVE-2013-2115
-
Alto
FALSE
Para puntales de 2 núcleos

-
CVE-2014-0114
-
Alto
FALSE
Para commons-beanutils

-
CVE-2015-0899
-
Alto
FALSE
Non se aplica a taglib

-
CVE-2015-2992
-
medio
FALSE
Refírese a struts2-core

-
CVE-2016-1181
-
Alto
FALSE
Non se aplica a taglib

-
CVE-2016-1182
-
Alto
FALSE
Non se aplica a taglib

puntales-tellas-1.3.8
-
CVE-2012-0394
-
medio
FALSE
Para puntales de 2 núcleos

-
CVE-2013-2115
-
Alto
FALSE
Para puntales de 2 núcleos

-
CVE-2014-0114
-
Alto
FALSE
Baixo commons-beanutils

-
CVE-2015-0899
-
Alto
FALSE
Non se aplica ás tellas

-
CVE-2015-2992
-
medio
FALSE
Para puntales de 2 núcleos

-
CVE-2016-1181
-
Alto
FALSE
Non se aplica a taglib

-
CVE-2016-1182
-
Alto
FALSE
Non se aplica a taglib

Fonte: www.habr.com