Skip to main content

Software Composition Analysis

Piensa en el desarrollo de software hoy en día como construir algo con bloques de LEGO. En vez de fabricar cada pequeño bloque desde cero, usas bloques listos (componentes de código abierto, bibliotecas, frameworks) para montar tu aplicación mucho más rápido.

El SCA es, esencialmente, la herramienta que analiza todos esos bloques de LEGO que has usado para garantizar que no tengan defectos peligrosos.

Análisis de Composición de Software (SCA) es un proceso automatizado que identifica los componentes de software de código abierto (open source) en una base de código. El objetivo principal es evaluar estos componentes para encontrar vulnerabilidades de seguridad, problemas de conformidad de licencia y analizar la calidad general del código que estás "importando" a tu proyecto.

Se estima que entre el 80% y 90% del código en aplicaciones modernas es de código abierto. Al importar bibliotecas de código abierto, las vulnerabilidades contenidas en ellas pasan a ser tuyas también.

  • Vulnerabilidades Heredadas: Si usas una biblioteca vulnerable, tu aplicación se vuelve vulnerable. El ejemplo más famoso y reciente fue la vulnerabilidad Log4Shell (CVE-2021-44228) en la biblioteca Java Log4j. Empresas en todo el mundo entraron en pánico para descubrir si y dónde usaban esta biblioteca. Herramientas de SCA fueron esenciales para esta identificación rápida.
  • Dependencias Transitivas: La biblioteca que añades (dependencia directa) puede depender de otras diez bibliotecas (dependencias transitivas). Una vulnerabilidad en cualquiera de ellas te afecta, aunque nunca hayas oído hablar de ese paquete. El SCA mapea toda esta estructura de dependencias.
  • Conformidad de Licencias: Componentes de código abierto vienen con licencias (MIT, Apache, GPL, etc.). Algunas de estas licencias tienen restricciones sobre cómo puedes usar el código, especialmente en productos comerciales. El uso indebido puede llevar a problemas legales serios. El SCA verifica estas licencias y alerta sobre conflictos.

El Proceso​

  1. Escaneo (Scan): La herramienta analiza los archivos de manifiesto de tu proyecto (como package.json en Node.js, pom.xml en Java/Maven, requirements.txt en Python, etc.). Estos archivos declaran las dependencias directas del proyecto.

  2. Identificación y Mapeo: La herramienta construye un inventario completo de todos los componentes, incluyendo las dependencias transitivas. El resultado de esta etapa es, idealmente, un SBOM (Software Bill of Materials).

  3. Análisis de Vulnerabilidades: Cada componente identificado se compara con bases de datos de vulnerabilidades conocidas, como el NVD (National Vulnerability Database), GitHub Advisories, y bases de datos privadas de la propia herramienta. Busca CVEs (Common Vulnerabilities and Exposures) asociados a esa versión específica del componente.

  4. Análisis de Licencias: Las licencias de cada componente son identificadas y comparadas con las políticas definidas por tu empresa para garantizar la conformidad.

  5. Informe y Alertas: La herramienta genera un informe detallado con:

    • Lista de componentes vulnerables.
    • La severidad de cada vulnerabilidad (generalmente usando la puntuación CVSS, o Common Vulnerability Scoring System).
    • Información sobre cómo corregir (ej: "actualiza la biblioteca X de la versión 1.2.3 a 1.2.5").
    • Alertas sobre licencias incompatibles.

Principales Beneficios del SCA en el SDLC​

  • Visibilidad: Finalmente sabes qué hay dentro de tu código.
  • Seguridad "Shift-Left": Al integrar el SCA en las fases iniciales del desarrollo (en el entorno del desarrollador, en el repositorio de código), encuentras y corriges problemas de seguridad más temprano, cuando son más fáciles y baratos de resolver. Esto es un pilar del DevSecOps.
  • Reducción de Riesgo: Evita que vulnerabilidades conocidas lleguen a producción.
  • Velocidad: Permite que los equipos de desarrollo usen componentes de código abierto con confianza, sin retrasar el proceso de innovación.
  • Cumplimiento: Garantiza la conformidad con las licencias de software y con regulaciones de seguridad.

Herramientas Populares de SCA​

Existen diversas herramientas en el mercado, tanto comerciales como de código abierto:

Comerciales:

  • Snyk Open Source: Muy popular entre desarrolladores por su integración y facilidad de uso.
  • Veracode Software Composition Analysis: Parte de una suite de seguridad de aplicaciones más amplia.
  • Sonatype Nexus Lifecycle: Enfocado en gobernanza de componentes en todo el ciclo de vida.
  • Checkmarx SCA (antiguo CxSCA): Integrado con la solución de SAST (Static Application Security Testing) de Checkmarx.
  • Sonarqube: Ofrece SCA nativo a partir de sus ediciones de pago (Developer Edition en adelante). La edición Community gratuita se enfoca en análisis de código estático (SAST).

Código Abierto (Open Source):

  • OWASP Dependency-Check: Una herramienta clásica y ampliamente utilizada que puede ser integrada en pipelines de CI/CD.
  • Trivy: Una herramienta versátil que, además de contenedores, también puede escanear dependencias de aplicaciones. Ya tenemos documentación sobre ella aquí en el sitio.

SBOM (Software Bill of Materials)​

El SBOM es un resultado directo y crucial del proceso de SCA. Haciendo una excelente analogía con el ecosistema Node.js, el SBOM es como si fuera un package-lock.json portátil y agnóstico de lenguaje.

Mientras el package-lock.json describe el árbol de dependencias exacto para un proyecto Node.js, un SBOM hace lo mismo de forma estandarizada (usando formatos como CycloneDX o SPDX) para cualquier tipo de software. Es, literalmente, una "lista de ingredientes" formal y estructurada de todos los componentes que forman una aplicación.

El gran poder de un archivo SBOM está en su portabilidad, permitiendo que sea usado como fuente de datos para diversas herramientas de seguridad. Por ejemplo, Trivy puede tanto generar un SBOM a partir de un proyecto, como analizar un SBOM ya existente en busca de vulnerabilidades. De esta forma, un inventario generado por una herramienta puede ser consumido por otra, como el OWASP Dependency-Check, optimizando el proceso de análisis.

Es fundamental entender que el SBOM es el inventario de componentes, no el informe de vulnerabilidades. Sin embargo, es con base en este inventario preciso que podemos generar informes de riesgos, analizar el impacto de nuevas amenazas y, crucialmente, gestionar la conformidad de licencias.

En este contexto, el SBOM se convierte en la mejor herramienta moderna para la divulgación de licencias. La tarea de verificar la conformidad legal deja de ser un proceso manual y se convierte en un análisis automatizado sobre un artefacto de ingeniería. Aunque no existe una ley universal que obligue a toda empresa a hacer la divulgación de sus componentes en todos los casos, esto ya es una exigencia en muchos contratos B2B y para la venta de software a sectores gubernamentales, haciendo del SBOM una necesidad de negocio.