**El Gobierno de EE.UU. relaja la exigencia de SBOM y SSDF: implicaciones para la ciberseguridad empresarial**
—
### 1. Introducción
En un giro inesperado para la estrategia de ciberseguridad nacional, las agencias federales estadounidenses ya no estarán obligadas a solicitar a los proveedores tecnológicos la entrega de software bills of material (SBOMs) ni declaraciones de conformidad con el Secure Software Development Framework (SSDF) de NIST. Esta modificación normativa, que afecta a la contratación pública de software, genera incertidumbre en torno a la transparencia y seguridad en la cadena de suministro digital, así como dudas sobre el futuro cumplimiento de estándares internacionales y legislaciones como NIS2 y GDPR.
—
### 2. Contexto del Incidente o Vulnerabilidad
Tras los incidentes de alto perfil como el ataque SolarWinds y las vulnerabilidades críticas explotadas en la cadena de suministro, la administración Biden había impuesto requisitos estrictos a los proveedores de software, exigiendo SBOMs y el alineamiento con NIST SSDF para cualquier producto suministrado a agencias federales. Estas directrices formaban parte de la Orden Ejecutiva 14028 (Mejorando la Ciberseguridad de la Nación), con el objetivo de fortalecer la visibilidad y la gestión de riesgos en el software gubernamental.
Sin embargo, la Oficina de Administración y Presupuesto (OMB) ha modificado recientemente estas obligaciones. Ahora, la aportación de SBOMs y la autoevaluación con respecto al SSDF se consideran prácticas recomendadas, pero no serán de cumplimiento obligatorio en los procesos de contratación pública.
—
### 3. Detalles Técnicos
**SBOM (Software Bill of Materials)**
Un SBOM es un listado estructurado y detallado de todos los componentes, dependencias y bibliotecas de un producto software. Permite identificar rápidamente vulnerabilidades conocidas (por ejemplo, CVE-2021-44228, Log4Shell), evaluar el riesgo y facilitar la respuesta ante incidentes. Herramientas como Syft, CycloneDX o SPDX son populares para su generación y análisis.
**SSDF (NIST SP 800-218)**
El SSDF es un marco de referencia para el desarrollo seguro de software. Incluye prácticas como la gestión de vulnerabilidades, la revisión de código, la autenticación fuerte y controles de seguridad en el ciclo DevSecOps. Su adopción se alinea con técnicas de MITRE ATT&CK como la defensa en profundidad, gestión de credenciales y protección de la cadena de suministro.
**Vectores de ataque y TTP**
La ausencia de SBOMs dificulta la detección de componentes vulnerables explotados mediante TTPs como “Supply Chain Compromise” (ID: T1195) y “Valid Accounts” (ID: T1078) según MITRE ATT&CK. Sin documentación clara, los indicadores de compromiso (IoC) pueden pasar inadvertidos, retrasando la contención y remediación.
**Exploits y herramientas**
La falta de visibilidad en dependencias facilita el uso de exploits sobre componentes desactualizados, accesibles en frameworks como Metasploit, Cobalt Strike o Sliver. Ejemplos recientes incluyen la explotación de bibliotecas open source no parcheadas en entornos federales.
—
### 4. Impacto y Riesgos
La flexibilización de estos requisitos expone a las agencias federales y a sus proveedores a mayores riesgos de seguridad:
– **Incremento de la superficie de ataque**: sin SBOMs, la identificación proactiva de vulnerabilidades es menos eficaz.
– **Respuestas más lentas ante incidentes**: la ausencia de inventario detallado de componentes retrasa el análisis forense y la contención.
– **Riesgo de cumplimiento normativo**: sectores regulados (financiero, sanitario, infraestructuras críticas) pueden verse en dificultades para cumplir NIS2 o GDPR, que exigen gestión y documentación de riesgos en la cadena de suministro.
– **Aumento de costes en la gestión de incidentes**: según Ponemon Institute, la falta de visibilidad en la supply chain incrementa el coste medio de una brecha en un 29%.
—
### 5. Medidas de Mitigación y Recomendaciones
Para minimizar el impacto de este cambio normativo, se recomienda a CISOs y responsables de seguridad:
– **Solicitar SBOMs voluntariamente** a proveedores críticos, especialmente en software de misión crítica o sensible.
– **Adoptar marcos como SSDF o ISO/IEC 27034** en el desarrollo de software interno y la evaluación de terceros.
– **Implementar soluciones de gestión de vulnerabilidades** y escaneo continuo de componentes (SCA).
– **Establecer requisitos contractuales de seguridad** aunque no sean obligatorios por ley.
– **Mantener un inventario actualizado de activos y dependencias** para facilitar la respuesta ante incidentes.
—
### 6. Opinión de Expertos
Varios analistas de ciberseguridad han expresado su preocupación. Katie Moussouris, CEO de Luta Security, advierte: “Eliminar estos requisitos envía un mensaje contradictorio sobre la importancia de la transparencia en la cadena de suministro”. Desde el sector privado, empresas como Google y Microsoft mantienen la obligatoriedad de SBOM en sus procesos internos y para sus partners.
Desde ENISA, se recalca que “la transparencia en los componentes de software es clave para la gestión proactiva del riesgo y la resiliencia operativa”.
—
### 7. Implicaciones para Empresas y Usuarios
– **Para empresas tecnológicas**: la relajación regulatoria podría hacer que algunas reduzcan sus controles, pero aquellas que exporten a la UE o sectores regulados seguirán necesitando SBOMs y alineamiento con SSDF.
– **Para usuarios finales**: aumenta la exposición a vulnerabilidades de día cero y ataques en la cadena de suministro.
– **Para los CISOs**: se incrementa la responsabilidad de evaluar el riesgo y establecer controles contractuales adicionales en ausencia de un marco federal obligatorio.
—
### 8. Conclusiones
La retirada de la obligación de solicitar SBOMs y atestiguar la conformidad con el NIST SSDF supone un retroceso en la madurez de la gestión de la cadena de suministro software en la administración pública estadounidense. Aunque la medida podría agilizar la contratación, debilita la capacidad para anticipar y responder a amenazas emergentes y dificulta el alineamiento con normativas internacionales más estrictas. En un contexto de creciente sofisticación de los ataques a la supply chain, la transparencia y la seguridad en el desarrollo de software siguen siendo factores críticos que no deberían relajarse.
(Fuente: www.darkreading.com)