Generación de SBOM en todos los equipos de ingeniería: una política, todos los pipelines

Por qué los escáneres por equipo no suman un programa de SBOM

Apunte cinco herramientas al mismo producto y obtendrá cinco SBOM. Las diferencias son estructurales, no errores:

• Entradas distintas, leídas en momentos distintos. Una herramienta lee el lockfile, otra el árbol de dependencias instalado, otra la imagen de contenedor, otra el binario. Cada una ve una parte distinta del producto.
• Nombres distintos para lo mismo. Una identifica los componentes por package URL, otra por CPE, otra solo por nombre de archivo. Dos SBOM que describen la misma biblioteca no se pueden cruzar por una clave común.
• Profundidad distinta. Algunas listan solo las dependencias directas, otras el árbol transitivo completo y otras también las herramientas de build. Por qué los generadores discrepan sobre el mismo repositorio se muestra en generadores de SBOM de código abierto.
• Algunas herramientas responden a otra pregunta. Los escáneres de vulnerabilidades de infraestructura informan de lo que está instalado en los hosts en ejecución. Es útil para operaciones, y no es una descripción del producto que usted distribuye.

La consecuencia: no puede fusionar, deduplicar ni comparar SBOM entre productos, y no puede mostrar a un auditor un proceso, porque no lo hay.

Método	Entrada que lee	Cuándo	Qué se le escapa	Identificador típico
Escáner de lockfiles o manifiestos	Lockfiles y manifiestos del checkout	Antes o después del build	Todo lo que ningún lockfile lista: hooks de instalación, descargas de scripts de build, imágenes base	Package URL
Escáner de imágenes de contenedor	Bases de datos de paquetes y archivos de la imagen	Después del build	Herramientas usadas solo en el build, código compilado dentro, todo lo que no tiene registro de paquete	Package URL para paquetes del sistema operativo y de lenguaje
Escáner de binarios o firmware	Cadenas y firmas del binario	Después del build	Certeza: versiones y componentes se infieren	CPE o nombre inferido
Escáner de vulnerabilidades de hosts	Software instalado en servidores en ejecución	En operación	El producto tal como se entrega a los clientes	CPE o nombre de producto del fabricante
Registro durante el build	Lo que descargó el build de la release	Durante el build	Software que usted no compiló; lo que no pudo ver se marca como incompleto	Package URL

La política de SBOM: qué estandarizar

Estandarice la SBOM, no el escáner. La política fija el resultado y el proceso; cada pipeline la cumple con el mejor generador que pueda ejecutar. Cada fila de la tabla es algo que usted puede comprobar.

Requisito	La regla	Por qué	Cómo comprobarlo
Alcance	Cada release de producto que se entrega a un cliente, incluidos firmware e imágenes de contenedor. Herramientas internas, opcional.	Clientes y reguladores preguntan por lo que usted distribuye.	Cada release del registro de releases tiene una SBOM.
Formato y versión	Un formato principal, CycloneDX o SPDX, con una versión mínima. Acepte el otro si se lo piden.	Un formato significa un parser, un validador y un almacén. BSI TR-03183-2 pide CycloneDX 1.6 o posterior o SPDX 3.0.1 o posterior, un mínimo sensato para clientes de la UE.	La validación de esquema informa del formato y la versión.
Campos mínimos	Una package URL en cada componente que la tenga, un CPE solo donde no exista, proveedor, versión, licencia declarada, relaciones de dependencia, nombre y versión de la herramienta, marca de tiempo y contexto de generación.	Son los que usan la correlación, la revisión de licencias y las auditorías. Alinéelos con los elementos mínimos de qué es una SBOM.	Una comprobación de campos en el pipeline cuenta los valores que faltan.
Cuándo se genera	En el build de CI que produce la release, siempre. No en el momento de la auditoría, no en un portátil.	Recompilar no es el mismo build; vea SBOM en tiempo de build.	El ID de build de la SBOM coincide con el ID de build de la release.
Profundidad	El árbol transitivo completo, no solo el nivel superior.	El mínimo de la CRA son las dependencias de nivel superior; las vulnerabilidades y los clientes van más allá.	Existen relaciones de dependencia por debajo del primer nivel.
Dónde se almacena	Junto al artefacto de la release, recuperable por producto y versión.	Una SBOM que nadie encuentra cuando llega un aviso de seguridad no es evidencia.	Recupere la SBOM de una release al azar por producto y versión.
Conservación	Como mínimo el periodo de soporte del producto más la conservación de documentación que exija su normativa.	La CRA fija un periodo de conservación para la documentación técnica, y la SBOM forma parte de ella.	Compare el periodo de la política con la conservación de cada herramienta.
Validación	Cada SBOM se valida contra el esquema en el pipeline; una no válida hace fallar el build o el control de release.	Las SBOM no válidas fallan sin avisar en las herramientas del cliente.	El registro del control de release muestra un paso de validación.
Responsabilidad	El equipo de producto es responsable de la generación; seguridad de producto es responsable de la política, las reglas de validación y los informes de cobertura.	La generación necesita al responsable del pipeline; la coherencia necesita un único responsable de las reglas.	Cada pipeline tiene un responsable designado.
Excepciones	Un registro de excepciones nominales y con plazo: equipo, motivo, fecha de fin.	La política sobrevive a los equipos que aún no pueden cumplirla.	Ninguna excepción ha superado su fecha de fin.

La lista de comprobación de buenas prácticas de SBOM cubre las reglas para una sola SBOM; esta política es la capa superior. Cada equipo declara cómo cumple su pipeline la política, en un archivo junto al pipeline:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Genere en el build, no por equipo a posteriori

La generación durante el build es el estándar al que aspirar. Describe el build que se distribuyó, incluye dependencias ocultas que ningún lockfile lista, y un único mecanismo produce SBOM con la misma forma para todos los equipos de ese pipeline. La diferencia se explica mejor con una cocina: un escáner prueba la sopa y adivina la receta; un registro observa lo que entra en la cocina.

Un escáner sigue siendo la herramienta adecuada para imágenes que usted no compiló, para binarios de terceros y para productos heredados sin CI. Dígalo en la política y registre el contexto de generación, para que quien la lea sepa qué vio cada SBOM.

Situación	Método de generación	Contexto de generación que registrar
Release compilada en una CI que usted controla	Registre el build o ejecute un generador dentro del job de la release	"Registrado durante el build" o "tras la instalación, a partir de archivos"
Imagen de contenedor compilada en CI	Registre el build de la imagen; escanee el resultado para sus paquetes del sistema operativo si el registro no los cubre	ID de build y digest de la imagen
Imagen o appliance de terceros	Escáner de imágenes, más la SBOM del fabricante si existe	"Resultado escaneado, no compilado por nosotros"
Binario de un proveedor	Pida la SBOM del build del proveedor; análisis binario como comprobación	Proveedor, versión, cómo se obtuvo
Producto heredado sin pipeline	Escanee el artefacto distribuido; planifique un pipeline	"Resultado escaneado" y una excepción con fecha de fin

CI mixta: GitHub Actions, GitLab y Jenkins en una misma organización

La política es independiente de la CI por diseño: define el resultado, de modo que un pipeline de GitLab o Jenkins puede cumplirla con un paso de generador, y un pipeline de GitHub Actions puede usar el registro durante el build. Reglas para un paso de generador:

• Ejecútelo en el job de la release, después del paso de instalación, no en un job aparte que vuelva a instalar.
• Fije la versión del generador y fije las actions de CI a un commit, no a un tag. Por qué esto importa en particular para los escáneres se explica en generadores de SBOM de código abierto.
• Registre el contexto de generación como "tras la instalación, a partir de archivos", para que se sepa qué vio.
• Valide el resultado contra el mismo esquema que todos los demás pipelines.

Generadores de código abierto como Syft, Trivy y cdxgen pueden escribir CycloneDX y SPDX, así que la regla de formato no obliga a elegir una herramienta. Para compararlos, vea comparativa de herramientas SBOM.

CRACI admite hoy GitHub Actions; GitLab CI y Jenkins están en la hoja de ruta, sin fecha. La consecuencia para el despliegue: empiece el registro durante el build donde se use GitHub Actions, mantenga los pasos de generador en el resto y haga el seguimiento de ambos en el mismo informe de cobertura.

Cuando un cliente quiere una versión de formato concreta

Un cliente pide CycloneDX 1.6 y sus herramientas escriben 1.7. Ocurre porque su herramienta de ingesta o su propia política está fijada a una versión; el mínimo de BSI es 1.6, así que los clientes de la UE suelen citarla. Sus opciones:

1. Pregunte si se acepta la versión más reciente. A menudo sí.
2. Convierta con la CycloneDX CLI, valide después contra la versión de destino y compruebe qué se ha perdido: los campos que solo existen en la especificación más reciente se eliminan.
3. Para una petición de SPDX, la misma CLI convierte a y desde SPDX JSON 2.3. Su documentación advierte de que convertir entre SPDX y CycloneDX "puede provocar la pérdida de parte de la información".

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

El validador comprueba contra CycloneDX 1.7 salvo que indique --input-version. Regla de la política: conserve la SBOM original como registro. Una copia convertida es una entrega derivada; guarde la derivación (herramienta, versión, fecha) con ella. Más sobre cómo responder a estas peticiones en peticiones de SBOM de clientes, y sobre los dos formatos en CycloneDX vs SPDX.

Datos de licencias para el equipo legal

La misma SBOM puede servir al equipo legal si la política pide los campos adecuados. Legal necesita la licencia de cada componente, la diferencia entre una licencia declarada (lo que dice el paquete) y una concluida (lo que alguien verificó), las obligaciones copyleft y una lista de componentes sin licencia. CycloneDX 1.6 marca las licencias como declaradas o concluidas, y SPDX tiene campos separados para ambas.

• Exija identificadores o expresiones de licencia SPDX, como MIT o Apache-2.0 OR MIT.
• Marque NOASSERTION y las licencias que faltan para revisión. En SPDX, NOASSERTION significa que no se hizo ninguna determinación o que no se dio información; no es una licencia.
• Envíe las licencias copyleft a legal antes de la release, no después.

Una SBOM contiene licencias declaradas. Una revisión de cumplimiento de licencias, con licencias concluidas, avisos y obligaciones, es trabajo jurídico o tarea de una herramienta especializada; vea cumplimiento de licencias de código abierto.

Despliegue equipo a equipo

Fase	Responsable	Criterio de salida	Obstáculo típico
1. Inventario: productos, pipelines, sistemas de CI y generadores actuales, una fila por pipeline de release	Seguridad de producto	Cada producto distribuido tiene una fila	Nadie sabe qué pipeline compila una release
2. Publicar la política con el registro de excepciones	Seguridad de producto	Política aprobada y publicada	Debate sobre qué herramienta imponer (la política no impone ninguna)
3. Piloto con uno o dos equipos que tengan un motivo: una petición de un cliente, un plazo, un producto que la herramienta actual no puede manejar	Equipos piloto	Las releases piloto se distribuyen con SBOM conformes	Los equipos sin un motivo urgente lo dejan en segundo plano
4. Añadir controles de validación en los pipelines piloto	Equipos piloto	Una SBOM no válida hace fallar la release	Miedo a bloquear releases; empiece con una advertencia
5. Ampliar por sistema de CI; retirar un escáner por equipo solo cuando el sustituto cumpla la política	Equipos de producto	Objetivo de cobertura alcanzado por sistema de CI	Pipelines sin responsable
6. Informar de la cobertura cada mes	Seguridad de producto	El informe llega a la dirección cada mes	Métricas calculadas a mano

La hoja de cálculo de inventario de la fase 1 debería ser la última; cómo dejar las hojas de cálculo se explica en automatización de SBOM. Un producto basado en Yocto es un piloto habitual, porque a los escáneres de uso general les cuesta; vea por qué los escáneres de SBOM no ven los builds de Yocto.

Medir la cobertura

Las cifras que piden la dirección y los auditores, cada una definida como un cociente:

• Cobertura de releases: releases distribuidas con una SBOM conforme a la política ÷ releases distribuidas.
• Cobertura de productos: productos con al menos una SBOM conforme en el periodo de soporte actual ÷ productos con soporte.
• Tasa de validación superada: SBOM que superan la validación ÷ SBOM generadas.
• Cobertura de identificadores: componentes con una package URL (o un CPE) ÷ componentes.
• Cobertura de licencias: componentes con una licencia declarada ÷ componentes.
• Completitud: SBOM cuyo generador indica que están completas ÷ SBOM. Solo es posible donde la herramienta lo informa.
• Tiempo hasta la SBOM: tiempo desde la release hasta que la SBOM está disponible.

Un ejemplo de informe mensual (cifras ilustrativas):

Métrica	Pipelines de GitHub Actions	Pipelines de GitLab y Jenkins	Todos
Cobertura de releases	46 / 48	19 / 27	65 / 75
Tasa de validación superada	100%	92%	97%
Cobertura de identificadores	99%	88%	95%
Excepciones abiertas	1	4	5

Como evidencia para un regulador o un auditor, el conjunto es la política, el registro de excepciones, el informe de cobertura y algunas SBOM de muestra. Muestra un proceso, aplicado y medido. Para la parte de la CRA, vea la guía de la CRA.

Dónde encaja CRACI

Para los pipelines de GitHub Actions, CRACI es el runner: usted configura runs-on: craci y cada job obtiene una SBOM registrada sin paso de generador. Cada SBOM incluye un estado de completitud, las dependencias transitivas, una package URL por paquete y la licencia declarada de cada componente, y se exporta como CycloneDX o SPDX. Las reglas de política de licencias pueden bloquear un build, las SBOM monitorizadas se reevalúan de forma continua y el historial de builds muestra qué builds contenían una dependencia vulnerable. Eso da a esos equipos, por defecto, las filas de la política "generada en el build de la release", "identificador" y "licencia". Se pueden añadir SBOM de terceros, de modo que los componentes comprados se monitorizan junto a sus builds.

Vea generación de SBOM en CRACI y SBOM en GitHub Actions.

Cuándo CRACI no es la respuesta

• Equipos en GitLab CI o Jenkins: hoy no, está en la hoja de ruta. Use un paso de generador que cumpla la política.
• GitHub Enterprise Server: hoy no es compatible.
• Escaneo de infraestructura y hosts, es decir, lo que está instalado en los servidores y las configuraciones erróneas: es otra tarea; mantenga esas herramientas.
• Análisis de binarios o firmware de imágenes de proveedores que usted no compila: CRACI registra builds y no escanea binarios.
• Conservación prolongada: CRACI conserva los datos de build 180 días por defecto, con conservación personalizada en Enterprise. Si su política necesita las SBOM durante más tiempo, expórtelas a su propio almacén.

Generación de SBOM entre equipos: preguntas frecuentes

¿Cómo estandarizamos la generación de SBOM entre equipos que usan herramientas distintas?

Estandarice el resultado, no la herramienta. Redacte una política que fije el formato y la versión, los campos mínimos, cuándo se genera la SBOM, dónde se almacena, cuánto tiempo se conserva y quién la valida. Deje que cada pipeline la cumpla con el mejor generador que pueda ejecutar y mida la cobertura frente a la política.

¿Qué debe incluir una política de SBOM?

Alcance, formato y versión mínima, campos mínimos (package URL, proveedor, versión, licencia declarada, dependencias, herramienta, marca de tiempo, contexto de generación), generación en el build de la release, profundidad transitiva completa, almacenamiento con la release, conservación, validación en el pipeline, responsabilidad y un registro de excepciones con plazo.

¿Debe cada equipo ejecutar su propio escáner o deben salir las SBOM del build?

Del build, siempre que sea posible. Una SBOM en tiempo de build describe el build que se distribuyó y da a todos los equipos de ese pipeline SBOM con la misma forma. Mantenga los escáneres para lo que usted no compiló: imágenes de terceros, binarios de proveedores y productos heredados sin pipeline.

Un cliente quiere nuestra SBOM en una versión anterior de CycloneDX. ¿Qué hacemos?

Pregunte primero si se acepta la versión más reciente. Si no, convierta una copia con la CycloneDX CLI (cyclonedx convert con --output-version v1_6), valídela contra esa versión y compruebe qué campos se eliminaron. Conserve el original como registro y guarde cómo se derivó la copia.

¿Cómo hacemos llegar al equipo legal los datos de licencias de nuestras SBOM?

Exija en la política identificadores o expresiones de licencia SPDX, marque NOASSERTION y las licencias que faltan para revisión, y envíe las licencias copyleft a legal antes de la release. La SBOM contiene licencias declaradas; las licencias concluidas, los avisos y las obligaciones requieren una revisión de licencias.

¿Cómo medimos la cobertura de SBOM entre productos?

Como cocientes: releases distribuidas con una SBOM conforme, productos con soporte con una SBOM conforme, tasa de validación superada, componentes con una package URL, componentes con una licencia declarada, SBOM completas donde la herramienta lo informa, y tiempo desde la release hasta la SBOM. Informe de ellos cada mes por sistema de CI.

¿Qué evidencia necesitamos para demostrar a un auditor que la generación de SBOM es coherente?

La política, el registro de excepciones, el informe mensual de cobertura y algunas SBOM de muestra con su contexto de generación. Juntos muestran un proceso, aplicado a cada release y medido, que es lo que comprueba un auditor o un cliente.