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

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.

Si puedes responder de inmediato cuando se divulga una vulnerabilidad

Lo que se necesita inmediatamente después de que se divulga una vulnerabilidad es, en la mayoría de los casos, la respuesta a una sola pregunta: ¿el software que está en funcionamiento contiene la versión afectada de ese componente? Si ya existe un inventario de componentes actualizado, responderla consiste en cotejar registros. Si no existe, se convierte en una investigación que recorre repositorios y entornos en ejecución uno por uno, y el tiempo necesario crece en proporción al número de elementos por revisar. No solo cambia el tiempo, sino también la confianza en el resultado. En una investigación manual, «no encontrado» no prueba que el componente esté ausente, por lo que no se puede emitir con fundamento un juicio de «no afectado». Sin poder separar el ámbito que requiere acción del que no lo requiere, se tiende a aplicar medidas preventivas sobre un ámbito amplio. Además, el momento de la divulgación no se elige. Empezar a construir el inventario después de la divulgación implica que construirlo cuesta tanto como la propia investigación manual, de modo que no sirve como material para llegar a tiempo. Tener preparado en tiempos normales un estado en el que basta con cotejar registros está directamente relacionado con cuánto tiempo se permanece expuesto tras la divulgación.

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.