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

La importancia del análisis de componentes de software de terceros (inglés: Software Composition Analysis — SCA) en el proceso de desarrollo está creciendo a medida que se publican informes anuales sobre vulnerabilidades de bibliotecas de código abierto, emitidos por empresas como Synopsys, Sonatype, Snyk y White Source. Según el informe El Estado de las Vulnerabilidades de Seguridad en Código Abierto 2020 el número de vulnerabilidades identificadas en código abierto en 2019 creció casi 1.5 veces en comparación con el año anterior, mientras que los componentes de código abierto son utilizados en entre el 60% y el 80% de los proyectos. Si consideramos opiniones independientes, los procesos de SCA son una práctica separada en OWASP SAMM y BSIMM como un indicador de madurez, y en la primera mitad de 2020 OWASP lanzó un nuevo estándar, el OWASP Software Component Verification Standard (SCVS), que proporciona las mejores prácticas para verificar componentes de terceros en la cadena de suministro de software.

Uno de los casos más representativos ocurrió con la empresa Equifax en mayo de 2017. Cibernéticos desconocidos obtuvieron información sobre 143 millones de estadounidenses, incluidos nombres completos, direcciones, números de seguro social y licencias de conducir. En 209,000 casos, también aparecieron datos sobre tarjetas bancarias de las víctimas. Esta filtración ocurrió como resultado de la explotación de una vulnerabilidad crítica en Apache Struts 2 (CVE-2017-5638), mientras que un arreglo se había lanzado en marzo de 2017. La empresa tuvo dos meses para instalar la actualización, pero nadie se preocupó por hacerlo.

En este artículo se discutirá la selección de herramientas para llevar a cabo SCA desde la perspectiva de la calidad de los resultados del análisis. También se realizará una comparación funcional de las herramientas. El proceso de integración en CI/CD y las capacidades de integración se dejarán para publicaciones posteriores. OWASP presentó una amplia lista de herramientas en su sitio web, pero en el marco de esta revisión solo abordaremos la herramienta de código abierto más popular, Dependency Check, la plataforma de código abierto menos conocida Dependency Track y la solución empresarial Sonatype Nexus IQ. También analizaremos cómo funcionan estas soluciones y compararemos los resultados obtenidos en términos de falsos positivos.

Principio de funcionamiento.

Dependency Check es una herramienta (CLI, maven, módulo jenkins, ant) que analiza los archivos del proyecto, recopila fragmentos de información sobre dependencias (nombre del paquete, groupid, título de 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 genera un informe único en formato HTML, JSON, XML…

Veamos cómo se ve un CPE:

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

Parte: Indicación de que el componente pertenece a una aplicación (a), sistema operativo (o), hardware (h) (Campo obligatorio)
Vendor: Nombre del fabricante del producto (Campo obligatorio)
Product: Nombre del producto (Campo obligatorio)
Versión: Versión del componente (Campo obsoleto)
Update: Actualización de paquete
Edition: Versión heredada (Campo obsoleto)
Language: Idioma definido en RFC-5646
SW Edition: Versión de software
Target SW: Entorno de software en el que funciona el producto
Target HW: Entorno de hardware en el que funciona el producto
Other: Información sobre el proveedor o producto

Un ejemplo de CPE se ve de la siguiente manera:

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

La cadena significa que el CPE versión 2.3 describe un componente de aplicación del fabricante pivotal_software con el nombre spring_framework versión 3.0.0. Si abrimos la vulnerabilidad CVE-2014-0225 en NVD, podemos ver una mención de este CPE. El primer problema que debe notarse de inmediato — el CVE en NVD, según CPE, informa sobre un problema en el marco, no en un componente específico. Es decir, si los desarrolladores están estrechamente acoplados al marco y la vulnerabilidad identificada no afecta a los módulos que utilizan los desarrolladores, el especialista en seguridad tendrá que analizar esta CVE y considerar una actualización.

La URL también es utilizada por las herramientas SCA. El formato de la URL del paquete es el siguiente:

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

Scheme: Siempre será 'pkg', indicando que es una URL de paquete (Campo obligatorio)
Type: ‘Tipo’ de paquete o ‘protocolo’ de paquete, como maven, npm, nuget, gem, pypi, etc. (Campo obligatorio)
Namespace: Algun prefijo del nombre, como el identificador de grupo de Maven, propietario de la imagen de Docker, usuario u organización de GitHub. Opcional y depende del tipo.
Nombre: Nombre del paquete (Campo obligatorio)
Versión: Versión del paquete
Qualifiers: Datos de calificación adicionales para el paquete, como SO, arquitectura, distribución, etc. Opcional y dependiente del tipo de elemento.
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/io@1.3.4
pkg:pypi/django-package@1.11.1.dev1

Dependency Track — plataforma web on-premise que acepta listas de materiales (BOM) compiladas CycloneDX y SPDX, es decir, especificaciones completas sobre las dependencias existentes. Es un archivo XML que describe las dependencias: nombre, hashes, URL del paquete, editor, licencia. Luego, Dependency Track analiza la BOM, verifica las vulnerabilidades identificadas de las dependencias contra la base de datos de vulnerabilidades (NVD, Sonatype OSS Index …), y genera gráficos, calcula métricas, actualizando regularmente los datos sobre el estado de la vulnerabilidad de los componentes.

Ejemplo de cómo puede verse una BOM en formato XML:

Apache
      org.apache.tomcat
      tomcat-catalina
      9.0.14
      
        3942447fac867ae5cdb3229b658f4d48
        e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a
        f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b
        e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282
      
      
        
          Apache-2.0
        
      
      pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14

La BOM no solo puede utilizarse como parámetros de entrada para Dependency Track, sino también para la gestión de inventarios de componentes de software en la cadena de suministro, por ejemplo, para proporcionar al cliente de software. En 2014, incluso se propuso en EE. UU. una ley «Cyber Supply Chain Management and Transparency Act of 2014», que estipulaba que al adquirir software, cualquier entidad gubernamental debía solicitar una BOM para prevenir el uso de componentes vulnerables, sin embargo, la ley nunca entró en vigor.

Volviendo a SCA, Dependency Track tiene integraciones listas con plataformas de notificación como Slack, y sistemas de gestión de vulnerabilidades como Kenna Security. También es importante mencionar que Dependency Track identifica versiones desactualizadas de paquetes y proporciona información sobre licencias (gracias al soporte de SPDX).

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

Dependency Track no acepta un proyecto como entrada, sino que toma un BOM. Esto significa que si queremos verificar el proyecto, primero debemos generar un bom.xml, por ejemplo, usando CycloneDX. Así, Dependency Track depende directamente de CycloneDX. Al mismo tiempo, esto permite la personalización. Así, el equipo de OZON escribió el módulo CycloneDX para construir archivos BOM para proyectos en Golang con el fin de escanearlos posteriormente a través de Dependency Track.

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

Resumamos algunas conclusiones sobre las características funcionales, así como sobre los lenguajes compatibles para el análisis:

Lenguaje
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Características funcionales

Características funcionales
Nexus IQ
Dependency Check
Dependency Track

Capacidad para verificar la limpieza de licencias de los componentes utilizados en el código fuente
+
—
+

Capacidad de escanear y analizar imágenes de Docker en busca de vulnerabilidades y limpieza de licencias
+ Integración con Clair
—
—

Capacidad para configurar políticas de seguridad para el uso de 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
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Existencia de un grupo de investigación especializado
+
—
—

Trabajo en un contorno cerrado
+
+
+

Uso de bases de datos externas
+ Base de datos privada de Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, soporte para base de datos de vulnerabilidades propia

Capacidad para filtrar componentes de código abierto al intentar cargar en el entorno de desarrollo según las políticas configuradas
+
—
—

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

Clasificación de vulnerabilidades encontradas según su criticidad
+
+
+

Modelo de rol de acceso
+
—
+

Soporte para la interfaz de línea de comandos CLI
+
+
+- (solo para CycloneDX)

Filtrado / ordenación de vulnerabilidades según criterios especificados
+
—
+

Tablero de estado de aplicaciones
+
—
+

Generación de informes en formato PDF
+
—
—

Generación de informes en formato JSONCSV
+
+
—

Soporte para el idioma ruso
—
—
—

Capacidades de integración

Integración
Nexus IQ
Dependency Check
Dependency Track

Integración con LDAP/Active Directory
+
—
+

Integración con el sistema de integración continua (continuous integration) Bamboo
+
—
—

Integración con el sistema de integración continua (continuous integration) TeamCity
+
—
—

Integración con el sistema de integración continua (continuous integration) GitLab
+
+- (como un plugin para GitLab)
+

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

Disponibilidad de plugins para IDE
+ IntelliJ, Eclipse, Visual Studio
—
—

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

Dependency Check

Primera ejecución

Ejecutaremos Dependency Check en una aplicación intencionadamente vulnerable DVJA.

Para ello utilizaremos Dependency Check Maven Plugin:

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

Como resultado, aparecerá dependency-check-report.html en el directorio target.

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

A continuación, se presenta información más detallada, en particular sobre la base de la cual se tomó la decisión (evidence), es decir, un BOM.

Luego se presentan CPE, PURL y la descripción de CVE. Las recomendaciones para su corrección, por cierto, no se incluyen debido a su ausencia en la base NVD.

Para revisar sistemáticamente los resultados del escaneo, se puede configurar Nginx con configuraciones mínimas, o enviar los defectos obtenidos a un sistema de gestión de defectos que soporte conectores para Dependency Check. Por ejemplo, Defect Dojo.

Dependency Track

Instalación

Dependency Track, a su vez, es una plataforma web con gráficos, por lo que la cuestión de almacenar defectos en una solución externa no se plantea aquí.
Para la instalación hay los siguientes escenarios soportados: Docker, WAR, Executable WAR.

Primera ejecución

Accedemos a la URL del servicio iniciado. Ingresamos con admin/admin, cambiamos el nombre de usuario y la contraseña, después de lo cual llegamos al Dashboard. Lo siguiente que haremos es crear un proyecto para una aplicación de prueba en Java en Home/Projects → Crear Proyecto . Tomaremos como ejemplo DVJA.

Dado que Dependency Track solo puede aceptar BOM como entrada, es necesario obtener este BOM. Utilizaremos CycloneDX Maven Plugin:

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

Obtenemos bom.xml y subimos el archivo en el proyecto creado DVJA → Dependencias → Cargar BOM.

Entramos en Administración → Analizadores. Entendemos que solo tenemos habilitado el Analizador Interno, que incluye NVD. También conectaremos Sonatype OSS Index.

Así, obtendremos la siguiente vista para nuestro proyecto:

También en la lista podemos 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 compatibles con la integración de Dependency Check fueron 1.0.0 a 4.0.2, mientras que yo probé la 5.3.2.

Aquí videos (y aquí), cuando esto aún era posible.

Nexus IQ

Primera ejecución

La instalación de Nexus IQ se realiza desde archivos comprimidos a través de la documentación, pero para estos fines hemos creado una imagen de Docker.

Después de ingresar a la consola, es necesario crear una Organización y una Aplicación.

Como se puede observar, la configuración en el caso de IQ es un poco más compleja, ya que también necesitamos crear políticas aplicables para diferentes "etapas" (dev, build, stage, release). Esto es necesario para bloquear componentes vulnerables a medida que avanzan por el pipeline hacia producción, o bloquearlos tan pronto como lleguen al Nexus Repo al ser descargados por los desarrolladores.

Para sentir la diferencia entre open source y enterprise, realizaremos un escaneo similar a través de Nexus IQ de manera análoga a Maven plugin, previamente creando 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= -Dclm.username= -Dclm.password=

Accedemos a la URL del informe generado en la interfaz web de IQ:

Aquí se pueden ver todas las violaciones de políticas con diferentes niveles de gravedad (de Info a Security Critical). La letra D junto al componente indica que es una Dependencia Directa, y la letra T junto al componente indica que es una Dependencia Transitiva.

Por cierto, el informe State of Open Source Security Report 2020 de Snyk informa que más del 70% de las vulnerabilidades de open source detectadas en Node.js, Java y Ruby se encuentran en dependencias transitivas.

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

Si vamos a la sección de vulnerabilidades y desplegamos el CVE, podremos leer la descripción de esta vulnerabilidad, las recomendaciones para su remediación, así como la razón por la que este componente ha sido señalado, es decir, la existencia de la clase DiskFileitem.class.

Resumamos solo lo que concierne a los componentes de terceros en Java, omitiendo componentes js. En paréntesis indicaremos el número de vulnerabilidades que se encontraron fuera de la NVD.

Total Nexus IQ:

Dependencias Escaneadas: 62
Dependencias Vulnerables: 16
Vulnerabilidades Encontradas: 42 (8 base de datos de sonatype)

Total Dependency Check:

Dependencias Escaneadas: 47
Dependencias Vulnerables: 13
Vulnerabilidades Encontradas: 91 (14 sonatype oss)

Total Dependency Track:

Dependencias Escaneadas: 59
Dependencias Vulnerables: 10
Vulnerabilidades Encontradas: 51 (1 sonatype oss)

El siguiente paso es analizar los resultados obtenidos y determinar qué vulnerabilidades son defectos reales y cuáles son falsos positivos.

Descargo de responsabilidad

Esta revisión no es una verdad incuestionable. El autor no tenía como objetivo destacar una herramienta sobre las demás. El propósito de la revisión fue mostrar los mecanismos de funcionamiento de las herramientas SCA y las formas de verificar sus resultados.

Comparación de resultados

Condiciones:

Un falso positivo en relación a vulnerabilidades de componentes de terceros es:

Inconsistencia del CVE con el componente identificado
Por ejemplo, si la vulnerabilidad se identifica en el framework struts2, y la herramienta señala un componente del framework struts-tiles, al que esta vulnerabilidad no se aplica, sería un falso positivo.
Inconsistencia del CVE con la versión identificada del componente
Por ejemplo, si la vulnerabilidad está ligada a la versión python > 3.5 y la herramienta marca como vulnerable la versión 2.7, esto sería un falso positivo, ya que la vulnerabilidad realmente solo se refiere a la rama del producto 3.x.
Duplicación de CVE
Por ejemplo, si el SCA señala un CVE que permite la ejecución remota de código (RCE), y luego el SCA indica para este mismo componente un CVE aplicable a productos de Cisco, que son susceptibles a esta RCE. En tal caso, sería un falso positivo.
Por ejemplo, se encontró una CVE en el componente spring-web, después de lo cual SCA indica la misma CVE en otros componentes del marco de trabajo Spring Framework, mientras que la CVE no tiene relación con otros componentes. En tal caso, sería un falso positivo.

El objeto de estudio elegido fue el proyecto de código abierto DVJA. En el estudio participaron solo componentes de Java (sin js).

Resultados generales

Pasemos directamente a los resultados de la revisión manual de las vulnerabilidades identificadas. El informe completo para cada CVE se puede consultar en el Apéndice.

Resultados generales sobre todas las vulnerabilidades:

Parámetro
Nexus IQ
Dependency Check
Dependency Track

Se han identificado un total de vulnerabilidades
42
91
51

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

No se encontraron vulnerabilidades relevantes (falsos negativos)
10
20
27

Resultados generales por componentes:

Parámetro
Nexus IQ
Dependency Check
Dependency Track

Total de componentes identificados
62
47
59

Total de componentes vulnerables
16
13
10

Componentes vulnerables identificados incorrectamente (falsos positivos)
1
5
0

Componentes vulnerables identificados incorrectamente (falsos positivos)
0
6
6

Construyamos gráficos visuales para evaluar la relación entre falsos positivos y falsos negativos respecto al total de vulnerabilidades. En el eje horizontal se indican los componentes, y en el eje vertical las vulnerabilidades identificadas en ellos.

Para comparar, un estudio similar fue realizado por el equipo de Sonatype probando un proyecto de 1531 componentes usando OWASP Dependency Check. Como podemos ver, la relación entre el ruido y las activaciones correctas es comparable con nuestros resultados.

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

Analicemos algunas CVE de los resultados de nuestro escaneo para entender la razón de tales resultados.

Más información

№1

Primero, analicemos algunos puntos interesantes de Sonatype Nexus IQ.

Nexus IQ señala un problema con la deserialización que puede permitir la ejecución remota de código (RCE) en Spring Framework varias veces. 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 duplicación de vulnerabilidad por varias CVE. Porque, si miramos CVE-2016-1000027 y CVE-2011-2894 en la base de datos NVD, parece que todo es obvio.

Componente
Vulnerabilidad

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Descripción CVE-2011-2894 de la NVD:

Descripción CVE-2016-1000027 de la NVD:

CVE-2011-2894 es bastante conocida por sí misma. En el informe de White Source de 2011 esta CVE fue reconocida como una de las más comunes. Las descripciones para CVE-2016-100027 son en general escasas en NVD, y parece que es aplicable solo a Spring Framework 4.1.4. Echemos un vistazo a reference y aquí se vuelve más o menos claro. De el artículo de Tenable entendemos que además de la vulnerabilidad en RemoteInvocationSerializingExporter en CVE-2011-2894, la vulnerabilidad también se observa en HttpInvokerServiceExporter. Esto es lo que nos dice Nexus IQ:

Sin embargo, no hay nada parecido en el NVD, lo que provoca que Dependency Check y Dependency Track generen falsos negativos.

También se puede deducir del CVE-2011-2894 que la vulnerabilidad está efectivamente presente en spring-context:3.0.5 y en spring-core:3.0.5. Se puede encontrar confirmación de esto en el artículo del descubridor de esta vulnerabilidad.

Nº2

Componente
Vulnerabilidad
Resultado

struts2-core:2.3.30
CVE-2016-4003
FALSO

Si examinamos la vulnerabilidad CVE-2016-4003, entendemos que fue corregida en la versión 2.3.28, sin embargo, Nexus IQ nos alerta sobre ella. En la descripción de la vulnerabilidad hay una nota:

Es decir, la vulnerabilidad solo existe en combinación con una versión obsoleta de JRE, lo cual se nos quiso advertir. Sin embargo, consideramos esto un falso positivo, aunque no el más grave.

Nº3

Componente
Vulnerabilidad
Resultado

xwork-core:2.3.30
CVE-2017-9804
VERDADERO

xwork-core:2.3.30
CVE-2017-7672
FALSO

Si observamos la descripción de CVE-2017-9804 y CVE-2017-7672, entenderemos que el problema radica en la clase URLValidator, y CVE-2017-9804 deriva de CVE-2017-7672. La existencia de la segunda vulnerabilidad no aporta ninguna utilidad adicional excepto que su severidad aumentó a Alta, por lo que se puede considerar un ruido innecesario.

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

Nº4

Hay varios aspectos que destacan a IQ frente a otras soluciones.

Componente
Vulnerabilidad
Resultado

spring-web:3.0.5
CVE-2020-5398
VERDADERO

El CVE en NVD indica que es aplicable solo a las versiones 5.2.x hasta 5.2.3, 5.1.x hasta 5.1.13 y versiones 5.0.x hasta 5.0.16, sin embargo, si miramos la descripción del CVE en Nexus IQ, veremos lo siguiente:
Aviso de desviación de asesoría: 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 5.0.x como se indica en la asesoría.

Después de esto, se presenta un PoC para esta vulnerabilidad, que indica que está presente en la versión 3.0.5.

El falso negativo se envía a Dependency Check y Dependency Track.

Nº5

Veamos los falsos positivos para Dependency Check y Dependency Track.

Dependency Check se distingue en particular porque refleja los CVE que se relacionan con todo el marco en NVD, en los componentes a los que estos CVE no son aplicables. Esto incluye CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, que Dependency Check "asoció" a struts-taglib:1.3.8 y struts-tiles-1.3.8. Estos componentes nada tienen que ver con lo que se describe en el CVE: el procesamiento de solicitudes, la validación de páginas, etc. Esto se debe a que lo único que los une a estos CVE y componentes es el marco, lo que llevó a Dependency Check a considerar esto como una vulnerabilidad.

La misma situación ocurre con spring-tx:3.0.5, y una situación similar con struts-core:1.3.8. Para struts-core, Dependency Check y Dependency Track encontraron muchas vulnerabilidades que en realidad son aplicables a struts2-core, que es en esencia un marco separado. En este caso, Nexus IQ entendió correctamente la situación y en los CVE que emitió, indicó que struts-core llegó al final de su vida útil y es necesario migrar a struts2-core.

Nº6

En algunas situaciones, interpretar un error evidente de Dependency Check y Dependency Track es injusto. En particular, los CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, que Dependency Check y Dependency Track asignaron a spring-core:3.0.5, en realidad pertenecen a spring-web:3.0.5. Al mismo tiempo, parte de estos CVE fueron encontrados por Nexus IQ, sin embargo, IQ los identificó correctamente para otro componente. El hecho de que estas vulnerabilidades no fueran encontradas en spring-core no significa que no existan en el marco en general y las herramientas de código abierto señalaron correctamente estas vulnerabilidades (simplemente se equivocaron un poco).

Conclusiones

Como podemos ver, determinar la veracidad de las vulnerabilidades identificadas mediante una revisión manual no proporciona resultados claros, lo que genera momentos de disputa. Los resultados son tales que la solución de Nexus IQ posee la menor tasa de falsos positivos y la mayor precisión.

En primer lugar, esto se debe a que el equipo de Sonatype amplió la descripción de cada vulnerabilidad CVE del NVD en sus bases, indicando con precisión hasta la clase o función de la vulnerabilidad para cada versión del componente, realizando investigaciones adicionales (por ejemplo, verificando vulnerabilidades en versiones más antiguas del software).

Un impacto significativo en los resultados también lo tienen las vulnerabilidades que no se incluyeron en el NVD, pero que sin embargo están presentes en la base de Sonatype con la etiqueta SONATYPE. Según el informe El Estado de las Vulnerabilidades de Seguridad en Código Abierto 2020 el 45% de las vulnerabilidades de código abierto detectadas no se reportan en el NVD. Según la base de datos de WhiteSource, solo el 29% de todas las vulnerabilidades de código abierto, registradas fuera del NVD, terminan publicándose en él, por lo que es tan importante buscar vulnerabilidades también en otras fuentes.

Como resultado, Dependency Check genera mucho ruido, omitiendo parte de los componentes vulnerables. Dependency Track produce menos ruido y detecta un gran número de componentes, lo que visualmente no resulta tan alarmante en la interfaz web.

Sin embargo, la práctica muestra que el código abierto debería ser el primer paso hacia un DevSecOps maduro. Lo primero en lo que se debe reflexionar para integrar SCA en el desarrollo son los procesos, es decir, pensar junto a la dirección y departamentos afines sobre cómo deberían ser los procesos ideales en la organización. Puede resultar que, para su organización, en un principio, Dependency Check o Dependency Track cubran todas las necesidades relevantes del negocio, mientras que las soluciones Enterprise serán una continuación lógica debido al aumento de la complejidad de las aplicaciones desarrolladas.

Apéndice A. Resultados relacionados con los componentes
Leyenda:

Alto — vulnerabilidades de alta y crítica gravedad en el componente
Medio — vulnerabilidades de gravedad media en el componente
VERDADERO — vulnerabilidad correctamente identificada (Problema positivo verdadero)
FALSO — falso positivo (Problema positivo falso)

Componente
Nexus IQ
Dependency Check
Dependency Track
Resultado

dom4j: 1.6.1
Alto
Alto
Alto
VERDADERO

log4j-core: 2.3
Alto
Alto
Alto
VERDADERO

log4j: 1.2.14
Alto
Alto
—
VERDADERO

commons-collections:3.1
Alto
Alto
Alto
VERDADERO

commons-fileupload:1.3.2
Alto
Alto
Alto
VERDADERO

commons-beanutils:1.7.0
Alto
Alto
Alto
VERDADERO

commons-codec:1:10
Medio
—
—
VERDADERO

mysql-connector-java:5.1.42
Alto
Alto
Alto
VERDADERO

spring-expression:3.0.5
Alto
componente no encontrado

VERDADERO

spring-web:3.0.5
Alto
componente no encontrado
Alto
VERDADERO

spring-context:3.0.5
Medio
componente no encontrado
—
VERDADERO

spring-core:3.0.5
Medio
Alto
Alto
VERDADERO

struts2-config-browser-plugin:2.3.30
Medio
—
—
VERDADERO

spring-tx:3.0.5
—
Alto
—
FALSO

struts-core:1.3.8
Alto
Alto
Alto
VERDADERO

xwork-core: 2.3.30
Alto
—
—
VERDADERO

struts2-core: 2.3.30
Alto
Alto
Alto
VERDADERO

struts-taglib:1.3.8
—
Alto
—
FALSO

struts-tiles-1.3.8
—
Alto
—
FALSO

Apéndice B. Resultados relacionados con las vulnerabilidades
Leyenda:

Alto — vulnerabilidades de alta y crítica gravedad en el componente
Medio — vulnerabilidades de gravedad media en el componente
VERDADERO — vulnerabilidad correctamente identificada (Problema positivo verdadero)
FALSO — falso positivo (Problema positivo falso)

Componente
Nexus IQ
Dependency Check
Dependency Track
Gravedad
Resultado
Comentario

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

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Alto
VERDADERO

log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Alto
VERDADERO

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Bajo
VERDADERO

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Alto
VERDADERO

—
CVE-2020-9488
—
Bajo
VERDADERO

SONATYPE-2010-0053
—
—
Alto
VERDADERO

commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Alto
FALSO
Duplica RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Alto
FALSO
Duplica RCE(OSSINDEX)

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

commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Alto
VERDADERO

SONATYPE-2014-0173
—
—
Medio
VERDADERO

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

—
CVE-2019-10086
CVE-2019-10086
Alto
FALSO
La vulnerabilidad solo es aplicable a versiones 1.9.2+

commons-codec:1:10
SONATYPE-2012-0050
—
—
Medio
VERDADERO

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

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

—
CVE-2020-2875
—
Medio
FALSO
La misma vulnerabilidad que CVE-2019-2692, pero con el apéndice 'los ataques pueden impactar significativamente a productos adicionales'

—
CVE-2017-15945
—
Alto
FALSO
No aplica a mysql-connector-java

—
CVE-2020-2933
—
Bajo
FALSO
Duplicado de CVE-2020-2934

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

spring-expression:3.0.5
CVE-2018-1270
componente no encontrado
—
Alto
VERDADERO

CVE-2018-1257
—
—
Medio
VERDADERO

spring-web:3.0.5
CVE-2016-1000027
componente no encontrado
—
Alto
VERDADERO

CVE-2014-0225
—
CVE-2014-0225
Alto
VERDADERO

CVE-2011-2730
—
—
Alto
VERDADERO

—
—
CVE-2013-4152
Medio
VERDADERO

CVE-2018-1272
—
—
Alto
VERDADERO

CVE-2020-5398
—
—
Alto
VERDADERO
Ejemplo notable a favor de IQ: 'El equipo de investigación de seguridad de Sonatype descubrió que esta vulnerabilidad fue introducida en la versión 3.0.2.RELEASE y no en 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

spring-context:3.0.5
CVE-2011-2894
componente no encontrado
—
Medio
VERDADERO

spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Alto
VERDADERO

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

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

—
CVE-2013-4152
—
Medio
FALSO
La vulnerabilidad se refiere al componente spring-web

—
CVE-2013-6429
CVE-2013-6429
Medio
FALSO
La vulnerabilidad se refiere al componente spring-web

—
CVE-2013-6430
—
Medio
FALSO
La vulnerabilidad se refiere al componente spring-web

—
CVE-2013-7315
CVE-2013-7315
Medio
FALSO
SPLIT de CVE-2013-4152. + La vulnerabilidad se refiere al componente spring-web

—
CVE-2014-0054
CVE-2014-0054
Medio
FALSO
La vulnerabilidad se refiere al componente spring-web

—
CVE-2014-0225
—
Alto
FALSO
La vulnerabilidad se refiere al componente spring-web

—
—
CVE-2014-0225
Alto
FALSO
Duplicado de esta misma vulnerabilidad en spring-web

—
CVE-2014-1904
CVE-2014-1904
Medio
FALSO
La vulnerabilidad se refiere al componente spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Medio
FALSO
La vulnerabilidad se refiere al componente spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Alto
FALSO
La vulnerabilidad se refiere al componente spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
Alto
FALSO
Para spring-expression / spring-messages

—
CVE-2018-1271
CVE-2018-1271
Medio
FALSO
La vulnerabilidad se refiere al componente spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Alto
VERDADERO

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Medio
VERDADERO

SONATYPE-2015-0327
—
—
Bajo
VERDADERO

struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
—
—
Medio
VERDADERO

spring-tx:3.0.5
—
CVE-2011-2730
—
Alto
FALSO
La vulnerabilidad no se refiere a spring-tx

—
CVE-2011-2894
—
Alto
FALSO
La vulnerabilidad no se refiere a spring-tx

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

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

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

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

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

—
CVE-2014-0225
—
Alto
FALSO
La vulnerabilidad no se refiere a spring-tx

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

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

—
CVE-2016-9878
—
Alto
FALSO
La vulnerabilidad no se refiere a spring-tx

—
CVE-2018-1270
—
Alto
FALSO
La vulnerabilidad no se refiere a spring-tx

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

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

struts-core:1.3.8
—
CVE-2011-5057 (OSSINDEX)

Medio
FALSO
Vulnerabilidad en Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Alto
FALSO
Vulnerabilidad en Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medio
FALSO
Vulnerabilidad en Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Alto
FALSO
Vulnerabilidad en Struts 2

CVE-2016-1182
3VE-2016-1182
—
Alto
VERDADERO

—
—
CVE-2011-5057
Medio
FALSO
Vulnerabilidad en Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Alto
FALSO
Vulnerabilidad en Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medio
FALSO
Vulnerabilidad en Struts 2

CVE-2015-0899
CVE-2015-0899
—
Alto
VERDADERO

—
CVE-2012-0394
CVE-2012-0394
Medio
FALSO
Vulnerabilidad en Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Alto
FALSO
Vulnerabilidad en Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Alto
FALSO
Vulnerabilidad en Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Alto
FALSO
Vulnerabilidad en Struts 2

—
CVE-2013-2115
CVE-2013-2115
Alto
FALSO
Vulnerabilidad en Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Alto
FALSO
Vulnerabilidad en Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Alto
FALSO
Vulnerabilidad en Struts 2

CVE-2014-0114
CVE-2014-0114
—
Alto
VERDADERO

—
CVE-2015-2992
CVE-2015-2992
Medio
FALSO
Vulnerabilidad en Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Alto
FALSO
Vulnerabilidad en Struts 2

CVE-2016-1181
CVE-2016-1181
—
Alto
VERDADERO

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Alto
FALSO
Vulnerabilidad en Struts 2

xwork-core:2.3.30
CVE-2017-9804
—
—
Alto
VERDADERO

SONATYPE-2017-0173
—
—
Alto
VERDADERO

CVE-2017-7672
—
—
Alto
FALSO
Duplicado de CVE-2017-9804

SONATYPE-2016-0127
—
—
Alto
VERDADERO

struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Alto
VERDADERO

—
CVE-2017-9787
CVE-2017-9787
Alto
VERDADERO

—
CVE-2017-9791
CVE-2017-9791
Alto
VERDADERO

—
CVE-2017-9793
—
Alto
FALSO
Duplicado de CVE-2018-1327

—
CVE-2017-9804
—
Alto
VERDADERO

—
CVE-2017-9805
CVE-2017-9805
Alto
VERDADERO

CVE-2016-4003
—
—
Medio
FALSO
Aplicable a Apache Struts 2.x hasta 2.3.28, pero esta es la versión 2.3.30. Sin embargo, a partir de la descripción, el CVE se aplica a cualquier versión de Struts 2 si se utiliza JRE 1.7 o anterior. Parece que aquí decidieron ser cautelosos, pero parece más un FALSE.

—
CVE-2018-1327
CVE-2018-1327
Alto
VERDADERO

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Alto
VERDADERO
La vulnerabilidad que aprovecharon los atacantes en Equifax en 2017.

CVE-2017-12611
CVE-2017-12611
—
Alto
VERDADERO

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Alto
VERDADERO

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

—
CVE-2013-2115
—
Alto
FALSO
Para struts2-core

—
CVE-2014-0114
—
Alto
FALSO
Para commons-beanutils

—
CVE-2015-0899
—
Alto
FALSO
No aplicable a taglib

—
CVE-2015-2992
—
Medio
FALSO
Aplicable a struts2-core

—
CVE-2016-1181
—
Alto
FALSO
No aplicable a taglib

—
CVE-2016-1182
—
Alto
FALSO
No aplicable a taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Medio
FALSO
Para struts2-core