Software bill of materials (SBOM)

¿Qué es un SBOM?

Un SBOM (Software bill of materials) es un registro estructurado de los componentes de un producto, las relaciones entre ellos y los metadatos que identifican a cada uno sin ambigüedad. Responde una sola pregunta operativa: si se anuncia una falla en el componente X, ¿entregamos X, en qué versión y dónde?

Esa pregunta parece trivial hasta que una fecha límite obliga a responderla. Una aplicación moderna es en su mayoría código que escribió otra persona y que su equipo nunca revisó. Una estimación de la industria citada en nuestra página de análisis de rutas de llamada ubica el uso típico entre el 10 % y el 20 % del código importado, así que la mayor parte de lo que se trae nunca se ejecuta. El SBOM que usted genera es, por lo tanto, largo, mayormente inerte e imposible de retener en la cabeza de nadie.

Un SBOM solo vale la pena producirlo si algo más lo lee. Una lista de dependencias de código abierto guardada en un repositorio no cambia nada. Esa misma lista, cruzada contra una fuente de vulnerabilidades y actualizada en cada build, convierte una divulgación en una orden de trabajo. Esa actualización es la línea que separa un inventario vivo de un trámite de cumplimiento.

Lo que un SBOM no es

Hay cuatro cosas que se confunden con suficiente frecuencia como para separarlas.

La distinción que más caro les sale a los equipos es la de los dos primeros. El documento es la salida; el SCA es el motor. Comprar la salida sin el motor deja una foto que ya está equivocada en el siguiente commit.

Por qué los SBOM importan ahora

Tres incidentes convirtieron una casilla de compras en una herramienta de respuesta a incidentes e hicieron del inventario de componentes un problema de seguridad de la cadena de suministro de software. Cada uno expuso una falta distinta, y cada falta hoy corresponde a un campo del estándar vigente.

Log4Shell: cuando nadie podía responder "¿lo usamos?"

Cuando se divulgó Log4Shell (CVE-2021-44228) en diciembre de 2021, el parche estuvo disponible casi de inmediato. El cuello de botella no fue la remediación. Fue el descubrimiento. Log4j estaba cuatro y cinco niveles adentro de herramientas de build, agentes y servidores de aplicaciones que nadie había pensado como consumidores de logging en Java.

Las organizaciones con un SBOM al día lo consultaron y en minutos tenían la lista de objetivos. El resto pasó semanas haciendo grep en repositorios y escribiéndoles a proveedores. Por eso el elemento Coverage de 2026 dice que un SBOM debería listar cada componente del software evaluado, incluidas las dependencias transitivas, sin profundidad mínima. Un inventario que se detuviera en las dependencias directas habría pasado por alto Log4j en casi todos los lugares donde estaba corriendo.

SolarWinds: por qué los hashes pasaron a ser dos campos

El compromiso de SolarWinds en 2020 funcionó porque el código malicioso llegó a través de una actualización oficial y firmada. Nada en la lista de dependencias se veía mal. Lo que estaba mal es que el artefacto entregado ya no coincidía con lo que había producido el build.

Un SBOM generado en tiempo de compilación da esa línea base. Si el hash criptográfico de un componente no coincide con el valor registrado, el pipeline tiene fundamento para rechazar el build antes de distribuirlo. CISA ahora lista el valor del hash y el algoritmo del hash como dos campos separados, justamente para que la comparación se automatice en vez de hacerse a ojo. Ese par de campos es lo que convierte un SBOM de documento de divulgación en control.

El compromiso de npm en 2025: el SBOM como triaje

En septiembre de 2025, un correo de phishing contra la cuenta de un solo mantenedor terminó con malware publicado en 18 paquetes de JavaScript ampliamente usados, con unos 2.600 millones de descargas semanales combinadas, entre ellos debug, chalk y ansi-styles. La ventana de exposición fue de horas. Los únicos equipos que pudieron actuar dentro de ella fueron los que podían filtrar un SBOM existente por nombre de paquete y versión. Nuestro análisis del incidente describe ese mismo movimiento dentro de nuestra plataforma: abrir la tabla Packages y filtrar por nombre de componente.

El SBOM en Fluid Attacks

Generamos el SBOM como subproducto del escaneo, no como un ejercicio aparte. La documentación de Fluid Attacks enuncia el principio sin rodeos: "SCA tools can automatically generate a comprehensive SBOM, providing a detailed, standardized record of all components and their origins".

Qué inventariamos, y a partir de qué

Nuestro Software Composition Analysis lee lockfiles y manifiestos en 19 gestores de paquetes soportados, que cubren JavaScript, Python, Java, Kotlin, Ruby, Swift, PHP, Go, C#, Scala y Dart. La cobertura se mueve: una versión de septiembre de 2026 sumó analizadores determinísticos de lockfiles para Yarn, pnpm y Bun.

Cada entrada se contrasta después contra nuestro propio catálogo de vulnerabilidades, no contra un espejo del CVE. La debilidad 448 en nuestra base de datos, "Use of software with malware", cubre el caso en que "one or more dependencies used in the project contains code or components suspected of being compromised by malware or malicious behavior". Esa entrada enlaza los requisitos que un auditor va a pedir, que es justo lo que una fuente cruda no entrega.

Cómo se ve en la práctica

El inventario se asocia a un objetivo de evaluación, que nuestra documentación de la plataforma define así: "A package ToE represents a third-party component on which the application depends".

La exportación en sí son dos clics: "In Packages, click on Export SBOM and follow the prompts". El resultado queda "available in the CycloneDX and SPDX formats".

La sección Packages exporta el inventario en dos formatos estandarizados.

Reachability determinística, no probabilística

La mayor parte del valor está después de la exportación. Un SBOM dice que hay una versión con falla; no dice si ese código puede ejecutarse. Eso lo respondemos trazando rutas de llamada, no puntuando probabilidades. Nuestras comparaciones públicas muestran la diferencia frente a dos proveedores de SCA.

Fuente: comparaciones públicas de Fluid Attacks contra Snyk y Black Duck, construidas con la información oficial de producto de cada proveedor.

Un veredicto probabilístico le dice al desarrollador que un hallazgo probablemente no importa. Uno determinístico le dice que la función nunca se invoca desde sus puntos de entrada. Solo el segundo sobrevive a una conversación con un auditor. Desde octubre de 2026, ese veredicto es además el séptimo criterio en nuestra configuración de prioridad de la organización.

El límite con el que nos topamos: el inventario cubre la porción menor

Acá está la parte que casi ninguna página de proveedor incluye. En nuestro benchmark, el universo de 1.201 vulnerabilidades se repartió con el 80 % en el código propio, el 13 % en el backend, y el resto en dependencias y frontend. Todo lo que un SBOM alcanza a ver vive en ese último 7 %, y lo comparte con el frontend.

Los números de detección apuntan en la misma dirección. Sobre ese conjunto, la herramienta automatizada que identificó el mayor porcentaje de vulnerabilidades fue nuestro propio escáner, con 22,7 % de recall y 99 % de precisión; la mejor de terceros llegó a 21,6 % de recall con 72 % de precisión. Un pentester trabajando el mismo conjunto encontró 1.076 de las 1.201 vulnerabilidades: 89,6 % de recall con 100 % de precisión. Ningún inventario cierra esa brecha, porque las fallas que más importan suelen estar en lógica de negocio que nadie importó.

El mejor recall automatizado fue 22,7 %; el pentester alcanzó 89,6 %.

Esto es un argumento a favor de generar el documento, no en contra. Es un argumento en contra de confundirlo con un programa de seguridad. Los equipos que combinan inventario de componentes con pruebas manuales cubren las dos mitades; los que compran solo lo primero cubren la mitad que era más fácil de automatizar.

La práctica que decide el resto: regenerar y bloquear

Un documento generado una vez queda desactualizado en el siguiente merge. La práctica que hace la diferencia es regenerarlo en cada build y hacer cumplir una política contra el resultado. Nuestro reporte State of Attacks 2026, que cubre 1.119.396 vulnerabilidades reportadas entre el 1 de enero y el 31 de diciembre de 2025, encontró que los sistemas que usaron nuestro CI Gate llegaron a una tasa de remediación de 72,2 % frente a 58 % en los sistemas sin él. El inventario es la entrada; la compuerta es lo que le da consecuencias.

Nuestra guía para el sector financiero hace el mismo señalamiento: mantener un registro detallado de cada componente en uso y escanearlo de forma continua.

Más a fondo: nuestra página sobre reachability analysis explica cómo el trazado de rutas de llamada filtra una lista de componentes hasta dejar lo explotable.

Qué lleva un SBOM: los elementos mínimos de 2026

En julio de 2026, CISA publicó la versión final de Minimum Elements for a Software Bill of Materials, desarrollada con la NSA, el FBI y quince agencias de ciberseguridad internacionales. Reemplaza la línea base de la NTIA de 2021 y el borrador de consulta pública de agosto de 2025. Los datos requeridos casi se duplicaron y ahora se dividen en dos grupos.

Metadatos del SBOM

Los metadatos describen el documento en sí: quién lo produjo, con qué herramienta, en qué punto del ciclo de vida y en qué formato. Los campos nuevos son una firma del autor, una versión del documento, el nombre y la versión del formato de datos, el nombre y la versión de la herramienta, y un contexto de generación. Este último importa: un registro construido desde el código fuente en tiempo de compilación y otro construido escaneando un binario terminado describen cosas distintas, y ahora el consumidor tiene derecho a saber cuál recibió.

Datos de componentes

Los datos de componentes describen los ingredientes: productor del componente, nombre, versión, identificadores, valor del hash, algoritmo del hash, licencia y las relaciones de dependencia entre ellos. Cada componente debería llevar al menos un identificador de software común, un campo que también puede contener identificadores únicos, hashes de commit e identificadores intrínsecos.

Qué cambió frente a la línea base de 2021

La revisión también separa lo que es genuinamente desconocido de lo que el autor conoce y está reteniendo, lo que le permite al consumidor distinguir un vacío de datos de una decisión comercial. Si usted certificó un documento contra la lista de 2021, asuma que ya no califica.

Misma idea, distinto producto: ambos declaran qué hay adentro.

Formatos de SBOM tras la revisión de 2026

CISA nombra dos formatos de datos como los de uso amplio. Un tercero, SWID, quedó fuera de la lista de formatos de SBOM.

Las etiquetas SWID, estandarizadas como ISO/IEC 19770-2, siguen en uso para gestión de activos de TI. CISA las retiró de los formatos de SBOM nombrados en 2026 porque SWID no es de uso amplio y tiene muy pocas herramientas detrás. La guía sigue pidiéndoles a las organizaciones que acepten cualquier formato interoperable y procesable por máquina de uso amplio, así que SWID no está prohibido: simplemente dejó de ser uno de los dos que CISA señala.

Si está produciendo el SBOM para un pipeline de seguridad, el formato de OWASP está hecho para eso y lleva declaraciones de explotabilidad de forma nativa. Si su motor es el cumplimiento de licencias, el de la Linux Foundation carga un número ISO, que todavía pesa con algunos compradores. Emitir los dos cuesta casi nada, y nuestra plataforma entrega el SBOM en ambos.

Regulaciones que exigen un SBOM

El SBOM dejó de ser una recomendación hace varios años.

La Executive Order 14028 es la que cambió el comportamiento del mercado. Convirtió al SBOM en condición de compra federal, y la exigencia se propagó por cadenas de suministro sin ninguna exposición federal. El EU Cyber Resilience Act, que cubrimos cuando se adoptó, fue más lejos al atar multas y retiro del mercado al incumplimiento.

Note lo que ninguno pide. Le exigen nombrar sus componentes, no demostrar que esos componentes son sólidos. El CRA ni siquiera obliga a divulgarlo: su anexo II solo dice que si el fabricante decide compartir el documento con los usuarios, debe indicar dónde encontrarlo. Un SBOM que usted puede producir pero no respaldar satisface a un revisor y deja la exposición intacta, y por eso el cumplimiento y la seguridad de la cadena de suministro de software no son el mismo objetivo.

Cómo generar un SBOM con SCA

Generarlo es la parte fácil. Elegir un escáner que produzca algo confiable, no.

El SCA resuelve el grafo de dependencias a partir de lockfiles y manifiestos, contrasta cada componente contra datos de vulnerabilidades y emite el SBOM en un formato estándar. Como corre en cada commit, el documento se mantiene vigente sin que nadie lo mantenga a mano. Nuestro post sobre herramientas DevSecOps describe la mecánica: mientras el escaneo inventaría las dependencias de código abierto de su software, producir el SBOM es un trámite.

Cuatro criterios separan las implementaciones útiles de las que solo marcan la casilla:

• Cobertura de ecosistemas: un escáner que no puede leer su formato de lockfile va a subreportar en silencio. Revise la lista de gestores de paquetes contra su stack, no contra una página de marketing.

• Resolución del grafo completo: confirme que la herramienta recorre todos los niveles. El elemento Coverage de CISA lo pide, y un escáner que solo lee manifiestos de primer nivel no puede producir un SBOM conforme.

• Inteligencia de vulnerabilidades: una lista de componentes no es una lista de riesgos. Pregunte contra qué se hace el contraste y si el veredicto de explotabilidad es determinístico o inferido.

• Bloqueo en el pipeline: generar sin una compuerta de política produce un documento que nadie lee. Nuestra documentación de análisis de cadena de suministro cubre cómo el resultado se conecta con políticas que rompen el build.

La salida alimenta después todo lo demás: nuestros Static Application Security Testing (SAST) y Dynamic Application Security Testing (DAST) cubren el código que el SBOM no ve, y la gestión de vulnerabilidades basada en riesgo en una sola plataforma es donde los hallazgos se priorizan. Nuestros planes Essential y Advanced generan el documento; el plan Advanced suma pentesters a la mitad que la automatización no alcanza.

La debilidad 448 vincula una dependencia comprometida con los requisitos 155, 262 y 330.

Conclusiones

Un SBOM es un inventario, y un inventario sirve tanto como las preguntas que uno puede hacerle. Los elementos mínimos de 2026 subieron la vara de lo que cuenta como un SBOM válido: cada dependencia anidada, un identificador de software común por componente, un hash partido en valor y algoritmo, un autor firmado, y dos formatos de uso amplio en vez de tres.

Cumplir esa vara es el mínimo para vender software al gobierno federal de EE. UU. o al mercado europeo. Un SBOM no es una estrategia de seguridad. Nuestro benchmark ubica el 93 % de las vulnerabilidades reales fuera de la capa de dependencias que un SBOM describe, y el mejor recall automatizado en 22,7 % frente al 89,6 % de un pentester. Genere el SBOM, regenérelo en cada build, bloquee el pipeline con él, y después vaya a probar la parte que no alcanza. Los primeros tres pasos son una decisión de herramientas. El cuarto decide su exposición real.

Preguntas frecuentes

¿Es lo mismo un SBOM que el SCA?

No. El análisis de composición de software es el proceso; el SBOM es una de sus salidas. El escaneo resuelve el grafo de dependencias y contrasta los componentes contra datos de vulnerabilidades. Es el documento estandarizado que ese escaneo produce. Se puede tener uno sin correr el otro, pero un archivo generado una vez y nunca actualizado deja de reflejar su software en cuestión de días.

¿Un SBOM tiene que listar las dependencias transitivas?

Sí, según el elemento Coverage de CISA de 2026. La guía dice que un inventario debería incluir todos los componentes del software evaluado, incluidas las dependencias transitivas, y afirma sin rodeos que no hay profundidad mínima. Eso reemplaza la línea base de 2021, que solo cubría dependencias de primer nivel. El razonamiento viene de incidentes como Log4Shell, donde la librería vulnerable casi nunca era una dependencia directa.

¿Cada cuánto debe actualizarse un SBOM?

En cada build. Las dependencias cambian con cada merge, y un inventario desactualizado da una falsa tranquilidad. Regenerarlo tampoco basta por sí solo: en los datos de nuestro State of Attacks 2026, los sistemas con una compuerta de CI llegaron a 72,2 % de remediación frente a 58 % de los que no la tenían.

¿Un SBOM encuentra vulnerabilidades de día cero?

No, y no es su propósito. Dice qué tiene usted, no qué está mal con eso. Su valor aparece en el momento en que se divulga una falla: usted lo consulta, encuentra cada build afectado y empieza a remediar mientras otros todavía están buscando. El tiempo de descubrimiento es la variable que cambia.

¿Qué es VEX y cómo se relaciona con los SBOM?

VEX declara si una vulnerabilidad conocida es realmente explotable en un producto dado. Un SBOM puede mostrar que usted entrega una librería con falla; el documento complementario puede declarar que esa función nunca es alcanzable desde sus puntos de entrada. Juntos, reducen la cola de remediación a lo que de verdad necesita trabajo.

¿Fluid Attacks genera SBOM, y en qué formatos?

Sí, en CycloneDX y SPDX, desde la sección Packages de nuestra plataforma. Nuestro SCA resuelve dependencias en 19 gestores de paquetes, contrasta cada componente contra nuestro propio catálogo de debilidades y determina la explotabilidad de forma determinística en 14 lenguajes. Los planes Essential y Advanced incluyen la generación y la exportación.

Sepa qué entrega y hasta dónde llega

Nuestros escáneres inventarían sus dependencias en cada commit y nuestros pentesters prueban el código que ese inventario nunca describe. Prueba gratuita · Contáctanos