Las cadenas de suministro de software se han vuelto muy complejas. Un producto puede incorporar paquetes de sistemas operativos, bibliotecas comerciales, componentes de código abierto, frameworks, firmware y dependencias procedentes de numerosos proveedores.
Por tanto, conocer exactamente qué componentes de software contiene un producto es una parte esencial de la gestión de riesgos de ciberseguridad. Esta visibilidad es importante para establecer un proceso eficaz y preciso de gestión de vulnerabilidades que, cuando sea posible, esté automatizado. Conocer los componentes y las versiones presentes permite a los fabricantes identificar los productos potencialmente afectados cuando se divulgan nuevas vulnerabilidades, evaluar su relevancia e impacto y adoptar las medidas correctivas adecuadas durante todo el ciclo de vida del producto.
Con la introducción del Reglamento (UE) 2024/2847, Reglamento de Ciberresiliencia de la UE, las SBOM también se han convertido en un aspecto normativo explícito para los fabricantes de productos con elementos digitales.
Una SBOM (lista de materiales de software) puede entenderse como un inventario estructurado de los componentes de software que contiene un producto. En lugar de limitarse a proporcionar una lista de nombres de software, una SBOM completa puede incluir información como:
El objetivo no es documentar por documentar. Una SBOM proporciona al fabricante visibilidad sobre su cadena de suministro de software y puede mejorar considerablemente su capacidad para responder a una pregunta clave en materia de ciberseguridad: “¿Afecta esta vulnerabilidad a algún componente incluido en mi producto y en mi producto final?”
Esta capacidad resulta especialmente importante a la hora de responder a vulnerabilidades recién descubiertas en componentes de terceros de uso generalizado.
Los formatos legibles por máquina permiten procesar esta información automáticamente mediante herramientas de desarrollo, gestión de vulnerabilidades y seguridad de productos. Dos de los formatos de SBOM más utilizados son CycloneDX y SPDX.
Sí. El Reglamento de Ciberresiliencia establece un requisito específico relacionado con las SBOM en el anexo I, parte II, punto 1, como parte de los requisitos de gestión de vulnerabilidades aplicables a los fabricantes:
Los fabricantes de productos con elementos digitales deberán:
(1) identificar y documentar las vulnerabilidades y los componentes presentes en los productos con elementos digitales, entre otras cosas, elaborando una lista de materiales de software en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior de los productos.
Como puede observarse, el CRA no prescribe un formato de SBOM concreto ni define en el propio Reglamento una lista exhaustiva de campos obligatorios. No obstante, el artículo 13, apartado 24, permite a la Comisión Europea especificar el formato y los elementos de la SBOM mediante actos de ejecución, teniendo en cuenta las normas y las mejores prácticas europeas o internacionales.
Por tanto, los fabricantes deben considerar el requisito del CRA como una base regulatoria mínima, y no como una especificación técnica completa para la implementación de SBOM.
Una SBOM no debe considerarse un documento de conformidad aislado. En virtud del CRA, forma parte de las obligaciones más amplias del fabricante en materia de gestión de vulnerabilidades.
El anexo I, parte II, exige a los fabricantes, entre otras cosas, identificar y documentar las vulnerabilidades y los componentes de software, abordar y corregir las vulnerabilidades sin demora, proporcionar actualizaciones de seguridad, divulgar información pertinente sobre las vulnerabilidades corregidas o proporcionar mecanismos para distribuir las actualizaciones de forma segura. La SBOM resulta especialmente útil cuando se integra en este proceso.
Por ejemplo, cuando se publica un nuevo CVE (Common Vulnerabilities and Exposures, vulnerabilidades y exposiciones comunes) que afecta a una biblioteca de terceros, el fabricante debe poder determinar si el componente afectado y la versión correspondiente están presentes en una o varias versiones del producto.
Por tanto, el verdadero valor de una SBOM no reside simplemente en generar el archivo, sino en mantener los procesos que permiten que la información sea precisa, trazable y útil para la toma de decisiones durante todo el ciclo de vida del producto.
Cuando el CRA exige una evaluación de la conformidad por parte de terceros, la cuestión probablemente no se limitará a comprobar si existe el archivo SBOM, sino que las preguntas de evaluación más relevantes serán si el fabricante ha establecido un proceso eficaz y reproducible.
Estas son algunas preguntas que las organizaciones deberían plantearse para garantizar que sus procesos de gestión de SBOM sean eficaces y cumplan los requisitos:
En definitiva, la SBOM debe considerarse una de las evidencias que forman parte de un ciclo de vida de ciberseguridad más amplio.
Desde la perspectiva de la evaluación de la conformidad, hay varias cuestiones especialmente relevantes.
La composición del software cambia con el tiempo. Por tanto, la SBOM debe estar claramente vinculada al producto y a la versión de software correspondientes. Un inventario genérico de componentes que no pueda asociarse a una versión concreta del producto puede tener un valor limitado como evidencia de conformidad.
La documentación técnica exigida por el CRA debe identificar, por sí misma, las versiones de software que afectan a la conformidad con los requisitos esenciales de ciberseguridad.
Una hoja de cálculo o un PDF actualizado manualmente pueden resultar útiles a nivel interno, pero el CRA hace referencia específicamente a un formato de uso común y legible por máquina.
El uso de formatos consolidados, como SPDX o CycloneDX, puede facilitar el procesamiento automatizado, la identificación de coincidencias con vulnerabilidades y el intercambio de información sobre componentes a lo largo de las cadenas de suministro.
Es posible que el nombre de un componente por sí solo no sea suficiente. Por ejemplo, dos paquetes con nombres similares pueden proceder de ecosistemas o proveedores diferentes.
Siempre que sea posible, los registros de los componentes deben incluir identificadores que permitan determinar con precisión el artefacto de software correspondiente. Algunos ejemplos son la información sobre la versión, las URL de los paquetes, los datos del proveedor y los hashes criptográficos.
El CRA exige explícitamente que se incluyan como mínimo las dependencias de nivel superior.
El software moderno suele depender de componentes que, a su vez, dependen de otros componentes. Por tanto, pueden existir vulnerabilidades en varios niveles por debajo del software integrado directamente por el fabricante.
No debe darse por supuesto que el mínimo exigido y el nivel de información necesario para una gestión eficaz de la seguridad del producto sean necesariamente equivalentes.
Los fabricantes deben comprender cómo se ha obtenido la información. En función del entorno de desarrollo, la información de la SBOM puede obtenerse mediante el análisis de dependencias del código fuente, los gestores de paquetes, los sistemas de compilación, las imágenes de contenedores, las herramientas de análisis de composición de software (SCA) y otras fuentes.
La generación automatizada puede mejorar la reproducibilidad, especialmente cuando se integra en los procesos de integración y entrega o despliegue continuos (CI/CD). Sin embargo, la generación automatizada no garantiza por sí sola que la información sea completa o correcta.
Los fabricantes siguen siendo responsables de comprender los riesgos de ciberseguridad asociados a los componentes incorporados a sus productos. Por tanto, la información sobre las SBOM proporcionada por los proveedores puede convertirse en una parte importante del proceso de garantía de seguridad de la cadena de suministro de software.
Es posible que los fabricantes deban establecer mecanismos contractuales o técnicos para obtener información adecuada sobre los componentes de sus proveedores de software.
Una SBOM creada al inicio del desarrollo de un producto y que nunca se actualiza pierde rápidamente su valor.
La información sobre los componentes debe mantenerse alineada con las versiones comercializadas del producto y con los cambios realizados durante el periodo de soporte.
El CRA exige que la documentación técnica se actualice continuamente cuando proceda, al menos durante el periodo de soporte.
La exhaustividad no debe evaluarse únicamente en función del número de campos cumplimentados. La cuestión más importante es si la SBOM permite al fabricante identificar los productos afectados cuando aparecen nuevas vulnerabilidades.
Por tanto, las organizaciones deberían considerar la integración de la información de la SBOM con fuentes de inteligencia sobre vulnerabilidades, como la información sobre CVE, las bases de datos de vulnerabilidades y, cuando proceda, la información VEX (Vulnerability Exploitability eXchange, intercambio de información sobre la explotabilidad de vulnerabilidades).
No necesariamente. El CRA no establece una obligación general de publicar la SBOM públicamente. La SBOM forma parte de la documentación técnica y, según el anexo VII, debe ponerse a disposición de las autoridades de vigilancia del mercado cuando estas lo soliciten de forma motivada y sea necesario para verificar el cumplimiento.
Esta distinción es importante porque la generación, el mantenimiento y la publicación de una SBOM son cuestiones diferentes.
Una SBOM generada automáticamente, pero incompleta, desactualizada o desconectada de la gestión de vulnerabilidades, aporta pocos beneficios en materia de ciberseguridad. Una SBOM útil debe permitir al fabricante responder a preguntas como las siguientes:
Cuando estas preguntas pueden responderse de forma coherente, la SBOM deja de ser un mero requisito documental de conformidad y se convierte en un elemento operativo de la seguridad de la cadena de suministro de software.
Las siguientes fuentes constituyen un buen punto de partida para las organizaciones que están preparando sus procesos de gestión de SBOM:
Applus+ utiliza cookies propias y de terceros para fines analíticos y para mostrarte publicidad personalizada en base a un perfil elaborado a partir de tus hábitos de navegación (por ejemplo, páginas visitadas). Puedes aceptar todas las cookies pulsando el botón “Aceptar” o configurarlas o rechazar su uso. Para más información, consulta nuestra Política de Cookies.
Permiten el funcionamiento de la web, cargar contenido multimedia y proteger su seguridad. Consulta las cookies que almacenamos en nuestra Política de cookies.
Nos permiten conocer cómo interactúas con la web, el número de visitas en las diferentes secciones y establecer estadísticas para mejorar nuestras prácticas comerciales. Consulta las cookies que almacenamos en nuestra Política de cookies.
A través de tu comportamiento en la web (dónde haces click, el tiempo que navegas, etc.) establecemos parámetros y un perfil para que visualices anuncios que se correspondan con tus intereses. Consulta las cookies que almacenamos en nuestra Política de cookies.