Qué es SBOM y para qué sirve: componentes, formatos y ejemplos

Una SBOM es el inventario de componentes de una aplicación

Una aplicación moderna rara vez se construye completamente desde cero. Incluso un programa aparentemente pequeño puede incorporar decenas o cientos de bibliotecas, paquetes, módulos, imágenes de contenedor y componentes de terceros. El problema aparece cuando nadie sabe con precisión qué se ha incluido, en qué versión y de dónde procede cada pieza.

Una SBOM, siglas de Software Bill of Materials, es un inventario estructurado de esos componentes. En español suele traducirse como lista de materiales de software. Su función se parece a la lista de ingredientes de un alimento o al despiece de una máquina: permite saber qué hay dentro del producto sin tener que investigar cada elemento desde cero.

La respuesta corta a qué es SBOM y para qué sirve sería, por tanto, la siguiente: es un documento legible por máquinas que identifica los componentes de un software y sus relaciones, y sirve para mejorar la visibilidad sobre dependencias, licencias, procedencia y posibles vulnerabilidades.

Una SBOM puede indicar, entre otros datos, que una aplicación utiliza una biblioteca determinada, su versión, el proveedor, un identificador estandarizado y la relación que mantiene con otros componentes. Eso permite responder con rapidez a una pregunta muy concreta: «¿Tenemos dentro de nuestros productos el componente afectado por esta vulnerabilidad?».

Conviene aclarar desde el principio que una SBOM no es un antivirus, un análisis de vulnerabilidades ni una garantía de seguridad. Es una fuente de información. Su utilidad depende de que sea completa, esté actualizada y se conecte con procesos capaces de interpretar los datos y actuar sobre ellos.

Por qué es tan difícil saber qué contiene el software

Cuando una persona empieza a programar, puede imaginar una aplicación como un conjunto de archivos escritos por su equipo. En la práctica, el código propio suele ser solo una parte del producto. Alrededor aparecen dependencias directas, dependencias transitivas, herramientas de compilación, componentes del sistema, servicios externos y paquetes descargados desde repositorios públicos o privados.

Una dependencia directa es la que el proyecto solicita expresamente. Por ejemplo, una aplicación puede declarar una biblioteca para procesar documentos JSON. Una dependencia transitiva es la que llega a través de otra: la biblioteca anterior necesita un segundo paquete y ese paquete, a su vez, depende de un tercero.

El equipo de desarrollo quizá recuerde la dependencia principal, pero no necesariamente toda la cadena. Además, los componentes cambian con el tiempo. Se actualizan versiones, se sustituyen paquetes, se modifican imágenes base y se generan compilaciones diferentes para desarrollo, pruebas y producción.

Esta complejidad encaja con una idea básica de los fundamentos del desarrollo de software: una aplicación no es únicamente el código que vemos en el editor, sino un sistema formado por múltiples elementos relacionados. La SBOM intenta convertir parte de esa complejidad en un inventario consultable.

Para qué sirve una SBOM en la práctica

El valor real de una SBOM aparece cuando se utiliza para tomar decisiones. Guardar un archivo y olvidarlo en una carpeta aporta poco. Integrarlo en el ciclo de desarrollo, la gestión de riesgos y la respuesta ante incidentes resulta mucho más útil.

Localizar componentes afectados por una vulnerabilidad

Supongamos que se publica una vulnerabilidad crítica en una biblioteca muy extendida. Sin inventario, cada equipo tendrá que revisar repositorios, manifiestos, imágenes y servidores para averiguar dónde se utiliza. En una organización con muchos productos, esa investigación puede consumir horas o días.

Con SBOM actualizadas es posible buscar el componente y su versión en todos los productos inventariados. La organización puede identificar qué aplicaciones requieren revisión, priorizar las expuestas y descartar las que no incorporan el paquete afectado.

Esto no significa que cualquier coincidencia confirme que una aplicación sea vulnerable. El componente puede estar presente pero no utilizar la función afectada, no ser accesible durante la ejecución o incorporar una corrección aplicada por el proveedor. La SBOM ayuda a encontrar candidatos; el análisis posterior determina el riesgo real.

Entender las dependencias directas y transitivas

Una de las aportaciones más importantes de una SBOM es hacer visibles componentes que el equipo no añadió de manera consciente. Si una dependencia directa incorpora otras cinco, esas relaciones pueden representarse en el documento.

Conocerlas facilita analizar qué ocurrirá al sustituir o actualizar una biblioteca. También ayuda a detectar paquetes abandonados, duplicados o presentes en varias versiones dentro del mismo producto.

Revisar licencias y obligaciones

Los componentes de código abierto no carecen de condiciones de uso. Cada proyecto puede distribuirse con una licencia diferente, y algunas obligan a conservar avisos, facilitar código fuente en determinadas circunstancias o cumplir otras condiciones.

Una SBOM puede registrar licencias declaradas o detectadas, lo que facilita su revisión por parte de los equipos técnicos y legales. Sin embargo, el dato debe verificarse: una herramienta puede no identificar bien una licencia, encontrar varias expresiones incompatibles o limitarse a reproducir la información declarada por el paquete.

Evaluar software adquirido a terceros

Una organización también puede solicitar una SBOM al proveedor de una aplicación. El objetivo no es recibir una lista interminable por cumplir un requisito, sino disponer de información para evaluar la cadena de suministro, reaccionar ante vulnerabilidades y conocer los componentes incorporados.

Antes de aceptar el documento conviene acordar su formato, alcance, frecuencia de actualización y mecanismo de entrega. Una SBOM correspondiente a una versión antigua del producto no representa necesariamente el software instalado.

Mejorar la respuesta ante incidentes

Durante un incidente, el tiempo dedicado a averiguar qué hay instalado retrasa las decisiones. Un inventario centralizado permite relacionar productos, versiones y componentes, aunque después sea necesario confirmar la información sobre los sistemas afectados.

La SBOM encaja así dentro de una estrategia más amplia de seguridad informática. No sustituye a la gestión de activos, los registros, la monitorización, las actualizaciones o las copias de seguridad, pero aporta visibilidad sobre una parte especialmente opaca: la composición interna del software.

Qué componentes y datos contiene una SBOM

No todas las SBOM incluyen exactamente los mismos campos. El contenido depende del formato, la herramienta, el tipo de producto y el nivel de profundidad alcanzado. Aun así, hay una serie de datos especialmente habituales.

Nombre y versión del componente

El nombre permite reconocer la biblioteca, paquete o módulo; la versión diferencia una edición de otra. Registrar únicamente el nombre tiene poco valor para la gestión de vulnerabilidades, porque una incidencia puede afectar a unas versiones y no a otras.

La versión también puede resultar ambigua. Algunos proveedores emplean sufijos propios, compilaciones modificadas o números que no coinciden con el proyecto original. Por eso suelen añadirse identificadores más precisos.

Proveedor, autor u organización responsable

Este campo señala quién suministra o mantiene el componente cuando esa información está disponible. No debe confundirse necesariamente con la persona o sistema que genera la SBOM.

Identificar el origen ayuda a distinguir paquetes con nombres similares y a seguir avisos publicados por el proveedor correcto.

Identificadores estandarizados

Los identificadores permiten relacionar componentes procedentes de herramientas diferentes. Entre los más conocidos se encuentran Package URL o purl, que describe paquetes de ecosistemas como npm, Maven, PyPI o NuGet, y CPE, utilizado en determinados catálogos y sistemas de gestión de vulnerabilidades.

Una identificación incorrecta puede producir falsos positivos o dejar vulnerabilidades sin detectar. Conviene conservar varios datos —nombre, versión, proveedor e identificadores— en lugar de confiar en una única cadena de texto.

Relaciones entre dependencias

Una SBOM útil no se limita a una lista plana. También puede describir que la aplicación depende de una biblioteca y que esta incorpora otros paquetes. Ese grafo de relaciones ayuda a entender cómo ha entrado cada elemento en el producto.

Las relaciones son esenciales cuando se intenta actualizar una dependencia transitiva. El equipo necesita saber qué paquete principal la introduce y si puede corregirla actualizando, sustituyendo o configurando otra pieza.

Hashes o huellas criptográficas

Algunos formatos permiten registrar el hash de un archivo o componente. Un hash funciona como una huella calculada a partir del contenido y puede ayudar a identificar artefactos concretos.

Es importante no atribuirle más garantías de las que ofrece. Como se explica al comprobar SHA-256 en Windows, una coincidencia demuestra que dos contenidos producen la misma huella esperada, pero no acredita por sí sola que el archivo sea legítimo o seguro. La confianza depende también de quién proporciona el valor de referencia y por qué canal.

Licencias

La SBOM puede indicar la licencia declarada por el proyecto, la licencia detectada en sus archivos o ambas. Esta distinción importa porque la información publicada en un manifiesto puede no coincidir con todos los archivos incluidos en el paquete.

Marca temporal y autoría del documento

Registrar cuándo y cómo se generó la SBOM ayuda a valorar su vigencia. También conviene identificar la herramienta, proceso u organización responsable de crearla.

Una SBOM sin relación clara con una versión, compilación o artefacto concreto pierde trazabilidad. El documento debería poder asociarse con aquello que describe.

Ejemplo sencillo de una SBOM

Imaginemos una aplicación web ficticia llamada PortalClientes. Utiliza un framework, una biblioteca de registro y un controlador para la base de datos. La biblioteca de registro incorpora además otro paquete de forma transitiva.

Una representación conceptual y simplificada podría contener:

• Aplicación: PortalClientes, versión 2.4.0.
• Componente: framework-web, versión 6.1.
• Componente: biblioteca-registro, versión 3.2.
• Componente: utilidad-codificacion, versión 1.8.
• Componente: controlador-base-datos, versión 5.0.
• Relación: PortalClientes depende de framework-web.
• Relación: PortalClientes depende de biblioteca-registro.
• Relación: biblioteca-registro depende de utilidad-codificacion.

Si mañana aparece una vulnerabilidad en utilidad-codificacion 1.8, el equipo puede descubrir que está presente aunque nunca la añadiera directamente. Después tendrá que comprobar si la vulnerabilidad afecta al contexto real, qué paquete la incorpora y qué actualización resuelve el problema.

Este ejemplo es deliberadamente sencillo. Una aplicación empresarial puede generar una SBOM con miles de componentes y relaciones. Por eso se emplean formatos estructurados y herramientas automáticas, no documentos escritos a mano.

CycloneDX y SPDX: los dos formatos más conocidos

Una SBOM necesita un formato común para poder intercambiarse entre herramientas, proveedores y clientes. Dos de los estándares más extendidos son CycloneDX y SPDX.

Ambos permiten representar componentes y relaciones, pero nacieron con enfoques y modelos diferentes. No tiene sentido declarar uno como ganador para todos los casos. La elección depende de las herramientas utilizadas, los requisitos del destinatario y los procesos que consumirán la información.

Aspecto	CycloneDX	SPDX
Enfoque habitual	Seguridad de la cadena de suministro y gestión de riesgos	Identificación de componentes, procedencia y licencias
Representación	Dispone de formatos estructurados como JSON y XML	Dispone de distintas serializaciones y modelos estructurados
Uso práctico	Frecuente en herramientas de seguridad y pipelines de desarrollo	Frecuente en inventarios, cumplimiento y ecosistemas de código abierto
Elección	Debe basarse en compatibilidad, requisitos y capacidad de automatización

Qué es CycloneDX

CycloneDX es un estándar orientado a describir componentes y dependencias dentro de la cadena de suministro de software. Su ecosistema contempla no solo inventarios, sino también información complementaria relacionada con vulnerabilidades, servicios y otros elementos del producto.

Resulta habitual encontrarlo en herramientas que generan SBOM desde repositorios, paquetes, imágenes de contenedor o procesos de integración continua. Su estructura permite que otra herramienta consuma el documento sin depender de una tabla diseñada para lectura manual.

Un fragmento conceptual abreviado podría parecerse a este:

{
  "bomFormat": "CycloneDX",
  "components": [
    {
      "type": "library",
      "name": "biblioteca-ejemplo",
      "version": "1.2.3",
      "purl": "pkg:ecosistema/biblioteca-ejemplo@1.2.3"
    }
  ]
}

El fragmento solo ilustra la idea; no representa una SBOM completa ni sustituye la validación frente al esquema oficial correspondiente.

Qué es SPDX

SPDX, impulsado dentro del ecosistema de la Linux Foundation, es un estándar abierto para comunicar información sobre componentes, licencias, derechos de autor y relaciones. También cuenta con reconocimiento como estándar internacional.

Su utilidad histórica en la identificación de licencias no impide utilizarlo como formato SBOM. Puede representar paquetes, archivos, fragmentos y relaciones, dependiendo del modelo y del nivel de detalle elegido.

Una representación conceptual puede expresar que un documento describe un paquete, indicar su versión, asociar una licencia y establecer relaciones con otros elementos. Igual que en CycloneDX, la implementación real debe seguir la especificación oficial y validarse.

¿Es mejor CycloneDX o SPDX?

La respuesta práctica es: el formato que puedan generar, validar y consumir correctamente todas las partes. Si un cliente exige SPDX, entregar CycloneDX puede crear trabajo adicional aunque técnicamente contenga información parecida. Si la plataforma de seguridad trabaja de forma nativa con CycloneDX, ese formato puede simplificar la automatización interna.

Antes de decidir conviene responder a estas preguntas:

• ¿Qué formatos admite la herramienta de generación?
• ¿Qué formato solicita el cliente, auditor o proveedor?
• ¿Puede validarse automáticamente el documento?
• ¿Se conservarán relaciones, licencias e identificadores durante una conversión?
• ¿Qué sistema almacenará y consultará las SBOM?
• ¿Existe un procedimiento para actualizar el inventario con cada compilación?

Convertir entre formatos puede ser posible, pero no siempre preserva todos los campos y matices. La equivalencia debe comprobarse, no darse por supuesta.

Cómo se genera una SBOM

Una SBOM se puede generar en diferentes momentos del ciclo de vida. Cada enfoque observa una parte distinta del producto, por lo que los resultados pueden variar.

Generación desde manifiestos y archivos de bloqueo

Los gestores de paquetes suelen utilizar manifiestos para declarar dependencias y archivos de bloqueo para fijar las versiones resueltas. Analizar estos archivos es rápido y encaja bien en proyectos donde las dependencias están correctamente declaradas.

El inconveniente es que el manifiesto puede no reflejar exactamente el artefacto final. Puede incluir dependencias de desarrollo que no llegan a producción, omitir archivos incorporados manualmente o no capturar componentes introducidos en fases posteriores.

Generación durante la compilación

Integrar la generación en el proceso de construcción permite asociar la SBOM con una compilación concreta. El pipeline puede crear el artefacto, producir el inventario, validarlo y conservar ambos juntos.

Este enfoque mejora la trazabilidad y reduce la posibilidad de que alguien olvide generar el documento. Además, combina bien con el control de versiones y las prácticas de mantenimiento del código, porque los cambios en dependencias quedan vinculados a revisiones y compilaciones identificables.

Análisis del artefacto final

Otra opción consiste en inspeccionar el paquete, binario, directorio desplegable o imagen de contenedor terminada. Este método puede descubrir componentes que no aparecen claramente en los manifiestos.

También tiene limitaciones. Los componentes compilados, modificados, minimizados o empaquetados de forma poco convencional pueden resultar difíciles de identificar. El análisis puede inferir una versión incorrecta o no reconocer una biblioteca.

Inspección del entorno en ejecución

Analizar el sistema desplegado permite observar ciertos componentes presentes durante la ejecución. Puede ser útil cuando existen plugins, paquetes instalados dinámicamente o diferencias entre el artefacto original y el entorno final.

Sin embargo, una inspección puntual no garantiza que se detecten todas las rutas de carga ni todos los elementos utilizados en otro momento. Tampoco debería sustituir al inventario generado durante la construcción.

Combinar varias fuentes

En proyectos importantes, una estrategia sólida puede combinar información del código fuente, el gestor de paquetes, el pipeline, el artefacto final y el entorno desplegado. Las discrepancias entre fuentes también aportan información: si el manifiesto declara un paquete que no aparece en producción, o el artefacto contiene otro no declarado, merece la pena investigarlo.

La experiencia en ingeniería de software y mantenimiento enseña que la automatización funciona mejor cuando forma parte del proceso normal y no depende de una tarea manual al final. Por eso, una SBOM debería generarse dentro del pipeline siempre que sea viable, identificarse con la versión construida y someterse a controles igual que otros artefactos del proyecto.

Proceso recomendado para implantar SBOM

1. Definir el alcance. Decide qué aplicaciones, imágenes, paquetes o dispositivos necesitan inventario y qué se considera un componente.
2. Seleccionar el formato. Elige CycloneDX, SPDX o ambos según los requisitos de intercambio y las herramientas disponibles.
3. Elegir el punto de generación. Prioriza una fase reproducible del pipeline y complementa el resultado con análisis del artefacto si es necesario.
4. Validar la estructura. Comprueba que el documento cumple el esquema oficial y que los campos obligatorios están presentes.
5. Evaluar la calidad. Revisa identificadores, versiones, relaciones, licencias y cobertura, no solo que el archivo pueda abrirse.
6. Vincular la SBOM al producto. Relaciona cada documento con una versión, compilación, imagen o hash concreto.
7. Almacenar y controlar el acceso. Centraliza los inventarios, conserva el historial y decide quién puede consultarlos.
8. Conectar con vulnerabilidades. Compara los componentes con fuentes fiables de avisos y aplica criterios de contexto y prioridad.
9. Regenerar ante cambios. Una actualización de dependencias o una nueva compilación debe producir una SBOM nueva.
10. Probar el procedimiento. Simula la aparición de una vulnerabilidad y mide cuánto se tarda en localizar productos potencialmente afectados.

La última prueba es especialmente útil. Una SBOM puede ser formalmente válida y, aun así, no permitir responder con rapidez porque falta un identificador, no está claro qué versión describe o nadie sabe dónde consultarla.

Cómo relacionar una SBOM con las vulnerabilidades

El flujo más básico consiste en extraer los identificadores y versiones de la SBOM, compararlos con una base de datos de vulnerabilidades y generar coincidencias. A partir de ahí empieza el trabajo realmente importante.

Una coincidencia puede ser:

• Verdadera y explotable: el componente y la versión están afectados, y la función vulnerable es accesible.
• Verdadera pero no explotable en ese contexto: el componente está presente, pero la configuración o el uso impide alcanzar el código afectado.
• Corregida por el proveedor: la versión conserva un identificador parecido, pero incorpora un parche específico.
• Un falso positivo: la herramienta ha relacionado mal el paquete con el aviso.
• Un resultado incierto: faltan versión, proveedor o identificadores suficientes.

Para comunicar si una vulnerabilidad afecta realmente a un producto puede utilizarse información VEX, siglas de Vulnerability Exploitability eXchange. VEX complementa la SBOM: el inventario indica qué componentes hay y la declaración VEX aporta contexto sobre el estado de vulnerabilidades concretas.

Esta distinción evita dos errores opuestos: ignorar una amenaza real porque hay demasiadas alertas o asumir que toda coincidencia exige la misma urgencia. La prioridad debe considerar exposición, explotabilidad, impacto, disponibilidad de corrección y criticidad del sistema.

Limitaciones de una SBOM

La SBOM es una herramienta valiosa precisamente cuando se entienden sus límites. Presentarla como una solución automática a la seguridad de la cadena de suministro genera una falsa sensación de control.

Puede estar incompleta

La herramienta de generación quizá no detecte componentes añadidos manualmente, código copiado, bibliotecas enlazadas de forma estática, plugins descargados después o dependencias incorporadas durante el despliegue.

Puede quedarse obsoleta

Una SBOM describe un estado concreto. Si se actualiza la aplicación y el documento no se regenera, deja de representar el producto actual. La fecha por sí sola tampoco basta: debe existir una relación inequívoca con la versión o compilación.

No demuestra que el software sea seguro

Una aplicación puede tener una SBOM impecable y contener vulnerabilidades en su código propio, errores de configuración, credenciales expuestas o fallos de autorización. El inventario de componentes no sustituye a las pruebas de software, al análisis de código ni a las revisiones de seguridad.

No confirma automáticamente la explotabilidad

La presencia de una versión asociada a una vulnerabilidad es una señal para investigar. No demuestra por sí misma que el fallo pueda explotarse en esa aplicación concreta.

La calidad de los identificadores importa

Los nombres ambiguos, las versiones vacías y los identificadores incorrectos dificultan la correlación. Una SBOM con mil componentes mal identificados puede ser menos útil que otra más pequeña pero precisa.

Puede revelar información sensible

El inventario puede facilitar detalles sobre tecnologías, versiones y estructura interna. Eso no significa que deba mantenerse siempre en secreto, pero sí que su distribución necesita una política. No todos los documentos tienen que publicarse sin restricciones.

No cubre toda la cadena de suministro

La SBOM describe componentes, pero no garantiza que el compilador sea legítimo, que el pipeline no haya sido manipulado, que las claves de firma estén protegidas o que el repositorio original sea confiable. Debe combinarse con controles de integridad, procedencia, firma, revisión y protección del proceso de construcción.

Cómo evaluar si una SBOM es de calidad

No basta con preguntar si existe. Conviene comprobar si sirve para responder a incidentes y tomar decisiones. Una revisión básica puede utilizar los siguientes criterios:

• Cobertura: incluye dependencias directas y transitivas relevantes.
• Precisión: nombres, versiones y proveedores coinciden con los artefactos reales.
• Identificación: utiliza purl, CPE u otros identificadores cuando corresponde.
• Relaciones: permite conocer qué componente introduce cada dependencia.
• Trazabilidad: está vinculada con una compilación o versión concreta.
• Actualización: se regenera de manera automatizada ante cambios.
• Validez técnica: cumple el esquema del formato utilizado.
• Capacidad de consumo: las herramientas internas pueden importarla y consultarla.
• Utilidad operativa: el equipo sabe qué hacer cuando aparece una coincidencia con una vulnerabilidad.

Una buena prueba consiste en elegir aleatoriamente varios componentes del artefacto y comprobar si aparecen con la versión correcta. También puede recorrerse una dependencia transitiva desde la aplicación hasta el paquete final para verificar que las relaciones están representadas.

SBOM no es lo mismo que SCA, inventario de activos o VEX

Estos conceptos suelen aparecer juntos, pero cumplen funciones distintas:

• SBOM: describe la composición de un producto de software.
• SCA: el análisis de composición de software utiliza herramientas para identificar componentes, licencias y vulnerabilidades, y puede generar o consumir una SBOM.
• Inventario de activos: registra sistemas, dispositivos, aplicaciones y responsables dentro de una organización.
• VEX: comunica el estado y la posible explotabilidad de vulnerabilidades en un producto.
• Escáner de vulnerabilidades: busca problemas conocidos mediante diferentes técnicas y fuentes.

Lo más útil es conectarlos. El inventario de activos indica dónde está desplegado un producto; su SBOM revela qué componentes contiene; el análisis de vulnerabilidades encuentra coincidencias; y VEX añade contexto sobre si el problema afecta realmente al producto.

Una forma razonable de empezar

Una organización no necesita inventariar todo su software el primer día. Puede comenzar con una aplicación importante, generar la SBOM durante la compilación, validarla y realizar un ejercicio de búsqueda de vulnerabilidades. Esa prueba permitirá descubrir problemas de identificación, almacenamiento y responsabilidades sin desplegar todavía un sistema complejo.

Después puede ampliarse el proceso a imágenes de contenedor, aplicaciones adquiridas y productos entregados a clientes. El objetivo no debería ser acumular archivos, sino reducir el tiempo necesario para responder preguntas sobre la composición del software.

Desde una perspectiva de ingeniería y docencia, la idea más importante es sencilla: no se puede gestionar bien aquello que no se conoce. Una SBOM aporta estructura a ese conocimiento, pero solo se convierte en una medida de seguridad cuando permanece actualizada, se contrasta con el producto real y desencadena acciones concretas.

Conclusión

Entender qué es SBOM y para qué sirve implica ir más allá de una lista de bibliotecas. Una SBOM es un inventario estructurado que puede incluir componentes, versiones, proveedores, licencias, identificadores, hashes y relaciones de dependencia.

CycloneDX y SPDX permiten intercambiar esa información mediante estándares reconocidos. La generación puede realizarse desde manifiestos, durante la compilación, sobre el artefacto final o mediante una combinación de fuentes. Integrarla en el pipeline suele ofrecer la mejor trazabilidad.

Su principal ventaja es acelerar la localización de componentes afectados, mejorar la revisión de dependencias y apoyar la gestión de licencias y proveedores. Su principal límite es igual de importante: saber que un componente está presente no demuestra que sea vulnerable ni que el producto sea seguro.

La SBOM funciona mejor como parte de un sistema formado por inventario de activos, análisis de composición, gestión de vulnerabilidades, VEX, pruebas y mantenimiento continuo. Tratada de ese modo, deja de ser un documento administrativo y se convierte en una herramienta práctica para comprender y proteger el software.

Preguntas frecuentes sobre SBOM

¿Una SBOM es obligatoria?

Depende del sector, el contrato, el cliente y la normativa aplicable. Aunque no exista una obligación general para cualquier proyecto, cada vez más procesos de compra y seguridad solicitan información estructurada sobre los componentes del software.

¿Una SBOM detecta vulnerabilidades?

No por sí sola. Identifica componentes y versiones. Otra herramienta debe comparar esos datos con fuentes de vulnerabilidades y el equipo debe comprobar si la coincidencia afecta realmente al producto.

¿Hay que publicar la SBOM?

No necesariamente. Puede entregarse a clientes concretos, compartirse bajo condiciones acordadas o mantenerse para uso interno. La decisión debe equilibrar transparencia, requisitos contractuales y exposición de información técnica.

¿Debe generarse una SBOM para cada versión?

Sí, siempre que cambie la composición del producto. Lo recomendable es vincular cada SBOM con una compilación, artefacto o versión concreta y regenerarla automáticamente.

¿CycloneDX y SPDX son compatibles?

Representan muchos conceptos parecidos y existen herramientas de conversión, pero no debe suponerse una equivalencia perfecta. Conviene validar que la conversión conserva componentes, relaciones, licencias e identificadores.

¿Una SBOM incluye el código desarrollado por la propia empresa?

Puede representar el producto principal y sus componentes internos, aunque el nivel de detalle depende del alcance definido. Normalmente no contiene el código fuente: contiene metadatos sobre los elementos que forman el software.