SBOM - Lista de materiales de software
Lectura de 2 min aprox.
Un SBOM (Software Bill of Materials) es una «lista de materiales» que enumera todos los componentes que conforman un software (bibliotecas, frameworks, paquetes dependientes, etc.). Aplica al software el concepto de BOM (lista de materiales) de la industria manufacturera, registrando en un formato legible por máquina qué versión de qué biblioteca se utiliza. Impulsado por el aumento de los ataques a la cadena de suministro y el incidente de Log4Shell en 2021, ha ido ganando atención mundial como medio para garantizar la transparencia del software.
Antecedentes históricos y legislación
El concepto de SBOM en sí se venía debatiendo desde principios de la década de 2010, pero el punto de inflexión llegó con la Orden Ejecutiva 14028 (Executive Order 14028), firmada por el presidente estadounidense Biden en mayo de 2021. Esta orden ejecutiva obligaba a entregar un SBOM con el software suministrado al gobierno federal, exigiendo la transparencia de la cadena de suministro de software a nivel nacional. Log4Shell (CVE-2021-44228), que salió a la luz en diciembre del mismo año, demostró de forma drástica que esta política era acertada. Organizaciones de todo el mundo investigaron con urgencia si sus sistemas contenían Log4j; las que habían preparado un SBOM pudieron identificar el alcance del impacto en cuestión de horas, mientras que las que no lo habían hecho tardaron semanas.
Los dos formatos principales
Gestionado por la Linux Foundation. Estandarizado internacionalmente como ISO/IEC 5962:2021. Destaca en la descripción de la información de licencias, lo que lo hace muy adecuado para la gestión del cumplimiento de código abierto. Admite los formatos JSON, RDF y Tag-Value.
Gestionado por OWASP. Diseñado específicamente para casos de uso de seguridad, facilita la integración de la información de vulnerabilidades y de VEX (Vulnerability Exploitability eXchange). Admite los formatos JSON, XML y Protocol Buffers.
Cuál elegir depende del propósito. Si el objetivo principal es el cumplimiento de licencias, SPDX es lo apropiado; si el objetivo principal es la gestión de la seguridad, CycloneDX encaja mejor. En la práctica, cada vez más organizaciones generan ambos y los usan según el propósito.
El flujo de generación del SBOM
Herramientas de generación automática
Crear un SBOM manualmente es poco práctico. El software moderno tiene de cientos a miles de dependencias, por lo que el uso de herramientas de generación automática es un requisito. Entre las herramientas más destacadas, Syft de Anchore puede generar un SBOM tanto a partir de imágenes de contenedor como de sistemas de archivos y es fácil de integrar en una canalización de CI/CD. Trivy de Aqua Security puede realizar el escaneo de vulnerabilidades y la generación de SBOM con una sola herramienta, llevando el proceso hasta el cotejo con la base de datos de CVE. El Dependency Graph de GitHub y el Dependency Scanning de GitLab también incorporan funciones de generación de SBOM, lo que permite la gestión a nivel de repositorio.
Errores comunes
Existe la idea errónea de que «hacer un SBOM te hace seguro», pero un SBOM no es más que una herramienta de visualización y, por sí solo, no mejora la seguridad. Lo importante es el proceso operativo de actualizar continuamente el SBOM, cotejarlo con las vulnerabilidades recién divulgadas y conectar eso con la gestión de parches. Además, un SBOM debe incluir no solo las dependencias directas, sino también las dependencias transitivas (bibliotecas de las que, a su vez, depende una dependencia). Incluso en el caso de Log4Shell, muchas organizaciones se vieron afectadas aunque no usaran Log4j directamente, porque los frameworks que utilizaban dependían internamente de Log4j.
Casos de uso reales
«La mañana siguiente a la divulgación de Log4Shell, nuestro equipo, que tenía un SBOM mantenido, identificó en dos horas los 12 servicios afectados y terminó de parchearlos todos antes del mediodía. Mientras tanto, el departamento sin SBOM dedicó dos semanas a una investigación manual, permaneciendo expuesto al riesgo todo ese tiempo.»
El panorama general de la seguridad de la cadena de suministro se explica en detalle en el artículo sobre ataques a la cadena de suministro, y las formas seguras de usar el código abierto se tratan en el artículo sobre auditorías de seguridad de código abierto. Para construir la base de seguridad de una organización, la lista de verificación de seguridad para startups también es una referencia útil.libros sobre seguridad de la cadena de suministro de software (Amazon) también resultan útiles en la práctica.
¿Te resultó útil este artículo?