SAST frente a SCA

La diferencia de un vistazo

	SAST	SCA
Siglas de	Static application security testing (pruebas estáticas de seguridad de aplicaciones)	Software composition analysis (análisis de composición de software)
Examina	Su propio código fuente	Componentes de código abierto y de terceros
Encuentra	Inyecciones, tratamiento inseguro de entradas, patrones inseguros	Vulnerabilidades conocidas, problemas de licencias, paquetes obsoletos
Se basa en	Reglas o modelos de cómo es el código defectuoso	Bases de datos de avisos publicados
Un hallazgo aparece cuando	Su código cambia	Cambia una dependencia o se publica un aviso nuevo
Ruido habitual	Falsos positivos en código que en realidad es seguro	Coincidencias reales que no afectan a su forma de usar el paquete
Corrección	Cambiar su código	Actualizar o sustituir el componente

Qué hace SAST

Una herramienta SAST lee el código fuente sin ejecutarlo y sigue cómo se mueven los datos por él. Si una entrada de usuario llega a una consulta de base de datos sin sanear, informa del archivo y la línea. Como trabaja sobre su código, puede encontrar fallos que nadie ha publicado nunca. También es el origen de las quejas por falsos positivos, ya que razona sobre lo que el código podría hacer, no sobre lo que hace.

Qué hace SCA

Un escaneo SCA identifica los componentes de un proyecto y los busca en datos de vulnerabilidades y licencias. No analiza la lógica de su código. Sabe que una versión tiene un fallo publicado, por lo que sus resultados suelen ser objetivos, pero dice menos sobre si ese fallo le importa a usted, salvo que la herramienta añada análisis de alcanzabilidad. Consulte qué es el análisis de composición de software para una visión completa.

Por qué necesita ambos

Los dos fallos son independientes. Una base de código sin hallazgos de SAST puede distribuir igualmente una dependencia vulnerable, y un árbol de dependencias limpio no dice nada sobre una inyección SQL en su propio controlador.

El momento también es distinto. Un hallazgo de SAST aparece cuando alguien cambia el código, así que una comprobación en la pull request detecta la mayoría. Un hallazgo de SCA puede aparecer en una versión que distribuyó hace meses, el día en que se publica un aviso nuevo, sin ningún commit que active nada. Por eso SCA necesita algo que siga comprobando lo que se ha distribuido.

Dónde encaja DAST

Las pruebas dinámicas de seguridad de aplicaciones (DAST) atacan una aplicación en ejecución desde fuera, como lo haría un atacante real. Encuentran lo que solo se manifiesta en tiempo de ejecución, como los problemas de autenticación y configuración, sin leer el código.

	SAST	SCA	DAST
Necesita	Código fuente	Manifiestos, imágenes o un registro del build	Una aplicación en ejecución
Se ejecuta	En las pull requests	En las pull requests, en los builds y después del lanzamiento	Contra un entorno de pruebas
Destaca en	Fallos en su código	Riesgos conocidos en las dependencias	Fallos de ejecución y configuración

¿Cuál debería ejecutar primero?

Para la mayoría de los equipos, SCA. Se configura rápido, se ejecuta en cuestión de segundos o minutos y cubre la mayor parte de lo que distribuye, porque la mayor parte de una aplicación moderna son dependencias. Añada después SAST, en las pull requests, y ajústelo a las reglas que importan para su stack. Añada DAST cuando tenga un entorno de pruebas estable al que dirigirlo.

¿Comprar una plataforma o varias herramientas?

Plataformas como Snyk, Checkmarx y GitHub Advanced Security agrupan SAST y SCA, lo que supone un solo contrato y un solo flujo de trabajo. Las herramientas independientes pueden ser más sólidas en cada área. Lo que más importa es la entrada: ambos tipos de escáner trabajan a partir de lo declarado o escrito, y ninguno ve lo que el build descargó realmente.

Lo que ninguno de los dos cubre

SAST y SCA leen archivos. Ninguno observa el build, de modo que el código que descarga un hook de instalación, los paquetes restaurados desde cachés de CI y las propias herramientas de build pueden quedar fuera de su vista. De esa carencia se ocupa la seguridad de la cadena de suministro de software.

CRACI cubre esa parte y deja el escaneo de código a las herramientas creadas para ello. Por diseño, no hace SAST ni detección de secretos, y muchas herramientas SAST excelentes funcionan junto a él. Es un runner de GitHub Actions que registra lo que descarga cada job en una SBOM y sigue cotejando las SBOM de lo distribuido con las nuevas vulnerabilidades. Consulte las mejores herramientas de SCA y dónde encaja CRACI junto a ellas.

SAST frente a SCA: preguntas frecuentes

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

SAST analiza el código que escribe su equipo en busca de fallos como las inyecciones. SCA analiza los componentes de código abierto y de terceros de los que depende en busca de vulnerabilidades conocidas y problemas de licencias.

¿SCA sustituye a SAST?

No. Examinan código distinto. SCA no encontrará un fallo en su propia lógica, y SAST no le dirá que una dependencia tiene una vulnerabilidad publicada.

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

SAST lee su código fuente. SCA comprueba sus dependencias. DAST prueba una aplicación en ejecución desde fuera. Cada uno encuentra problemas que los otros dos pasan por alto.

¿Snyk es SAST o SCA?

Ambos. Snyk empezó con el escaneo de dependencias de código abierto y también ofrece SAST, además de escaneo de contenedores y de infraestructura como código.

¿SonarQube es SAST o SCA?

SonarQube es conocido sobre todo por el análisis estático del código propio, es decir, SAST. Consulte las ediciones actuales para ver qué más incluyen.

¿Qué va primero, SAST o SCA?

SCA suele dar resultados más rápidos, porque es sencillo de configurar y cubre la mayor parte de lo que distribuye. SAST requiere más ajustes para mantener a raya los falsos positivos.