SCA — comprobamos el «código ajeno» en busca de fallos

Imagina que estás construyendo una casa. Tú mismo diseñaste las paredes, revisaste cada ladrillo y te aseguraste de no haber olvidado las llaves en la cerradura. Pero ¿y si el hormigón que compraste a un proveedor externo con el tiempo empieza a desmoronarse? ¿O si en los marcos de las ventanas que instalaste hay defectos ocultos?

En el desarrollo moderno la situación es exactamente así. Una aplicación promedio hoy en día está formada en un 80–90% por bibliotecas de código abierto. Solo escribes una pequeña parte del código (la punta del iceberg), que gestiona un enorme volumen de código ajeno oculto «bajo la superficie».

¿Qué es SCA y por qué lo necesita un novato?

SCA (Software Composition Analysis) es el proceso de analizar la composición de tu software. En pocas palabras, es una herramienta que lista todas las bibliotecas que usas (incluidas las que ni siquiera sospechas) y las comprueba contra bases de datos de vulnerabilidades conocidas.

¿Por qué es crítico?

Puedes ser un genio de la programación y escribir código perfectamente seguro, pero si usas una biblioteca popular para logging o procesamiento de imágenes que tiene un agujero —tu aplicación será comprometida.

Un ejemplo clásico: Log4Shell (2021). En una pequeña biblioteca de Java (Log4j), usada por millones de servidores en todo el mundo, se encontró una vulnerabilidad crítica. A los atacantes les bastaba con «colocar» una cadena especialmente formada en un lugar que fuera a los logs para obtener ejecución remota de código y control total del servidor. Las empresas pasaban semanas solo para encontrar en cuáles de sus proyectos se estaba usando esa biblioteca.

¿Cómo funciona? Dependencias transitivas

Cuando añades al proyecto una biblioteca (por ejemplo, requests en Python o express en Node.js), esta, a su vez, arrastra otras bibliotecas. Esas — otras. Esto se llama dependencias transitivas.

Al final, al añadir un paquete puedes sin querer introducir en el proyecto otros 50 módulos ajenos. Los escáneres SCA analizan tus archivos de manifiesto (package.json, requirements.txt, go.mod, pom.xml) y construyen el árbol completo de dependencias, comprobando cada elemento.

Herramienta: presentación de Trivy

Para un principiante una buena elección es Trivy de la empresa Aqua Security. Es la «navaja suiza» de la seguridad: sabe escanear tanto archivos de proyecto como imágenes Docker, repositorios Git y otros objetivos.

¿Por qué Trivy?

• Es rápido.
• Encuentra vulnerabilidades conocidas en dependencias y paquetes.
• Genera informes comprensibles: qué se encontró, dónde está y a qué versión hay que actualizarse.

Ejemplo práctico: escaneando un proyecto

Supongamos que tienes un proyecto en Node.js o Python.

Instalación

macOS:

brew install aquasecurity/trivy/trivy

(También en Homebrew está disponible la fórmula trivy, es decir, también se puede instalar así: brew install trivy.)

Linux/Windows: Descarga el binario desde los releases de Trivy e instálalo en el PATH.

Ejecución del escaneo del sistema de archivos

trivy fs ./путь/к/вашему/проекту

¿Qué verás en la terminal? Trivy mostrará una tabla. En ella habrá:

• Biblioteca: nombre de la biblioteca (por ejemplo, django o lodash).
• Vulnerability ID: número de la vulnerabilidad en el registro mundial (por ejemplo, CVE-2023-1234).
• Severidad: cuán peligroso es (LOW, MEDIUM, HIGH, CRITICAL).
• Versión instalada: qué versión tienes ahora.
• Versión corregida: a qué versión debes actualizarte para cerrar el agujero.

Estrategia de supervivencia: ¿qué hacer con los resultados?

Cuando ejecutes un escáner SCA por primera vez en un proyecto real, puedes horrorizarte: «¡Tengo 200 vulnerabilidades! ¿Qué hago?!» Tranquilo. No todas son igualmente peligrosas.

1) Prioridades (Triage)

Primero arregla CRITICAL y HIGH. Son los agujeros que con más frecuencia se pueden explotar relativamente rápido y con alto impacto. Las vulnerabilidades de LOW a menudo son más teóricas y pueden esperar.

2) Actualizar — el mejor remedio

En la mayoría de los casos la solución de SCA es simplemente actualizar las dependencias:

npm update

pip install --upgrade ...

Pero ten cuidado: las actualizaciones mayores (por ejemplo, de la versión 2.0 a la 3.0) pueden romper tu código. Siempre verifica que todo funcione después de actualizar.

3) Automatización (Dependabot y análogos)

Si usas GitHub, activa Dependabot. Es un robot que escanea las dependencias y crea automáticamente Pull Requests con la actualización si encuentra una vulnerabilidad. Solo te queda pasar por el proceso estándar de revisión/pruebas y pulsar el botón «Merge».

Trampa de SCA: cumplimiento de licencias

Además de la seguridad, las herramientas SCA a menudo verifican licencias. Imagina que por accidente usaste una biblioteca con licencia GPL en un proyecto comercial. Dependiendo del escenario de distribución y de la interpretación legal, esto puede crear obligaciones de divulgar el código fuente u otros requisitos. Los escáneres SCA avanzados advierten sobre esto de antemano, para que los abogados de tu empresa no tengan sorpresas.

Resumen: reglas para trabajar con dependencias

• Menos — mejor: no añadas una librería al proyecto solo por una función que puedas escribir en cinco líneas de código. Cada paquete nuevo es un potencial agujero de seguridad.
• Escanea regularmente: se encuentran nuevas vulnerabilidades todo el tiempo. Lo que era seguro ayer puede convertirse en una amenaza crítica hoy.
• Usa archivos lock: siempre fija las versiones (package-lock.json, poetry.lock) para que en producción no entre una versión de la biblioteca que no hayas probado.