¿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, comprobando si hay actualizaciones o problemas de licencia y, a continuación, elaborando un informe. 

Aunque el análisis de la composición del software puede analizar todo tipo de elementos de software, incluyendo componentes propietarios e imágenes de contenedor, se utiliza más comúnmente para analizar bibliotecas de código abierto. Los componentes de código abierto se incluyen en cierta medida en casi todas las bases de código modernas 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 las vulnerabilidades de seguridad de los componentes de software de origen desconocido, los problemas de compatibilidad entre distintas licencias de código abierto y la documentación o el soporte incompletos o insuficientes de las bibliotecas de código abierto.  

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

El SCA difiere de otras formas de exploración de vulnerabilidades, como las pruebas estáticas de seguridad de aplicaciones (SAST), las pruebas dinámicas de seguridad de aplicaciones (DAST) y la exploración de dependencias.

Los equipos de TI suelen utilizar herramientas de 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 en 2024, lo que pone de relieve la necesidad generalizada de soluciones SCA.¹

El SCA recopila el código fuente, lo compara con las bases de datos de vulnerabilidades, analiza la base de código en busca de posibles problemas de cumplimiento, elimina los 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 del entorno informático, incluidos sus componentes, marcos, bibliotecas, imágenes de contenedor, módulos y dependencias. Las dos formas principales de escaneo SCA son: 

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

• Escaneo dinámico o en tiempo de ejecución, que identifica las bibliotecas tal como se ejecutan en tiempo real escaneando el código binario. 

Ambos tipos de escaneos tienen beneficios y desventajas. Un análisis estático puede incluir vulnerabilidades de componentes de terceros en el código fuente que no están realmente implementados en el tiempo de ejecución, lo que genera falsos positivos. Por otro lado, es posible que un escaneo dinámico nunca sea completamente exhaustivo, ya que no todos los elementos del código se ejecutan en el entorno de 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 señaladas las posibles vulnerabilidades, la herramienta SCA asignará una puntuación de amenaza a cada una (a menudo utilizando el Sistema de Puntuación de Vulnerabilidades Comunes 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 monitorizar este proceso para garantizar que los cambios aplicados no afecten a las dependencias o funcionalidades existentes.

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

La Iniciativa de código abierto enumera más de 100 licencias de código abierto aprobadas, algunas de las cuales permiten crear productos patentados a partir de código abierto. Sin embargo, no todos son compatibles, lo que significa que las organizaciones son responsables de garantizar que sus productos cumplan con la normativa.

Las soluciones de SCA pueden comprobar que todo el software de código abierto lleva 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 las dependencias entre los componentes del proyecto, una fuente importante de vulnerabilidades potenciales.

Las herramientas de 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 se produce cuando una pieza de software pasa a depender indirectamente 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 "alcanzable", 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 composición de software se recopilan en un informe y a menudo se presentan en un panel de control, datos sin procesar como un archivo JSON, una nueva SBOM o alguna 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 las vulnerabilidades detectadas son alcanzables.

• El machine learning y la inteligencia artificial han contribuido a la identificación de falsos positivos. Con el entrenamiento adecuado, los modelos pueden identificar con precisión si una vulnerabilidad es accesible o no. El procesamiento del lenguaje natural también se utiliza para analizar los mensajes de confirmación de control de versiones de repositorios como GitHub, con el fin de detectar posibles problemas que no se pueden identificar en el código. 

Algunas herramientas de SCA incluyen características de monitorización continua y corrección, que integran aún más la práctica en el flujo de trabajo de desarrollo de DevSecOps. La corrección automática suele realizarse iniciando solicitudes de extracción que notifican a los desarrolladores que solucionen problemas de licencias o apliquen nuevos parches de seguridad.

Los beneficios del SCA incluyen una mayor confianza en las posiciones 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 del ecosistema informático se utilizan de acuerdo con sus requisitos de licencia y conformidad, el SCA puede ayudar a las organizaciones a reducir el riesgo legal.

Identificar las vulnerabilidades de la red creadas por la imprevisibilidad de los componentes de software de código abierto es una parte crucial de la gestión de riesgos informáticos. Al hacer que la cadena de suministro de software de código abierto sea más transparente, las organizaciones pueden disfrutar de los beneficios de la personalización y la disminución de costes, sin dejar de confiar en que han reducido 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 retos que plantea el análisis de la composición del software incluyen la falta de exhaustividad en el seguimiento de las vulnerabilidades, la limitación de los 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 SCA proporciona a los equipos de TI un mapa completo de componentes de software, dependencias y vulnerabilidades, DAST y SAST se centran y revelan los defectos individuales de esos componentes y las aplicaciones de software más grandes que constituyen.

La diferencia entre DAST y SAST es similar a la diferencia entre el escaneado 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 estáticas de seguridad de aplicaciones (SAST) profundizan en el código fuente de una aplicación, buscando vulnerabilidades en el código a medida que se escribe.  

Mientras que el SCA se centra en enumerar y analizar los componentes de un determinado software, el DAST y el 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 el SCA, pero también se pueden practicar de forma independiente. 

SCA difiere de la
correlación 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 las dependencias en todo el entorno de TI.

El mapeo de dependencias puede centrarse en dependencias dentro y entre aplicaciones, pero también puede ir más a fondo, buscando dependencias en infraestructuras de red o sistemas reales completos, como una red eléctrica inteligente. El mapeo de dependencias suele ser un componente de las prácticas SCA, pero puede ejecutarse por sí solo, independientemente de las soluciones SCA.