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

Cómo funciona el SCA

1. Identifica los componentes. La herramienta lee aquello a lo que se la apunta: manifiestos y lockfiles de un repositorio, paquetes instalados o el contenido de una imagen de contenedor o de un binario. El resultado es un inventario de componentes y versiones, que a menudo se exporta como SBOM.
2. Los coteja con riesgos conocidos. Cada componente se busca en bases de datos de vulnerabilidades como GitHub Advisory Database, OSV y la NVD, y su licencia declarada se compara con su política.
3. Prioriza. Los hallazgos se ordenan por gravedad, y algunas herramientas añaden análisis de alcanzabilidad para comprobar si su código puede llegar a invocar la función vulnerable.
4. Corrige. Muchas herramientas sugieren una versión corregida o abren una pull request, como hacen Dependabot y Renovate. En una dependencia transitiva vulnerable, la corrección suele estar en el paquete que la incorpora, como muestra un grafo de dependencias.

Qué encuentra el SCA

• Vulnerabilidades conocidas en las versiones que utiliza, con los avisos que las describen.
• Riesgo de licencias, como una licencia copyleft en un producto propietario.
• Paquetes obsoletos y sin mantenimiento que no recibirán correcciones de seguridad.
• Paquetes maliciosos, en las herramientas que también analizan cómo se comportan los paquetes en lugar de limitarse a cotejar avisos.

SCA frente a SAST

El SCA y las pruebas estáticas de seguridad de aplicaciones (SAST) suelen venderse juntos, pero examinan código distinto y responden a preguntas distintas.

	SCA	SAST
Qué analiza	Los componentes de código abierto y de terceros de los que usted depende	El código que escribe su equipo
Qué encuentra	Vulnerabilidades conocidas, problemas de licencia, paquetes obsoletos	Fallos en su código, como inyecciones o un manejo inseguro de las entradas
Qué lee	Manifiestos, lockfiles, paquetes instalados, imágenes o binarios	Código fuente
Qué genera un hallazgo nuevo	Un cambio de dependencia, o un aviso nuevo sobre una versión que ya distribuye	Un cambio en su código
Resultado típico	Componentes vulnerables con versiones corregidas, y una SBOM	Ubicaciones del código con el fallo y una corrección sugerida

Necesita ambos. Una base de código sin hallazgos de SAST aún puede distribuir una dependencia vulnerable, y un árbol de dependencias limpio no dice nada sobre su propio código. Consulte SAST frente a SCA para ver la comparación completa. Una diferencia importa para saber cómo ejecutarlos: un hallazgo de SAST aparece cuando su código cambia, mientras que un hallazgo de SCA puede aparecer sobre una versión que usted distribuyó hace meses, el día en que se publica un aviso nuevo.

Dónde se detiene el SCA

Todo resultado de SCA depende del primer paso: identificar los componentes. Un componente que la herramienta nunca identificó no se puede cotejar, priorizar ni corregir, y tampoco aparece como una laguna. Los puntos ciegos habituales:

• Lo que los archivos no dicen. La mayoría de las herramientas de SCA leen manifiestos y lockfiles. Un lockfile ausente o desactualizado, los paquetes restaurados desde cachés de CI, las herramientas de build, las descargas y los scripts de instalación nunca llegan al inventario. Consulte por qué un lockfile no es un registro de lo distribuido.
• Las herramientas discrepan. Dos escáneres apuntados al mismo commit devuelven listas de componentes distintas, porque cada uno tiene sus propias reglas sobre qué leer y cómo nombrarlo. Consulte lo que se les escapa a los generadores de SBOM de código abierto.
• Binarios. El software que se distribuye como binario precompilado declara poco o nada que un lector de manifiestos pueda ver.
• Solo vulnerabilidades conocidas. El cotejo encuentra lo que se ha publicado. Un paquete malicioso nuevo o un fallo no divulgado aún no tiene aviso.
• Una instantánea. Un escaneo en una pull request describe ese momento. Los nuevos avisos sobre versiones que ya están en producción necesitan algo que siga comprobando lo distribuido.

No es un defecto de un producto concreto. Es como funciona el escaneo, sea comercial o de código abierto. CRACI ha encontrado paquetes vulnerables de los que Snyk y Aikido no informaron, porque esos componentes nunca estuvieron en lo que escanearon.

Registre el build, conserve su SCA

CRACI cierra la brecha de identificación desde el lado del build. Es un runner de GitHub Actions que registra cada paquete que descarga cada job, a cualquier profundidad del árbol e incluidos los paquetes restaurados desde cachés de CI, en una SBOM que indica su propia completitud. Sigue reevaluando las SBOM de lo distribuido a medida que se publican nuevas vulnerabilidades, y el historial de builds muestra qué builds anteriores contenían un paquete vulnerable.

CRACI no hace SAST ni análisis de alcanzabilidad, por diseño. Los equipos lo ejecutan junto a una herramienta de SCA o SAST que cubre las pull requests y su propio código. Consulte la comparativa de herramientas de SCA, dónde encaja CRACI junto a sus herramientas de SCA o reserve una demo para comparar una SBOM registrada con su escaneo actual.

Análisis de composición de software: preguntas frecuentes

¿Qué es el SCA en ciberseguridad?

El análisis de composición de software (SCA) es la práctica de encontrar los componentes de código abierto y de terceros de su software y comprobar si tienen vulnerabilidades conocidas, problemas de licencia o versiones obsoletas. Cubre el código del que usted depende, a diferencia del código que escribe.

¿Cuál es la diferencia entre SCA y SAST?

El SAST analiza el código que escribe su equipo en busca de fallos como los errores de inyección. El SCA analiza los componentes de los que usted depende en busca de vulnerabilidades conocidas y problemas de licencia. Responden a preguntas distintas, por lo que la mayoría de los programas de seguridad ejecutan ambos.

¿Qué significa el escaneo SCA?

Un escaneo SCA lee los manifiestos, los lockfiles, los paquetes instalados o una imagen de contenedor de un proyecto, averigua qué componentes contiene y los coteja con datos de vulnerabilidades y licencias. El resultado es una lista de hallazgos, a menudo con una SBOM de los componentes que identificó.

¿Una SBOM es lo mismo que el SCA?

No. Una SBOM es un inventario: la lista de componentes de una versión. El SCA es el análisis: identificar los componentes y comprobar sus riesgos. Muchas herramientas de SCA producen una SBOM por el camino, y una SBOM puede alimentar la monitorización de vulnerabilidades después del lanzamiento.

¿Cuáles son las limitaciones del SCA?

Solo analiza los componentes que puede identificar, normalmente a partir de manifiestos y lockfiles. Se le pueden escapar los paquetes restaurados desde cachés de CI, las herramientas de build, las descargas y los binarios sin metadatos de paquete. Encuentra vulnerabilidades conocidas, no desconocidas, y un escaneo es una instantánea, salvo que la herramienta siga revisando lo distribuido.

¿Cuáles son las mejores herramientas de SCA?

Depende de lo que necesite más allá de lo básico: análisis de alcanzabilidad, detección de paquetes maliciosos, política de licencias o flujo de trabajo para desarrolladores. Consulte nuestra comparativa de 13 herramientas de SCA para ver qué cubre cada una y dónde se queda corta.