SBOM y seguridad de la cadena de suministro de software: ¿puede confiar en sus dependencias?

Una aplicación media en producción contiene mucho más código escrito por desconocidos que por su propio equipo. En nuestra experiencia, un servicio Node.js con 30 dependencias directas arrastra sin despeinarse más de mil paquetes transitivos, y casi nadie ha leído ninguno de ellos. Cuando llegue el próximo momento XZ Utils o event-stream, ganarán los equipos capaces de responder una sola pregunta en minutos: ¿estamos ejecutando de verdad la versión afectada?

El iceberg de las dependencias

Usted audita su código. Revisa cada pull request. Y después npm install ejecuta scripts de postinstalación arbitrarios de un paquete a seis niveles de profundidad en su árbol, mantenido por alguien cuya cuenta protege una contraseña de 2014. Esa es la asimetría en el corazón de la seguridad de la cadena de suministro: sus controles cubren el diez por ciento del código que escribió su equipo, y sus atacantes lo saben.

Tres propiedades convierten a las dependencias en una superficie de ataque especialmente incómoda:

• Invisibilidad transitiva. Usted eligió express. No eligió las decenas de paquetes que trajo consigo, y nadie más de su equipo tampoco. Sobre la mayor parte de su árbol nadie tomó nunca una decisión de confianza.
• Ejecución en el momento de la instalación. Muchos ecosistemas ejecutan scripts de ciclo de vida al instalar. Basta comprometer un paquete popular para conseguir ejecución de código en cada equipo de desarrollo y cada runner de CI que lo descarga, antes incluso de que arranque la aplicación.
• Herencia de confianza. El portátil comprometido de un mantenedor, un dominio de correo caducado o un proyecto personal cedido a un tercero se convierten en su incidente. El ataque a event-stream funcionó exactamente así: un desconocido servicial pidió permisos de publicación sobre un paquete abandonado y los consiguió.

De esto no se sale a base de revisiones. El árbol es demasiado grande y cambia cada semana. Lo que sí puede construir son tres capas: inventario (saber qué despliega), verificación (probar de dónde viene) y controles de entrada (frenar y sanear lo que entra). Los SBOM son la capa de inventario, y todo lo demás se apoya sobre ella.

Qué es exactamente un SBOM

Un SBOM (Software Bill of Materials) es un inventario legible por máquina de cada componente de un artefacto concreto: nombre del paquete, versión exacta, proveedor, hashes criptográficos, licencia y las relaciones de dependencia entre componentes. No es una hoja de cálculo. Tampoco su package.json, que declara intenciones y no resoluciones. Es un documento estructurado ligado a una compilación concreta.

Dominan dos formatos, y la elección es bastante menos dramática de lo que sugiere internet:

• SPDX (ISO/IEC 5962). El veterano. La herencia más sólida en cumplimiento de licencias, herramientas por todas partes, preferido en los ecosistemas de la Linux Foundation.
• CycloneDX (nacido en OWASP, hoy estandarizado como ECMA-424). Diseñado para flujos de seguridad. Soporte de primera clase para referencias de vulnerabilidades, VEX, servicios y componentes de hardware y de ML. Si su caso de uso principal es la respuesta a vulnerabilidades, empiece por aquí.

Ambos se serializan a JSON. Ambos se convierten entre sí con una fidelidad aceptable. Elija uno, genérelo de forma consistente y no permita que el debate de formatos retrase el despliegue.

La regulación está empujando con fuerza. La contratación federal estadounidense exige SBOM a sus proveedores desde la Orden Ejecutiva 14028, y el Reglamento Europeo de Ciberresiliencia (CRA) extiende obligaciones parecidas a casi cualquiera que venda productos con elementos digitales en la Unión Europea. En España, quien trabaja con la administración ya nota la misma dirección vía el Esquema Nacional de Seguridad y NIS2, y si dirige una startup latinoamericana que vende a clientes enterprise de Estados Unidos o Europa, las cláusulas de SBOM llegarán a sus contratos igualmente, se prepare o no. Prepararse sale más barato.

Genere en el build, no bajo demanda

El modo de fallo más común con los SBOM: generar uno trimestral a partir de un escaneo del código fuente y dar la casilla por marcada. Un SBOM desconectado de un artefacto de compilación concreto es una conjetura con extensión de archivo. Las reglas que importan:

• Un SBOM por artefacto y por build. El SBOM de api:1.4.2 describe exactamente esa imagen, con su lockfile resuelto incluido.
• Escanee el artefacto, no solo el código fuente. Una imagen de contenedor contiene paquetes del sistema operativo (apk, deb, rpm), dependencias del lenguaje y binarios sueltos que alguien copió dentro. Un escaneo del código fuente no ve nada de la primera categoría y se pierde la tercera por completo.
• Guarde los SBOM junto a la release y manténgalos consultables. Su valor se multiplica cuando puede buscar de una sola vez en todas las versiones desplegadas.

Con Syft, cada modo de generación es un solo comando:

# Directorio de código fuente, con lectura del lockfile
syft dir:. -o cyclonedx-json > sbom.cdx.json

# Imagen de contenedor construida, incluye paquetes del SO y binarios
syft registry:ghcr.io/acme/api:1.4.2 -o cyclonedx-json > sbom-image.cdx.json

Después, adjunte el SBOM a la imagen como atestación firmada, de modo que quien lo consuma pueda verificar que lo produjo su pipeline y que nadie lo editó después:

cosign attest --predicate sbom-image.cdx.json \
  --type cyclonedx ghcr.io/acme/api:1.4.2

Dónde muere en silencio la precisión de un SBOM

Todo generador tiene puntos ciegos. Conozca los suyos:

• Código vendorizado o copiado. Una función levantada de un artículo de blog o una librería incrustada a mano no tienen identidad de paquete. No aparecerán.
• Binarios estáticos. Los binarios de Go incorporan información de build que las herramientas saben leer. Un binario de C sin símbolos es una caja negra con nombre de archivo.
• Frontend empaquetado. Después de que webpack o esbuild hagan su trabajo, el artefacto es un bloque minificado. Genere el SBOM desde el lockfile antes del bundling y publique ambos.
• Los jars con shading del mundo JVM renombran paquetes internamente y burlan cualquier correspondencia ingenua.

Un SBOM que presume de una completitud que no tiene es peor que no tener SBOM, porque la gente se lo cree. Documente con precisión qué cubre su paso de generación y qué no puede ver.

Del inventario a las respuestas

La recompensa llega cuando cae un CVE serio. Sin SBOM, hay que recompilar y reescanear cada servicio para saber si están expuestos, y eso son días que no tiene. Con SBOM almacenados, se consultan documentos:

grype sbom:./sbom-image.cdx.json --fail-on high

Mejor todavía: cargue el SBOM de cada release en un servidor Dependency-Track. Este reevalúa de forma continua su inventario existente contra los avisos nuevos, de modo que cuando aterrice el próximo bug de la clase Log4Shell tendrá la lista de servicios afectados en minutos, sin tocar una sola compilación. Esa diferencia de velocidad lo es todo durante un incidente, y encaja directamente con el trabajo de proceso de nuestro manual de respuesta a incidentes.

Cuente con ruido. Un escáner que compara contra un SBOM marcará versiones vulnerables que su código nunca ejercita. Para eso existe VEX (Vulnerability Exploitability eXchange): una declaración legible por máquina, publicada junto al SBOM, que deja registrado su análisis:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "statements": [{
    "vulnerability": { "name": "CVE-2026-XXXXX" },
    "products": [{ "@id": "pkg:oci/api@sha256%3A3d1f..." }],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path"
  }]
}

Los equipos que se saltan el VEX se ahogan en hallazgos, terminan ignorando el escáner y acaban peor que antes de instalarlo. El triaje no es una sobrecarga opcional. Es el producto.

Lo que un SBOM nunca va a detectar

Seamos honestos con los límites, porque los proveedores no lo serán. Un SBOM es un inventario de componentes conocidos. No hace nada contra:

• Paquetes maliciosos sin CVE. Un typosquat o una release recién troyanizada están "limpios" hasta que alguien los descubre. Su SBOM los listará con toda fidelidad y no levantará ninguna alarma.
• El compromiso del sistema de build. SolarWinds distribuyó compilaciones envenenadas partiendo de una lista de dependencias limpia. El malware entró durante la compilación, por debajo de la capa que cualquier SBOM describe.
• La toma de control de la cuenta de un mantenedor que publica una versión de parche de aspecto legítimo por el canal habitual.

Cerrar esos huecos exige procedencia y controles de entrada, no más inventario.

Exija procedencia. Evidencia criptográfica de dónde salió un artefacto y qué pipeline lo compiló. SLSA aporta el modelo de madurez, Sigstore aporta las herramientas. En concreto: publique sus propios paquetes con npm publish --provenance, verifique las imágenes de terceros con cosign verify contra la identidad de CI del editor, y trate los artefactos sin firmar de proveedores críticos como hallazgos que hay que escalar.

Fije por contenido, no por nombre. Los nombres y las etiquetas se pueden mover. Los digests, no:

# GitHub Actions: fijar a un SHA de commit, no a una etiqueta que alguien puede reapuntar
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

# Fijar las imágenes base por digest
FROM node:22-slim@sha256:3d1f9a...

Frene el camino de entrada. La mayoría de las versiones maliciosas de paquetes se detectan y retiran a los pocos días de publicarse. Un periodo de enfriamiento convierte la detección de la comunidad en su protección:

{
  "extends": ["config:recommended"],
  "minimumReleaseAge": "7 days",
  "internalChecksFilter": "strict"
}

Esa configuración de Renovate significa que una release secuestrada tiene que sobrevivir una semana de escrutinio público antes de que sus bots siquiera la propongan. El coste: dependencias un poco menos frescas. El beneficio: dejar de ser la víctima temprana que descubre el compromiso para todos los demás.

Neutralice los scripts de instalación. Ejecutar npm ci --ignore-scripts en CI elimina la primitiva de ejecución más común, a cambio de tener que autorizar de vez en cuando algún paquete que de verdad necesita un paso de build. En nuestra experiencia, el intercambio compensa en todas partes, equipos de los desarrolladores incluidos.

Un despliegue de 30 días que de verdad perdura

Aquí el orden importa. Inventario antes que bloqueos, bloqueos antes que firmas. Los equipos que empiezan por las firmas y se saltan los lockfiles construyen una catedral sobre arena.

1. Días 1 a 3: disciplina de lockfiles. Cada repositorio versiona sus lockfiles. CI instala con npm ci, pip install --require-hashes o el equivalente del ecosistema, y falla ante cualquier deriva.
2. Días 4 a 7: generar SBOM en CI. Añada Syft a los pipelines de sus cinco servicios más críticos. CycloneDX JSON, un SBOM por artefacto compilado, almacenado con la release.
3. Días 8 a 12: levantar Dependency-Track. Ingesta automática de cada SBOM. Dirija las alertas al canal que su guardia de verdad lee.
4. Días 13 a 17: línea base y triaje. El primer escaneo será feo. Clasifique cada hallazgo: explotable ahora, necesita una actualización planificada, o no afectado (redacte la declaración VEX mientras el análisis está fresco).
5. Días 18 a 22: bloquear el pipeline. Haga fallar los builds ante vulnerabilidades críticas nuevas con exploits conocidos. No bloquee por el histórico acumulado, o el equipo esquivará el control en menos de un mes.
6. Días 23 a 26: fijar y verificar. Fije las actions de CI a un SHA y las imágenes base a su digest. Active la verificación de procedencia para sus proveedores más críticos.
7. Días 27 a 30: añadir el enfriamiento. Renovate o Dependabot con una edad mínima de release, más --ignore-scripts en cada job de CI.

Todo esto vive dentro de su pipeline de entrega, y por eso pertenece a la misma conversación que el resto de sus controles. Nuestras guías sobre el pipeline DevSecOps y los pipelines de CI/CD en los que los equipos confían cubren la maquinaria de alrededor.

¿Cuánto rigor necesita realmente?

No todos los equipos necesitan el nivel 3 de SLSA. El marco que aplicamos con nuestros clientes:

• Vende software o APIs a grandes empresas o a compradores regulados. Programa completo: SBOM por release, Dependency-Track, VEX, procedencia firmada. Los departamentos de compras exigirán los documentos pronto, tanto en licitaciones europeas bajo el CRA como en contratos enterprise en América, y un "podemos generar uno el próximo trimestre" pierde operaciones.
• Opera un SaaS para clientes más pequeños. Generación de SBOM, escaneo continuo, disciplina de lockfiles y enfriamiento. Posponga el VEX hasta que el ruido del escáner sea un coste medible.
• Herramientas internas, equipo pequeño. Lockfiles, osv-scanner en CI, actions fijadas por SHA. Aproximadamente una hora de configuración compra la mayor parte de la reducción de riesgo disponible.
• Integra mucho código generado por IA. Añada una puerta humana específica para la introducción de dependencias nuevas. Los LLM alucinan nombres de paquetes verosímiles, los ocupas registran esos nombres, y el slopsquatting ya es un vector de entrada real.

El hilo común: los controles en el camino de entrada son baratos y duraderos. El análisis a posteriori es caro y siempre llega tarde. La confianza en su árbol de dependencias debe ganarse con evidencia, nunca asumirse, el mismo principio que zero trust aplica en la capa de red.

Cómo puede ayudar Innovation T

Innovation T construye y opera esta maquinaria para equipos de Europa y el norte de África: generación de SBOM cableada en CI, despliegues de Dependency-Track que sobreviven al contacto con volúmenes reales de alertas, procedencia firmada y políticas de entrada afinadas para que los desarrolladores sigan rápidos mientras los atacantes se vuelven lentos. Ejecutamos el despliegue de 30 días anterior como un proyecto de alcance cerrado y le entregamos un pipeline que su equipo mantiene de verdad.

Si un cliente acaba de pedirle un SBOM, o sencillamente no puede responder "¿estamos ejecutando la versión afectada?" en menos de una hora, hablemos. Explore nuestros servicios o contáctenos para una evaluación de preparación de su cadena de suministro.