Desarrollo seguro: Parte 4 — SCA: verificación de dependencias

La mayor parte del código en una aplicación moderna no la ha escrito usted. El framework, el driver de la base de datos, las librerías para logging, para parsear JSON y para trabajar con imágenes — todo eso es código abierto ajeno, y cada una de esas librerías arrastra varias más. Una vulnerabilidad en cualquiera de ellas se convierte en una vulnerabilidad de su aplicación. Revisar esta parte del proyecto es tarea de SCA.

Qué es SCA

SCA (Software Composition Analysis, análisis de la composición del software) — herramientas que generan la lista completa de dependencias del proyecto y la comparan con bases de datos de vulnerabilidades conocidas. Muchas de ellas también verifican las licencias de las librerías.

La principal dificultad son las dependencias transitivas. Al añadir al proyecto un paquete, por ejemplo requests en Python o express en Node.js, también obtiene todos los paquetes de los que ese paquete depende. El escáner SCA lee los manifiestos y los archivos lock (package-lock.json, poetry.lock, go.sum, pom.xml) y construye todo el árbol, no solo lo que usted indicó explícitamente.

Cuán serio fue esto lo mostró la vulnerabilidad Log4Shell en la librería Java Log4j en diciembre de 2021. Bastaba con enviar una cadena especialmente construida a un sitio que se registrara en los logs para ejecutar código en el servidor. Muchas empresas pasaron semanas averiguando en qué proyectos se usaba esa librería. Si la lista de dependencias de cada proyecto hubiera estado a mano, la respuesta habría tomado minutos.

Herramientas

Trivy es una buena primera opción: una herramienta para código, imágenes y SBOM. Grype y OSV-Scanner son útiles como segunda opinión, porque las bases de vulnerabilidades de distintos escáneres difieren un poco.

Escaneo del proyecto

Trivy se instala desde el gestor de paquetes o con un binario desde la página de releases. Comprobación de un directorio de proyecto:

trivy fs --scanners vuln .

En el informe, para cada hallazgo se indica la librería, el identificador de la vulnerabilidad (por ejemplo, CVE), el nivel de severidad, la versión instalada y la versión en la que se corrigió la vulnerabilidad.

Comprobación de licencias:

trivy fs --scanners license .

Las mismas comprobaciones con otros escáneres:

grype dir:.
osv-scanner scan source -r .

SBOM: lista de componentes

SBOM (Software Bill of Materials) — lista legible por máquina de todos los componentes de la aplicación. Se crea en cada build y se guarda junto con el release. Cuando aparece una nueva vulnerabilidad, basta verificar los SBOM guardados, no rebuildar los proyectos.

trivy fs --format cyclonedx --output sbom.json .
trivy sbom sbom.json

El primer comando crea un SBOM en formato CycloneDX, el segundo lo comprueba en busca de vulnerabilidades. También se soporta el formato SPDX.

SCA en CI

La comprobación debe ejecutarse automáticamente. Ejemplo de job de GitHub Actions que detiene la build ante vulnerabilidades críticas:

name: sca
on: [pull_request]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Trivy
        run: curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
      - name: Scan dependencies
        run: trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 .

--exit-code 1 convierte los hallazgos en error de compilación, --severity limita la comprobación a niveles serios, para que el CI no se detenga por cada pequeña cosa.

Qué hacer con los resultados

Al primer escaneo en un proyecto real pueden aparecer cientos de hallazgos. Es normal.

1. Empiece por HIGH y CRITICAL, especialmente en librerías que procesan datos de entrada: framework web, parseo de archivos, serialización.
2. Compruebe si se usa realmente el código vulnerable. Una vulnerabilidad en una función que la aplicación no invoca es menos urgente. Pero no posponga esas actualizaciones para siempre.
3. Actualice en pasos pequeños. Una actualización mayor puede romper la aplicación, por lo que después de cada actualización hacen falta tests.
4. Si no hay parche, registre una excepción deliberada con fecha de revisión: Trivy tiene para eso el archivo .trivyignore.

Las actualizaciones automáticas las realizan Dependabot o Renovate: el bot abre un pull request con la nueva versión, y a usted solo le queda esperar los tests y aceptarlo. Renovate es más flexible en la configuración y no solo funciona con GitHub, sino también con GitLab, incluso en su propio servidor.

Archivos lock

El archivo lock fija las versiones exactas de todas las dependencias, incluidas las transitivas. Sin él, dos builds del mismo código pueden obtener versiones distintas de las librerías, y en producción llegará una versión que nadie verificó.

• Mantenga el archivo lock en el repositorio.
• En CI instale las dependencias exactamente según él: npm ci, poetry install, pip install --require-hashes -r requirements.txt.
• Actualice el archivo lock de forma consciente, en un cambio separado que pase las mismas comprobaciones.

Licencias de las dependencias

Los escáneres SCA también alertan sobre licencias. Las licencias copyleft (GPL, AGPL) pueden obligar a divulgar el código fuente, pero las obligaciones dependen de cómo distribuya el producto. Un programa que entrega a clientes y un servicio que solo corre en sus servidores son casos distintos, y la AGPL se aplica también al uso en red. Es mejor acordar una lista de licencias permitidas con el equipo legal una vez y verificarla automáticamente.

Lo principal

• Cada dependencia nueva es otro proveedor de código. No añada una librería solo por una función de cinco líneas.
• Escanee con regularidad, no solo en la build: cada día se descubren nuevas vulnerabilidades en versiones antiguas.
• Mantenga archivos lock y SBOM — así a la pregunta «dónde está esta librería» se podrá responder en minutos.