SBOM y seguridad de la cadena de suministro de software

Un SBOM (Software Bill of Materials) es el inventario legible por máquina de todos los componentes que forman una aplicación: librerías, dependencias transitivas, licencias y versiones. Sin ese inventario, la seguridad de la cadena de suministro de software es un ejercicio a ciegas: cuando aparece una vulnerabilidad crítica en una dependencia, ¿cómo saber en cuántos de tus productos está presente si nunca has documentado lo que despliegas? El problema no es teórico. Según el DBIR 2025 de Verizon, la participación de terceros en brechas alcanzó el 30% del total, el doble que el año anterior, y el coste medio de una brecha se situó en 4,44 millones de dólares según el informe de IBM. Los ataques a la cadena de suministro de software permiten comprometer a muchas víctimas a través de un solo punto de entrada.

Desde una perspectiva de seguridad ofensiva, la cadena de suministro es un objetivo de altísimo rendimiento: comprometer una librería popular equivale a obtener acceso a miles de organizaciones que la integran sin auditarla. Este artículo explica qué es un SBOM, cómo se genera e integra en el pipeline, y cómo encaja con SLSA, la firma de artefactos y normativas como NIS2 y DORA.

Qué es un SBOM y por qué importa

Un SBOM responde a una pregunta aparentemente simple: ¿qué hay realmente dentro de este software? La respuesta rara vez es trivial. Una aplicación moderna en Node.js o Python puede arrastrar cientos de dependencias transitivas que el desarrollador nunca eligió de forma consciente. Cada una de ellas es superficie de ataque. Cada una puede introducir una vulnerabilidad conocida (CVE) o, peor, código malicioso deliberado.

El SBOM materializa ese árbol de dependencias en un formato estructurado y verificable. Con él puedes responder en minutos, y no en semanas, a preguntas críticas como "¿estamos afectados por esta CVE?" o "¿qué productos incluyen esta versión concreta de la librería comprometida?". Esa capacidad de respuesta es la diferencia entre contener un incidente en horas o descubrir semanas después que llevabas expuesto todo ese tiempo.

La cadena de suministro no se limita al código de terceros. Incluye las imágenes base de contenedores, los binarios compilados, los plugins del sistema de build y hasta las propias herramientas del pipeline. Cualquiera de esos eslabones puede ser el punto débil, como analizamos con más detalle en nuestra guía sobre ataques a la cadena de suministro de software.

Casos reales que cambiaron las reglas

Tres incidentes ilustran por qué la industria dejó de tratar el SBOM como un lujo.

SolarWinds (2020). Los atacantes comprometieron el proceso de build de la plataforma Orion e inyectaron una puerta trasera (SUNBURST) en actualizaciones firmadas legítimamente. Alrededor de 18.000 organizaciones recibieron la actualización troyanizada. La lección fue demoledora: la firma de un artefacto no garantiza nada si el proceso que lo genera está comprometido. Firmar código malicioso solo lo convierte en código malicioso firmado.

XZ Utils / CVE-2024-3094 (2024). Una puerta trasera con puntuación CVSS 10 se introdujo en la librería de compresión xz/liblzma. No afectó a Debian estable: los principales expuestos fueron Debian unstable y Fedora 40 beta/Rawhide. El backdoor buscaba comprometer la autenticación SSH y, de forma condicional, habilitar ejecución remota de código en sshd. Lo más inquietante fue el método: un atacante bajo el alias "Jia Tan" pasó casi dos años contribuyendo al proyecto de forma legítima hasta ganarse permisos de mantenedor, una operación de largo plazo minuciosamente planificada. Andrés Freund, ingeniero de Microsoft, lo investigó de forma deliberada tras observar un consumo de CPU anómalo, latencia elevada en SSH y errores de Valgrind.

Dependencias maliciosas en npm y PyPI. Los repositorios públicos reciben oleadas constantes de paquetes maliciosos mediante typosquatting (nombres casi idénticos a paquetes populares), dependency confusion y secuestro de cuentas de mantenedores. Un SBOM no evita por sí solo que instales uno de estos paquetes, pero sí permite detectar rápidamente su presencia cuando se publica el indicador de compromiso.

En nuestros ejercicios de red team comprobamos con frecuencia que las organizaciones no pueden decir con certeza qué versiones de qué librerías tienen en producción. Esa ceguera es precisamente lo que explota un atacante.

SBOM: formatos CycloneDX y SPDX

Existen dos estándares dominantes, y conviene entender sus fortalezas para elegir bien.

CycloneDX

Desarrollado bajo el paraguas de OWASP, CycloneDX nació con un enfoque explícito de seguridad. Además del inventario de componentes soporta VEX (Vulnerability Exploitability eXchange), que permite declarar si una vulnerabilidad conocida es realmente explotable en tu contexto o si el componente afectado no se invoca. También modela relaciones de servicios, dependencias y pedigrí (procedencia y modificaciones de un componente). Es el formato preferido cuando el objetivo primario es la gestión de riesgo y la respuesta a vulnerabilidades.

SPDX

SPDX (Software Package Data Exchange), estandarizado por la Linux Foundation y reconocido como norma ISO/IEC 5962, es especialmente fuerte en el cumplimiento de licencias, con un modelo granular para representar licenciamiento complejo. Es la elección natural cuando el foco está en la conformidad legal y la interoperabilidad a gran escala.

En la práctica, muchas herramientas generan ambos formatos. La recomendación pragmática: usa CycloneDX si tu prioridad es la respuesta a vulnerabilidades y SPDX si es el cumplimiento de licencias. Y no lo trates como una decisión excluyente, porque la conversión entre formatos es viable.

Cómo generar e integrar un SBOM en el pipeline

Un SBOM que nadie genera de forma automática ni consume es documentación muerta. El valor aparece cuando se produce en cada build y alimenta controles automáticos. Estos son los pasos clave.

1. Generación automática en el build

Herramientas como Syft (Anchore), Trivy o el propio soporte nativo de CycloneDX para Maven, npm o Gradle generan el SBOM a partir del árbol real de dependencias durante la compilación. El momento importa: un SBOM generado tras el build, sobre el artefacto final (imagen de contenedor o binario), refleja lo que realmente se despliega, no solo lo que declara el fichero de manifiesto.

# Generar SBOM de una imagen de contenedor con Syft (CycloneDX JSON)
syft registry.ejemplo.com/api:1.4.2 -o cyclonedx-json > sbom.json

# Escanear ese SBOM contra bases de vulnerabilidades con Grype
grype sbom:sbom.json --fail-on high

2. Análisis de composición (SCA) sobre el SBOM

El SBOM alimenta el análisis de composición de software (SCA), que lo coteja con bases de datos de vulnerabilidades como la NVD o el catálogo KEV de CISA. Aquí es donde el inventario se convierte en acción: puedes configurar el pipeline para que falle si aparece una vulnerabilidad crítica sin corregir. Esta lógica es complementaria al SAST y al DAST, como explicamos en el OWASP Top 10 2025.

3. Almacenamiento y consulta centralizada

Guardar el SBOM junto al artefacto (por ejemplo, como attestation adjunta en el registro OCI) permite que, ante una nueva CVE, consultes todos los SBOM históricos y sepas al instante qué versiones están afectadas. Plataformas como Dependency-Track de OWASP centralizan este inventario y monitorizan de forma continua.

4. Integración en el hardening del pipeline

La generación del SBOM es un control más dentro del endurecimiento del pipeline CI/CD. Debe ejecutarse en un entorno de build de confianza, con permisos mínimos y sin exposición de secretos, tal como detallamos en seguridad CI/CD y hardening de pipelines.

SLSA y firma de artefactos con Sigstore

El SBOM dice qué hay dentro del software. No dice de dónde viene ni si el proceso que lo construyó es fiable. Ahí entran SLSA y Sigstore.

SLSA: procedencia verificable

SLSA (Supply-chain Levels for Software Artifacts) es un marco de la Linux Foundation que define niveles de garantía sobre la integridad del proceso de construcción. Su versión 1.2, publicada en 2025, añadió principalmente el Source Track para razonar sobre la procedencia del código fuente. La idea central es generar una attestation firmada que documente cómo, dónde y a partir de qué se construyó cada artefacto. Así, un consumidor puede verificar que el binario salió de un pipeline concreto.

Conviene distinguir los niveles. SLSA Build L2 aporta procedencia firmada mediante una plataforma de build alojada, lo que eleva el listón frente a los patrones de ataque más comunes sobre GitHub Actions o GitLab CI. L3 refuerza el aislamiento entre builds y protege la procedencia frente a pasos de build no confiables. No obstante, L3 presupone una plataforma de build de confianza: no cubre por sí solo el compromiso de dicha plataforma, de modo que no constituye una garantía frente a un ataque al propio sistema de build del tipo SolarWinds. Para la mayoría de organizaciones, L2 es un objetivo realista a corto plazo y L3 la meta a la que aspirar en entornos críticos.

Sigstore: firma sin gestionar claves

Sigstore, proyecto de la Linux Foundation respaldado por Google y Red Hat, resuelve el mayor dolor de la firma tradicional: la gestión de claves privadas de larga duración. Ofrece firma keyless mediante certificados de corta duración ligados a identidades OIDC. Sus tres piezas encajan así:

• cosign: firma y verifica artefactos y contenedores.
• Fulcio: autoridad certificadora que emite certificados efímeros.
• Rekor: registro de transparencia inmutable que deja constancia pública de cada firma.

Combinado con la procedencia SLSA, Sigstore refuerza la trazabilidad desde el código fuente hasta el artefacto desplegado. La firma keyless reduce la exposición de claves privadas persistentes, uno de los problemas que la gestión clásica arrastra durante años. Conviene tener presente su límite: una cuenta OIDC o de CI comprometida todavía puede obtener un certificado y firmar, de modo que Sigstore no garantiza por sí solo que el software sea correcto ni sustituye a los controles de identidad. Esto conecta con la disciplina de gestionar secretos y credenciales de máquina, un asunto que tratamos en identidades no humanas y gestión de secretos.

SBOM, SSDLC y su relación con NIS2 y DORA

El SBOM no es un artefacto aislado, sino una pieza del ciclo de vida de desarrollo seguro (SSDLC). Integrarlo pronto, en la fase de build y no como auditoría posterior, es lo que lo hace efectivo. Un SBOM generado tarde documenta el problema; uno generado en cada build ayuda a prevenirlo.

En el plano normativo europeo, la presión regulatoria ha convertido estas prácticas en expectativa, cuando no en obligación explícita.

• Cyber Resilience Act (CRA). El reglamento europeo sobre resiliencia cibernética incorpora la exigencia de SBOM para productos con elementos digitales, con aplicación plena prevista hacia diciembre de 2027. Es, hasta la fecha, la norma europea que menciona el SBOM de forma más directa.

• NIS2. La directiva no nombra el SBOM de forma literal, pero exige resultados de gestión de riesgo (seguridad de la cadena de suministro, adquisición y desarrollo seguros, gestión de vulnerabilidades y de activos) que el SBOM es la vía natural de evidenciar. Si tu organización está sujeta a NIS2, mantener un inventario de componentes actualizado es una de las formas más eficientes de demostrar diligencia debida. Los detalles de aplicación en España los cubrimos en cómo cumplir NIS2 en España.

• DORA. En el sector financiero, DORA pone el foco en el riesgo de terceros TIC. El SBOM aporta la visibilidad sobre los componentes de esos proveedores que la norma implica. La delimitación entre ambos marcos la explicamos en DORA vs NIS2.

La conclusión desde una óptica ofensiva es directa: las organizaciones que no saben qué componen sus productos no pueden defenderlos ni demostrar cumplimiento. El SBOM convierte esa incertidumbre en un inventario accionable, y con SLSA y Sigstore encima, en una cadena de confianza verificable de extremo a extremo.

Preguntas frecuentes

¿Qué diferencia hay entre CycloneDX y SPDX?

CycloneDX, mantenido por OWASP, está orientado a la seguridad y la respuesta a vulnerabilidades (incluye VEX y modelado de riesgo). SPDX, estandarizado por la Linux Foundation e ISO, destaca en el cumplimiento de licencias. Muchas herramientas generan ambos, así que no es una elección excluyente: la prioridad de tu caso de uso (riesgo o licencias) determina cuál usar como principal.

¿Un SBOM previene los ataques a la cadena de suministro?

Por sí solo no los previene, pero es la base para responder a ellos. Reduce drásticamente el tiempo de respuesta ante una nueva vulnerabilidad al indicarte de inmediato qué productos incluyen el componente afectado. Combinado con SCA, firma de artefactos (Sigstore) y procedencia (SLSA), sí forma parte de una defensa efectiva contra estos ataques.

¿Es obligatorio el SBOM con NIS2?

NIS2 no menciona el SBOM de forma explícita, pero exige medidas de seguridad de la cadena de suministro, gestión de vulnerabilidades y de activos. El SBOM es la manera más eficiente de evidenciar esos requisitos. El Cyber Resilience Act sí incorpora la exigencia de SBOM de forma más directa para productos con elementos digitales.

¿En qué punto del pipeline debo generar el SBOM?

Idealmente tras el build, sobre el artefacto final (imagen de contenedor o binario), para que refleje lo que realmente se despliega y no solo lo declarado en los manifiestos. Debe generarse de forma automática en cada build, almacenarse junto al artefacto y alimentar controles de SCA que puedan bloquear despliegues con vulnerabilidades críticas.

Asegura tu cadena de suministro con Secra

En Secra evaluamos la seguridad de tu cadena de suministro de software desde la perspectiva del atacante: analizamos dependencias, procesos de build, firma de artefactos y la exposición real de tu pipeline. Si quieres saber qué llevas realmente en producción y cómo un adversario podría comprometerlo, contacta con nuestro equipo o conoce nuestro servicio de desarrollo seguro (SSDLC y DevSecOps).