Completitud de la SBOM

Una SBOM está completa cuando enumera cada componente que entró en el software que describe, en todos los niveles del árbol de dependencias, incluidos los componentes que ningún lockfile ni manifiesto enumera. La completitud de la SBOM es esa propiedad. Los 2026 Minimum Elements de la CISA piden a los autores de SBOM que indiquen explícitamente cuándo una información es desconocida, y señalan que los destinatarios pueden considerar incompleta una SBOM si se retienen datos esenciales de los componentes.

Completitud, validez y calidad son cosas distintas

Pregunta	Qué significa	Qué lo comprueba	Qué no puede decir
Válida	El archivo cumple el esquema de CycloneDX o SPDX	Un validador de esquemas	Si faltan componentes
Calidad de campos	Cada componente tiene nombre, versión, proveedor, identificador, licencia y hash	Un evaluador de calidad	Si faltan componentes
Completa	No falta nada de lo que entró en el software	Una comparación con lo que el build recibió realmente	Las entradas que la comparación no vio

El identificador de la segunda fila suele ser una package URL o un CPE. Un archivo puede superar perfectamente las dos primeras comprobaciones y aun así dejar fuera la mitad del software.

Por qué la completitud es difícil de medir a posteriori

Un escáner trabaja a partir de lockfiles, manifiestos o la salida terminada. No puede saber nada de un paquete que descargó un script post-install, de un crate compilado dentro de un binario ni de una capa de la imagen base que nunca se le mostró. Cada uno de ellos es una dependencia oculta.

Tome un servicio Node.js cuyo lockfile enumera 400 paquetes. Uno de ellos tiene un script postinstall que descarga un binario precompilado durante npm ci. Una SBOM generada a partir de package-lock.json es válida, cada componente tiene versión y package URL, y el binario no está. Ninguna puntuación de calidad lo señalará, porque nada en el archivo apunta a lo que falta.

Reconstruir más tarde tampoco resuelve la cuestión: salvo que el build sea un build reproducible, un segundo build puede recibir algo distinto del primero.

Cómo indicar la completitud con honestidad

• Indique el contexto de generación: si la SBOM se creó a partir del código fuente antes del build, se registró durante el build o se produjo analizando la salida después.
• Enumere las lagunas conocidas: partes del software que la herramienta no pudo ver, como código incorporado, binarios precompilados o componentes instalados fuera de un gestor de paquetes.
• Prefiera un estado con motivos a una puntuación. Un porcentaje de completitud necesita un total, y ese total es justo lo que nadie conoce. Una indicación como «incompleta: el job permitió tráfico no supervisado» permite actuar.

Buenas prácticas de SBOM trata de forma más amplia la práctica de indicar lo que una SBOM no pudo ver.

Estados de completitud en CRACI

CRACI asigna un estado de completitud a la SBOM de cada job, y los cachés también reciben uno. Los estados, tal como los define la documentación de CRACI:

• Complete: «CRACI observó evidencias completas del job, y cada caché restaurada estaba completa».
• Complete with connections: «Se cumplieron los requisitos, pero el job usó una o más conexiones de red personalizadas».
• Incomplete: «CRACI identificó una condición que podría dejar dependencias fuera de la SBOM».
• Unavailable: «CRACI no pudo terminar de evaluar las evidencias».
• Not recorded: «El job es anterior a la indicación de completitud».

CRACI puede indicarlo porque ve el tráfico de cada job hacia las fuentes de paquetes y, por tanto, sabe cuándo algo pudo haberle esquivado: tráfico que no supervisó, o una caché restaurada cuya propia SBOM estaba incompleta. Cuando un job está incompleto, muestra el motivo, por ejemplo «Unmonitored traffic was allowed». Vea generación de SBOM.

Estos estados se aplican a los builds que se ejecutan en runners de CRACI. Para una SBOM de un proveedor, o de un pipeline que no se ejecuta en CRACI, use las comparaciones y las reglas anteriores.