Escaneo SCA

Qué ocurre en un escaneo SCA

1. Lee el objetivo. El escáner lee manifiestos y lockfiles como package-lock.json, poetry.lock o Cargo.lock, o desempaqueta una imagen de contenedor.
2. Construye la lista de componentes. Convierte lo que ha encontrado en nombres y versiones, normalmente incluidas las dependencias transitivas.
3. Coteja los datos. Cada componente se busca en fuentes como GitHub Advisory Database, OSV y la NVD, y su licencia se compara con su política.
4. Informa. Los hallazgos aparecen ordenados por gravedad, normalmente con una versión corregida. En CI, una política puede hacer que el job falle.

Para conocer la práctica más amplia a la que pertenece, consulte qué es el análisis de composición de software.

Dónde ejecutar los escaneos SCA

Un solo escaneo en un solo lugar deja lagunas. Cada etapa responde a una pregunta distinta, por lo que la mayoría de los equipos ejecuta más de uno.

Dónde	Qué responde	Qué se le escapa
Equipo del desarrollador o IDE	¿Es seguro añadir este paquete?	Todo aquello en lo que el desarrollador no lo ejecuta
Pull request	¿Añade este cambio un riesgo conocido?	Avisos nuevos sobre código que no ha cambiado
Build de CI	¿Qué contiene la versión?	Todo lo que el escáner no puede ver en el build
Registro de contenedores	¿Qué hay en esta imagen?	El código compilado y las herramientas de build que no dejan rastro
Después del lanzamiento	¿Le afecta algo nuevo a lo que distribuimos?	Nada, si el registro de lo distribuido está completo

La última fila es la que omite la mayoría de los programas. Un aviso nuevo afecta a una versión que usted distribuyó hace meses, y ninguna pull request activará un escaneo por ello.

Cómo leer los resultados de un escaneo SCA

El primer escaneo de un proyecto real suele devolver cientos de hallazgos. Revíselos en este orden:

1. Empiece por lo que se está explotando. Un hallazgo en el catálogo KEV de CISA tiene prioridad sobre una puntuación CVSS más alta sin explotación conocida. Consulte cómo priorizar vulnerabilidades.
2. Compruebe que se aplica. Las dependencias solo de desarrollo no se distribuyen. Algunas herramientas añaden análisis de alcanzabilidad para comprobar si el código vulnerable puede llegar a invocarse.
3. Corrija en el nivel adecuado. En un hallazgo transitivo, la corrección suele estar en el paquete que lo incorpora, como muestra un grafo de dependencias.
4. Registre lo que no va a corregir. Un hallazgo que ha decidido aceptar debe indicar por qué; de lo contrario, la siguiente persona repetirá el trabajo. VEX es la forma estándar de registrarlo.

Por qué un escaneo limpio no significa software limpio

• Ve lo que está declarado. Un escáner lee los archivos que tiene delante, así que un repositorio sin lockfile le da poco con lo que trabajar, y el código que descarga un hook de instalación nunca aparece.
• Ve aquello a lo que usted lo apunta. La imagen base, las herramientas de build y las GitHub Actions de su pipeline son independientes del manifiesto de su aplicación.
• Solo conoce lo publicado. Un paquete malicioso nuevo aún no tiene aviso.
• La lista no es el build. Los builds resuelven las versiones al ejecutarse, de modo que lo que leyó el escaneo y lo que contiene la versión pueden diferir.

Son límites del propio 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.

Escáneres gratuitos y comerciales

Las opciones gratuitas cubren bien lo básico. Las alertas de Dependabot vienen con GitHub, OWASP Dependency-Check y Trivy son de código abierto, y Grype se combina con el generador de SBOM Syft. Las herramientas comerciales añaden políticas, priorización, alcanzabilidad y flujos de trabajo para muchos equipos. La comparativa de las mejores herramientas de SCA analiza 13 de ellas, y esta guía muestra por qué los generadores gratuitos no coinciden entre sí.

Escaneo SCA y registro durante el build

CRACI no es un escáner, y usted no tiene que renunciar al suyo. 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, y después sigue reevaluando las SBOM de lo distribuido a medida que se publican nuevas vulnerabilidades. Su escáner cubre las pull requests y los equipos de los desarrolladores. CRACI cubre el build y todo lo que viene después. Consulte dónde encaja CRACI junto a sus herramientas de SCA.

Escaneo SCA: preguntas frecuentes

¿Qué es un escaneo SCA?

Un escaneo SCA lee los manifiestos, los lockfiles o la imagen de contenedor de un proyecto, averigua qué componentes de código abierto utiliza y los coteja con datos de vulnerabilidades y licencias.

¿El SCA es lo mismo que el escaneo de dependencias?

Casi. El escaneo de dependencias suele consistir en comprobar si las dependencias tienen vulnerabilidades conocidas. SCA es el término más amplio y abarca también las licencias, los paquetes obsoletos y la elaboración de un inventario como una SBOM.

¿Cuándo deben ejecutarse los escaneos SCA?

En las pull requests, para impedir que entren nuevos riesgos; en el build de CI, para describir la versión; y de forma continua después del lanzamiento, porque los nuevos avisos afectan al software que ya ha distribuido.

¿Cuánto tarda un escaneo SCA?

Normalmente, de unos segundos a unos minutos, porque lee metadatos en lugar de analizar todo su código. Por eso resulta práctico ejecutarlo en cada pull request.

¿Por qué los escáneres SCA dan resultados distintos?

Cada uno tiene sus propias reglas sobre qué leer, cómo nombrar los componentes y qué datos de vulnerabilidades utilizar. Un mismo commit puede producir listas de componentes y hallazgos diferentes.

¿El escaneo SCA detecta malware?

El cotejo de avisos solo detecta versiones maliciosas cuando ya existe un aviso. Las herramientas que analizan el comportamiento de los paquetes pueden detectar algunas antes. Un paquete malicioso nuevo no tiene aviso el día en que aparece.