Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Los elementos mínimos de la CISA para 2026 sustituyeron a los criterios de referencia de la Administración Nacional de Telecomunicaciones e Información (NTIA) de 2021 el 29 de julio de 2026 y establecieron 17 campos de datos.
- La Oficina de Gestión y Presupuesto (OMB) derogó en enero de 2026 los memorandos federales sobre la certificación de seguridad del software, dejando las solicitudes de SBOM a discreción de cada organismo.
- Los requisitos de la CRA en materia de SBOM entrarán en vigor el 11 de diciembre de 2027 y establecen las dependencias de nivel superior como cobertura mínima.
- Un componente puede figurar correctamente en una SBOM y, aun así, ser malicioso, haber sido manipulado o haber quedado sin solución.
Los requisitos relativos a las SBOM están cambiando. La Oficina de Gestión y Presupuesto (OMB) derogó sus memorandos de certificación federal en enero de 2026; la FDA volvió a publicar sus directrices sobre ciberseguridad de los dispositivos médicos en febrero; la CISA sustituyó en julio la referencia de 2021 para los datos de las SBOM, y la Ley de Ciberresiliencia (CRA) de la UE comenzará a exigir las SBOM a los fabricantes a partir de diciembre de 2027. Siempre que se exija una SBOM, lo que se entrega es una lista de los componentes que contiene el software.
Esa lista es útil. La lista de ingredientes que aparece en el envase de un alimento indica que el producto contiene cacahuetes, lo cual es importante si eres alérgico. Comprobar si la fábrica estaba limpia o si el proveedor es quien dice ser requiere una inspección, lo cual es una tarea aparte.
Una SBOM funciona de la misma manera. El hecho de elaborar una no modifica tu exposición, ya que cualquier componente vulnerable, manipulado o abandonado permanece en tu software una vez creada la lista. Y ninguna de esas cuatro normas se limita a la lista. El requisito federal situó la SBOM dentro de un conjunto más amplio de prácticas de desarrollo seguro. El propio documento de la CISA afirma que la SBOM es información que aún requiere análisis, y la FDA y la CRA van más allá al asociarla con la obligación de evaluar los componentes que incluye y de aplicarles parches.
Requisitos de la SBOM a partir de octubre de 2026
En estos momentos, hay cuatro conjuntos de normas que son los más importantes. En la tabla se ofrece un resumen, y en los apartados siguientes se detallan.
| Fuente | Qué se pide | Situación a fecha de 7 de octubre de 2026 |
|---|---|---|
| Contratación pública federal (Orden Ejecutiva 14028 y OMB M-26-05) | Entrega de la SBOM a los compradores, a discreción de la agencia de compras | La Orden Ejecutiva 14028 sigue vigente. Las notas de certificación de la OMB quedaron derogadas el 23 de enero de 2026. |
| Elementos mínimos de la CISA 2026 | Un conjunto básico de campos de datos de la SBOM | Publicado el 29 de julio de 2026. Sustituye a la referencia de la NTIA de 2021. |
| Artículo 524B de la FDA | Inclusión de una SBOM en las solicitudes previas a la comercialización de dispositivos cibernéticos | En vigor para las solicitudes presentadas a partir del 29 de marzo de 2023. Directrices reeditadas el 3 de febrero de 2026. |
| Ley de ciberresiliencia de la UE | Una SBOM que incluya, como mínimo, las dependencias de nivel superior | La obligación relativa a la lista de materiales de seguridad (SBOM) entrará en vigor el 11 de diciembre de 2027. Las obligaciones de presentación de informes comenzaron el 11 de septiembre de 2026. |
Lo que queda del requisito federal sobre la lista de materiales de seguridad (SBOM)
La Orden Ejecutiva 14028, firmada en mayo de 2021, marcó el inicio del requisito federal relativo a la SBOM. El apartado 4(e)(vii) exigía que el NIST elaborara directrices para facilitar a los compradores una SBOM de cada producto, ya fuera directamente o a través de un sitio web público. La orden no ha sido revocada, pero se ha retirado la mayor parte del marco normativo que la rodeaba. Una orden ejecutiva de junio de 2025 (OE 14306) eliminó las disposiciones sobre certificación que la OE 14144, firmada en enero de 2025, había añadido, incluida la validación centralizada por parte de la CISA de las certificaciones de los proveedores. Posteriormente, el 23 de enero de 2026, el memorándum M-26-05 de la OMB derogó los memorandos M-22-18 y M-23-16, que servían de base al Formulario de Certificación de Desarrollo Seguro de Software.
Las agencias pueden seguir utilizando el formulario e incluir la entrega de la SBOM en las condiciones del contrato, pero la política general del Gobierno ya no exige ninguna de las dos cosas. Si vendes software a un comprador federal, la obligación de presentar una SBOM depende ahora de la política de la propia agencia y del contrato en cuestión.
La referencia de la CISA para 2026 en materia de datos de SBOM
El 29 de julio de 2026, la CISA, la NSA, el FBI y 15 organizaciones internacionales asociadas publicaron los «Elementos mínimos para una lista de materiales de software (SBOM) de 2026». Este documento sustituye al de 2021 de la Administración Nacional de Telecomunicaciones e Información (NTIA), elaborado a raíz de la Orden Ejecutiva 14028, y aumenta el número mínimo de campos de datos de 7 a 17. Entre los nuevos campos se incluyen la firma del autor de la SBOM, un valor hash y un algoritmo hash para cada componente, las licencias de los componentes, el nombre y la versión de la herramienta de generación, y un contexto de generación que indique en qué fase del ciclo de vida se generó la SBOM, por ejemplo, antes o después de la compilación.
Hay otros dos cambios que revisten importancia en la práctica. La cobertura debe incluir ahora las dependencias transitivas sin profundidad mínima, mientras que la versión de 2021 solo exigía las dependencias de nivel superior. Además, cada componente debe contar con al menos un identificador procesable por máquina, como un Package-URL.
El documento señala que sus elementos no establecen nuevos requisitos, sino que se limitan a perfeccionar la forma en que las organizaciones generan y solicitan las SBOM. Asimismo, deja fuera de los elementos mínimos la confirmación de la exactitud, la cobertura y la exhaustividad de una SBOM, ya que estas requieren medidas de calidad distintas de las que ofrece una firma.
Nota: La propia conclusión de la CISA es que una SBOM, por sí sola, es información sobre los componentes de software, y que el análisis es lo que convierte esa información en conocimientos.
Requisitos de la FDA relativos a la SBOM en virtud del artículo 524B
El Congreso añadió el artículo 524B a la Ley FD&C mediante la Ley de Reforma Integral de Alimentos y Medicamentos, en diciembre de 2022. Se aplica a las solicitudes previas a la comercialización presentadas a partir del 29 de marzo de 2023 para un «dispositivo cibernético», es decir, un dispositivo que incluye software, puede conectarse a Internet y presenta características que podrían hacerlo vulnerable a amenazas cibernéticas. La FDA interpreta esta disposición de forma amplia, considerando el firmware como software y incluyendo conectores como los puertos USB y serie entre los medios de conexión. Los tipos de solicitudes afectados son las 510(k), PMA, PDP, De Novo y HDE. En virtud del apartado 524B(b)(3), el fabricante debe proporcionar una lista de componentes de software (SBOM) que abarque los componentes comerciales, de código abierto y disponibles en el mercado.
La guía de la FDA, reeditada el 3 de febrero de 2026, exige más que los campos básicos. Recomienda que la entrada de cada componente incluya su estado de soporte (como «en mantenimiento activo», «ya no se mantiene» o «abandonado») y su fecha de fin de soporte, y que los fabricantes planifiquen cómo actualizar o sustituir los componentes de terceros cuando finalice el soporte. Dicha guía no es vinculante, es anterior a la actualización de la CISA de 2026 y sigue citando el trabajo de la NTIA de 2021 sobre los atributos básicos. La propia ley añade la obligación de aplicar parches. El artículo 524B(b)(2) exige a los fabricantes de dispositivos cibernéticos que pongan a disposición actualizaciones y parches de forma periódica para las vulnerabilidades conocidas inaceptables y, fuera de ciclo, para aquellas críticas que puedan suponer un riesgo incontrolado.
Requisitos de la CRA en materia de SBOM y las cuestiones que dejan sin resolver
El punto 1 de la Parte II del Anexo I de la Ley de Ciberresiliencia exige a los fabricantes que identifiquen y documenten las vulnerabilidades y los componentes, entre otras cosas mediante la elaboración de una SBOM en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior. El reglamento entró en vigor el 10 de diciembre de 2024, y las principales obligaciones, incluida la relativa a la SBOM, se aplican a partir del 11 de diciembre de 2027. La SBOM se incluye en la documentación técnica, y una autoridad de vigilancia del mercado puede solicitarla, motivando su petición, cuando la necesite para comprobar el cumplimiento. Compartirla con los usuarios es opcional.
La parte II del mismo anexo también exige a los fabricantes que aborden y subsanen las vulnerabilidades sin demora, entre otras cosas mediante la facilitación de actualizaciones de seguridad. El artículo 13 impone una obligación de diligencia debida a la hora de integrar componentes de terceros, incluidos los de código abierto, y exige a los fabricantes que, si descubren una vulnerabilidad en un componente, la notifiquen a su responsable de mantenimiento y, a continuación, la corrijan en su propio producto. La obligación relativa a la SBOM, por lo tanto, conlleva obligaciones que la propia SBOM no cumple. La lista muestra qué contiene el producto, pero examinar esos componentes y corregirlos es una labor que el fabricante aún tiene que realizar. El nivel superior también va en contra de esas obligaciones en la práctica: cuando se publica un aviso, el componente afectado suele ser una dependencia transitiva, y una SBOM que se limita a las dependencias de nivel superior no indicará si el producto la incluye. Cumplir con la obligación de corrección resulta más fácil con una SBOM que vaya más allá del mínimo exigido.
El papel del NIST
Si estás buscando los requisitos del NIST para las SBOM, lo primero que debes saber es que el NIST no publica sus propios elementos de datos de las SBOM. La NTIA estableció la referencia en 2021, y la CISA ha establecido la actual. La función del NIST se centra en la orientación sobre los procesos. El Marco de Desarrollo Seguro de Software (SSDF, SP 800-218, versión 1.1) incluye una SBOM como ejemplo de los datos de procedencia que los productores deben conservar para cada componente de una versión. El SSDF era importante para los proveedores federales porque el formulario de certificación que la OMB derogó en enero les obligaba a confirmar el cumplimiento del SSDF. Desde dicha derogación, una agencia aún puede solicitar la certificación, pero la política a nivel de todo el Gobierno ya no la exige.
Si un contrato establece que hay que seguir las directrices del NIST, adapta tus prácticas de desarrollo al SSDF, elabora una SBOM que cumpla con los elementos de la norma CISA 2026 y vuelve a generarla con cada lanzamiento. Aunque todavía ningún organismo regulador exige los elementos de la norma 2026, estos constituyen la referencia más estricta publicada, y una SBOM elaborada según dichos elementos también cumple con los requisitos mínimos de la FDA y la CRA. Lee primero la redacción del contrato, ya que es lo que determina cuáles de esos requisitos son importantes para el comprador.
Estas normas establecen quién debe elaborar una SBOM y qué debe incluir. La FDA y la CRA también mencionan las obligaciones posteriores, como la aplicación de parches y la diligencia debida, pero apenas dan detalles sobre cómo llevarlas a cabo. Ahí es donde la SBOM deja de ser suficiente.
Lo que una SBOM conforme a la normativa no puede hacer por sí sola
Cumple todos los requisitos de la SBOM mencionados anteriormente y dispondrás de un documento que recoge el contenido de tu software. Este puede incluir más información que solo los nombres y las versiones, como un hash y la firma del autor de cada componente. También se pueden adjuntar otros documentos. Una declaración VEX (Vulnerability Exploitability eXchange) indica si una vulnerabilidad incluida en la lista afecta al producto, y una certificación de procedencia vincula un artefacto a la compilación que lo generó. Incluso con todo eso en mano, aún se llevan a cabo tres comprobaciones adicionales.
¿Coincide el artefacto con su origen?
La línea de base de 2026 exige un valor hash para el artefacto ejecutable de cada componente y una firma del autor de la SBOM. El hash identifica el artefacto descrito, y la firma garantiza que el autor declarado ha firmado la SBOM y que esta no ha sido alterada posteriormente. Ninguno de los dos compara el artefacto con el repositorio de código fuente al que apunta el proyecto. Si una cuenta de mantenedor pirateada publica una versión manipulada, o si un paquete del registro contiene código que no está en el repositorio del proyecto, la SBOM lo registra como cualquier otra entrada, con un hash que coincide con el archivo que has descargado.
La comprobación de un artefacto frente a su código fuente puede realizarse de diferentes maneras. Una certificación de procedencia, por ejemplo, vincula el artefacto a la compilación que lo generó. Una recompilación a partir del código fuente sustituye el artefacto del registro por uno que tú mismo has compilado, de modo que lo que distribuyes contiene únicamente lo que hay en el repositorio. Ambas opciones tienen la misma limitación: determinan si el artefacto coincide con el código fuente, pero no si el código fuente está limpio. Una cuenta pirateada o una confirmación maliciosa superaría cualquiera de estas comprobaciones.
¿Debería haberse admitido ese componente?
Los «typosquats», la suplantación de espacios de nombres y los paquetes con un comportamiento de instalación hostil aparecen en la lista como cualquier otro paquete. La función de la SBOM es registrar lo que se ha resuelto, y eso es lo que ha hecho. La decisión de resolver o no el paquete se tomó anteriormente, y la CRA enmarca esa decisión como un ejercicio de diligencia debida a la hora de integrar componentes de terceros.
Algunos ecosistemas ejecutan código del paquete durante la instalación o la compilación. Un script del ciclo de vida de npm se ejecuta durante la instalación, un script «build.rs» de Rust se ejecuta durante la compilación y un hook de inicio «.pth» de Python puede ejecutar código cada vez que se inicia el intérprete. Muchos procesos generan la SBOM en el momento de la compilación o posteriormente, por lo que el paquete queda documentado después de que haya tenido la oportunidad de ejecutarse.
¿Hay alguna solución y quién se va a encargar de desarrollarla?
Una lista SBOM, junto con los datos de avisos, te indica que un componente tiene una vulnerabilidad conocida. Un documento VEX puede indicar si una vulnerabilidad afecta a tu producto, y el estado de soporte que las directrices de la FDA recomiendan registrar indica si el proveedor anterior sigue existiendo para solucionarla. Todo ello describe el problema, pero nada de ello genera un parche.
Imagina un componente de tu árbol con una vulnerabilidad conocida en una línea de versiones que ya no recibe mantenimiento por parte del desarrollador original. A veces, el proyecto sigue activo en una versión principal más reciente; otras veces, se ha abandonado por completo. En cualquier caso, puedes actualizar, sustituir o aplicar un parche a la versión que utilizas. La actualización no es posible cuando no existe una versión corregida, y no siempre es segura aunque la haya. Sustituir implica reescribir todo aquello que utilizara el componente, lo cual resulta más complicado cuando este llegó como una dependencia transitiva que tú nunca elegiste. Eso deja como única opción aplicar un parche a la versión que utilizas. Alguien tiene que escribir la corrección o adaptarla desde la línea principal más reciente —si el proyecto sigue activo allí— y, a continuación, verificar que el comportamiento del componente sigue siendo compatible. Se trata de un trabajo muy específico, y es algo que el equipo de desarrollo original no va a hacer para un componente que ya no mantiene.
Las tres comprobaciones, una al lado de la otra, tienen este aspecto.
| Comprobar | Cuando tiene que pasar | Qué puede registrar una SBOM | Lo que no puede hacer |
|---|---|---|---|
| El artefacto coincide con su origen | Antes de que el paquete entre en tu compilación | Un hash y una firma del autor | Compara el artefacto con su fuente |
| Se puede afirmar con seguridad que el componente es seguro | Antes de que el paquete entre en tu compilación | Nombre, versión y relaciones | Evalúa si es seguro ejecutar el paquete |
| Existe una solución y se aplica | Cuando se detecta una vulnerabilidad | Estado del soporte y datos VEX, cuando se faciliten | Crear o aplicar un parche |
Cómo es el resto del trabajo
Cada uno de los tres controles es una tarea que alguien debe realizar. La selección determina si un paquete debe admitirse antes de que llegue al equipo de un desarrollador o a un agente de compilación. La recompilación a partir del código fuente te proporciona un artefacto que coincide con el código del repositorio del proyecto. La aplicación continua de parches mantiene los componentes actualizados cuando el desarrollo original se ralentiza o se detiene.
Según el SSDF: el marco del NIST enumera, como ejemplos de componentes de terceros, revisarlos antes de su uso, comprobar que cada uno siga recibiendo mantenimiento, planificar medidas para aquellos que no lo reciban y compilarlos a partir del código fuente cuando no se pueda confirmar la procedencia de un binario.
Sigue siendo necesario disponer de la SBOM para responder a la pregunta «¿nos afecta esto?» cuando se publica un aviso de seguridad. Solo ofrece una respuesta satisfactoria cuando abarca las dependencias transitivas y refleja lo que realmente se ha distribuido, lo cual es una de las razones para elaborarla según la referencia de 2026 de la CISA, en lugar de según el mínimo exigido por la CRA.
Cuando evalúes cualquiera de las herramientas de seguridad de la cadena de suministro disponibles en el mercado, pregúntate en qué momento del proceso actúa cada una: antes de que te llegue el paquete, durante la instalación o una vez que el artefacto está instalado. Muchas herramientas de esta categoría informan sobre lo que ya está ahí, y un ataque que se ejecuta durante la instalación, la compilación o el inicio del intérprete ya se habrá ejecutado cuando llegue el informe.
SecureChain, de TuxCare, actúa antes de que el paquete llegue a tus manos. Analiza los paquetes en busca de malware oculto y código sospechoso, bloqueando aquellos que no superan el análisis. A continuación, recompila los paquetes a partir del código fuente en entornos de compilación aislados. En el caso de los componentes activos, aplica parches a las vulnerabilidades en el marco del SLA a medida que surgen CVE, y cuando el desarrollador original deja de mantener un paquete, el servicio Endless Lifecycle Support (ELS) sigue proporcionando las correcciones necesarias. La cobertura abarca paquetes de JavaScript, Python, Java, Go, Rust y PHP.
Qué hacer una vez que se dispone de la SBOM
Los requisitos de la SBOM han cambiado varias veces desde 2021, así que considera el documento como algo que debes volver a generar con cada lanzamiento y prioriza los controles que reducen el riesgo antes de hacerlo. Si aún no dispones de uno, elabóralo según los elementos de la CISA 2026, incluyendo las dependencias transitivas. Si ya tienes uno, comprueba que vaya más allá de las dependencias de primer nivel y refleje lo que realmente se ha distribuido. Si no es así, genera uno nuevo a partir del árbol de dependencias resuelto o del artefacto compilado, sin límite de profundidad, antes de hacer nada más con él. A continuación, compáralo con los datos de los avisos de seguridad, clasifica los componentes vulnerables según si existe una corrección en la cadena de suministro y decide qué hacer con aquellos que no la tengan. Puedes sustituir el componente, pedir a alguien que aplique un parche a la versión que utilizas o registrar una aceptación explícita del riesgo.
Si tu SBOM sigue detectando paquetes que ya nadie mantiene, descubre cómo SecureChain for Open Source bloquea los paquetes de riesgo antes de que lleguen a tu entorno y sigue aplicándoles parches una vez que finaliza el soporte del desarrollador original.
PREGUNTAS FRECUENTES
¿Cuáles son los requisitos de la SBOM?
Los requisitos de la SBOM son normas que obligan a los fabricantes de software a facilitar una lista de componentes de software, es decir, un listado de los componentes que forma parte de un producto. Los principales son la sección 524B de la FDA para dispositivos médicos, en vigor desde 2023; la Ley de Ciberresiliencia de la UE, que entrará en vigor el 11 de diciembre de 2027; y las condiciones de contratación pública federales que las agencias estadounidenses establecen ahora contrato por contrato. Los «Elementos Mínimos» de la CISA para 2026 definen los campos de datos básicos.
¿Sigue existiendo un requisito federal relativo a la SBOM?
La Orden Ejecutiva 14028, que establecía directrices para facilitar una SBOM a los compradores, sigue vigente. La Oficina de Gestión y Presupuesto (OMB) derogó los memorandos que exigían certificaciones de seguridad del software (M-22-18 y M-23-16) el 23 de enero de 2026. Las agencias estadounidenses aún pueden solicitar una SBOM en las condiciones del contrato, por lo que la obligación de presentarla depende del comprador.
¿Cuáles son los requisitos de la FDA en materia de SBOM para los productos sanitarios?
El artículo 524B de la Ley FD&C exige que, en las solicitudes previas a la comercialización de dispositivos cibernéticos —es decir, dispositivos con software capaz de conectarse a Internet y que podrían ser vulnerables a amenazas cibernéticas—, se incluya una lista de materiales de software (SBOM) que abarque el software comercial, de código abierto y listo para usar. La guía de la FDA de febrero de 2026 también recomienda indicar el estado de soporte de cada componente y la fecha de fin de soporte.
¿Cuáles son los requisitos de la CRA en materia de SBOM?
La Ley de Ciberresiliencia de la UE (CRA) exige a los fabricantes de productos con elementos digitales que elaboren una lista de componentes de software (SBOM) en un formato de uso común y legible por máquina, que abarque, como mínimo, las dependencias de nivel superior. Esta obligación entrará en vigor el 11 de diciembre de 2027, y las autoridades de vigilancia del mercado podrán solicitar la SBOM, motivando su petición, para comprobar el cumplimiento de la normativa. La CRA también exige a los fabricantes que subsanen sin demora las vulnerabilidades de sus productos y componentes.
¿Cómo se cumplen los requisitos del SBOM del NIST?
El NIST no establece los elementos de datos de la SBOM. Estos proceden de los «Elementos mínimos de 2026» de la CISA, que sustituyeron a la referencia de 2021 de la Administración Nacional de Telecomunicaciones e Información (NTIA), una agencia del Departamento de Comercio de EE. UU. La función del NIST consiste en ofrecer orientación sobre los procesos en el Marco de Desarrollo Seguro de Software (SP 800-218), por lo que el cumplimiento suele implicar adaptar las prácticas de desarrollo a dicho marco, elaborar una SBOM que cumpla con los elementos de la CISA y actualizarla con cada lanzamiento.
¿Una SBOM hace que el software sea más seguro?
No por sí sola. Una SBOM registra qué componentes forman parte del software, lo que te ayuda a reaccionar cuando se da a conocer una vulnerabilidad. No verifica que un paquete coincida con su código fuente, ni evalúa si debería haberse instalado, ni proporciona un parche.
¿Qué se puede hacer con un componente que presenta una vulnerabilidad pero para el que no hay ninguna corrección por parte del desarrollador original?
Puedes sustituir el componente o aplicar un parche a la versión que utilizas. La sustitución puede implicar una reescritura, mientras que la aplicación de un parche significa que alguien tiene que escribir y probar la corrección, ya que ninguna versión del desarrollador original la incluye. Un proveedor que ofrezca soporte ampliado para paquetes de código abierto al final de su ciclo de vida puede proporcionar ese parche. Incluir el componente en una SBOM documenta la vulnerabilidad sin modificarlo.
