Summary

  • En el informe GAO-26-107530, altos funcionarios de 17 de 24 agencias federales dijeron que las orientaciones de OMB y NIST chocaban al recoger y almacenar listas de componentes de software (SBOM). La cifra mide dificultades declaradas en la contratación, no incidentes de seguridad ni productos peligrosos.
  • El GAO compara la antigua OMB M-22-18, que trataba la recogida como opcional y la lista como prueba estática, con la propuesta del NIST de datos por versión útiles para analizar vulnerabilidades. OMB retiró M-22-18 en enero de 2026 y permitió en M-26-05 que cada agencia pidiera por contrato una lista actualizada cuando la necesitara.
  • El GAO recomendó a la Cybersecurity and Infrastructure Security Agency (CISA) explicar cómo generar, recibir y analizar esos datos dentro de compras, desarrollo y gestión de riesgos. La prueba de utilidad es el trayecto desde un componente identificado hasta una decisión de seguridad con responsable.

La lista que termina en una carpeta

Un SBOM enumera piezas de una versión de software. La oficina de compras puede recibirlo como documentación del proveedor y cerrar el expediente. La de seguridad necesitará hacer una pregunta distinta meses después: una biblioteca aparece en un aviso de vulnerabilidad, ¿está dentro del programa que la agencia mantiene operativo? Para contestar hacen falta datos ligados a la versión o al entorno que realmente funciona, y un procedimiento para usarlos.

El informe del GAO publicado el 23 de junio de 2026 examinó las compras de nube de 24 agencias. En 17, los responsables describieron un choque entre las instrucciones de OMB y NIST para recoger y conservar SBOM. Es un recuento de respuestas sobre la práctica de adquisición. El mismo informe también habla de 17 agencias con dificultades para controlar el coste de la nube, pero esa es otra pregunta. Ninguna de estas cifras equivale a 17 brechas de seguridad.

El informe original completo identifica tres puntos en la antigua fricción. La OMB M-22-18 presentaba la recogida como optativa, mientras NIST pedía a los productores seguir y compartir componentes de cada versión. OMB encargaba a cada agencia crear su proceso de recogida; NIST apuntaba a datos entregados por el productor en formatos normalizados. OMB veía un comprobante de cumplimiento; NIST veía datos que podían entrar en la búsqueda de vulnerabilidades y la gestión del riesgo. Para redactar un contrato, esas diferencias importan más que una definición elegante de SBOM.

Cinco agencias dijeron al GAO que las formas y procedimientos propios de cada comprador cargarían de trabajo a los productores que venden al gobierno por varias vías. Cinco comunicaron problemas para obtener la información del fabricante, incluso cuando un revendedor separaba a la agencia del productor. Los dos grupos pueden compartir miembros; el informe no autoriza sumarlos como diez agencias distintas. Ambos muestran el mismo vacío: no basta con querer la lista si nadie ha fijado quién la crea, quién puede exigirla y cuándo se actualiza.

El memorando cambió; la entrega sigue pendiente

La OMB M-26-05 del 23 de enero de 2026 revocó M-22-18 y su texto complementario M-23-16. La norma antigua explica lo que investigó el GAO; ya no manda en el presente. La nueva atribuye al titular de cada agencia la responsabilidad de asegurar software y equipos, mantiene la exigencia de inventarios completos y permite escoger cláusulas contractuales para recibir un SBOM vigente a petición. En plataformas de nube, la cláusula debería referirse al entorno de producción real.

El cambio da margen y coloca la decisión en un despacho concreto. La agencia puede ajustar la demanda de información al riesgo. Si decide usar SBOM, tiene que resolver quién puede pedirlo, con qué rapidez llega, qué versión describe y dónde acaba. El GAO considera que el memorando de enero aclaró responsabilidades sin cerrar el problema operativo. Un archivo opcional entregado tarde o en un formato imposible de procesar no ayuda a reaccionar ante una biblioteca vulnerable.

Las orientaciones del NIST sobre la cadena de software sitúan los componentes dentro del trabajo de seguridad. La visión conjunta publicada por CISA en septiembre de 2025 habla de crear, consumir y analizar los datos junto a procesos existentes de desarrollo y riesgo. Según el GAO, ese texto todavía no enseñaba a cada agencia cómo conectar la información con sus herramientas y procedimientos. La intención era clara; faltaba la tubería.

CISA tiene el encargo de unir los extremos

El GAO recomendó que el Department of Homeland Security encargara a CISA instrucciones adicionales sobre generación, recepción y análisis de SBOM para compras, desarrollo y gestión de riesgos. El departamento aceptó. Su respuesta esperaba terminar el trabajo para el 30 de septiembre de 2026. Esa fecha es una previsión en una respuesta oficial; la ficha pública de la recomendación figuraba abierta al comprobarla para este artículo. La entrega efectiva de una guía y su uso por las agencias necesitan prueba propia.

El puente útil exige varios nombres y plazos. El productor debe identificar la versión distribuida o el entorno de nube en producción. El contrato debe dar acceso a datos actuales, también cuando interviene un revendedor. El formato debe poder analizarse junto a información de vulnerabilidades. Por último, un operador debe tener la tarea de decidir y dejar constancia cuando cambie una pieza o aparezca un aviso. OMB define la elección de política, NIST la práctica técnica y CISA tiene que volver ejecutable la conexión.

Una guía oficial de CISA que detalle esos pasos, seguida de contratos y procesos en los que se vea una lista vigente llegar a quien decide, cambiaría la evaluación. El GAO ya recogió el síntoma en 17 agencias: dos libros de instrucciones se rozan justo donde una administración compra y protege el mismo programa. El inventario de componentes empieza a valer cuando sobrevive a la mudanza del expediente de compras a la consola de seguridad.

Sources