Qué es el análisis de composición del software

[10/12/2021] El análisis de composición del software (SCA, por sus siglas en inglés) se refiere a obtener información sobre qué componentes y dependencias de código abierto se utilizan en su aplicación y cómo se utilizan, todo de forma automatizada. Este proceso tiene el propósito de evaluar la seguridad de estos componentes y cualquier riesgo potencial o conflicto de licencia que surja de ellos. La incorporación correcta de herramientas de SCA en su flujo de trabajo de desarrollo de software es un paso importante hacia el fortalecimiento de la seguridad y la integridad de la cadena de abastecimiento de software al garantizar que cualquier código prestado no presente riesgos de seguridad o problemas de cumplimiento legal en sus productos.

Por qué es necesario el análisis de composición del software

Los días en que las aplicaciones de software se creaban desde cero quedaron atrás. La adopción desenfrenada de software de código abierto ha revolucionado el desarrollo de las aplicaciones. Los desarrolladores independientes y las empresas pueden utilizar los componentes y las bibliotecas existentes en su código para implementar funcionalidades, desde simples validaciones de formularios web hasta complejas operaciones criptográficas.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Si bien la reutilización del código de fuente abierto ha eliminado en gran medida la necesidad de reinventar la rueda, tiene algunas advertencias: ¿qué pasa si el código que está tomando prestado tiene errores o vulnerabilidades de seguridad? Además, ¿qué pasa si los términos de la licencia del componente de código abierto entran en conflicto con la licencia de su aplicación? ¿Quién va a revisar todo esto?

Revisar una docena de componentes podría ser una tarea sencilla de realizar manualmente, pero las aplicaciones de software modernas se crean utilizando cientos de bibliotecas. Estas bibliotecas pueden tener otras dependencias. Este proceso puede ejecutar muchas capas de profundidad y, antes de que se dé cuenta, su aplicación, que de otra manera parece contener solo un puñado de bibliotecas, puede estar generando cientos o miles de dependencias transitivas. Aquí es donde el SCA llega al rescate.

Análisis de composición del software y SBOM

La mayoría de las herramientas de SCA pueden generar una lista de materiales de software (SBOM, por sus siglas en inglés). Una SBOM es una cuenta detallada de inventario: todas las dependencias y componentes que conforman su aplicación. Una SBOM ideal proporciona el nombre del componente, el número de versión, la fecha de lanzamiento, la suma de comprobación, la información de la licencia, entre otros metadatos, para cada componente presente en su aplicación.

Esto se puede hacer de dos formas:

1. Escaneo del manifiesto: La herramienta de SCA escanea los archivos del manifiesto de compilación de su aplicación, como package.json, para JavaScript o pom.xml para proyectos Apache Maven (Java) y genera una lista de dependencias allí. Este enfoque funciona cuando los desarrolladores escanean aplicaciones sin los artefactos de compilación final contenidos dentro o desde un sistema de control de versiones (por ejemplo, GitHub, GitLab o SVN).
2. Escaneo binario: La herramienta de SCA escanea sus artefactos de construcción e identifica los componentes de código abierto a través de huellas digitales binarias. Este proceso identifica todos los paquetes incluidos en la compilación final de su aplicación, lo que reduce los falsos positivos y detecta el software y las bibliotecas de terceros agregados a su aplicación de una manera no estandarizada. No todas las herramientas de SCA tienen capacidades de escaneo binario.
3. Escaneo de manifiestos y binarios: Algunas soluciones de SCA pueden optar por un enfoque híbrido: escaneo de manifiestos y binarios para llegar a una SBOM de alta precisión. Por lo tanto, la sofisticación de su solución de SCA determina con qué precisión puede identificar todos los componentes que acechan en su aplicación.

Normalmente, las SBOM se proporcionan como archivos de texto en XML, JSON o formatos similares, que los hacen legibles para humanos y máquinas. A continuación, se muestra un ejemplo de una SBOM para la aplicación Keycloak, versión 10.0.2. El documento XML se basa en el estándar OWASP CycloneDX y enumera los componentes que componen Keycloak, incluidas sus sumas de comprobación, número de versión, fecha de lanzamiento e información de licencia. Cabe resaltar que una sola versión de Keycloak contiene más de 900 componentes, según la SBOM:

El formato SPDX de la Fundación Linux, aunque todavía está basado en texto, difiere del estándar CycloneDX. A continuación, se muestra un ejemplo.

¿Cómo ayudan las herramientas de SCA a encontrar vulnerabilidades de código abierto?

Las herramientas de SCA automatizadas pueden ayudar a los equipos de software a crear y enviar código de alta calidad, y empoderar a las partes interesadas con un enfoque proactivo para la gestión de riesgos. Al identificar las vulnerabilidades y los riesgos de seguridad en las primeras etapas del proceso de desarrollo de software, las herramientas de SCA pueden permitir a los desarrolladores de software seleccionar componentes más seguros, sin problemas, por adelantado. Esta ventaja acelera el proceso de desarrollo al minimizar la necesidad de evaluaciones de seguridad repetidas, ya que, desde el principio, se toma el cuidado suficiente al incluir bibliotecas y componentes de terceros en una aplicación.

Si un componente con riesgos y vulnerabilidades conocidos es absolutamente necesario, los equipos de desarrollo pueden tomar una decisión cuando el componente se presenta por primera vez, y contemplar la adopción de posibles soluciones para usar el componente de forma segura.

El objetivo del proceso y las herramientas de SCA no termina simplemente escaneando las fuentes y binarios de su aplicación para producir una SBOM. El desafío clave radica en mapear con precisión cada versión del componente a las vulnerabilidades conocidas. Además, viene el aspecto de cumplimiento: permitir que las partes interesadas revisen y resuelvan sin problemas cualquier conflicto de licencia que planteen los componentes.

Hace unos años, el proceso pudo haber sido sencillo. Basta con revisar las fuentes CVE proporcionadas por MITRE o NVD y asignarlas a las versiones de los componentes presentes en su aplicación. Las investigaciones que incluyen un artículo producido por la Universidad de Florida Central, George Mason y Georgia Tech han demostrado que los avisos de CVE a menudo pueden ser inexactos y contener inconsistencias. Otras veces, los datos de CVE pueden malinterpretarse debido a cómo los datos de Common Platform Enumeration (CPE) se presentan en estos avisos.

Por ejemplo, un aviso de CVE emitido por vulnerabilidad en el servidor Tomcat puede aplicarse solo a un componente seleccionado en el espacio de nombres de Apache Tomcat, como org.apache.tomcat: coyote en lugar de todo el espacio de nombres de Apache Tomcat, pero esto puede no quedar claro únicamente partiendo de los CPE mencionados en el aviso.

Por lo tanto, las herramientas de SCA deben ser lo suficientemente inteligentes como para asignar con precisión las vulnerabilidades de seguridad a los componentes afectados, en lugar de confiar ciegamente en los avisos de CVE y marcar los componentes benignos. Para minimizar la fricción para los desarrolladores y dar paz a los equipos de evaluación de seguridad y cumplimiento, las soluciones de SCA deben minimizar la aparición de falsos positivos en las vulnerabilidades de sus resultados, pero sin correr el riesgo de introducir falsos negativos (es decir, no detectar riesgos de seguridad). Esto puede justificar la intervención humana y la investigación de seguridad y herramientas de escaneo de archivos basadas en firmas.

Además, depender únicamente de las fuentes CVE para la inteligencia de seguridad no es suficiente. Los avisos de vulnerabilidad pueden aparecer en las páginas web de los proveedores de productos, GitHub, y en muchos otros lugares, incluidas las bases de datos privadas. Del mismo modo, los exploits de prueba de concepto para los días cero o las vulnerabilidades conocidas pueden aparecer en Exploit-DB, foros de hackers y otros lugares misteriosos. No todas las herramientas de SCA son iguales y deben tener la capacidad suficiente para obtener inteligencia de una gran cantidad de fuentes y dar sentido a miles de estas entradas.

Amenazas más recientes de la cadena de abastecimiento: malware, bibliotecas secuestradas, confusión de dependencias

Al seleccionar las herramientas de SCA para su organización, otro desafío que surge es mantenerse al día con los ataques novedosos, no solo con los riesgos y vulnerabilidades de seguridad conocidos.

Como si adelantarse a los días cero ya no fuera un problema, ahora estamos viendo una mayor incidencia de ataques de typosquatting y malware de confusión de dependencias que se infiltra en registros de código abierto como npm, PyPI y RubyGems, y estos siguen evolucionando.

Como investigador senior de seguridad, he analizado cientos de muestras de malware y dependencias paquetes de confusión que se infiltran en el ecosistema de código abierto. Octubre del 2021 marcó la primera vez que vimos código de ransomware funcional incluido en un typosquat inteligentemente llamado: noblox.js-proxies. El paquete legítimo se llama noblox.js-proxied y es un espejo del paquete oficial Noblox.js, un envoltorio de API de juegos de Roblox.

El mismo mes, los actores de amenazas también secuestraron bibliotecas npm enormemente populares, ua-parser-js, coa y rc para instalar criptomineros y ladrones de contraseñas. La biblioteca UA Parser se descarga más de siete millones de veces a la semana y es utilizada por Facebook, Microsoft, Amazon, Google, entre otras empresas de tecnología, lo que demuestra el impacto potencial que podría haber resultado de un secuestro como este. Asimismo, coa tiene alrededor de nueve millones de descargas semanales y rc alrededor de 14 millones.

Sin embargo, en lugar de un ataque de apropiación indebida o de secuestro de dependencia, este incidente de la cadena de abastecimiento involucró a actores de amenazas que comprometieron la cuenta npm de los mantenedores principales detrás de estos proyectos. JetBrains reveló el impacto potencial a los desarrolladores de Kotlin/JS, que habían ejecutado casos de prueba de Karma durante la ventana de compromiso, ya que ua-parser-js era una de las dependencias para el marco de prueba de Karma.

Todo esto da lugar a la pregunta: ¿Son sus herramientas de SCA capaces de detectar inyecciones de malware, typosquats maliciosos, secuestros de dependencias y bibliotecas comprometidas antes de que se distribuyan en sentido descendente?

Identificar los miles de componentes que componen su aplicación es, en sí mismo, una tarea abrumadora para una herramienta automatizada, y mucho más para un equipo de desarrolladores humanos. Luego viene la tarea de examinar las fuentes de seguridad que enumeran miles de vulnerabilidades que pueden aplicarse o no a su aplicación. Por último, el panorama de amenazas en constante evolución ha complicado aún más los asuntos para la seguridad e integridad de la cadena de abastecimiento de software. La integración de una solución de SCA completa, rápida y precisa en su flujo de trabajo de desarrollo de software se ha vuelto indispensable, pero obtener una que aborde la mayoría, si no todas, las nuevas amenazas mencionadas anteriormente siguen siendo un desafío.

Basado en el artículo de Axe Sharma (CSO) y editado por CIO Perú