El 29 de julio de 2026, la CISA publicó los «Elementos mínimos para 2026» Software Bill of Materials (SBOM), que sustituyen a las directrices de referencia de la NTIA vigentes desde 2021, y que han sido elaboradas conjuntamente con la NSA, el FBI y 15 organismos internacionales de ciberseguridad.
Los «Elementos mínimos para una lista de materiales de software ( Software , SBOM) de 2026» (Bill of Materials (SBOM) ) son la especificación actualizada de la CISA sobre los datos que debe contener una SBOM, y el cambio más relevante es de carácter estructural, no numérico: los elementos de 2026 no prohíben las SBOM generadas a partir de manifiestos de código fuente, pero sí exigen a los autores que declaren cómo se ha generado la SBOM, que calculen el hash del artefacto ejecutable y que etiqueten cada campo que no hayan podido rellenar. Un SBOM basado únicamente en un manifiesto revela ahora sus propias lagunas en un formato legible por máquina.
MetaDefender Software Supply Chain es la plataforma de seguridad de la cadena de suministro de software de OPSWAT, diseñada para analizar artefactos, archivos binarios y capas de imágenes de contenedores —precisamente la categoría de datos que exigen ahora los nuevos requisitos relativos al hash, el contexto de generación y la cobertura—.
De un vistazo
- 17 campos de datos: 9 de metadatos de la SBOM y 8 de datos de componentes
- 6 prácticas y procesos
- 10 campos nuevos, 8 actualizaciones importantes, 1 eliminación (Control de acceso, integrado en Distribución y Entrega)
- Se aplica a todo el software, «incluido el software de código abierto, el software de inteligencia artificial y el SaaS».
- No se trata de nuevos requisitos, sino de una mejora en la forma en que las organizaciones generan y solicitan las SBOM
Cambios en las SBOM para 2026 que resultan más difíciles de cumplir para las SBOM basadas únicamente en el código fuente
1. El valor hash del componente requiere el artefacto ejecutable
Los campos «Valor hash del componente» y «Algoritmo hash del componente» especifican claramente qué es lo que se somete al proceso de hash: «el resultado generado al aplicar un algoritmo hash criptográfico a un artefacto de componente ejecutable». No se trata de la entrada del manifiesto ni de la cadena de versión declarada.
- Un analizador que lee los archivos package-lock.json, pom.xml o requirements.txt no modifica ningún artefacto ejecutable, por lo que ambos campos de hash devuelven «desconocido».
- Cuando exista una función hash, el algoritmo deberá utilizar los nombres textuales de las funciones hash de la IANA y estar aprobado por una autoridad como el NIST
- Los hash son los que permiten al destinatario confirmar que el componente descrito es el mismo que se ha enviado.
2. El contexto de la generación de la SBOM hace que el método forme parte del registro
El «contexto de generación del SBOM» es la novedad más discreta, pero la más significativa desde el punto de vista estructural: «la fase relativa del ciclo de vida del software y los datos disponibles en el momento en que el autor del SBOM lo generó». La CISA define tres valores —antes de la compilación, durante la compilación y después de la compilación— y vincula cada uno de ellos con la forma en que se elaboró el SBOM: un SBOM extraído del código fuente se corresponde con la fase más temprana, mientras que las herramientas de análisis binario lo sitúan en la más tardía.
- Los equipos de compras pueden especificar qué fase del ciclo de vida aceptarán, dando preferencia a las SBOM extraídas del artefacto compilado frente a las de nivel de código fuente.
- Las plataformas de gestión de vulnerabilidades pueden ponderar los resultados en función del contexto declarado.
- Se sigue permitiendo el uso de una SBOM derivada del código fuente, pero ya no puede presentarse como equivalente a una generada a partir del binario final.
3. La amplitud sustituye a la profundidad, sin un mínimo establecido
El elemento «Profundidad» de 2021 solo exigía dependencias de primer nivel; una definición que, según afirma ahora la CISA, «reflejaba las capacidades de las herramientas de SBOM en aquel momento, más que la profundidad de la información necesaria para tomar decisiones de seguridad fundamentadas». La cobertura es ahora más exigente: «todos los componentes que conforman el software de destino, incluidas las dependencias transitivas. No hay un nivel mínimo de profundidad».
La prueba es funcional. Un destinatario «debería poder concluir que una vulnerabilidad recién comunicada no le afecta si la SBOM no incluye el componente asociado a dicha vulnerabilidad». La ausencia se convierte en prueba, lo cual solo es válido cuando la cobertura es lo suficientemente completa. Es poco probable que el análisis del manifiesto por sí solo alcance ese nivel de exigencia en los siguientes casos:
- Código vinculado estáticamente y de terceros: no deja ninguna entrada en el manifiesto
- Proyectos en C y C++: ningún gestor de paquetes universal realiza un seguimiento de las DLL y los objetos compartidos que se incorporan durante la compilación.
- Código fuente copiado —que la CISA describe como «en la práctica, una dependencia que es más fácil de controlar si se trata como una bifurcación y una relación de dependencia»—
- Container capas de imágenes: paquetes instalados mediante comandos de capa en lugar de declarados en un manifiesto
Ahora es obligatorio declarar la información desconocida
- Los autores deben distinguir entre la información que desconocen y la información que se les ha ocultado deliberadamente.
- Se recomienda a los autores que establezcan un procedimiento para que los destinatarios puedan solicitar información sobre el contenido censurado relacionado con la seguridad.
- «Las organizaciones pueden considerar que una SBOM está incompleta si el autor de la misma omite datos esenciales sobre los componentes».
- La «tolerancia a los errores» se ha sustituido partiendo de la base de que los destinatarios «pueden esperar que los datos de la SBOM sean precisos»; los errores derivados de la «selección de herramientas inadecuadas» constituyen ahora un factor legítimo en la evaluación de riesgos del destinatario.
Modificaciones adicionales introducidas por la CISA en los elementos de la SBOM de 2026
Cambiar | Qué es | Por qué es importante |
Firma del autor de la SBOM (nuevo) | Una firma digital vinculada al autor de la SBOM | Permite al destinatario confirmar que la SBOM es auténtica y que no ha sido modificada tras su firma |
Licencia de componentes (nueva) | La licencia bajo la que se distribuye cada componente | Se plantean riesgos relacionados con los derechos de autor y el cumplimiento normativo; la CISA hace hincapié en los identificadores de licencia SPDX |
Datos procesables por máquina (antes «Soporte a la automatización») | Solo SPDX y CycloneDX | Se ha eliminado el SWID por no ser de uso generalizado; se reducen a dos los formatos aceptados |
Fabricante de componentes (antes: Nombre del proveedor) | Una organización con nombre por cada componente | Añade una opción alternativa explícita de «procedencia desconocida» cuando la fuente no está clara |
Frecuencia (actualizada) | Una nueva SBOM para cada versión, actualización y compilación que incorpore componentes modificados | Es difícil mantener ese ritmo manualmente, lo que lleva a los equipos a optar por la generación automatizada. |
Cómo subsanar las deficiencias tras la construcción
La actualización de 2026 refleja la valoración de la CISA de que las herramientas de SBOM han madurado lo suficiente como para exigir más, y la información que ahora espera se encuentra más allá de la compilación.
MetaDefender™ Software Supply Chain genera datos SBOM directamente a partir del artefacto compilado:
- Analiza artefactos, archivos binarios y capas de imágenes de contenedores, en lugar de limitarse únicamente a los archivos de dependencias
- Identifica los binarios de C, C++ y C# a través de metadatos de Portable Executable y la identificación basada en firmas
- Genera SBOM en CycloneDX y SPDX, y amplía los informes existentes para detectar componentes y CVE que se habían pasado por alto en análisis anteriores
- Realiza referencias cruzadas con GHSA, CVE y EUVD, y señala las licencias que no cumplen con los requisitos
- Se integra con los flujos de trabajo de CI/CD y los registros de artefactos, como JFrog Artifactory, de modo que la generación de la SBOM pueda realizarse en cada compilación
Para saber cómo MetaDefender ,Software ySupply Chain pueden ayudar a cumplir los requisitos de la SBOM a lo largo de todo el ciclo de vida del desarrollo:
Preguntas frecuentes
¿Qué ha cambiado en los elementos mínimos de la SBOM de la CISA 2026?
La actualización añade diez nuevos campos de datos, introduce ocho modificaciones importantes y elimina un elemento. El cambio estructural más significativo es la sustitución de «Profundidad» por «Cobertura», y los nuevos campos —entre los que se incluyen el «Valor hash del componente», el «Contexto de generación de la SBOM» y la «Firma del autor de la SBOM»— aumentan las expectativas sobre cómo se generan y verifican los datos de la SBOM.
¿Son obligatorios los elementos mínimos de la SBOM de la CISA 2026?
No. La CISA no establece ningún plazo de cumplimiento ni mecanismo de ejecución, y señala que el documento «no constituye un asesoramiento a efectos de cumplimiento, normativos o jurídicos». La fuerza práctica proviene de los requisitos de contratación pública y de las normativas que hacen referencia a las líneas de base de la SBOM, como la Ley de Ciberresiliencia de la UE.
¿Los elementos mínimos de la SBOM de la CISA 2026 requieren un análisis binario o posterior a la compilación?
No de forma explícita. Sin embargo, el «valor hash del componente» requiere acceso al artefacto ejecutable, el «contexto de generación del SBOM» exige que los autores declaren la fase del ciclo de vida, y los campos sin rellenar deben marcarse como «desconocidos». Por lo tanto, un SBOM que solo incluya el código fuente cumple con el formato al tiempo que documenta sus propias lagunas.
¿Se aplican los elementos mínimos de la CISA 2026 al software de IA y al SaaS?
Sí. El ámbito de aplicación abarca todo el software, incluido el de código abierto, la IA y el SaaS. La CISA señala que estas categorías pueden requerir elementos adicionales, pero no los define aquí, remitiéndose en su lugar a las directrices conjuntas del G7 sobre la SBOM para la IA publicadas en mayo de 2026.
¿Qué formatos de SBOM se aceptan en los elementos mínimos de la CISA 2026?
SPDX y CycloneDX, descritos como los dos formatos más utilizados para generar y utilizar SBOM. Se han eliminado las etiquetas SWID por no ser «un formato de datos SBOM ampliamente utilizado para el que existan múltiples herramientas». No deben utilizarse versiones obsoletas de ningún formato para software nuevo.
