Las vulnerabilidades de código están aumentando en frecuencia e impacto dado que el software se compone cada vez de más 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).
¿Qué es SBOM?
Imagina que estás construyendo una casa, para ello la idea sería llevar a cabo esta tarea de manera eficiente. Por lo que necesitas una lista detallada de todos los materiales que utilizarás: desde ladrillos y cemento hasta tuberías y cables eléctricos.
De manera similar, en el mundo del desarrollo de software, 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.
Figura 1: Ejemplo de elementos SBOM
Esencialmente, el SBOM es el equivalente digital de una lista de materiales de fabricación. Detalles básicos como estos son fundamentales al analizar el software en busca de vulnerabilidades ya que se basan en una variedad de componentes.
¿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 acuerdo a lo anterior, podemos indicar que el propósito principal de un SBOM es proporcionar visibilidad sobre las dependencias de un software. Esto incluye no solo los paquetes directamente incluidos en la aplicación, sino también las dependencias transitivas: los componentes en los que confían tus propias dependencias. Esta visibilidad es esencial para identificar cualquier paquete riesgoso que pueda comprometer la seguridad de tu aplicación.
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», el propietario del proyecto podría simplemente abandonar el pasatiempo y tomar el ukelele y dejar todos los proyectos dependientes.
Si bien actualmente no todos los proveedores exigen un SBOM al adquirir software, la Administración Nacional de Telecomunicaciones e Información de EE. UU. ha sentado las bases para su posible requerimiento futuro. Además, en un entorno donde los ataques cibernéticos contra componentes de código abierto están en aumento. Por lo que, contar con un SBOM te proporciona información vital para buscar vulnerabilidades, problemas de licencias y otros componentes riesgosos.
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).
La taxonomía se centra en SBOM:
- 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.
La NTIA también fomenta la interoperabilidad entre herramientas para que todos juntos puedan generar más conciencia y aumentar el uso.
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.
El futuro de los SBOM
No solo en los EE. UU. Sino a nivel mundial, los gobiernos y la industria ven los SBOM como cada vez más críticos para la seguridad. Vemos un futuro en el que los SBOM se reconocen y aprovechan. Existe la visión de que más organizaciones aprovechen los SBOM y ayuden a la comunidad a refinar las herramientas para satisfacer las necesidades más amplias de la industria. SBOM no es la solución a todas sus preocupaciones de seguridad, sino que los equipos los reconocen como parte de las decisiones de seguridad inteligentes.
Beneficios del SBOM para desarrolladores y consumidores
Para los desarrolladores de software, mantener un SBOM ayuda a rastrear las dependencias del proyecto, facilita la identificación de componentes vulnerables y mejora la consistencia del trabajo en equipo. Para los consumidores, un SBOM proporciona transparencia sobre el software adquirido, garantizando que cumpla con los requisitos de seguridad y arquitectura internos, y reduce los riesgos asociados con el uso de software de terceros.
Finalmente, ¿es importante contar con un SBOM? La respuesta es sí, es una herramienta esencial para un desarrollador de software seguro, ya que le proporciona visibilidad sobre las dependencias de software, le ayuda a gestionar riesgos y vulnerabilidades, y promueve la transparencia en el desarrollo y adquisición de software. Al adoptar un enfoque proactivo para la gestión de dependencias, las organizaciones pueden fortalecer su seguridad y construir productos de software más seguros y confiables.
