Buenas prácticas de SBOM

Generar las SBOM

1. Genere en CI, para cada versión

Una SBOM hecha a mano queda obsoleta antes de que alguien la lea. Conviértala en un paso del pipeline que compila la versión, o utilice un runner que la genere sin paso alguno, para que ninguna versión se distribuya sin ella. Para GitHub Actions, consulte cómo generar una SBOM en GitHub Actions.

2. Describa el build que se distribuyó

Los builds no son reproducibles por defecto. Compilar dos veces el mismo commit no garantiza las mismas dependencias, porque las versiones se resuelven durante el build y los pasos pueden variar. Una SBOM de un portátil o de un escaneo posterior describe un build parecido, no el que usted distribuyó. Solo una SBOM del build de CI que generó la versión demuestra lo que contiene. Consulte SBOM generadas durante el build.

3. Cubra algo más que el lockfile

Un lockfile no es un registro de lo que se distribuyó. Los scripts de instalación descargan código, los scripts de build de Rust descargan archivos y los builds de contenedores incorporan una imagen base con sus propios paquetes del sistema operativo. Decida qué debe cubrir la SBOM y después compruébelo: busque en su SBOM un paquete de su imagen base y una herramienta de build.

4. Incluya las dependencias transitivas y sus relaciones

Las vulnerabilidades suelen estar por debajo de sus dependencias directas. Una lista plana muestra que un componente está ahí, pero no qué hay que actualizar. Conserve el grafo de dependencias en la SBOM, de modo que cada hallazgo venga acompañado del paquete que lo incorpora.

5. Declare lo que no pudo ver

Los 2026 Minimum Elements piden a los autores de SBOM que identifiquen de forma explícita la información desconocida. Una SBOM parcial que lo dice vale más que una SBOM parcial que parece terminada. Registre también la herramienta, su versión y el contexto de generación, para que quien la lea pueda juzgar lo que cubre el archivo.

Conservar las SBOM

6. Conserve una SBOM por versión, vinculada al artefacto

Cuando un cliente con una versión antigua pregunta si está expuesto, necesita la SBOM de esa versión, no la más reciente. Almacene cada SBOM con el build y el artefacto que describe, y decida cuánto tiempo conservarla en función de cuánto tiempo da soporte a esa versión. Los hashes de la SBOM ayudan a vincularla al artefacto exacto.

7. Elija un formato y un identificador, y manténgalos

Estandarice CycloneDX o SPDX, una versión del formato y las package URLs como identificadores. La mayor parte de los problemas al comparar SBOM se debe a que las herramientas nombran lo mismo de forma distinta. Valide cada archivo en el pipeline y pida el mismo formato a sus proveedores.

Usar las SBOM

8. Monitorice lo que distribuyó, no solo lo que está compilando

El momento de mayor valor de una SBOM es el día después de que se publique un aviso sobre software lanzado el año pasado. Un escaneo en una pull request no sirve de nada entonces. Reevalúe las SBOM almacenadas de las versiones con soporte frente a los nuevos datos de vulnerabilidades, de modo que cada aviso nuevo se convierta en una lista de versiones afectadas.

9. Asigne los hallazgos a un responsable y registre la decisión

Una SBOM con mil vulnerabilidades cotejadas es una lista, no un plan. Ordene los hallazgos con un método de priorización, envíe cada uno al equipo responsable de la corrección y registre por qué no actuó sobre el resto, por ejemplo en una declaración VEX.

10. Use la misma SBOM para clientes y auditores

Los clientes, los auditores y los reguladores hacen preguntas similares. Respóndalas a partir de la SBOM que usan sus propios equipos, en lugar de elaborar un documento aparte que se vaya desviando. Si comparte SBOM, decida quién puede verlas y cómo reciben las actualizaciones, y pida lo mismo a sus proveedores.

Errores habituales

Error	Por qué perjudica	En su lugar
Una SBOM por repositorio	No dice nada sobre ninguna versión concreta	Una por versión, vinculada al artefacto
Generarla solo al llegar la auditoría	Describe un build que nadie distribuyó	En cada versión, en CI
Dar la SBOM por terminada	Llegan nuevos avisos después del lanzamiento	Siga monitorizándola
Comparar solo el número de componentes	Más no es mejor si las entradas son erróneas	Compruebe paquetes concretos que sabe que están ahí

Cómo lo aborda CRACI

CRACI cubre las prácticas que dependen del build. Es un runner de GitHub Actions que registra cada paquete que descarga cada job, incluidas las dependencias ocultas que ningún lockfile enumera, en una SBOM en CycloneDX o SPDX con un estado de completitud. Conserva cada build anterior y su SBOM dentro del periodo de retención de su plan, reevalúa las SBOM monitorizadas a medida que aparecen nuevas vulnerabilidades y muestra qué builds contenían una dependencia vulnerable. Los equipos de seguridad hacen el triaje de los hallazgos y los envían a los equipos responsables de la corrección. Consulte gestión de SBOM para ver cómo se comparan los gestores, o las mejores herramientas de SBOM.

Buenas prácticas de SBOM: preguntas frecuentes

¿Cuándo debe generarse una SBOM?

Durante el build de CI que genera la versión, siempre. Una SBOM creada en ese momento describe lo que se distribuyó, mientras que una creada más tarde describe una recompilación o un escaneo.

¿Cuánto tiempo deben conservarse las SBOM?

Como mínimo, mientras dé soporte a la versión, más lo que exijan sus reguladores o contratos. Necesita la SBOM de una versión antigua para saber si una nueva vulnerabilidad afecta a sus usuarios.

¿Deben automatizarse las SBOM?

Sí. Una SBOM manual está desactualizada en la siguiente versión. Genere las SBOM en el pipeline, valídelas allí y almacénelas con el build.

¿Debe compartir su SBOM con los clientes?

Compártala cuando un cliente o un regulador la pida, en condiciones que le resulten aceptables. Una SBOM revela lo que usted utiliza, por lo que muchas empresas la comparten a petición en lugar de publicarla.

¿Cuál es la diferencia entre una SBOM y la gestión de SBOM?

Una SBOM es un archivo. La gestión de SBOM es el trabajo continuo de almacenar las SBOM por versión, monitorizarlas en busca de nuevas vulnerabilidades y ponerlas a disposición de quienes las necesitan.