Qué es un SBOM Lo que Necesitas Saber
86
Views

En el vertiginoso mundo de la tecnología y la ciberseguridad, surgen términos clave que es fundamental comprender. Uno de estos términos es el ‘SBOM‘ o ‘Bill of Materials’ de software.

En este artículo, exploraremos a fondo qué es un SBOM y por qué es crucial para la gestión de riesgos y la seguridad cibernética.

¿Qué Es Un Sbom?

Concepto de SBOM o Software Bill of Materials
Concepto de SBOM o Software Bill of Materials

Una lista de materiales de software (Software Bill of Materials o SBOM, por sus siglas en inglés) es una lista jerárquica y detallada de todas las dependencias, sus números de versión y la procedencia de una determinada pieza de software. También puede incluir otros datos, como el tipo de licencia o detalles sobre qué base de datos consultar para la divulgación de vulnerabilidades. Los SBOM no se limitan a las aplicaciones y pueden crearse para muchas cosas, como una imagen Docker, un sistema operativo o incluso componentes de hardware.

¿Para Qué Sirve Un Sbom?

Aunque dependen en gran medida de tus objetivos, los SBOM pueden tener muchos usos. Tener todos los datos relevantes a mano puede conducir a resultados más rápidos durante la respuesta a incidentes, mejores decisiones de políticas respaldadas por hechos, y una mayor conciencia de la seguridad de su software en general. Los SBOM son valiosos durante toda la vida de un programa de seguridad y, en algunos casos, son fundamentales para la captación de clientes.

¿Cuándo debería empezar a recopilar, crear y utilizar los SBOM? Ahora mismo. O justo después de leer este blog. Los SBOM son el tipo de recurso en el que desea invertir antes de verse afectado por un incidente que podrían ayudarle a resolver.

¿Qué Aspecto Tienen Los Sboms?

Ejemplo De Entrada Sbom

He aquí un ejemplo de cómo puede ser una entrada en la práctica:

{
 "id": "6374b5ebf62f54ea", 
 "name": "@types/node", 
 "version": "17.0.21", 
 "type": "npm", 
 "foundBy": "javascript-package-cataloger", 
 "locations": [ 
  { 
   "path": "/usr/local/lib/python3.8/dist-packages/playwright/driver/package/node_modules/@types/node/package.json", 
   "layerID": "sha256:062e37f31d9f5b9bcdcdac59e1138ac60b2a4997aeb916f1d140f5b55c6c7144"
   } 
  ],
  "licenses": [ "MIT" ], 
  "language": "javascript", 
  "cpes": [ 

"cpe:2.3:a:\\@types\\/node:\\@types\\/node:17.0.21:*:*:*:*:*:*:*", 

"cpe:2.3:a:*:\\@types\\/node:17.0.21:*:*:*:*:*:*:*" 
 ], 
 "purl": "pkg:npm/%40types/node@17.0.21", 
 "metadataType": "NpmPackageJsonMetadata", 
 "metadata": { 
 "name": "@types/node", 
 "version": "17.0.21", 
 "author": "", 
 "licenses": [
   "MIT" 
  ], 
  "homepage": "https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node", 
  "description": "", 
  "url": "https://github.com/DefinitelyTyped/DefinitelyTyped.git",
  "private": false
  } 
}

Aquí podemos ver que se registran muchos aspectos: la licencia, el número de versión, la URL del paquete e incluso dónde está instalado el paquete.

Este SBOM está en un formato de la herramienta syft. Otros formatos para SBOM son CycloneDX y SPDX. Puedes encontrar controversia en línea sobre qué formato usar, pero tener un SBOM en cualquier formato es mejor que no tenerlo mientras intentas decidir cuál es el mejor para tu caso de uso. (Además, syft puede convertir entre formatos).

Formatos

Cyclonedx

CycloneDX fue creado por el Open Web Application Security Project (OWASP). De ello se deduce que se creó pensando en la ciberseguridad. Esto se ve reforzado por el hecho de que los SBOM en formato CycloneDX pueden incluir información sobre vulnerabilidades o enlazar con un VEX (Vulnerability Exploitability eXchange) independiente, CycloneDx cumple los requisitos mínimos de la NTIA para SBOM.

SPDX

SPDX (Software Package Data Exchange) fue desarrollado por la Fundación Linux. Inicialmente se centró en la documentación de licencias utilizadas en componentes de software, pero también admite información de seguridad. La especificación SPDX es una norma abierta internacional (ISO/IEC 5962:2021) y cumple los requisitos mínimos de la NTIA para SBOM.

Otros

Existen otras especificaciones (nuevas y antiguas) que no se mencionan aquí. Por ahora, CycloneDX y SPDX son los principales formatos a tener en cuenta cuando se trabaja con SBOM.

Fuentes

Los SBOM pueden generarse para diferentes capas relacionadas con el software. He aquí algunos ejemplos:

  • Hardware
  • Sistema operativo
  • Compilador
  • Dependencias transitivas y directas
  • Empaquetador
  • Aplicación

Esta lista no es exhaustiva. Es posible que existan otras capas para las que se puedan generar SBOM. Algunas de estas capas pueden estar fuera de su alcance. Por ejemplo, si usted es un consumidor de aplicaciones de software, necesitará recibir SBOMs del editor de software para capas como el compilador, y posiblemente para dependencias transitivas.

Por Qué Son Importantes Las Sboms

Aunque los detalles varían según los casos de uso, he aquí por qué los SBOM son importantes, en general.

  1. Las agencias gubernamentales de EE.UU. comenzarán a exigir SBOMs a sus proveedores de software (para más detalles, ver Timeline for the United States Executive Order on Improving the Nation’s Cybersecurity).
  2. Los SBOM pueden ayudar a mejorar su postura de seguridad, proporcionando visibilidad sobre la profundidad de su software instalado, y la seguridad de la cadena de suministro de software de sus proveedores. Esto le permite reforzar proactivamente los puntos débiles o desarrollar detecciones en áreas que no pueden reforzarse.
  3. Cuando una vulnerabilidad se hace pública, los SBOM pueden proporcionar visibilidad de su riesgo potencial de explotación, especialmente si la vulnerabilidad se encuentra en una biblioteca en lugar de en el software principal (por ejemplo, Apache Log4j). Esto puede acortar significativamente el tiempo de identificación del riesgo, permitiendo que los esfuerzos de resolución o remediación comiencen antes.

Cómo Generar Un Sbom

En primer lugar, es de esperar que sus proveedores de software proporcionen SBOM para las capas de información que están más allá de su visibilidad. Por ejemplo, no siempre es posible generar un SBOM a partir de un binario resultante para el compilador utilizado para crearlo.

Además, es importante invertir en automatización. El software es un blanco móvil. Cuando se actualiza o se instalan nuevos paquetes, es necesario recopilar, crear o regenerar las SBOM para mantener el conocimiento del inventario en su conjunto. La automatización de este proceso, especialmente durante el desarrollo del software, reducirá los problemas de adopción causados por los gastos generales adicionales.

Herramientas

Las siguientes herramientas pueden utilizarse para generar SBOM para el software que cree o los artefactos que reciba (como imágenes Docker).

Mi favorita entre ellas es syft por su versatilidad y compatibilidad, pero otras de esta lista pueden ser útiles para razones específicas, como una mejor integración en tu entorno. Esta lista no es exhaustiva; existen muchas otras herramientas en este ámbito. Además, estas herramientas son específicas para la creación de SBOM. Hay muchas otras que son más un conjunto de herramientas para la seguridad del software en general.

Ejemplo

En este ejemplo, se está creando un SBOM en formato syft JSON a partir de una imagen Docker (mcr.microsoft.com/playwright/python:focal). A continuación, la salida se visualiza en jless. (Para más información sobre cómo trabajar con datos en formato JSON, lee este blog que escribí sobre el tema).

Creación de un SBOM mediante syft
Creación de un SBOM mediante syft

Figura 1 – Creación de un SBOM mediante syft a partir de una imagen Docker

El proceso para crear un SBOM para un directorio es muy similar. El comando tiene el siguiente aspecto:

syft packages dir:path/to/walk

¿Necesitas un SBOM para una infraestructura como el sistema operativo de un dispositivo virtual? Apunte syft a la raíz de la unidad:

syft packages dir:/

Cómo Utilizar Las Sboms

Escaneado Único

Hay ocasiones en las que se desea analizar una única SBOM en busca de vulnerabilidades. Por ejemplo, puede ser útil analizar SBOM individuales durante el proceso de adquisición de software. O si usted es un desarrollador, puede que desee analizar el estado de su software después de actualizar las dependencias. Para esos momentos, aquí tiene un par de sugerencias:

GRYPE

Anchore, el creador de syft, tiene otra herramienta útil llamada grype. Al igual que syft, es muy versátil y, de hecho, utiliza syft para operaciones relacionadas con SBOM bajo el capó. Con grype, puede analizar un directorio, una imagen contenedora (en varios formatos) o un SBOM (en formato syft, SPDX o CycloneDX). Construye una base de datos de vulnerabilidades en disco a partir de una variedad de fuentes de datos de vulnerabilidades disponibles públicamente. La salida de grype es muy utilitaria. Es perfecto para herramientas automatizadas, proporcionando salida en una variedad de formatos legibles por máquina.

BOMBER

bomber puede leer los tres formatos SBOM mencionados en este blog (CycloneDX, SPDX, syft). Requiere un SBOM para realizar su escaneo, por lo que emparejarlo con algo como syft funciona bien para imágenes o directorios. Aunque por defecto sólo consulta una única base de datos de vulnerabilidades (OSV), también soporta Sonatype OSS Index (con una cuenta gratuita de sonatype) o snyk Vulnerability DB (con una cuenta de pago de snyk). La salida estándar de bomber es muy elegante. Y aún mejor, dará salida a un archivo HTML que puede ser compartido, por ejemplo, como un archivo adjunto de correo electrónico.

Agregación

Como habrás adivinado, los SBOM pueden acumularse rápidamente. Desde los de los paquetes de software hasta los de todas sus bibliotecas, por no hablar de los de la infraestructura en la que se instalan. Es necesario crear un plan para acorralar los SBOMS, aprovecharlos y supervisarlos frente al panorama de amenazas en constante cambio. He aquí dos excelentes herramientas que le ayudarán a hacerlo:

GUAC

GUAC es capaz de ingerir muchos tipos de artefactos. Actualmente incluye SBOM (en formato CycloneDX o SPDX), SLSA (Supply-chain Levels for Software Artifacts), In-toto ITE6, OpenSSF Scorecard y Dead Simple Signing Envelope. Se componen para crear un gráfico que puede consultarse sobre cualquier aspecto de los documentos relacionados. Un buen ejemplo de cómo combinar el gráfico con el OSV Certifier para luego poder consultar vulnerabilidades de Log4j se encuentra en el documento Setup + Demo. GUAC está en sus primeras etapas, por lo que están buscando colaboradores. Puede ser una herramienta útil de exploración de datos, pero tiene un largo camino por recorrer antes de que una buena interfaz sea creada y envuelta alrededor de ella.

Pista de dependencia OWASP (OWASP dependency track)

OWASP dependency track es un tablero común para rastrear y analizar continuamente SBOMs para una variedad de usos. Es un excelente lugar para agregar todos tus SBOMs. Incluso mejor, tiene un buen soporte de notificaciones y se integra con todas las principales aplicaciones de chat, así como con el correo electrónico. El soporte de Integración Continua para tu canal de software (donde los SBOMs deben ser generados para cualquier software que crees) es proporcionado por un par de plugins disponibles del sistema CI/CD, o por una API muy robusta. Una vez cargadas, las vulnerabilidades se pueden triar para crear una perspectiva general de su panorama de seguridad de software actual.

Utilización

Disponer de sus SBOM puede ayudar a responder a multitud de preguntas con mayor rapidez que el esfuerzo manual. Pueden proporcionar una visión más profunda de los rincones a los que los escáneres de vulnerabilidades no pueden acceder. Y tener los SBOMs continuamente comprobados contra vulnerabilidades recién descubiertas y publicadas puede acortar considerablemente el tiempo medio para remediar (MTTR).

Primer Ejercicio De Reflexión

Como ejercicio de reflexión, imaginemos (o, para algunos, recordemos) una situación como la de Log4j, que es un buen ejemplo para este primer ejercicio porque se trataba de una vulnerabilidad en una biblioteca utilizada por las aplicaciones. Sin SBOM, las preguntas deben plantearse a los desarrolladores de la aplicación. Hay un tiempo de espera inherente en que esos desarrolladores de la aplicación lean las preguntas y respondan. Además, el uso de diferentes versiones de la aplicación podría hacer que las preguntas se multiplicaran. En el caso de una aplicación vulnerable, esto también desvía la atención de los desarrolladores de la actualización de la aplicación para abordar la vulnerabilidad. Todo este trabajo manual y el retraso en la comunicación generan una sobrecarga y un tiempo de espera desafortunados.

Ahora, imaginemos la misma situación, pero la aplicación ha sido enviada con SBOMs. Usted es capaz de consultar los SBOMs y compararlos con la divulgación de vulnerabilidades para determinar si la aplicación era vulnerable, sin necesidad de preguntar a los desarrolladores de la aplicación o ir a buscar archivos para comparar contra versiones. Incluso mejor, si tiene una monitorización continua de las vulnerabilidades que se comparan con sus SBOM disponibles, es probable que se le notifique automáticamente.

La supervisión continua de su colección de SBOM acorta el tiempo de saneamiento más que cualquier otra cosa que pueda hacer, porque sabrá si es vulnerable sin siquiera preguntar.

Segundo Ejercicio De Reflexión

Hagamos otro ejercicio de reflexión. En este caso, reduciremos un poco el alcance. Pensemos en una situación como la de la puerta trasera Sunburst de la plataforma Orion de SolarWinds. El alcance es menor porque existe un rango de versiones conocido susceptible de ser explotado, por lo que no necesitamos ir hasta los desarrolladores de la aplicación en busca de respuestas. La comprobación de la vulnerabilidad es mucho más sencilla. ¿Está ejecutando una versión vulnerable del software? Incluso una solución de inventario de software medianamente decente podrá responder a esta pregunta. Pero la pregunta más importante (especialmente durante la respuesta a incidentes) es: ¿Durante cuánto tiempo hemos sido vulnerables? Esta pregunta crea la ventana para sus esfuerzos de remediación y pivotalmente da forma al tamaño del esfuerzo necesario para garantizar la continuidad del negocio.

Así pues, comienza el trabajo manual. Debe decidir si va a lanzar una investigación completa de todos los indicadores de compromiso en todo su entorno. O puedes intentar primero identificar cuándo y dónde existió el software a lo largo del tiempo y centrar tus esfuerzos ahí.

La situación es muy distinta si las SBOM están disponibles y se han agregado. Puede identificar rápidamente las versiones y dónde están desplegadas. De hecho, si los SBOM se supervisan continuamente, la respuesta puede estar ya en su bandeja de entrada. Una vez más, el tiempo de remediación se acorta drásticamente.

Tercer Ejercicio De Reflexión

¿Qué opinas de esto? Imagina que eres nuevo en una organización y estás trabajando para fortalecer la seguridad. Tu primera misión es echar un vistazo al terreno. Necesitas entender qué tienes. Luego, viene la tarea de evaluar cuánto estás expuesto a las vulnerabilidades, para que puedas enfocar tu tiempo y energía donde realmente importa y lograr un impacto positivo significativo.

Sin SBOM, hay que hacerlo con otras herramientas que no son del todo adecuadas para el trabajo. O peor aún, debes hacerlo manualmente.

Puedes colocar SBOMs en algo como OWASP dependency track y saber en la primera hora dónde encontrar las mayores debilidades del sistema.

Cuarto Ejercicio De Reflexión

O tal vez estés a cargo de la adquisición de software para una organización. ¿Cómo evalúas la seguridad de un nuevo programa informático que te planteas comprar? Hay muchas formas de hacerlo, y el análisis de una lista de materiales suministrados no hace sino aumentar su visibilidad. El uso de una herramienta para escanear un SBOM proporcionado puede permitirte saber en qué te estás metiendo e incluso puede ayudarte a orientar las preguntas relacionadas con la forma en que el proveedor asegura tu cadena de suministro de software durante el proceso de adquisición.

Reflexiones Finales

Las SBOMs no van a desaparecer – se vuelven más integrales para un programa exitoso de seguridad de la información con cada grado de separación de la creación de software. Si aún no lo has hecho, no hay mejor momento que éste para empezar a recopilar (o crear) SBOM para tu entorno. Y recuerda, los SBOM no son estáticos, por lo que merece la pena invertir tiempo en su automatización. Esa automatización y previsión pueden ahorrarte un tiempo valioso cuando llegue el próximo tsunami de explotación de software.

Categorías:
Diccionario

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *