**Cambios en el SBOM amplían su alcance, pero expertos advierten sobre carencias en gestión de riesgos**
—
### 1. Introducción
En los últimos meses, el Software Bill of Materials (SBOM) se ha consolidado como una herramienta esencial en la cadena de suministro de software, permitiendo a empresas y organizaciones identificar y gestionar los componentes de software utilizados en sus productos. Sin embargo, la reciente aprobación de más de veinte cambios en los campos del SBOM ha generado debate entre los profesionales de ciberseguridad. Pese a que estas modificaciones buscan hacer los SBOM más completos y detallados, algunos expertos alertan de que el marco actual sigue sin abordar de forma efectiva las necesidades reales de gestión de riesgos.
—
### 2. Contexto del Incidente o Vulnerabilidad
El auge de los ataques a la cadena de suministro, como el caso SolarWinds en 2020, ha intensificado la presión regulatoria sobre la transparencia en el desarrollo de software. Iniciativas como la orden ejecutiva estadounidense 14028 y normativas europeas como NIS2 y la actualización del RGPD han puesto el foco en la obligatoriedad de contar con SBOM, tanto para proveedores como para consumidores de software. La comunidad técnica y organismos como la Open Web Application Security Project (OWASP) han impulsado la estandarización de SBOM, principalmente a través de formatos como SPDX, CycloneDX y SWID.
—
### 3. Detalles Técnicos
#### Cambios en los campos del SBOM
Los más de veinte cambios recientemente introducidos afectan a campos clave del SBOM, incluyendo:
– **Metadatos de autoría**: Mayor granularidad en los datos del responsable del componente (nombre, contacto, organización).
– **Rastreo de dependencias transitivas**: Mejor seguimiento de bibliotecas y módulos indirectos.
– **Identificadores de vulnerabilidades (CVE)**: Inclusión obligatoria de referencias a CVE asociadas y su historial de explotación conocido.
– **Timestamps y versionado**: Registro preciso de fecha y hora de compilación, y distinción clara entre versiones menores y parches.
– **Licenciamiento**: Especificación más detallada de licencias y restricciones de uso, en línea con exigencias de cumplimiento (por ejemplo, RFC 2119).
– **Campos de Integridad**: Mejora en el uso de hashes SHA-256 y SHA-512 para verificar la autenticidad de los binarios.
#### Vectores de ataque y TTP
La información detallada en los nuevos SBOM facilita la aplicación de técnicas del marco MITRE ATT&CK, especialmente en las fases de Reconocimiento (T1595), Explotación de confianza en la cadena de suministro (T1195) y Explotación de vulnerabilidades (T1210). Los Indicadores de Compromiso (IoC) extraídos de los SBOM permiten correlacionar versiones vulnerables con campañas activas identificadas en feeds de amenazas (por ejemplo, CISA KEV).
#### Herramientas y explotación
Herramientas como Metasploit y Cobalt Strike ya incorporan módulos capaces de analizar los datos de SBOM, identificando versiones explotables de componentes populares (Log4j, OpenSSL, Apache Struts, etc.). La automatización de la búsqueda de CVE en SBOM se está integrando en pipelines de CI/CD a través de plugins de SCA (Software Composition Analysis) como Snyk, Black Duck y Dependency-Track.
—
### 4. Impacto y Riesgos
La ampliación de los campos del SBOM incrementa la visibilidad sobre el software desplegado, permitiendo una reacción más rápida ante la publicación de nuevas vulnerabilidades. Sin embargo, el volumen de datos generados puede derivar en una sobrecarga para los equipos de seguridad, dificultando la priorización de riesgos reales. Estudios recientes indican que el 80% de los incidentes relacionados con la cadena de suministro se deben a componentes no inventariados o a una gestión ineficaz de los SBOM.
Por otro lado, la ausencia de mecanismos de scoring de riesgo y la falta de integración nativa con plataformas SIEM/SOAR limita la eficacia del SBOM como herramienta de gestión de riesgos.
—
### 5. Medidas de Mitigación y Recomendaciones
– **Automatización**: Integrar la generación y análisis de SBOM en los pipelines de CI/CD, utilizando herramientas de SCA.
– **Priorización basada en riesgo**: Implementar soluciones de scoring de vulnerabilidades (CVSS, EPSS) que correlacionen los datos del SBOM con la exposición real.
– **Integración con SIEM/SOAR**: Enlazar los SBOM con plataformas de monitoreo y respuesta para automatizar la detección y mitigación de amenazas.
– **Formación y sensibilización**: Capacitar a los equipos de desarrollo y operaciones sobre la importancia del SBOM y su correcto mantenimiento.
– **Cumplimiento normativo**: Garantizar que los SBOM cumplen los requisitos de NIS2, RGPD y otras regulaciones aplicables, con especial atención a la protección de datos personales y la notificación de incidentes.
—
### 6. Opinión de Expertos
Analistas de seguridad y CISOs consultados por Dark Reading coinciden en que los cambios en el SBOM suponen un avance técnico, pero subrayan la necesidad de evolucionar hacia un enfoque más centrado en la gestión dinámica del riesgo. “El SBOM debe convertirse en algo más que un inventario estático; necesitamos visibilidad contextual y capacidades de respuesta automatizada”, señala un CISO del sector financiero. Desde el ámbito del pentesting, se señala la facilidad con la que actores maliciosos pueden explotar la información expuesta si no se gestiona adecuadamente.
—
### 7. Implicaciones para Empresas y Usuarios
Las organizaciones con infraestructuras críticas o expuestas a la cadena de suministro deberán revisar sus políticas de gestión de componentes de software y adoptar soluciones que permitan la integración dinámica de SBOM. Para los usuarios finales, el SBOM aporta transparencia, pero también eleva la exigencia de verificar la seguridad de los productos adquiridos y exigir a los proveedores cumplimiento normativo y técnico.
—
### 8. Conclusiones
La ampliación de los campos en los SBOM representa un avance importante hacia la transparencia en la cadena de suministro de software, alineándose con las tendencias regulatorias y de mercado. Sin embargo, sin mecanismos efectivos de gestión del riesgo y automatización de la respuesta, el SBOM corre el riesgo de convertirse en una herramienta burocrática más que en un elemento clave de la defensa activa. El reto para los próximos meses será dotar al SBOM de inteligencia contextual y capacidad de integración con el resto del ecosistema de ciberseguridad corporativo.
(Fuente: www.darkreading.com)