Los ataques a la cadena de suministro van en aumento, pero muchas organizaciones no están preparadas para hacerles frente. En este boletín de LinkedIn, Gonda Lamberink, ejecutiva de ciberseguridad de Bureau Veritas, explica cómo los SBOM le ayudarán a prepararse para las futuras amenazas a la cadena de suministro. Hace hincapié en que comprender el contexto de las vulnerabilidades, como si el software es realmente explotable, es indispensable para maximizar el valor de los SBOM.

La amenaza: el aumento de los ataques a la cadena de suministro

El uso generalizado de componentes de código abierto en el software y vulnerabilidades como Log4j y SolarWinds han expuesto la fragilidad de las cadenas de suministro.

En 2024, Sonatype en su 10º Informe Anual sobre el Estado de la Cadena de Suministro de Software afirma que los ataques a la cadena de suministro de software aumentaron, duplicándose con respecto al año anterior. En agosto, se habían identificado más de 700.000 paquetes maliciosos de software de código abierto (OSS), un asombroso aumento del 156% interanual, lo que subraya la escalada de riesgos para las organizaciones que no gestionan eficazmente sus dependencias de OSS.

A pesar de los crecientes riesgos para las cadenas de suministro, la capacidad de respuesta de las organizaciones es escasa. Según las Perspectivas Mundiales de Ciberseguridad 2024 del Foro Económico Mundial (FEM), el 55,9% de los líderes cree que tecnologías como la IA Generativa dan actualmente ventaja a los atacantes, mientras que sólo el 8,9% ve que el panorama cibernético favorece a los defensores. En lo que respecta a los ataques a la cadena de suministro, el 54% de las organizaciones no conocen suficientemente las cibervulnerabilidades de su cadena de suministro.

SBOM: parte de la solución

Como profesional del sector de la ciberseguridad, creo que los SBOM son una gran parte de la solución a este problema de seguridad de la cadena de suministro y, especialmente, a la actual falta de transparencia de la cadena de suministro de software. Tienen el potencial de convertirse en un elemento esencial de las prácticas de seguridad del software: pueden facilitar la colaboración y la responsabilidad en la cadena de suministro para mitigar los riesgos.

En primer lugar: ¿qué es una SBOM?

Una SBOM (Software Bill of Materials) es esencialmente una lista detallada de todos los componentes que forman una pieza de software, muy parecida a la lista de ingredientes de los alimentos envasados, escrita en un formato estándar. Cataloga todos los componentes de software de código abierto y propietario. Las SBOM ofrecen a las organizaciones transparencia en su cadena de suministro de software, de modo que puedan gestionar mejor sus riesgos de seguridad, los requisitos de conformidad y las vulnerabilidades operativas.

¿Por qué son importantes las SBOM?

Dado que los SBOM documentan los componentes de un sistema o producto de software, son fundamentales para crear visibilidad sobre las posibles vulnerabilidades y dependencias. Dos incidentes de gran repercusión ponen de relieve la importancia de las SBOM:

• SolarWinds (2020): Los atacantes inyectaron código malicioso durante el proceso de creación del software, comprometiendo a más de 18.000 clientes, incluidas agencias federales y grandes corporaciones. Aunque los SBOM no podrían haber evitado el ataque, habrían proporcionado una ayuda crucial: podrían haber ayudado a las organizaciones a verificar si estaban utilizando la versión de software afectada y a actuar con mayor rapidez para hacer frente a los riesgos.
• Log4j (2021): Todo el mundo recuerda este ataque. Un fallo crítico en una biblioteca Java muy utilizada afectó a millones de aplicaciones. A diferencia de SolarWinds, donde el ataque tenía como objetivo un proceso, Log4j puso de relieve los riesgos de la dependencia de componentes. Muchas organizaciones desconocían que dependían de Log4j, lo que provocó retrasos en su respuesta. En este caso, los SBOM habrían sido transformadores. Al proporcionar a las organizaciones una visibilidad detallada de las dependencias de software, los SBOM podrían haber permitido identificar rápidamente el uso de Log4j, priorizar la corrección y habrían reducido realmente el enorme impacto de la vulnerabilidad.

Impulso normativo para el uso de SBOM

Los reguladores y responsables políticos de todo el mundo han reconocido la importancia de los SBOM. Estos son algunos ejemplos clave de regulación y política que hacen referencia y también obligan al uso de los SBOM:

• EU Cyber Resilience Act (CRA): Exige SBOM para todos los productos digitales con el fin de abordar las vulnerabilidades del software y reforzar la responsabilidad en las cadenas de suministro.
• Orden ejecutiva 14028 de EE.UU.: Obliga el uso de SBOM para la adquisición federal de software, con directrices de la NTIA, el NIST y la CISA que apoyan su adopción.
• Normas específicas del sector: Industrias como la sanidad, el transporte y las infraestructuras críticas hacen ahora hincapié en los SBOM para alinearse con, por ejemplo, las directrices de ciberseguridad de la FDA, la normativa de la CEPE para la homologación de vehículos y la normativa NIS2.

Cómo utilizar los SBOM en la práctica

Por supuesto, la normativa y la política no equivalen a la acción. Veo algunas cosas que la industria puede hacer para ayudar a que los SBOM despeguen y recomendaría a los vendedores de software y a los usuarios que hicieran lo siguiente:

• Vendedores: Generar SBOM en cada fase del ciclo de vida del software (fuente, compilación, despliegue) de acuerdo con formatos estándar de SBOM ampliamente utilizados, como SPDX y CycloneDX. Implemente sistemas automatizados de actualización en tiempo real para mantener la precisión.
• Integradores: Incorporen los SBOM a sus soluciones y mantengan una comunicación abierta con los propietarios de assets sobre su uso e impacto.
• Propietarios y operadores de assets: Aprovechen los SBOM para alinear los procesos de adquisición, operaciones, gestión de vulnerabilidades y respuesta a incidentes con las mejores prácticas de seguridad del software.

La adopción de SBOM resulta mucho más eficaz cuando las organizaciones siguen estándares establecidos o también aún emergentes, no sólo para su generación -como formatos como SPDX y CycloneDX- sino también para su intercambio y consumo.

Además, mi principal consejo es integrar los SBOM con las herramientas existentes, incluidos el Análisis de Composición de Software (SCA), los pipelines de Integración Continua/Despliegue Continuo (CI/CD), los sistemas de Governance, Risk, and Compliance (GRC) y las soluciones de gestión de vulnerabilidades, lo que aumenta enormemente su utilidad, especialmente si se utilizan junto a otros artefactos, tan importantes como un SBOM, como un archivo Vulnerability Exploitability eXchange (VEX), que contiene el estado y el impacto de las vulnerabilidades asociadas a un SBOM.

Este enfoque transforma los SBOM de una lista estática en conocimientos procesables que refuerzan la seguridad, el cumplimiento y los flujos de trabajo operativos:

• Las herramientas de automatización pueden agilizar la creación, actualización, intercambio y consumo de las SBOM a lo largo del ciclo de vida del software, reduciendo los errores y aumentando la eficacia.
• Vincular los SBOM con datos contextualizados sobre vulnerabilidades, fuentes de Inteligencia sobre amenazas y marcos de governance permite a las organizaciones abordar las vulnerabilidades y los riesgos con mayor eficacia.

Mi conclusión: sí, los SBOM cambian las reglas del juego

Conclusión: Los SBOM están transformando la seguridad de la cadena de suministro al abordar la necesidad de visibilidad y responsabilidad, especialmente en industrias críticas. Proporcionan información que permite a las organizaciones gestionar los riesgos e identificar las vulnerabilidades de forma más eficaz, como se observa en sectores como el de la energía, donde los SBOM desempeñan un papel clave a la hora de satisfacer las necesidades de cumplimiento y mantener las operaciones.

Así que sí, para responder a la pregunta central de este artículo: Creo que los SBOM cambian las reglas del juego de la seguridad de la cadena de suministro, especialmente cuando se combinan con el contexto sobre la posibilidad de explotar las vulnerabilidades a través de archivos VEX. Los SBOM identifican las vulnerabilidades, mientras que los archivos VEX ayudan eficazmente a priorizar y remediar los riesgos reales. Ninguno de los dos deben ser artefactos estáticos: su pleno potencial se realiza mediante la integración con, entre otros, los conductos de CI/CD y los sistemas de gestión de vulnerabilidades, con la automatización asegurando que se actualizan constantemente y siguen siendo procesables.