El proveedor concluyó una entrega y envió junto con ella un archivo como bom.json o sbom.spdx.json.
La primera reacción suele ser positiva: finalmente existe una lista estructurada de los componentes utilizados en el software.
La segunda pregunta es más difícil:
¿Y ahora qué hacemos con esto?
Una SBOM no reduce el riesgo simplemente por existir.
Su valor aparece cuando la organización puede validar el documento, relacionarlo con el software recibido, enriquecer los datos y transformar el inventario en decisiones de seguridad, operación, soporte y respuesta.
Comienza por la identidad: ¿esta SBOM pertenece al software que recibí?
Antes de buscar CVEs, existe una pregunta más básica.
La SBOM debe corresponder exactamente al producto, versión y artefacto que se está evaluando.
Verifica, cuando estén disponibles:
- Nombre del producto;
- Versión;
- Proveedor;
- Fecha de generación;
- Identificadores de los componentes;
- Relaciones entre componentes;
- Hashes;
- Versión del formato;
- Herramienta o proceso de generación;
- Referencia al artefacto o release correspondiente;
- Información de procedencia;
- Mecanismo de firma o atestación, cuando esté disponible;
- Evidencias de integridad y autenticidad de la SBOM.
Si el proveedor entregó la versión 5.4.2 del producto, pero la SBOM representa la versión 5.3.9, el análisis puede ser técnicamente correcto, pero operacionalmente inútil.
Lo mismo ocurre con una SBOM generada a partir de un manifiesto que no refleja el artefacto final.
SPDX o CycloneDX no es la primera decisión
SPDX y CycloneDX son formatos ampliamente utilizados para representar composición e información relacionada.
SPDX es un estándar abierto internacional y su línea 3.x amplía el modelo para diferentes tipos de información de BOM. Por su parte, CycloneDX ofrece capacidades específicas para SBOM, VEX y otros tipos de inventario.
La elección del formato importa para la interoperabilidad, las herramientas y los detalles disponibles, pero el consumidor debería evitar convertir la discusión en:
¿Qué formato es mejor?
antes de responder:
¿El documento contiene los datos que necesitamos para tomar la decisión?
Una SBOM incompleta en un formato excelente sigue estando incompleta.
Verifica la profundidad de la composición
Uno de los primeros controles consiste en evaluar si el inventario representa solo componentes de primer nivel o también dependencias transitivas.
Considera:
Aplicación
└── biblioteca A
└── biblioteca B
└── biblioteca CSi la SBOM presenta solo la biblioteca A, una vulnerabilidad o un problema de soporte en la biblioteca C puede permanecer invisible.
El CRA europeo establece, en sus requisitos de gestión de vulnerabilidades, que los fabricantes identifiquen y documenten vulnerabilidades y componentes, incluso mediante una SBOM en un formato comúnmente utilizado y legible por máquina que cubra al menos las dependencias de primer nivel.
Este es un mínimo regulatorio específico del CRA, no necesariamente el nivel de detalle suficiente para todos los casos de riesgo.
Para la seguridad operacional, las dependencias transitivas suelen ser necesarias.
Una SBOM no es una lista de CVEs
Es importante separar composición de inteligencia.
La SBOM responde principalmente:
¿Qué existe en este software?
El análisis de vulnerabilidades responde:
¿Qué sabemos hoy sobre los riesgos conocidos de estos componentes?
Estos datos cambian a ritmos diferentes.
Una SBOM puede permanecer igual mientras mañana se publica una nueva vulnerabilidad.
Por eso, el modelo correcto no consiste en analizar el archivo una vez y archivarlo. Consiste en mantener la composición vinculada a fuentes actualizadas de:
- Vulnerabilidades;
- Malware;
- Licencias;
- EOL/soporte;
- Advisories del proveedor;
- Políticas internas.
- 01SBOM recibidaComposición declarada por el proveedor
- 02ValidaciónIdentidad, versión, formato y relaciones
- 03EnriquecimientoVulnerabilidades, licencias, EOL e inteligencia
- 04ContextoVEX, exposición y uso real
- 05PolíticaCriterios de aceptación y excepción
- 06DecisiónAceptar, corregir, bloquear o escalar
- 07MonitoreoReevaluar cuando surjan nuevos datos
El malware requiere una pregunta diferente
Una SBOM puede ayudar a localizar un componente conocido como malicioso, pero disponer de una lista de componentes no equivale a realizar una detección de malware.
Por eso, vulnerabilidades, malware, integridad, procedencia y confianza en el origen deben tratarse como señales complementarias. Una vulnerabilidad puede identificarse mediante un identificador conocido; un componente comprometido o malicioso requiere otras fuentes de inteligencia y mecanismos de análisis.
En la práctica, la pregunta deja de ser solo “¿este componente tiene una vulnerabilidad?” y pasa a ser “¿este componente es confiable, está íntegro, carece de vulnerabilidades conocidas y continúa siendo aceptable para nuestro contexto?”
Este punto se desarrolla con mayor profundidad en el artículo:
SCA identifica vulnerabilidades. Pero ¿qué ocurre con el malware?
La licencia y el soporte también forman parte de la decisión
La composición puede revelar componentes que:
- Utilizan licencias incompatibles con la política de la empresa;
- Poseen una licencia desconocida;
- Han llegado al fin de vida (EOL) o al fin de soporte (EOS/EOSL);
- Están abandonados;
- Dependen de versiones muy antiguas;
- No tienen un camino claro de actualización.
Una SBOM operacional no debería tratarse solo como una entrada para el escaneo de vulnerabilidades.
Puede apoyar decisiones de seguridad, aspectos legales/licenciamiento, arquitectura, continuidad, procurement y gestión de proveedores.
Dónde entra VEX
VEX — Vulnerability Exploitability eXchange — existe para representar el estado de una vulnerabilidad en el contexto de un producto.
Imagina que la SBOM identifica una biblioteca asociada a una CVE crítica.
Esto no significa automáticamente que la vulnerabilidad sea explotable en el producto final.
El componente puede no ejecutar el código vulnerable, estar configurado de manera que la condición no exista, contar con una mitigación específica o estar presente solo en una etapa que no llega al runtime.
Una declaración VEX puede registrar este contexto.
CycloneDX, por ejemplo, posee soporte específico para representar la explotabilidad mediante VEX.
Pero VEX no debe utilizarse como un botón de “ignorar vulnerabilidad”.
Una declaración de not_affected debe contar con suficiente justificación y contexto para respaldar la decisión, además de ser reevaluada cuando existan cambios relevantes en el producto, componente o condición de explotación.
El proveedor debería poder responder preguntas sobre la SBOM
Recibir el archivo no pone fin a la relación.
Un proceso maduro de adquisición puede establecer preguntas como:
- ¿Qué producto y versión representa la SBOM?
- ¿Cómo fue generada?
- ¿Cubre las dependencias transitivas?
- ¿Existe un vínculo con el artefacto entregado?
- ¿Cuál es la frecuencia de actualización?
- ¿Cómo comunica el proveedor las nuevas vulnerabilidades?
- ¿El proveedor publica VEX?
- ¿Cómo informa una versión corregida?
- ¿Cuál es el período de soporte de los componentes críticos?
- ¿Existe un canal de divulgación de vulnerabilidades?
- ¿Cómo se comunican los cambios de composición entre releases?
Estas respuestas pueden incorporarse al proceso de due diligence y gestión de proveedores.
La SBOM debe seguir siendo útil después de la compra
Un error común es concentrar todo el esfuerzo en la recepción e ingesta del software.
El día de la adquisición:
SBOM → análisis → aceptaciónDespués, el archivo queda almacenado y nadie vuelve a consultarlo.
El problema es que el riesgo cambia.
Una aplicación aprobada hoy puede verse afectada mañana por una nueva CVE, nueva evidencia de explotación, un paquete identificado como malicioso, EOL, un cambio de licencia, una modificación de criticidad o un advisory del proveedor.
Por eso, la relación debería ser continua:
- 01ProductoVersión y ownership conocidos
- 02SBOMComposición vinculada al producto
- 03InteligenciaDatos actualizados continuamente
- 04PolíticaCriterios de riesgo y excepción
- 05ResponsableDecisión y respuesta
El CRA está acelerando la adopción — pero la generación es solo el comienzo
En junio de 2026, ENISA publicó un informe sobre la adopción de SBOM.
La investigación señaló al Cyber Resilience Act como un acelerador de las iniciativas de SBOM y de su integración al SDLC.
El movimiento regulatorio ayuda a aumentar la disponibilidad y estandarización de estos documentos.
Pero la propia evolución de la comunidad ya muestra la siguiente etapa.
En agosto de 2026, OpenSSF anunció BOMHort como proyecto Sandbox, destacando el desafío operacional de gestionar, consultar y analizar grandes volúmenes de SBOMs a escala.
Este movimiento sugiere un cambio importante: el desafío está pasando de generar SBOM a operar SBOM a escala.
Un proceso simple para comenzar
No es necesario crear una plataforma compleja desde el primer día.
Una organización puede comenzar con cinco etapas.
1. Recibir
Definir formatos aceptados, canales y metadatos mínimos.
2. Validar
Confirmar producto, versión, estructura y calidad del inventario.
3. Enriquecer
Cruzar la composición con vulnerabilidades, malware, licencias, soporte y otras fuentes.
4. Decidir
Aplicar políticas y registrar aceptación, corrección, bloqueo o excepción.
5. Monitorear
Reevaluar los productos existentes a medida que surjan nuevos datos.
Checklist de consumo de SBOM
Antes de considerar una SBOM como “procesada”, verifica:
- El producto y la versión corresponden a la entrega;
- El formato es válido y procesable;
- Los componentes poseen identificadores útiles;
- Las relaciones entre dependencias están presentes;
- Se conoce la profundidad de las dependencias;
- La composición fue cruzada con inteligencia de vulnerabilidades;
- El malware fue considerado por separado;
- Las licencias fueron evaluadas;
- EOL/soporte fue evaluado;
- VEX posee justificación cuando se utiliza;
- Las excepciones tienen responsable y vigencia;
- Existe un mecanismo de actualización y monitoreo;
- El origen y la autenticidad de la SBOM fueron verificados, cuando corresponda;
- La SBOM posee un vínculo verificable con el artefacto o release analizado.
La prueba decisiva
Elige un software de terceros que ya esté en producción.
Toma la SBOM entregada por el proveedor e intenta responder:
Si mañana se publica una nueva vulnerabilidad crítica en una dependencia transitiva de este producto, ¿quién será notificado y cuánto tiempo tardaremos en saber si estamos expuestos?
Si la respuesta es “necesitamos abrir el archivo e investigar manualmente”, la SBOM existe.
Pero todavía no se ha convertido en gobernanza operacional.
Fuentes y referencias
- ENISA — SBOM Adoption State of Play 2026
- EUR-Lex — Cyber Resilience Act, Regulation (EU) 2024/2847
- Comissão Europeia — Cyber Resilience Act: Manufacturers
- SPDX — Specifications
- CycloneDX — Vulnerability Exploitability eXchange (VEX)
- OpenSSF — Improving Risk Management Decisions with SBOM Data
- OpenSSF — Introducing BOMHort
- Xmart — Cyber Resilience Act: ¿qué cambia para las empresas de software?
¿Tu organización recibe SBOMs, pero le cuesta convertirlas en decisiones?
Xmart apoya la arquitectura, gobernanza, análisis y operación de controles de Software Supply Chain y AppSec.
