Hasta ahora hemos revisado código y configuración propios. Pero una aplicación moderna como BazarNube es, en su mayor parte, código de otros: React, Express, decenas de paquetes npm, Spring y sus dependencias transitivas en el módulo Java. Cada una de esas piezas puede tener vulnerabilidades conocidas (CVE) que un atacante explota sin tocar tu lógica. Eso es A06:2021 – Componentes Vulnerables y Desactualizados (Vulnerable and Outdated Components).

Es una categoría peculiar: rara vez la "descubres" auditando tu código, porque el fallo está en una librería. Se combate con proceso: inventariar lo que usas, saber qué versiones tienes, vigilar los CVE que las afectan y actualizar a tiempo. Un solo paquete transitivo desactualizado —de esos que ni sabías que tenías— puede ser la puerta de entrada. En esta lección aplicamos el análisis de composición de software (SCA) que ya presentamos en el módulo 2 (02-05, Dependency-Check) al package.json y al pom.xml de BazarNube.

Aviso legal y ético: los CVE y versiones citados son ilustrativos. Practica el análisis solo sobre sistemas y dependencias propias o con autorización explícita.

1. Por qué las dependencias son un riesgo de primer nivel
2. Dependencias directas y transitivas
3. SCA: npm audit y OWASP Dependency-Check
4. El SBOM: inventario de lo que compones
5. Gestión de versiones y actualización segura
6. Riesgos de la cadena de suministro (a alto nivel)
7. Errores comunes, ejercicios y soluciones

Cuando se publica un CVE de una librería popular, se hace público el fallo y, a menudo, cómo explotarlo. A partir de ese momento hay una carrera: los atacantes escanean internet en busca de aplicaciones que aún usen la versión vulnerable. Casos históricos (como el de una librería de serialización o de un framework web ampliamente usado) han provocado brechas masivas simplemente porque las víctimas no actualizaron a tiempo.

Lo agrava que:

• El código de terceros suele ser la mayor parte de la aplicación.
• Muchas dependencias son transitivas (dependencias de tus dependencias): ni sabes que están.
• Actualizar da "miedo" (puede romper algo), así que se pospone.

Tu package.json lista las dependencias directas, pero el árbol real (en package-lock.json) incluye cientos de paquetes transitivos. La vulnerabilidad suele estar en uno transitivo que nunca elegiste conscientemente. Por eso no basta con "revisar lo que instalé": necesitas herramientas que recorran todo el árbol.

El SCA (Software Composition Analysis) compara tu árbol de dependencias con bases de datos de vulnerabilidades conocidas y te dice qué versiones tienes que son vulnerables.

npm audit recorre package-lock.json, señala severidad y a menudo ofrece npm audit fix para actualizar automáticamente a una versión parcheada. Intégralo en CI: por ejemplo, fallar el build si hay vulnerabilidades altas o críticas.

Ya lo presentamos en 02-05. Analiza el pom.xml (y .jar) contra la base de datos pública de vulnerabilidades (NVD) e informa de los CVE que afectan a tus dependencias:

failBuildOnCVSS convierte el hallazgo en un fallo de build, forzando a atender las vulnerabilidades graves antes de desplegar. Hay equivalentes comerciales y open source (Snyk, Trivy, Grype), pero Dependency-Check es el proyecto OWASP de referencia.

Un SBOM (Software Bill of Materials) es la "lista de ingredientes" de tu software: qué componentes y versiones exactas lo forman. Es la base para responder rápido a un CVE nuevo: cuando aparezca "vulnerabilidad crítica en la librería X versión Y", con un SBOM sabes al instante si BazarNube la usa y dónde.

Formatos estándar como CycloneDX o SPDX permiten intercambiar el SBOM con clientes y herramientas. Generarlo en cada build y archivarlo te da trazabilidad: sabes exactamente qué compuso cada versión desplegada.

El objetivo no es "estar siempre en la última versión a cualquier precio", sino mantener un proceso controlado:

1. Fija versiones (lockfiles: package-lock.json, pom.xml con versiones concretas) para builds reproducibles.
2. Automatiza avisos de actualización (Dependabot, Renovate) que abren PRs cuando hay versiones nuevas o parches de seguridad.
3. Prueba antes de actualizar: una buena batería de tests permite actualizar con confianza; sin tests, la actualización da miedo y se pospone (la raíz del problema).
4. Prioriza por riesgo: primero los CVE de severidad alta/crítica y los que sean explotables en tu contexto.
5. Elimina lo que no usas: cada dependencia sobrante es superficie de ataque. Menos es más.

Más allá de "usar versiones con CVE", existe el riesgo de que la propia dependencia sea maliciosa o manipulada: paquetes con nombres parecidos a los legítimos (typosquatting), cuentas de mantenedores comprometidas que publican versiones con puertas traseras, o dependencias que "de repente" cambian de dueño. Buenas prácticas a alto nivel:

• Verifica la integridad de lo que descargas (los lockfiles guardan hashes; no los ignores).
• Desconfía de dependencias sin mantenimiento, con muy pocos usos o de origen dudoso.
• Restringe de dónde se instalan paquetes (registro interno/proxy).

La verificación de integridad de artefactos y del pipeline es tan importante que tiene su propia categoría: A08 (Fallos de Integridad de Software y Datos), que veremos en la lección 03-10. Aquí basta con quedarnos con la idea de que "componentes seguros" incluye también su procedencia.

• Ignorar las dependencias transitivas. Ahí está la mayoría de los CVE; usa SCA que recorra todo el árbol.
• No integrar el SCA en CI. Un audit manual que nadie ejecuta no protege; automatízalo y haz fallar el build.
• Actualizar sin tests. Sin red de seguridad, la actualización se pospone eternamente.
• Acumular dependencias que no usas. Cada una es superficie; poda periódicamente.
• No tener inventario (SBOM). Ante un CVE nuevo, tardarás días en saber si te afecta.
• Confiar ciegamente en cualquier paquete. Vigila procedencia y mantenimiento (cadena de suministro).
• Consejo: define una política clara ("no desplegamos con CVE crítico abierto") y automatízala; convierte la seguridad de dependencias en parte del flujo normal, no en una tarea heroica esporádica.

Ejercicio 1. npm audit reporta una vulnerabilidad alta en un paquete que resulta ser transitivo de una librería que sí usas directamente. La librería directa aún no ha publicado una versión que actualice esa transitiva. ¿Qué opciones tienes?

Ejercicio 2. ¿Por qué un SBOM acelera la respuesta cuando se publica un CVE crítico en una librería muy usada?

Ejercicio 3. Un compañero propone quitar npm audit de CI "porque a veces falla el build por vulnerabilidades que no nos afectan". ¿Qué alternativa mejor propondrías?

Solución 1. Opciones, de más a menos preferible: (a) actualizar la librería directa si publica un fix; (b) forzar la versión parcheada de la transitiva mediante overrides (npm) o resolutions; (c) si no hay parche, evaluar el riesgo real (¿es explotable en tu uso?), aplicar mitigaciones y vigilar; (d) como último recurso, sustituir la librería directa por otra mantenida. Documenta la decisión en el backlog.

Solución 2. Porque el SBOM es un inventario exacto de componentes y versiones desplegadas: en lugar de investigar manualmente cada servicio, buscas la librería y versión afectadas en el SBOM y sabes de inmediato si y dónde estás expuesto, priorizando el parcheo. Reduce el tiempo de respuesta de días a minutos.

Solución 3. No eliminarlo, sino calibrarlo: fijar --audit-level=high (o critical) para no bloquear por vulnerabilidades menores, y gestionar los falsos positivos o los CVE no explotables mediante excepciones documentadas y con fecha de revisión (allowlist temporal), no desactivando la comprobación entera. Así mantienes la protección sin fricción injustificada.

A06 no se resuelve con una técnica de codificación, sino con disciplina de proceso: inventariar (SBOM), analizar la composición (npm audit, Dependency-Check) de forma automática en CI, actualizar con una red de tests, podar lo innecesario y vigilar la procedencia. En BazarNube, integrar el SCA en el pipeline convierte los CVE en tareas rutinarias del backlog en lugar de en incidentes.

Entrada de backlog — A06: npm audit --audit-level=high en CI del front y la API; Dependency-Check con failBuildOnCVSS=7 en el módulo Java; Dependabot habilitado; SBOM CycloneDX generado por build; poda de dependencias sin uso pendiente.

Hemos asegurado quién accede, qué se protege, cómo se inyecta, cómo se diseña, cómo se configura y qué componentes usamos. Toca volver a un control fundamental que dejamos pendiente al distinguirlo de la autorización: la autenticación. La siguiente lección es A07:2021 – Fallos de Identificación y Autenticación, con el login y las sesiones de BazarNube.