Las vulnerabilidades de código están aumentando en frecuencia e impacto. Dado que el software se compone cada vez más de piezas de diferentes proveedores, a las que a menudo se hace referencia como la cadena de suministro de software, puede resultar difícil encontrarlas y repararlas rápidamente.
Una solución a este problema es utilizar una lista de materiales de Software. (SBOM – Software Bill of Materials). Allan Friedman, director de iniciativas de ciberseguridad en la Administración Nacional de Telecomunicaciones e Información (NTIA) del Departamento de Comercio de EE. UU, compartió lo importante que es ser transparente en el funcionamiento interno del código a través de un SBOM.
¿Qué es SBOM?
SBOM es una serie de metadatos que describe el árbol de dependencia de un paquete de software. Incluye información clave como el proveedor, el número de versión y el nombre del componente. Estos detalles básicos como estos son fundamentales al analizar el software en busca de vulnerabilidades, ya que se basan en una variedad de componentes, como se detalla en el diagrama de flujo a continuación (Figura 1).
Figura 1: Ejemplo de elementos SBOM
¿Cuál es el valor de un SBOM?
La transparencia ayuda a que los mercados prosperen. Por ejemplo, los ingredientes y las etiquetas de los alimentos brindan a las personas el conocimiento que necesitan para tomar decisiones inteligentes. Las etiquetas no garantizan que las personas comerán de manera saludable, pero les brindan la información para tomar decisiones de alimentación saludables. De manera similar, un SBOM no resolverá automáticamente todos los problemas de seguridad, pero sí empodera a los equipos para resolverlos de manera más rápida y sencilla. Los SBOM también pueden decirle sobre un componente de software. Por ejemplo, si ve que hay seis versiones de un paquete en un SBOM, existe un alto riesgo de que una de ellas sea vulnerable. Las capacidades van más allá de las vulnerabilidades y se convierten en redundancia. Por ejemplo, la cuestión de cuántos proyectos de código abierto dependen de un solo componente. Esto se describe como el «Problema del ukelele», o el propietario del proyecto podría simplemente abandonar el pasatiempo y tomar el ukelele y dejar todos los proyectos dependientes.¿Por qué no estamos haciendo esto hoy?
Hay muchas razones por las que los SBOM no son una práctica estándar en la actualidad. Si bien gradualmente están ganando terreno , sigue habiendo un problema del huevo y la gallina en el que nadie lo pide y, por lo tanto, no se proporciona. Además, un SBOM no es necesariamente fácil de crear en las cadenas de suministro. Como concepto nuevo, la industria lucha con las mejores prácticas y herramientas a su alrededor. Por ejemplo, un SBOM requiere una denominación coherente, en la que los proveedores e incluso los compañeros de trabajo del mismo grupo pueden asignar nombres diferentes al mismo componente. También existen preocupaciones sobre licencias y código abierto.Cómo construir un SBOM
Hay algunos principios rectores para hacer SBOM con el proceso de la NTIA. Lo más importante es darse cuenta que debe gatear antes de poder caminar. Es necesario un SBOM de referencia para que los equipos puedan alinearse en torno a él. Los SBOM creados deben ser legibles por máquina para que puedan automatizarse fácilmente y luego publicarse en una ubicación conocida o detectable para facilitar su acceso y análisis.Cómo implementar un SBOM
Hay tres formatos para implementar un SBOM hoy:
- SPDIX: Un esfuerzo de base de la Fundación Linux. El programa es un estándar abierto para comunicar información SBOM, incluidos componentes, licencias, derechos de autor y referencias de seguridad.
- CycloneDX: diseñado específicamente para contextos de seguridad y análisis de componentes de la cadena de suministro.
- Etiquetas SWID: compuestas por archivos que registran información única sobre un componente de software y ayudan con las iniciativas de gestión de inventario.
Ejemplo de SBOM
Una prueba de concepto importante fue en el sector de la atención médica, aprovechando una lista de materiales para encontrar vulnerabilidades y componentes explotables. También permitió informar a los proveedores de problemas de software con dispositivos médicos importantes.
Herramientas
Si bien hay muchas herramientas disponibles para hacer SBOM, la NTIA tiene una taxonomía de herramientas para ayudar a los equipos a elegir la correcta (Figura 2 a continuación).
- Producción: Es importante tener cuidado al elegir el formato de su SBOM y generar artefactos, así como analizar y editar listas existentes.
- Consumo: Las buenas herramientas permiten a los equipos leer contenidos y comparar entre SBOM para detectar diferencias.
- Transformación: Se pueden combinar varias fuentes de SBOM y otros datos para la auditoría.
Reconocimiento gubernamental
Como se logró con los dispositivos médicos (una cuestión de vida o muerte), los SBOM deberían ser factibles para hacer esto para otras industrias y aplicaciones, como se indica en la Figura 3. La administración actual reconoce la importancia de la ciberseguridad y emitió una Orden Ejecutiva , que describe los SBOM y su propuesta de valor en la Sección 4.
