Nuevas obligaciones para los SBOM: CISA impone firma digital y cobertura sin límites de dependencias

El 31 de julio de 2026, CISA, junto con 16 entidades gubernamentales de cuatro continentes, publicó la versión actualizada de la guía sobre los elementos mínimos para el Software Bill of Materials. El documento sustituye las directrices NTIA de 2021 e introduce diez nuevos campos obligatorios, el paso del concepto de “profundidad” al de “cobertura” y la introducción de la firma digital para certificar integridad y autenticidad. Al día siguiente, la agencia también difundió una guía separada sobre la seguridad del código abierto.

Los diez campos que rediseñan el inventario de software

La nueva guía añade diez elementos hasta ahora ausentes. Entre ellos, el más impactante es la firma digital del SBOM, diseñada para garantizar su integridad y autenticidad a lo largo de toda la cadena de suministro. Además, aparece la obligación de indicar el nombre y la versión de la herramienta utilizada para generar el inventario, junto con otros datos que hacen rastreable el origen de cada componente.

El borrador inicial, que databa de 2025, se refinó tras recibir comentarios de más de 90 organizaciones, entre ellas Google, Microsoft y AWS. El resultado es un conjunto de requisitos que, si bien formalizan prácticas ya extendidas —como señala Jeff Williams de OWASP y Contrast Security—, hacen más estricta la transparencia exigida a quienes suministran software al gobierno federal.

De la profundidad a la cobertura: adiós a los límites en las dependencias indirectas

El cambio estructural más relevante afecta a la gestión de las dependencias. Hasta ayer, el campo “depth” fijaba un nivel máximo de anidamiento que declarar. La nueva guía lo elimina e introduce el campo “coverage”: a partir de ahora, el SBOM debe incluir todas las dependencias transitivas, es decir, las dependencias de las dependencias, sin ningún techo de profundidad.

Este cambio obliga a los proveedores a un análisis recursivo completo de los componentes de terceros, reduciendo los puntos ciegos donde una vulnerabilidad podía esconderse en un paquete anidado más allá del límite anterior. La cobertura se convierte en un requisito absoluto, ya no parametrizable.

Qué significa para quienes suministran software al gobierno de EE. UU.

Las organizaciones que operan bajo requisitos de conformidad federal deberán adaptar sus procesos de generación de SBOM para cumplir tres condiciones inmediatas:

• incluir la firma digital;
• registrar la herramienta y la versión utilizadas para producir el inventario;
• extender el análisis a todos los niveles de dependencia, sin excepciones.

No son obligaciones revolucionarias, porque las herramientas basadas en SPDX y CycloneDX ya ofrecen buena parte de estas funcionalidades. Sin embargo, el endurecimiento formal eleva la apuesta para la gestión del riesgo de la cadena de suministro y para la conformidad con los marcos derivados de las directrices de CISA.

Las críticas: sin VEX y verificación, el SBOM sigue siendo una herramienta parcial

Según Williams, la guía no aborda dos puntos esenciales. En primer lugar, falta el VEX (Vulnerability Exploitability eXchange), es decir, un formato para contextualizar la explotabilidad real de las vulnerabilidades en un contexto de despliegue específico. En su ausencia, el SBOM sigue generando listas de CVE sin ayudar a establecer prioridades de parcheo.

El segundo punto crítico es la verificación de exactitud y cobertura. La guía no exige que el inventario declarado coincida con lo realmente distribuido o desplegado, ni contempla controles automáticos de coherencia. Esto limita la utilidad práctica del documento en las decisiones de seguridad diarias. A la espera de evoluciones, el experto recomienda verificaciones internas de completitud y correspondencia entre el SBOM y los artefactos reales.

Al día siguiente: una guía sobre la seguridad del código abierto

El 1 de agosto, CISA publicó una segunda guía, dedicada a las mejores prácticas para la seguridad del software de código abierto. No es una integración directa del nuevo SBOM, sino que se suma al marco general con el que la agencia está rediseñando los requisitos de transparencia y rigor en la cadena del software, extendiendo las indicaciones también al ecosistema de los componentes abiertos.