¿Un SBOM es lo mismo que una página de cumplimiento de licencias?

Un SBOM es un inventario de componentes legible por máquina, construido para herramientas de seguridad y cadena de suministro, no una divulgación de licencias. Los elementos mínimos de la NTIA lo definen como proveedor, nombre del componente, versión, identificadores únicos, relaciones de dependencia y autor, lo cual son datos de identidad para el cruce de vulnerabilidades, no texto de licencia revisado.

Las herramientas de seguridad cruzan los CVE con las identidades de los componentes. La documentación del Anexo I de la CRA espera listas de componentes en formatos habituales. Los equipos de respuesta a vulnerabilidades rastrean el radio de impacto a través de los gráficos de dependencias.

Los campos de licencia del SBOM son puntos de partida, no aprobaciones. Los identificadores SPDX en CycloneDX a menudo proceden de los metadatos del registro de npm, que con frecuencia son incorrectos, incompletos, o están marcados como NOASSERTION. Los equipos de AppSec rara vez adjuntan el texto completo de la licencia GPL o de un SDK propietario a una exportación de SBOM.

• Identidad del componente (nombre, versión, PURL, hash) para el cruce de vulnerabilidades.
• Metadatos de proveedor y autor para la trazabilidad de la cadena de suministro.
• Formato legible por máquina (CycloneDX, SPDX) para herramientas y documentación normativa.
• Entrada para la documentación de componentes de la CRA y los programas de seguridad de producto.
• Detección de deriva cuando CI genera un nuevo SBOM en cada build.
• No es: divulgación de licencias de terceros legible por humanos para revisión legal.
• No es: texto completo de la licencia, aviso o bloques de atribución por componente.
• No es: puertas de publicación que confirmen que una persona revisó cada obligación.

La divulgación de licencias aporta texto de licencia revisado y legible por humanos, atribución y avisos vinculados a una versión distribuida concreta, algo que un SBOM no aporta. Un SBOM responde a "qué componentes hay aquí" para las herramientas de seguridad; la divulgación responde a "qué estamos legalmente obligados a reproducir cuando distribuimos esto" para compras y legal.

La divulgación de licencias de terceros responde a las preguntas de compras y legal: qué software de open source y de terceros hay en este producto, bajo qué licencias, con qué aviso y atribución, a fecha de qué versión revisada.

En los equipos de ingeniería de varias personas, las dependencias cambian constantemente. Un ingeniero fusiona un parche; otro añade un SDK; los paquetes transitivos cambian. Un registro de divulgación solo funciona si se reimporta, se revisa de nuevo y se vuelve a publicar cuando cambia la base de código, tanto si lo alojas en una URL como si adjuntas una exportación a un cuestionario.

• Inventario revisado por cada producto distribuido, no metadatos en bruto del registro.
• Texto completo de la licencia de cada componente dentro del alcance, no solo el ID de SPDX.
• Atribución y aviso de derechos de autor donde lo exijan MIT, Apache, BSD, GPL.
• Filas de copyleft y licencias personalizadas bloqueadas hasta una revisión explícita.
• Alcance de producto claro: qué SKU o versión cubre el registro.
• Aprobación de publicación: alguien responsable antes de compartir externamente.
• Proceso de mantenimiento: se actualiza cuando cambian los lockfiles o SBOM.

Ten esta tabla a mano cuando un cuestionario pida tanto "SBOM" como "cumplimiento de licencias de open source". Se solapan en el inventario, pero no en el entregable.

No. Puedes generar archivos CycloneDX perfectos en cada versión y aun así fallar una revisión de compras que pide cumplimiento de licencias, porque un SBOM lista componentes pero no reproduce el texto de la licencia, los avisos y la atribución que exigen las obligaciones de distribución.

El comprador abre tu adjunto, ve nombres de componentes y cadenas de "MIT", y pregunta dónde está el texto de la licencia.

La CRA empuja a las organizaciones a documentar componentes, lo que acelera la adopción de SBOM. No sustituye décadas de expectativa de los compradores de que los proveedores mantengan la divulgación de licencias de terceros. La documentación de seguridad de producto de la UE y los apartados de licencias de las RFP empresariales son vías paralelas.

Los equipos de seguridad son responsables de la gravedad de las vulnerabilidades, el parcheo y la notificación de incidentes. Las obligaciones de licencia (aviso, atribución, condiciones de copyleft) necesitan un responsable que revise antes de compartir externamente. Ese responsable rara vez es la misma persona que fusiona los PR de Dependabot.

El modelo eficiente importa el mismo SBOM o lockfile en ambos pipelines. Seguridad consume el SBOM para los CVE y la documentación de la CRA. Cumplimiento importa el mismo archivo en una cola de revisión: cada componente necesita revisión, texto completo, aprobación, y luego publicación en un registro de divulgación.

Cuando el SBOM cambia en la siguiente versión, ambos equipos reaccionan. Seguridad vuelve a analizar en busca de vulnerabilidades. Cumplimiento vuelve a revisar las filas de licencia nuevas o modificadas. Una fuente de inventario, dos salidas. Ninguna salida sustituye a la otra.

• Importa CycloneDX, SPDX o lockfiles una vez por candidato de versión.
• Seguridad: análisis de vulnerabilidades, documentación de la CRA, trazabilidad de incidentes.
• Cumplimiento: coincidencia de licencia, adjunción del texto completo, escalado de copyleft, puerta de publicación.
• Publica el registro de divulgación a partir de la instantánea aprobada (página o exportación, según exija el comprador).
• Comprobación de deriva: señala los cambios del SBOM que carecen de nueva aprobación de cumplimiento.

Subir el JSON del SBOM a un portal de proveedores y llamarlo cumplimiento de licencias. Pegar los ID de SPDX en una hoja de cálculo sin texto. Asumir que un análisis de licencias de FOSSA o Snyk equivale a una divulgación revisada sin puertas de publicación.

Generar un PDF con herramientas de SBOM una vez y reutilizarlo en varias versiones mientras los ingenieros siguen fusionando dependencias. El mismo problema de instantánea obsoleta que cualquier exportación estática, sin importar el formato.