DevSecOps: Principios y comparación de SCA. Parte uno

La importancia del análisis de componentes de software de terceros (Software Composition Analysis - SCA) en el proceso de desarrollo está creciendo a medida que se publican los informes anuales sobre vulnerabilidades de bibliotecas de código abierto, que son publicados por Synopsys, Sonatype, Snyk, White Source. Según el estado de las vulnerabilidades de seguridad de código abierto 2020El número de vulnerabilidades de código abierto identificadas 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 del 60% al 80% de los proyectos. Si recurre a una opinión independiente, los procesos de SCA son una práctica separada de OWASP SAMM y BSIMM como indicador de madurez, y en el primer semestre de 2020 OWASP lanzó el nuevo Estándar de verificación de componentes de software (SCVS) de OWASP, que proporciona las mejores prácticas para verificar componentes de terceros en la cadena de suministro POR.







Uno de los casos más reveladores ocurrió con Equifax en mayo de 2017. Atacantes desconocidos confiscaron información sobre 143 millones de estadounidenses, incluidos nombres completos, direcciones, números de seguro social y licencias de conducir. En 209.000 casos, los documentos también incluían información sobre las tarjetas bancarias de las víctimas. Esta filtración se debió a la explotación de una vulnerabilidad crítica en Apache Struts 2 (CVE-2017-5638), mientras que la corrección se lanzó en marzo de 2017. La compañía tuvo dos meses para instalar la actualización, pero nadie se molestó por eso.



Este artículo discutirá el tema de elegir una herramienta para realizar SCA en términos de la calidad de los resultados del análisis. También habrá una comparación funcional de las herramientas. El proceso de inserción en CI / CD y las posibilidades de integración se dejarán para futuras publicaciones. OWASP presentó una amplia lista de herramientas en su sitio web , pero como parte de la revisión actual, solo tocaremos la herramienta de código abierto más popular Dependency Check, la plataforma de código abierto un poco menos conocida Dependency Track y la solución Sonatype Nexus IQ Enterprise. También averiguaremos cómo funcionan estas soluciones y compararemos los resultados obtenidos para los falsos positivos.

Principio de funcionamiento

Dependency Check es una utilidad (CLI, maven, módulo jenkins, ant) ​​que analiza los archivos del proyecto, recopila información sobre las dependencias (nombre del paquete, groupid, título de la especificación, versión ...), crea una línea CPE - (Common Platform Enumeration), Package URL (PURL) y detecta vulnerabilidades para CPE / PURL de bases de datos (NVD, Sonatype OSS Index, NPM Audit API ...), y luego crea un informe único en formato HTML, JSON, XML ...



Veamos 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) (elemento obligatorio)
• Proveedor: Nombre del fabricante del producto (obligatorio)
• Producto: Nombre del producto (artículo obligatorio)
• Versión: versión del componente (artículo obsoleto)
• Actualización: actualiza el paquete
• Edición: versión heredada (obsoleta)
• Idioma: el idioma definido en RFC-5646
• Edición SW: versión de software
• SW de destino: el entorno de software en el que se ejecuta el producto
• HW de destino: el entorno de hardware en el que se ejecuta el producto
• Otro: información del proveedor o del producto

Un ejemplo de CPE se ve así:

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

La línea significa que CPE versión 2.3 describe un componente de la aplicación del fabricante pivotal_software con el nombre de la spring_frameworkversió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 es que el CVE en NVD, según el CPE, informa que hay un problema en el framework, 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 utilizan los desarrolladores, el especialista en seguridad de alguna manera tendrá que desmontar este CVE y pensar en actualizar.



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

• Tema: Siempre habrá 'pkg' indicando que esta es la URL del paquete (Requerido)
• Tipo: el "tipo" del paquete o el "protocolo" del paquete, como maven, npm, nuget, gem, pypi, etc. (Cláusula obligatoria)
• Espacio de nombres: algún prefijo de nombre, como el ID de grupo de Maven, el propietario de la imagen de Docker, el usuario de GitHub u organización. Opcional y depende del tipo.
• Nombre: nombre del paquete (obligatorio)
• Versión: versión del paquete
• Calificadores: calificaciones adicionales para el paquete, como sistema operativo, 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/io@1.3.4
pkg:pypi/django-package@1.11.1.dev1

Dependency Track es una plataforma web local que acepta listas de materiales (BOM) listas para usar generadas por CycloneDX y SPDX , es decir, especificaciones listas para usar sobre las dependencias existentes. 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, examina los CVE disponibles para las dependencias identificadas de la base de datos de vulnerabilidades (NVD, Sonatype OSS Index ...), luego crea gráficos, calcula métricas y actualiza periódicamente los datos de estado de vulnerabilidad de los componentes.



Un ejemplo de cómo podría verse 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/tomcat-catalina@9.0.14</purl>
    </component>
      <!-- More components here -->
  </components>
</bom>

La lista de materiales se puede utilizar no solo como parámetros de entrada para la ruta de dependencia, sino también para inventariar componentes de software en la cadena de suministro, por ejemplo, para proporcionar software al cliente. En 2014, la Ley de Transparencia y Gestión de la Cadena de Suministro Cibernético de 2014 incluso se propuso para su consideración en los Estados Unidos , que establecía que al comprar software, cualquier estado. la institución debe solicitar un BOM para evitar la explotación de componentes vulnerables, pero la ley nunca entró en vigencia.



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 debe decirse que Dependency Track, entre otras cosas, detecta versiones desactualizadas de paquetes y proporciona información sobre licencias (debido al soporte para SPDX).



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



La vía de dependencia no acepta el proyecto como entrada, sino la lista de materiales. Esto significa que si queremos verificar el proyecto, primero necesitamos generar bom.xml, por ejemplo, usando CycloneDX. Por lo tanto, Dependency Track depende directamente de CycloneDX. Al mismo tiempo, permite la personalización. Entonces, el equipo de OZON escribió el módulo CycloneDX para crear archivos BOM para proyectos de Golang para un mayor análisis a través de Dependency Track.



Nexus IQEs una solución SCA comercial de Sonatype, que forma parte del ecosistema Sonatype, que también incluye Nexus Repository Manager. Nexus IQ puede aceptar como datos de entrada tanto archivos de guerra (para proyectos java) a través de la interfaz web o API, como BOM, si su organización no ha logrado reconstruir desde CycloneDX a una nueva solución. A diferencia de las soluciones de código abierto, IQ no solo se refiere al CPE / PURL para el 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 de 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 lenguajes admitidos para el análisis:





Funcionalidad





Oportunidades de integración

Verificación de dependencia

Primer comienzo

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



Para hacer esto, usaremos el complemento Dependency Check Maven :

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

Como resultado, dependecy-check-report.html aparecerá en el directorio de destino.







Abramos el archivo. Luego de la información resumida sobre la cantidad total de vulnerabilidades, podemos ver información sobre vulnerabilidades con un alto nivel de Severidad y Confianza, indicando el paquete, CPE, número CVE.



A esto le sigue información más detallada, en particular en qué se basa la evidencia, es decir, una determinada lista de materiales.







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







Para revisar sistemáticamente los resultados del análisis, puede configurar Nginx con una configuración mínima o enviar los defectos resultantes a un sistema de gestión de defectos que admita los conectores Dependency Check. Por ejemplo, Defect Dojo.

Pista de dependencia

Instalación

Dependency Track, a su vez, es una plataforma web con gráficos de visualización, por lo que no existe un problema grave de almacenamiento de defectos en una solución de terceros.

Existen los siguientes scripts compatibles para la instalación: Docker, WAR, ejecutable WAR.

Primer comienzo

Vaya a la URL del servicio en ejecución. Ingresamos por admin / admin, cambiamos el nombre de usuario y la contraseña, y luego llegamos al Tablero. Lo siguiente que haremos es crear un proyecto para la aplicación de prueba Java en Inicio / Proyectos → Crear proyecto . Tomemos DVJA como ejemplo.







Dado que la ruta de dependencia solo puede aceptar una lista de materiales como entrada, esta lista de materiales debe recuperarse. Let uso de la CycloneDX Maven Plugin :

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

Obtenga bom.xml y cargue el archivo en el proyecto DVJA creado → Dependencias → Cargar BOM .



Vayamos a Administración → Analizadores. Entendemos que solo tenemos el Analizador interno habilitado, incluido NVD. También conectaremos Sonatype OSS Index.







Por lo tanto, obtendremos 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 que probé la 5.3.2.



Aquí hay un video (y ahora ) cuando aún era posible.

Nexus IQ

Primer comienzo

El Nexus IQ se instala desde los archivos de 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 puede ver, la configuración en el caso de IQ es un poco más complicada, porque también necesitamos crear políticas aplicables a diferentes "etapas" (desarrollo, compilación, etapa, lanzamiento). Esto es necesario para bloquear componentes vulnerables a medida que se mueven a lo largo de la tubería más cerca del producto, o para 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 del Nexus IQ de la misma manera a través del complemento Maven , habiendo creado previamente una aplicación de prueba en la interfaz 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 políticas con diferentes niveles de importancia (desde Información hasta Seguridad crítica). 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 sobre el estado de 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 están 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 la línea de tiempo, así como en qué punto la vulnerabilidad ya no es vulnerable. La altura de las velas en el gráfico muestra la popularidad de este componente.







Si va a la sección de vulnerabilidades y divulga el CVE, puede leer una descripción de esta vulnerabilidad, recomendaciones para su eliminación, así como el motivo por el cual se violó este componente, es decir, la presencia de una 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 del NVD.



IQ 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)

En los siguientes pasos, analizaremos los resultados y descubriremos 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 innegable. El autor no tenía el objetivo de hacer que un instrumento separado se destacara de los demás. El objetivo de la revisión era mostrar cómo funcionan las herramientas SCA y cómo verificar sus resultados.

Comparación de resultados

Condiciones: un



falso positivo de vulnerabilidades en componentes de terceros es:

• Desajuste de CVE para el componente identificado
• , struts2, struts-tiles, , false positive
• CVE
• , python > 3.5 2.7 — false positive, 3.x
• CVE
• , SCA CVE, RCE, SCA CVE, Cisco, RCE. false positive.
• Por ejemplo, CVE se encontró en un componente spring-web, después de lo cual SCA apunta al mismo CVE en otros componentes de Spring Framework, mientras que CVE no tiene nada que ver con otros componentes. En este caso, será un falso positivo.

El proyecto de código abierto DVJA fue elegido como objeto de investigación. La investigación involucró solo componentes java (no js).

Resumen de resultados

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



Resumen de resultados para todas las vulnerabilidades:



Resumen de resultados por componente:



Construyamos gráficos visuales para evaluar 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 llevó a cabo un estudio similar para probar un proyecto de 1531 componentes utilizando OWASP Dependency Check. Como podemos ver, la relación entre el ruido y los disparadores correctos es comparable a nuestros resultados.





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



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

Más detalles

# 1

Primero echemos un vistazo a algunos puntos interesantes del Sonatype Nexus IQ.



Nexus IQ apunta a un problema de deserialización con la capacidad de ejecutar 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 una duplicación de la vulnerabilidad en varios CVE. Porque si miras CVE-2016-1000027 y CVE-2011-2894 en la base de datos NVD, entonces parece que todo es obvio





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





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





CVE-2011-2894 en sí es bastante famoso. El informe de White Source de 2011 clasificó este CVE como uno de los más frecuentes. Las descripciones para CVE-2016-100027 son, en principio, un poco en NVD, y parece ser aplicable solo para Spring Framework 4.1.4. Eche un vistazo a la referencia y aquí se vuelve más o menos claro. Entendemos por el artículo de Tenable que además de la vulnerabilidad RemoteInvocationSerializingExporteren CVE-2011-2894, la vulnerabilidad se observa 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 un falso negativo.



Además, a partir de la descripción de CVE-2011-2894, puede comprender que la vulnerabilidad está realmente presente en spring-context: 3.0.5 y spring-core: 3.0.5. La confirmación de esto se puede encontrar en un artículo de la persona que encontró esta vulnerabilidad.

# 2

Si estudiamos la vulnerabilidad CVE-2016-4003 entenderemos que se corrigió 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, consideramos que esto es un falso positivo, aunque no el peor.

Numero 3

Si miramos las descripciones de CVE-2017-9804 y CVE-2017-7672, entenderemos que el problema es URLValidator class, y CVE-2017-9804 se deriva 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 puede considerarse ruido innecesario.



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

# 4

Hay varias cosas que distinguen al CI de otras decisiones.





El CVE en NVD dice que solo es aplicable para las versiones 5.2.xa 5.2.3, 5.1.xa 5.1.13 y versiones 5.0.xa 5.0.16, sin embargo, si miramos la descripción de CVE en el Nexus IQ, 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 informa que está presente en la versión 3.0.5.



Se envía un falso negativo a Comprobación de dependencia y Seguimiento de dependencia.

# 5

Veamos el falso positivo para la verificación de dependencia y el seguimiento de dependencia.



Dependency Check se destaca porque refleja aquellos CVE que se aplican a todo el marco en NVD en aquellos componentes a los que esos CVE no son aplicables. Esto se aplica a CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, cuya verificación de dependencia "atornilló" 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 al hecho de que lo común entre estos CVE y los componentes es solo el marco, por lo que Dependency Check lo consideró una vulnerabilidad.



La misma situación 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 han encontrado muchas vulnerabilidades que son realmente aplicables a struts2-core, que es esencialmente un marco separado. En este caso, Nexus IQ entendió correctamente la imagen y en esos CVE que emitió, indicó que struts-core llegó al final de su vida útil y era necesario pasar a struts2-core.

# 6

En algunas situaciones, es injusto interpretar un error explícito de Comprobación de dependencia y Seguimiento 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 son Comprobación de dependencia y Seguimiento de dependencia referido a spring-core: 3.0.5 en realidad se refiere a spring-web: 3.0.5. Al mismo tiempo, se encontraron algunos de estos CVE y el Nexus IQ, sin embargo, el IQ los identificó correctamente para otro componente. Dado que estas vulnerabilidades no se encontraron en spring-core, no se puede argumentar que no están en el marco, en principio, y las herramientas de código abierto señalaron correctamente estas vulnerabilidades (solo fallaron un poco).

conclusiones

Como podemos ver, la determinación de la confiabilidad de las vulnerabilidades identificadas mediante revisión manual no da resultados inequívocos, lo que conduce a cuestiones controvertidas. Los resultados son tales que la solución Nexus IQ tiene la tasa de falsos positivos más baja y la mayor precisión.



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



Una influencia importante en los resultados la juegan aquellas vulnerabilidades que no estaban incluidas en NVD, pero que sin embargo están presentes en la base de datos Sonatype con la marca SONATYPE. Según el estado de las vulnerabilidades de seguridad de código abierto 2020El 45% de las vulnerabilidades de código abierto descubiertas no se informa a NVD. Según la base de datos WhiteSource, solo el 29% de todas las vulnerabilidades de código abierto informadas fuera de NVD terminan siendo publicadas allí, por lo que es importante buscar vulnerabilidades en otros lugares también.



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



Sin embargo, la práctica muestra que el código abierto debería ser el primer paso en el camino hacia DevSecOps maduro. Lo primero en lo que hay que pensar para integrar SCA en el desarrollo son los procesos, es decir, pensar junto con la dirección y los departamentos relacionados sobre cómo deberían verse los procesos ideales en su organización. Puede resultar que para su organización al principio, Dependency Check o Dependency Track cubra todas las necesidades comerciales, y las soluciones empresariales serán una continuación lógica debido a la creciente complejidad de las aplicaciones desarrolladas.