DevSecOps: principios de funcionamiento y comparación de SCA. Parte uno

La importancia del análisis de componentes de software de terceros (Análisis de composición de software en inglés - SCA) en el proceso de desarrollo está creciendo con la publicación de informes anuales sobre las vulnerabilidades de las bibliotecas de código abierto, publicados por Synopsys, Sonatype, Snyk, White Source. Según el informe El estado de las vulnerabilidades de seguridad de código abierto 2020 el número de vulnerabilidades identificadas en código abierto en 2019 aumentó casi 1.5 veces en comparación con el año anterior, mientras que los componentes de código abierto se utilizan en un 60% a 80% de los proyectos. En una opinión independiente, los procesos SCA son una práctica separada de OWASP SAMM y BSIMM como indicador de madurez, y en la primera mitad de 2020, OWASP lanzó un nuevo Estándar de verificación de componentes de software (SCVS) de OWASP que proporciona las mejores prácticas para verificar componentes en la cadena de suministro POR.

Uno de los casos más ilustrativos. sucedió con Equifax en mayo de 2017. Atacantes desconocidos han obtenido información sobre 143 millones de estadounidenses, incluidos nombres completos, direcciones, números de seguridad social y licencias de conducir. En 209 casos, los documentos también incluían información sobre las tarjetas bancarias de las víctimas. Esta fuga se produjo como consecuencia de la explotación de una vulnerabilidad crítica en Apache Struts 000 (CVE-2-2017), mientras que la corrección se publicó en marzo de 5638. La empresa tuvo dos meses para instalar la actualización, pero nadie se preocupó por eso.

Este artículo discutirá el tema de elegir una herramienta para realizar SCA en términos de calidad de los resultados del análisis. También se dará una comparación funcional de los instrumentos. Dejaremos el proceso de incrustación en CI/CD y las oportunidades de integración para publicaciones posteriores. OWASP ha introducido una amplia gama de herramientas en tu sitio web, pero como parte de la revisión actual, solo mencionaremos la herramienta Dependency Check de código abierto más popular, la plataforma Dependency Track de código abierto un poco menos conocida y la solución Sonatype Nexus IQ Enterprise. También entenderemos cómo funcionan estas soluciones y compararemos los resultados obtenidos para falsos positivos.

¿Cómo funciona?

Comprobación de dependencia es una utilidad (CLI, maven, módulo jenkins, ant) ​​que analiza archivos de proyecto, recopila fragmentos de información sobre dependencias (nombre del paquete, groupid, título de la especificación, versión ...), construye una cadena CPE - (Common Platform Enumeration ), URL del paquete ( PURL) y detecta vulnerabilidades para CPE/PURL de bases de datos (NVD, Sonatype OSS Index, NPM Audit API…), después de lo cual crea un informe único en formato HTML, JSON, XML…

Considere cómo se ve el CPE:

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

• Parte: Una indicación de que el componente pertenece a la aplicación (a), sistema operativo (o), hardware (h) (Ítem requerido)
• Vendedor: Nombre del fabricante del producto (Ítem requerido)
• Producto: Nombre del producto (obligatorio)
• Versión: Versión del componente (elemento obsoleto)
• Actualizar: Actualización del paquete
• Edición: Versión heredada (elemento obsoleto)
• Idioma: Idioma definido en RFC-5646
• Edición SO: Versión del software
• SO objetivo: El entorno de software en el que se ejecuta el producto.
• Hardware de destino: Entorno de hardware donde se ejecuta el producto
• Otro: Información del proveedor o producto

Un ejemplo de CPE se ve así:

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

La cadena significa que la versión 2.3 de CPE describe un componente de aplicación del fabricante. pivotal_software con el nombre spring_framework versión 3.0.0. Si abrimos una vulnerabilidad CVE-2014-0225 en NVD, podemos ver la mención de este CPE. El primer problema al que debe prestar atención de inmediato es que CVE en NVD, según CPE, informa la presencia de un problema en el marco, y no en un componente específico. Es decir, si los desarrolladores están estrechamente vinculados al marco y la vulnerabilidad identificada no se aplica a los módulos que usan los desarrolladores, el especialista en seguridad de alguna manera tendrá que desmontar este CVE y pensar en actualizarlo.

Las herramientas SCA también utilizan la URL. El formato de la URL del paquete es el siguiente:

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

• Esquema: Siempre habrá 'pkg' que indica que se trata de una URL de paquete (obligatorio)
• Tipo: El "tipo" del paquete o el "protocolo" del paquete, como maven, npm, nuget, gem, pypi, etc. (elemento requerido)
• Espacio de nombres: Algún prefijo de nombre, como un ID de grupo de Maven, propietario de una imagen de Docker, usuario u organización de GitHub. Opcional y depende del tipo.
• Nombre: Nombre del paquete (obligatorio)
• Versión: Versión del paquete
• Clasificación: Datos de calificación adicionales para el paquete, como SO, arquitectura, distribución, etc. Elemento opcional y específico del tipo.
• Subruta: Ruta adicional en el paquete relativa a la raíz del paquete

Por ejemplo:

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

Pista de dependencia — Plataforma web en las instalaciones que acepta listas de materiales (BOM) listas para usar generadas CiclónDX и SPDX, es decir, especificaciones preparadas sobre las dependencias disponibles. Este es un archivo XML con una descripción de las dependencias: nombre, hash, URL del paquete, editor, licencia. A continuación, Dependency Track analiza la lista de materiales, analiza los CVE disponibles para las dependencias identificadas de la base de datos de vulnerabilidades (NVD, Sonatype OSS Index...) y luego crea gráficos, calcula métricas y actualiza periódicamente los datos sobre el estado de vulnerabilidad de los componentes. .

Un ejemplo de cómo se vería una 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>

BOM se puede utilizar no solo como parámetros de entrada para Dependency Track, sino también para inventariar componentes de software en la cadena de suministro, por ejemplo, para proporcionar software a un cliente. En 2014, incluso se propuso una ley para su consideración en los Estados Unidos. «Ley de Gestión y Transparencia de la Cadena de Suministro Cibernético de 2014», que dijo que al comprar software, cualquier estado. una institución debe solicitar un BOM para evitar el uso de componentes vulnerables, pero la ley no ha entrado en vigor.

Volviendo a SCA, Dependency Track tiene integraciones listas para usar con plataformas de notificación como Slack, sistemas de gestión de vulnerabilidades como Kenna Security. También vale la pena mencionar que Dependency Track también detecta versiones obsoletas de paquetes y proporciona información sobre licencias (debido a la compatibilidad con SPDX).

Si hablamos específicamente de la calidad de SCA, entonces hay una diferencia fundamental.

Dependency Track no acepta un proyecto como entrada, sino una lista de materiales. Esto significa que si queremos probar el proyecto, primero debemos generar bom.xml, por ejemplo con CycloneDX. Por lo tanto, Dependency Track depende directamente de CycloneDX. Al mismo tiempo, permite la personalización. Así escribió el equipo de OZON Módulo CycloneDX para crear archivos BOM para proyectos de Golang para un análisis posterior a través de Dependency Track.

Coeficiente intelectual del nexo es una solución SCA comercial de Sonatype, que forma parte del ecosistema de Sonatype, que también incluye Nexus Repository Manager. Nexus IQ puede aceptar como entrada archivos de guerra (para proyectos Java) a través de la interfaz web o API, y BOM si su organización no ha tenido tiempo de cambiar de CycloneDX a una nueva solución. A diferencia de las soluciones de código abierto, IQ no solo se refiere al CP/PURL del componente identificado y la vulnerabilidad correspondiente en la base de datos, sino que también tiene en cuenta su propia investigación, por ejemplo, el nombre de la función o clase vulnerable. Los mecanismos del CI se discutirán más adelante en el análisis de los resultados.

Resumamos algunas de las características funcionales y también consideremos los idiomas admitidos para el análisis:

idioma
Coeficiente intelectual del nexo
Comprobación de dependencia
Pista de dependencia

Java
+
+
+

C / C ++
+
+
-

C#
+
+
-

. Net
+
+
+

Erlang
-
-
+

JavaScript (NodoJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Rubí
+
+
+

Perl
-
-
-

Scala
+
+
+

C objetivo
+
+
-

rápido
+
+
-

R
+
-
-

Go
+
+
+

Funcionalidad

Funcionalidad
Coeficiente intelectual del nexo
Comprobación de dependencia
Pista de dependencia

La capacidad de garantizar que se verifique la pureza de la licencia de los componentes utilizados en el código fuente
+
-
+

Capacidad para escanear y analizar vulnerabilidades y limpieza de licencias para imágenes de Docker
+ Integración con Clair
-
-

Capacidad para configurar la política de seguridad para usar bibliotecas de código abierto
+
-
-

Capacidad para escanear repositorios de código abierto en busca de componentes vulnerables
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
-
+ Hexadecimal, RubyGems, Maven, NPM, Nuget, Pypi

Disponibilidad de un equipo de investigación dedicado
+
-
-

Funcionamiento en circuito cerrado
+
+
+

Uso de bases de datos de terceros
+ Base de datos cerrada Sonatype
+ Sonatype OSS, asesores públicos de NPM
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, compatibilidad con base de datos de vulnerabilidad propia

Capacidad para filtrar componentes de código abierto al intentar cargarlos en el ciclo de desarrollo de acuerdo con las políticas configuradas
+
-
-

Recomendaciones para corregir vulnerabilidades, disponibilidad de enlaces a la solución
+
+- (depende de la descripción en las bases de datos públicas)
+- (depende de la descripción en las bases de datos públicas)

Ranking de vulnerabilidades descubiertas por criticidad
+
+
+

Modelo de acceso a roles
+
-
+

soporte CLI
+
+
+- (solo CycloneDX)

Selección/clasificación de vulnerabilidades según criterios definidos
+
-
+

Tablero por estado de la aplicación
+
-
+

Generación de informes en formato PDF
+
-
-

Generación de informes en formato JSONCSV
+
+
-

Soporte de idioma ruso
-
-
-

Oportunidades de integración

integración
Coeficiente intelectual del nexo
Comprobación de dependencia
Pista de dependencia

Integración con LDAP/Directorio Activo
+
-
+

integración de integración continua de bambú
+
-
-

Integración con el sistema de integración continua (integración continua) TeamCity
+
-
-

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

Integración con sistema de integración continua (integración continua) Jenkins
+
+
+

Disponibilidad de complementos IDE
+ IntelliJ, Eclipse, Visual Studio
-
-

Soporte para integración personalizada a través de servicios web (API) de la herramienta
+
-
+

Comprobación de dependencia

Первый запуск

Ejecute Dependency Check en una aplicación deliberadamente vulnerable DVJA.

Para esto usamos Complemento Maven de verificación de dependencia:

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

Como resultado, aparecerá Dependency-Check-Report.html en el directorio de destino.

Abramos el archivo. Después de un resumen del número total de vulnerabilidades, podemos ver información sobre vulnerabilidades con un alto nivel de Severidad y Confianza, indicando el paquete, CPE, número de CVE.

A continuación se incluye información más detallada, en particular, sobre la base de la cual se tomó la decisión (evidencia), es decir, una determinada lista de materiales.

Luego viene CPE, PURL y una descripción de CVE. Por cierto, las recomendaciones de reparación no se adjuntan debido a su ausencia en la base de datos de NVD.

Para ver sistemáticamente los resultados del análisis, puede configurar Nginx con una configuración mínima o enviar los defectos recibidos a un sistema de gestión de defectos que admita conectores de verificación de dependencia. Por ejemplo, Defecto Dojo.

Pista de dependencia

Instalación

Dependency Track, a su vez, es una plataforma basada en la web con gráficos de visualización, por lo que no hay un problema grave de almacenamiento de defectos en una solución de terceros.
Existen los siguientes escenarios admitidos para la instalación: Docker, WAR, WAR ejecutable.

Первый запуск

Vaya a la URL del servicio en ejecución. Ingresamos a través de admin / admin, cambiamos el nombre de usuario y la contraseña, luego de lo cual accedemos al Panel de control. Lo siguiente que haremos será crear un proyecto para una aplicación de prueba Java en Inicio/Proyectos → Crear proyecto . Tomemos DVJA como ejemplo.

Dado que Dependency Track solo puede tomar BOM como entrada, se debe recuperar esta BOM. usemos Complemento CycloneDX Maven:

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

Obtenemos bom.xml y cargamos el archivo en el proyecto creado DVJA → Dependencias → Subir BOM.

Vamos a Administración → Analizadores. Entendemos que solo tenemos habilitado el Internal Analyzer, que incluye NVD. Conectemos también Sonatype OSS Index.

Por lo tanto, obtenemos la siguiente imagen para nuestro proyecto:

También en la lista puede encontrar una vulnerabilidad aplicable a Sonatype OSS:

La principal decepción fue que Dependency Track ya no acepta informes xml de Dependency Check. Las últimas versiones admitidas de la integración de Dependency Check fueron 1.0.0 - 4.0.2 mientras probé 5.3.2.

aquí está видео (y aquí) cuando todavía era posible.

Coeficiente intelectual del nexo

Первый запуск

La instalación de Nexus IQ proviene de los archivos del software documentación, pero hemos compilado una imagen de Docker para este propósito.

Después de iniciar sesión en la consola, debe crear una Organización y una Aplicación.

Como puedes ver, la configuración en el caso de IQ es algo más complicada, porque también necesitamos crear políticas que sean aplicables a diferentes “etapas” (dev, build, stage, release). Esto es necesario para bloquear los componentes vulnerables a medida que se acercan a la tubería de producción, o bloquear tan pronto como ingresan al Nexus Repo cuando los desarrolladores los descargan.

Para sentir la diferencia entre el código abierto y la empresa, realicemos el mismo escaneo a través de Nexus IQ de la misma manera a través de Complemento de Maven, habiendo creado previamente una aplicación de prueba en la interfaz de 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 la URL del informe generado en la interfaz web de IQ:

Aquí puede ver todas las infracciones de la política con diferentes niveles de gravedad (desde Información hasta Crítico para la seguridad). La letra D al lado del componente significa que el componente es Dependencia Directa, y la letra T al lado del componente significa que el componente es Dependencia Transitiva, es decir, es transitivo.

Por cierto, el informe Informe sobre el estado de la seguridad de código abierto 2020 de Snyk informa que más del 70 % de las vulnerabilidades de código abierto encontradas en Node.js, Java y Ruby se encuentran en dependencias transitivas.

Si abrimos una de las infracciones de la política de Nexus IQ, podemos ver la descripción del componente, así como el Gráfico de versión, que muestra la ubicación de la versión actual en el gráfico de tiempo, así como en qué punto la vulnerabilidad deja de existir. ser vulnerable La altura de las velas en el gráfico muestra la popularidad del uso de este componente.

Si va a la sección de vulnerabilidades y abre el CVE, puede leer la descripción de esta vulnerabilidad, las recomendaciones para la remediación, así como la razón por la cual se violó este componente, es decir, la presencia de la clase. DiskFileitem.class.

Resumamos solo los componentes Java de terceros eliminando los componentes js. Entre paréntesis, indicamos el número de esas vulnerabilidades que se encontraron fuera de NVD.

CI total de Nexus:

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

Comprobación de dependencia total:

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

Pista de dependencia total:

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

El siguiente paso es analizar los resultados y averiguar cuál de estas vulnerabilidades es un defecto real y cuál es un falso positivo.

Descargo de responsabilidad

Esta revisión no es una verdad indiscutible. El autor no tenía el objetivo de destacar un instrumento separado en el contexto de otros. El propósito de la revisión fue mostrar cómo funcionan las herramientas SCA y cómo verificar sus resultados.

Comparación de resultados

Términos y condiciones:

Los falsos positivos para vulnerabilidades de componentes de terceros son:

• Falta de coincidencia de CVE con el componente identificado
• Por ejemplo, si se encuentra una vulnerabilidad en el marco struts2 y la herramienta apunta a un componente del marco struts-tiles que no se ve afectado por esta vulnerabilidad, se trata de un falso positivo.
• Discrepancia de CVE con la versión del componente detectado
• Por ejemplo, la vulnerabilidad está vinculada a la versión de Python > 3.5 y la herramienta marca la versión 2.7 como vulnerable; esto es un falso positivo, ya que, de hecho, la vulnerabilidad solo se aplica a la rama del producto 3.x.
• Duplicación de CVE
• Por ejemplo, si el SCA apunta a un CVE que permite implementar un RCE, entonces el SCA apunta al mismo CVE que se aplica a los productos de Cisco que están sujetos a ese RCE. En este caso, será falso positivo.
• Por ejemplo, se encontró un CVE en el componente spring-web, después de lo cual SCA apunta al mismo CVE en otros componentes de Spring Framework, mientras que el CVE no tiene nada que ver con otros componentes. En este caso, será falso positivo.

El objeto de investigación es el proyecto Open Source DVJA. El estudio involucró solo componentes java (sin js).

Resumen de resultados

Pasemos al resultado de una revisión manual de las vulnerabilidades identificadas. Un informe completo para cada CVE se puede encontrar en el Apéndice.

Resumen de resultados para todas las vulnerabilidades:

Parámetro
Coeficiente intelectual del nexo
Comprobación de dependencia
Pista de dependencia

Total de vulnerabilidades identificadas
42
91
51

Vulnerabilidades incorrectamente identificadas (falso positivo)
2 (4.76%)
62 (68,13%)
29 (56.86%)

No se encontraron vulnerabilidades relevantes (falso negativo)
10
20
27

Resumen de resultados por componentes:

Parámetro
Coeficiente intelectual del nexo
Comprobación de dependencia
Pista de dependencia

Componentes totales revelados
62
47
59

Componentes vulnerables totales
16
13
10

Los componentes vulnerables están identificados incorrectamente (falso positivo)
1
5
0

Los componentes vulnerables están identificados incorrectamente (falso positivo)
0
6
6

Construyamos gráficos visuales para estimar la proporción de falsos positivos y falsos negativos con respecto al número total de vulnerabilidades. Los componentes están marcados horizontalmente y las vulnerabilidades identificadas en ellos están marcadas verticalmente.

En comparación, el equipo de Sonatype realizó un estudio similar probando un proyecto de 1531 componentes utilizando OWASP Dependency Check. Como podemos ver, la relación entre el ruido y las respuestas correctas es consistente con nuestros resultados.

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

Echemos un vistazo a algunos de los CVE de nuestros resultados de escaneo para comprender el motivo de tales resultados.

Más

№ 1

Analicemos primero algunos puntos interesantes del Sonatype Nexus IQ.

Nexus IQ señala un problema de deserialización con la capacidad de RCE varias veces en Spring Framework. CVE-2016-1000027 en spring-web:3.0.5 por primera vez y CVE-2011-2894 en spring-context:3.0.5 y spring-core:3.0.5. Al principio, parece que hay una duplicación de la vulnerabilidad en varios CVE. Porque, si observa CVE-2016-1000027 y CVE-2011-2894 en la base de datos de NVD, parece que todo es obvio.

componente
Vulnerabilidad

primavera-web: 3.0.5
CVE-2016-1000027

primavera-contexto: 3.0.5
CVE-2011-2894

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

Descripción CVE-2011-2894 de nvd:


Descripción CVE-2016-1000027 de nvd:


CVE-2011-2894 es bastante conocido por sí mismo. en el informe Fuente blanca para 2011 este CVE ha sido reconocido como uno de los más comunes. Las descripciones de CVE-2016-100027 son, en principio, pocas en NVD y parece ser aplicable solo para Spring Framework 4.1.4. echemos un vistazo a referencia y aquí se vuelve más o menos claro. De Artículos sostenibles Entendemos que además de la vulnerabilidad en RemoteInvocationSerializingExporter en CVE-2011-2894, la vulnerabilidad se ve en HttpInvokerServiceExporter. Esto es lo que nos dice Nexus IQ:

Sin embargo, no hay nada como esto en NVD, por lo que Dependency Check y Dependency Track reciben falsos negativos.

También se puede entender a partir de la descripción de CVE-2011-2894 que la vulnerabilidad está presente tanto en spring-context:3.0.5 como en spring-core:3.0.5. La confirmación de esto se puede encontrar en el artículo del que encontró esta vulnerabilidad.

№ 2

componente
Vulnerabilidad
resultado

struts2-core: 2.3.30
CVE-2016-4003
FALSO

Si estudiamos la vulnerabilidad CVE-2016-4003 entenderemos que fue corregida en la versión 2.3.28, sin embargo Nexus IQ nos informa al respecto. Hay una nota en la descripción de la vulnerabilidad:

Es decir, la vulnerabilidad existe solo en conjunto con una versión desactualizada del JRE, sobre la cual decidieron advertirnos. Sin embargo, lo consideramos Falso Positivo, aunque no el más terrible.

№ 3

componente
Vulnerabilidad
resultado

xwork-núcleo: 2.3.30
CVE-2017-9804
VERDADERO

xwork-núcleo: 2.3.30
CVE-2017-7672
FALSO

Si nos fijamos en la descripción de CVE-2017-9804 y CVE-2017-7672, entenderemos que el problema está en URLValidator class, con CVE-2017-9804 derivado de CVE-2017-7672. La presencia de la segunda vulnerabilidad no conlleva ninguna carga útil, excepto que su gravedad ha aumentado a Alta, por lo que se puede considerar ruido innecesario.

En general, no se encontraron otros falsos positivos para el Nexus IQ.

№ 4

Hay algunas cosas que hacen que IQ se destaque de otras soluciones.

componente
Vulnerabilidad
resultado

primavera-web: 3.0.5
CVE-2020-5398
VERDADERO

El CVE en NVD dice que solo se aplica a las versiones 5.2.x a 5.2.3, 5.1.x a 5.1.13 y versiones 5.0.x a 5.0.16, sin embargo, si observamos la descripción de CVE en Nexus IQ, entonces veremos lo siguiente:
Aviso de desviación del aviso: el equipo de investigación de seguridad de Sonatype descubrió que esta vulnerabilidad se introdujo en la versión 3.0.2.RELEASE y no en la 5.0.x como se indica en el aviso.

A esto le sigue una PoC para esta vulnerabilidad, que establece que está presente en la versión 3.0.5.

Se envía un falso negativo a Dependency Check y Dependency Track.

№ 5

Veamos los falsos positivos de Dependency Check y Dependency Track.

Dependency Check se destaca en particular porque refleja los CVE que se aplican a todo el marco en NVD a aquellos componentes a los que no se aplican estos CVE. Esto aplica a CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, cuya Dependency Check “fijó ” a struts-taglib:1.3.8 y struts-tiles-1.3.8. Estos componentes no tienen nada que ver con lo que se describe en CVE: procesamiento de solicitudes, validación de páginas, etc. Esto se debe a que solo el marco es común entre estos CVE y los componentes, por lo que Dependency Check consideró esto como una vulnerabilidad.

Misma situación con spring-tx:3.0.5 y situación similar con struts-core:1.3.8. Para struts-core, Dependency Check y Dependency Track encontraron muchas vulnerabilidades que en realidad se aplican a struts2-core, que es esencialmente un marco separado. En este caso, Nexus IQ entendió correctamente la imagen y en los CVE que emitió, indicó que struts-core había llegado al final de su vida y era necesario cambiar a struts2-core.

№ 6

En algunas situaciones, tratar un error explícito de verificación de dependencia y seguimiento de dependencia es injusto. En particular CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225 que son Dependency Check y Dependency Track referido a spring-core:3.0.5 en realidad se refiere a spring-web:3.0.5. Al mismo tiempo, algunos de estos CVE fueron encontrados por Nexus IQ, sin embargo, IQ los identificó correctamente con otro componente. Por el hecho de que estas vulnerabilidades no se encontraron en Spring-Core, no se puede argumentar que, en principio, no están en el marco, y las herramientas de código abierto señalaron correctamente estas vulnerabilidades (solo se perdieron un poco).

Hallazgos

Como podemos ver, la determinación de la confiabilidad de las vulnerabilidades identificadas por revisión manual no arroja resultados inequívocos, lo que genera problemas controvertidos. Los resultados son que la solución Nexus IQ tiene la tasa de falsos positivos más baja y la precisión más alta.

En primer lugar, esto se debe a que el equipo de Sonatype amplió la descripción de cada vulnerabilidad CVE de NVD en sus bases de datos, indicando, hasta la clase o función de la vulnerabilidad para una versión particular del componente, habiendo realizado investigación (por ejemplo, comprobando vulnerabilidades en versiones de software anteriores).

Las vulnerabilidades que no se incluyeron en NVD, pero que sin embargo están presentes en la base de datos de Sonatype marcadas como SONATYPE, también tienen una influencia importante en los resultados. Según el informe El estado de las vulnerabilidades de seguridad de código abierto 2020 El 45% de las vulnerabilidades de código abierto descubiertas no se informan a NVD. Según la base de datos de WhiteSource, solo el 29% de todas las vulnerabilidades de código abierto archivadas fuera de NVD terminan siendo publicadas allí, por lo que es tan importante buscar vulnerabilidades en otros lugares también.

Como resultado, Dependency Check genera mucho ruido y pierde algunos de los componentes vulnerables. Dependency Track produce menos ruido y detecta una gran cantidad de componentes, lo que no daña visualmente los ojos en la interfaz web.

Sin embargo, la práctica muestra que es el código abierto el que debería convertirse en los primeros pasos hacia un DevSecOps maduro. Lo primero en lo que debe pensar para incorporar SCA en el desarrollo son los procesos, es decir, pensar con la gerencia y los departamentos relacionados sobre cómo deberían ser los procesos ideales en su organización. Puede resultar que para su organización, al principio, Dependency Check o Dependency Track cubrirán todas las necesidades comerciales, y las soluciones Enterprise serán una continuación lógica debido a la creciente complejidad de las aplicaciones que se están desarrollando.

Apéndice A. Resultados de los componentes
Leyenda:

• Alto: vulnerabilidades de nivel alto y crítico en el componente
• Medio: vulnerabilidades de gravedad media en el componente
• VERDADERO - Problema positivo verdadero
• FALSO - Problema de falso positivo

componente
Coeficiente intelectual del nexo
Comprobación de dependencia
Pista de dependencia
resultado

dom4j:1.6.1
Alta
Alta
Alta
VERDADERO

log4j-núcleo: 2.3
Alta
Alta
Alta
VERDADERO

log4j: 1.2.14
Alta
Alta
-
VERDADERO

commons-colecciones: 3.1
Alta
Alta
Alta
VERDADERO

carga de archivos comunes: 1.3.2
Alta
Alta
Alta
VERDADERO

commons-beanutils: 1.7.0
Alta
Alta
Alta
VERDADERO

códec común: 1:10
Medio
-
-
VERDADERO

mysql-conector-java:5.1.42
Alta
Alta
Alta
VERDADERO

primavera-expresión: 3.0.5
Alta
componente no encontrado

VERDADERO

primavera-web: 3.0.5
Alta
componente no encontrado
Alta
VERDADERO

primavera-contexto: 3.0.5
Medio
componente no encontrado
-
VERDADERO

resorte-núcleo: 3.0.5
Medio
Alta
Alta
VERDADERO

struts2-config-navegador-plugin:2.3.30
Medio
-
-
VERDADERO

primavera-tx: 3.0.5
-
Alta
-
FALSO

puntales-núcleo: 1.3.8
Alta
Alta
Alta
VERDADERO

xwork-núcleo: 2.3.30
Alta
-
-
VERDADERO

puntales2-núcleo: 2.3.30
Alta
Alta
Alta
VERDADERO

puntales-taglib: 1.3.8
-
Alta
-
FALSO

puntales-azulejos-1.3.8
-
Alta
-
FALSO

Apéndice B. Resultados de vulnerabilidad
Leyenda:

• Alto: vulnerabilidades de nivel alto y crítico en el componente
• Medio: vulnerabilidades de gravedad media en el componente
• VERDADERO - Problema positivo verdadero
• FALSO - Problema de falso positivo

componente
Coeficiente intelectual del nexo
Comprobación de dependencia
Pista de dependencia
Gravedad
resultado
comentario

dom4j:1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Alta
VERDADERO

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Alta
VERDADERO

log4j-núcleo: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Alta
VERDADERO

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Baja
VERDADERO

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
-
Alta
VERDADERO

-
CVE-2020-9488
-
Baja
VERDADERO

SONATYPE-2010-0053
-
-
Alta
VERDADERO

commons-colecciones: 3.1
-
CVE-2015-6420
CVE-2015-6420
Alta
FALSO
Duplica RCE(OSSINDEX)

-
CVE-2017-15708
CVE-2017-15708
Alta
FALSO
Duplica RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (ÍNDICE OS)
RCE(ÍNDICEOSS)
Alta
VERDADERO

carga de archivos comunes: 1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Alta
VERDADERO

SONATYPE-2014-0173
-
-
Medio
VERDADERO

commons-beanutils: 1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Alta
VERDADERO

-
CVE-2019-10086
CVE-2019-10086
Alta
FALSO
La vulnerabilidad es aplicable solo para las versiones 1.9.2+

códec común: 1:10
SONATYPE-2012-0050
-
-
Medio
VERDADERO

mysql-conector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Alta
VERDADERO

CVE-2019-2692
CVE-2019-2692
-
Medio
VERDADERO

-
CVE-2020-2875
-
Medio
FALSO
La misma vulnerabilidad que CVE-2019-2692, pero con la adición de que "los ataques pueden afectar significativamente a productos adicionales"

-
CVE-2017-15945
-
Alta
FALSO
No se aplica a mysql-conector-java

-
CVE-2020-2933
-
Baja
FALSO
Duplicar a CVE-2020-2934

CVE-2020-2934
CVE-2020-2934
-
Medio
VERDADERO

primavera-expresión: 3.0.5
CVE-2018-1270
componente no encontrado
-
Alta
VERDADERO

CVE-2018-1257
-
-
Medio
VERDADERO

primavera-web: 3.0.5
CVE-2016-1000027
componente no encontrado
-
Alta
VERDADERO

CVE-2014-0225
-
CVE-2014-0225
Alta
VERDADERO

CVE-2011-2730
-
-
Alta
VERDADERO

-
-
CVE-2013-4152
Medio
VERDADERO

CVE-2018-1272
-
-
Alta
VERDADERO

CVE-2020-5398
-
-
Alta
VERDADERO
Caso a favor de IQ: "El equipo de investigación de seguridad de Sonatype descubrió que esta vulnerabilidad se introdujo en la versión 3.0.2.RELEASE y no en la 5.0.x como se indica en el aviso".

CVE-2013-6429
-
-
Medio
VERDADERO

CVE-2014-0054
-
CVE-2014-0054
Medio
VERDADERO

CVE-2013-6430
-
-
Medio
VERDADERO

primavera-contexto: 3.0.5
CVE-2011-2894
componente no encontrado
-
Medio
VERDADERO

resorte-núcleo: 3.0.5
-
CVE-2011-2730
CVE-2011-2730
Alta
VERDADERO

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medio
VERDADERO

-
-
CVE-2013-4152
Medio
FALSO
Duplicado de la misma vulnerabilidad en spring-web

-
CVE-2013-4152
-
Medio
FALSO
La vulnerabilidad se relaciona con el componente spring-web.

-
CVE-2013-6429
CVE-2013-6429
Medio
FALSO
La vulnerabilidad se relaciona con el componente spring-web.

-
CVE-2013-6430
-
Medio
FALSO
La vulnerabilidad se relaciona con el componente spring-web.

-
CVE-2013-7315
CVE-2013-7315
Medio
FALSO
SPLIT desde CVE-2013-4152. + La vulnerabilidad se relaciona con el componente spring-web

-
CVE-2014-0054
CVE-2014-0054
Medio
FALSO
La vulnerabilidad se relaciona con el componente spring-web.

-
CVE-2014-0225
-
Alta
FALSO
La vulnerabilidad se relaciona con el componente spring-web.

-
-
CVE-2014-0225
Alta
FALSO
Duplicado de la misma vulnerabilidad en spring-web

-
CVE-2014-1904
CVE-2014-1904
Medio
FALSO
La vulnerabilidad se relaciona con el componente spring-web-mvc

-
CVE-2014-3625
CVE-2014-3625
Medio
FALSO
La vulnerabilidad se relaciona con el componente spring-web-mvc

-
CVE-2016-9878
CVE-2016-9878
Alta
FALSO
La vulnerabilidad se relaciona con el componente spring-web-mvc

-
CVE-2018-1270
CVE-2018-1270
Alta
FALSO
Para expresiones primaverales/mensajes primaverales

-
CVE-2018-1271
CVE-2018-1271
Medio
FALSO
La vulnerabilidad se relaciona con el componente spring-web-mvc

-
CVE-2018-1272
CVE-2018-1272
Alta
VERDADERO

CVE-2014-3578
CVE-2014-3578(ÍNDICEOSS)
CVE-2014-3578
Medio
VERDADERO

SONATYPE-2015-0327
-
-
Baja
VERDADERO

struts2-config-navegador-plugin:2.3.30
SONATYPE-2016-0104
-
-
Medio
VERDADERO

primavera-tx: 3.0.5
-
CVE-2011-2730
-
Alta
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2011-2894
-
Alta
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2013-4152
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2013-6429
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2013-6430
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2013-7315
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2014-0054
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2014-0225
-
Alta
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2014-1904
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2014-3625
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2016-9878
-
Alta
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2018-1270
-
Alta
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2018-1271
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

-
CVE-2018-1272
-
Medio
FALSO
La vulnerabilidad no se aplica a spring-tx

puntales-núcleo: 1.3.8
-
CVE-2011-5057(ÍNDICEOSS)

Medio
FASLE
Vulnerabilidad a Struts 2

-
CVE-2012-0391(ÍNDICEOSS)
CVE-2012-0391
Alta
FALSO
Vulnerabilidad a Struts 2

-
CVE-2014-0094(ÍNDICEOSS)
CVE-2014-0094
Medio
FALSO
Vulnerabilidad a Struts 2

-
CVE-2014-0113(ÍNDICEOSS)
CVE-2014-0113
Alta
FALSO
Vulnerabilidad a Struts 2

CVE-2016-1182
3VE-2016-1182
-
Alta
VERDADERO

-
-
CVE-2011-5057
Medio
FALSO
Vulnerabilidad a Struts 2

-
CVE-2012-0392(ÍNDICEOSS)
CVE-2012-0392
Alta
FALSO
Vulnerabilidad a Struts 2

-
CVE-2012-0393(ÍNDICEOSS)
CVE-2012-0393
Medio
FALSO
Vulnerabilidad a Struts 2

CVE-2015-0899
CVE-2015-0899
-
Alta
VERDADERO

-
CVE-2012-0394
CVE-2012-0394
Medio
FALSO
Vulnerabilidad a Struts 2

-
CVE-2012-0838(ÍNDICEOSS)
CVE-2012-0838
Alta
FALSO
Vulnerabilidad a Struts 2

-
CVE-2013-1965(ÍNDICEOSS)
CVE-2013-1965
Alta
FALSO
Vulnerabilidad a Struts 2

-
CVE-2013-1966(ÍNDICEOSS)
CVE-2013-1966
Alta
FASLE
Vulnerabilidad a Struts 2

-
CVE-2013-2115
CVE-2013-2115
Alta
FASLE
Vulnerabilidad a Struts 2

-
CVE-2013-2134(ÍNDICEOSS)
CVE-2013-2134
Alta
FASLE
Vulnerabilidad a Struts 2

-
CVE-2013-2135(ÍNDICEOSS)
CVE-2013-2135
Alta
FASLE
Vulnerabilidad a Struts 2

CVE-2014-0114
CVE-2014-0114
-
Alta
VERDADERO

-
CVE-2015-2992
CVE-2015-2992
Medio
FALSO
Vulnerabilidad a Struts 2

-
CVE-2016-0785(ÍNDICEOSS)
CVE-2016-0785
Alta
FALSO
Vulnerabilidad a Struts 2

CVE-2016-1181
CVE-2016-1181
-
Alta
VERDADERO

-
CVE-2016-4003(ÍNDICEOSS)
CVE-2016-4003
Alta
FALSO
Vulnerabilidad a Struts 2

xwork-núcleo: 2.3.30
CVE-2017-9804
-
-
Alta
VERDADERO

SONATYPE-2017-0173
-
-
Alta
VERDADERO

CVE-2017-7672
-
-
Alta
FALSO
Doble a CVE-2017-9804

SONATYPE-2016-0127
-
-
Alta
VERDADERO

struts2-core: 2.3.30
-
CVE-2016-6795
CVE-2016-6795
Alta
VERDADERO

-
CVE-2017-9787
CVE-2017-9787
Alta
VERDADERO

-
CVE-2017-9791
CVE-2017-9791
Alta
VERDADERO

-
CVE-2017-9793
-
Alta
FALSO
Duplicar a CVE-2018-1327

-
CVE-2017-9804
-
Alta
VERDADERO

-
CVE-2017-9805
CVE-2017-9805
Alta
VERDADERO

CVE-2016-4003
-
-
Medio
FALSO
Se aplica a Apache Struts 2.x hasta 2.3.28, que es la versión 2.3.30. Sin embargo, según la descripción, CVE funciona en todas las versiones de Struts 2, siempre que se use JRE 1.7 e inferior. Aparentemente decidieron reasegurarnos aquí, pero parece más FALSO

-
CVE-2018-1327
CVE-2018-1327
Alta
VERDADERO

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Alta
VERDADERO
La misma vulnerabilidad explotada por los atacantes en Equifax en 2017

CVE-2017-12611
CVE-2017-12611
-
Alta
VERDADERO

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Alta
VERDADERO

puntales-taglib: 1.3.8
-
CVE-2012-0394
-
Medio
FALSO
Para struts2-core

-
CVE-2013-2115
-
Alta
FALSO
Para struts2-core

-
CVE-2014-0114
-
Alta
FALSO
Para commons-beanutils

-
CVE-2015-0899
-
Alta
FALSO
No relacionado con taglib

-
CVE-2015-2992
-
Medio
FALSO
Relacionado con struts2-core

-
CVE-2016-1181
-
Alta
FALSO
No relacionado con taglib

-
CVE-2016-1182
-
Alta
FALSO
No relacionado con taglib

puntales-azulejos-1.3.8
-
CVE-2012-0394
-
Medio
FALSO
Para struts2-core

-
CVE-2013-2115
-
Alta
FALSO
Para struts2-core

-
CVE-2014-0114
-
Alta
FALSO
Bajo commons-beanutils

-
CVE-2015-0899
-
Alta
FALSO
No aplica para azulejos.

-
CVE-2015-2992
-
Medio
FALSO
Para struts2-core

-
CVE-2016-1181
-
Alta
FALSO
No relacionado con taglib

-
CVE-2016-1182
-
Alta
FALSO
No relacionado con taglib

Fuente: habr.com