¿Qué es el análisis de composición de software (SCA)?

Las herramientas SCA funcionan escaneando el código fuente del software, recopilándolo en una base de datos, comparándolo con bases de datos de vulnerabilidades conocidas, buscando actualizaciones o problemas de licencia y luego produciendo un informe. 

Aunque el análisis de la composición del software puede examinar todo tipo de elementos de software, incluidos los componentes propietarios y las imágenes de contenedores, se utiliza con mayor frecuencia para analizar bibliotecas de código abierto. Casi todos los códigos fuente modernos incluyen, en mayor o menor medida, componentes de código abierto, y dado que las vulnerabilidades de su código son de dominio público, es especialmente importante mantener el software de código abierto actualizado y transparente.

Las herramientas SCA gestionan los riesgos de vulnerabilidades de seguridad de componentes de software de origen desconocido, problemas de compatibilidad entre diferentes licencias de código abierto y documentación o soporte incompletos o insuficientes para bibliotecas de código abierto.  

El análisis de composición de software es parte de la canalización  DevOps nativa de la nube que integra el proceso de desarrollo de software con las operaciones de TI. SCA también apoya la postura de seguridad de una organización como parte de la pipeline DevSecOps, que integra la seguridad con el desarrollo y las operaciones. Las herramientas SCA se pueden desplegar en un entorno de desarrollo integrado (IDE), proporcionando análisis de código en tiempo real durante el proceso de desarrollo.

El SCA se diferencia de otras formas de análisis de vulnerabilidades, como las pruebas estáticas de seguridad de aplicaciones (SAST), las pruebas dinámicas de seguridad de aplicaciones (DAST) y el análisis de dependencias.

Los equipos de TI suelen utilizar herramientas SCA para generar una lista de materiales de software (SBOM). La SBOM enumera todos los componentes, bibliotecas y módulos de un producto de software en un formato legible por máquina para el cumplimiento y la seguridad de la cadena de suministro. Las SBOM también pueden informar aún más las políticas de escaneo de SCA.

Según los datos de la encuesta de International Data Corporation, el 93 por ciento de las empresas con al menos 100 empleados utilizaban software de código abierto a partir de 2024, lo que pone de relieve la necesidad generalizada de soluciones SCA. 1

La SCA recopila el código fuente, lo compara con bases de datos de vulnerabilidades, analiza la base de código en busca de posibles problemas de cumplimiento, elimina falsos positivos y crea un informe para los equipos de ciberseguridad y desarrollo. 

Las herramientas SCA escanean y analizan activamente el código durante el desarrollo como parte del pipeline de integración continua y entrega continua (CI/CD) a lo largo del ciclo de vida del desarrollo, centrándose principalmente en los componentes de código abierto y las dependencias de terceros.

Para ello, las herramientas SCA enumeran primero los elementos básicos de todo el software en el entorno de TI, incluidos sus componentes, marcos, bibliotecas, imágenes de contenedores, módulos y dependencias. Las dos formas principales de escaneo SCA son: 

• Escaneo estático o manifiesto, que lee los archivos de configuración y metadatos para encontrar los elementos descritos explícitamente en ellos.

• Escaneo dinámico o en tiempo de ejecución, que identifica las bibliotecas a medida que se ejecutan en tiempo real mediante el escaneo del código binario. 

Ambos tipos de escaneos tienen beneficios e inconvenientes. Un análisis estático puede incluir vulnerabilidades de componentes de terceros en el código fuente que no se implementan realmente en el entorno de ejecución, lo que crea falsos positivos. Un escaneo dinámico, en cambio, puede que nunca sea completamente exhaustivo, ya que todos los elementos del código no se ejecutan en el tiempo de ejecución. Muchas organizaciones utilizan una combinación de ambos.

Una vez que una herramienta SCA ha terminado de recopilar el código, crea una lista de materiales de software (SBOM) y compara los componentes de la SBOM con bases de datos que describen vulnerabilidades comunes y riesgos de seguridad de software modernos.

Los equipos de seguridad comparan el SBOM tanto con bases de datos propietarias de vulnerabilidades conocidas como con otras públicas como la National Vulnerability Database (NVD) o la lista de Vulnerabilidades y Exposiciones Comunes (CVEs). Una vez que se marcan las vulnerabilidades potenciales, la herramienta SCA asignará a cada una una puntuación de amenaza (a menudo utilizando el Common Vulnerability Scoring System o CVSS) que permite al equipo de ciberseguridad priorizar la corrección.

Algunas herramientas de seguridad automatizan la gestión de vulnerabilidades aplicando el parche o la actualización adecuados como parte del pipeline de CI/CD. Los equipos de seguridad suelen monitorear este proceso para garantizar que los cambios aplicados no afecten las dependencias o la funcionalidad existentes.

Las herramientas de SCA también verifican la SBOM con las políticas y leyes de la empresa sobre licencias de software para garantizar el cumplimiento.

La Open Source Initiative recoge más de 100 licencias de código abierto aprobadas, algunas de las cuales permiten crear productos propietarios a partir de código abierto. Sin embargo, no todos son compatibles, lo que significa que las organizaciones son responsables de asegurarse de que sus productos cumplan con las normas.

Las soluciones de SCA pueden verificar que todo el software de código abierto tenga la atribución requerida, o que los elementos sujetos a "copyleft", que prohíbe su uso en software propietario y protegido por derechos de autor, no estén incluidos en el desarrollo de ese software. 

El análisis de la composición del software también puede detectar dependencias entre los componentes del proyecto, una de las principales fuentes de posibles vulnerabilidades.

Las herramientas SCA pueden detectar tanto dependencias directas, donde los componentes de software se utilizan directamente entre sí a nivel de código, como dependencias transitivas. Una dependencia transitiva ocurre cuando una pieza de software se vuelve indirectamente dependiente de un componente de software del que depende una de sus dependencias directas. Por ejemplo: el componente A depende del componente B, que depende del componente C. En este escenario, el componente A depende transitivamente del componente C.

Las herramientas de SCA deben determinar qué dependencias introducen vulnerabilidades y cuáles no, para reducir el número de alertas falsas. Para ello, evalúan la cadena de suministro de software y determinan si una vulnerabilidad en el código es "accesible", es decir, si se invocará en un entorno de tiempo de ejecución dada la configuración actual de la red. 

Los resultados del análisis de la composición del software se recopilan en un informe y suelen presentarse en un panel de control propio, en forma de datos sin procesar (como un archivo JSON), en una nueva SBOM o en una combinación de los tres.

En los últimos años, los desarrolladores han avanzado en la reducción de falsos positivos en estos informes.

• El análisis de métodos vulnerables rastrea las rutas de llamada de los componentes de software para garantizar que se pueda acceder a las vulnerabilidades detectadas.

• Machine learning y la inteligencia artificial han contribuido a la identificación de falsos positivos. Con el entrenamiento adecuado, los modelos pueden determinar con precisión si se puede acceder a una vulnerabilidad o no. El procesamiento de lenguaje natural también se utiliza para analizar los mensajes de commit de control de versiones de repositorios como GitHub para detectar posibles problemas no identificables en el código. 

Algunas herramientas de SCA incluyen características de supervisión continua y corrección automática, lo que permite integrar aún más esta práctica en el flujo de trabajo de desarrollo de DevSecOps. La corrección automática suele realizarse iniciando pull requests que notifican a los desarrolladores que apliquen arreglos de licencias o apliquen nuevos parches de seguridad.

Los beneficios de la SCA incluyen una mayor confianza en las posturas de cumplimiento y ciberseguridad de una organización, así como una mayor automatización de los flujos de trabajo de TI.

Al ayudar a garantizar que todos los componentes de código abierto en el ecosistema de TI se utilicen de acuerdo con sus requisitos de licencia y cumplimiento, la SCA puede ayudar a las organizaciones a reducir el riesgo legal.

Identificar las vulnerabilidades de la red derivadas de la imprevisibilidad de los componentes de software de código abierto es una parte fundamental de la gestión de riesgos de TI. Al aumentar la transparencia de la cadena de suministro del software de código abierto, las organizaciones pueden disfrutar de las ventajas de la personalización y la reducción de costos, al tiempo que tienen la seguridad de haber minimizado los riesgos de seguridad asociados.

Al automatizar grandes partes del seguimiento de vulnerabilidades, dependencias y cumplimiento, las soluciones SCA liberan a los equipos de TI para realizar otras tareas. Esta amplia automatización también ayuda a reforzar las prácticas de DevOps de una organización.

Algunos de los desafíos que plantea el análisis de composición de software incluyen la falta de exhaustividad en el seguimiento de vulnerabilidades, la limitación de falsos positivos y la gestión del alcance del análisis.

El análisis de composición de software es diferente de DAST y SAST, dos métodos de prueba adicionales utilizados para identificar vulnerabilidades de seguridad en aplicaciones modernas. 

Mientras que el SCA proporciona a los equipos de TI un mapa completo de los componentes de software, sus dependencias y vulnerabilidades, el DAST y el SAST se centran en detectar y revelar los fallos individuales de dichos componentes y de las aplicaciones de software más amplias que estos conforman.

La diferencia entre DAST y SAST es similar a la diferencia entre el análisis estático y el dinámico en SCA. Las pruebas dinámicas de seguridad de aplicaciones (DAST) evalúan las aplicaciones en sus entornos de producción, imitando a los usuarios maliciosos y los ciberataques para ayudar a identificar problemas de seguridad. Las pruebas de seguridad de aplicaciones estáticas (SAST) profundizan en el código fuente de una aplicación, buscando vulnerabilidades en el código a medida que se escribe.  

Mientras que SCA se centra en enumerar y analizar los componentes de un software determinado, DAST y SAST se centran específicamente en probar ese software en busca de vulnerabilidades de seguridad, ya sea en tiempo de ejecución en el caso del primero o en el código fuente en el caso del segundo. Ambos se utilizan a menudo junto con SCA, pero también se pueden practicar de forma independiente. 

La SCA difiere del mapeo de dependencias, el proceso de identificar, comprender y visualizar las relaciones entre aplicaciones, sistemas y procesos dentro de las operaciones de TI de una organización.

Las herramientas SCA proporcionan una visión general de las dependencias de los componentes e identifican las posibles vulnerabilidades que podrían surgir de ellos, pero el mapeo de dependencias se refiere a una categoría más amplia de prácticas de observabilidad que identifican dependencias en todo el entorno de TI.

El mapeo de dependencias puede centrarse en las dependencias dentro y entre aplicaciones, pero también puede ir más allá, buscando dependencias en la infraestructura de red o en sistemas completos del mundo real, como una red eléctrica inteligente. El mapeo de dependencias suele ser un componente de las prácticas de SCA, pero se puede ejecutar por sí solo, independientemente de las soluciones de SCA.