SBOM

Un SBOM se genera durante la compilación, que es cuando de verdad se conoce el conjunto de dependencias resuelto, y se publica en uno de los formatos establecidos, principalmente SPDX o CycloneDX. Cada componente lleva un identificador, una versión, un proveedor y su relación con los demás, para que quien lo consume pueda recorrer el grafo en vez de leer una lista plana.

El motivo de que esto se convirtiera en un requisito de compra y no en una elegancia de ingeniería es normativo. El Cyber Resilience Act europeo impone a los fabricantes de productos con elementos digitales la obligación de identificar y documentar los componentes que entregan, y los pliegos del sector público lo piden cada vez más por su nombre. Verifica las obligaciones exactas y las fechas aplicables contra el texto publicado antes de citarlas en un documento.

Generarlo desde el sitio equivocado. Un SBOM producido desde un fichero de manifiesto lista lo que los desarrolladores pidieron; un SBOM producido desde la compilación lista lo que de verdad se resolvió, incluidos los componentes transitivos que son la mayor parte del grafo y la mayor parte del riesgo. Los dos difieren, y el segundo es el que merece la pena tener.

Que se quede viejo es el siguiente problema. Un SBOM describe una compilación. Si se genera una vez para un pliego y no se vuelve a generar, describe un software que ya no es el que se entrega, y eso es peor que no tener ninguno porque se le da crédito. Tiene que ser un artefacto de todas las compilaciones, guardado con la entrega.

Y después la limitación honesta: es un inventario, no una evaluación. Te dice que un componente está, no si la función vulnerable es alcanzable, ni si el código se modificó después de compilar, ni si el componente estaba comprometido aguas arriba. La alcanzabilidad es trabajo del software composition analysis, y la integridad de la propia compilación es trabajo de la firma y de la procedencia, que es lo que ataca un ataque a la cadena de suministro.

En una diligencia debida técnica, que exista un SBOM al día es una señal fuerte de madurez de ingeniería, y su ausencia es un hallazgo por derecho propio, porque significa que la empresa analizada no puede contestar a la pregunta de los componentes durante un incidente. Comprobamos que se genere en cada compilación, que cubra las dependencias transitivas y que alguien lo consuma, porque un artefacto que nadie lee es un gesto de cumplimiento. Esto forma parte de cómo revisamos la composición del software en una diligencia debida.