Avance de los estándares SBOM: Snyk y SPDX

Muchas personas conocen el proyecto SPDX por el trabajo realizado en la lista de licencias SPDX. Esta lista de identificadores canónicos para distintas licencias de software se usa en una gran variedad de programas enfocados en desarrolladores, desde Snyk hasta GitHub. Pero el proyecto SPDX, que forma parte de Linux Foundation, tiene un enfoque mucho más amplio: ofrecer un estándar abierto para comunicar información sobre la lista de materiales de software.

Una lista de materiales de software, o SBOM, es una lista de los componentes de una pieza de software. Una analogía común es la lista de ingredientes en el empaque de los alimentos. El software es cada vez más complejo y está compuesto por un número creciente de componentes. Esto no se limita a bibliotecas y frameworks de código abierto; una aplicación moderna puede constar de varios servicios, cada uno con su propia SBOM, empaquetados junto con herramientas que podrían incorporar aún más dependencias.

SPDX busca estandarizar la forma de definir esa SBOM y ofrecer un formato legible por máquinas en torno al cual la industria del software pueda desarrollar herramientas para resolver numerosos problemas de la cadena de suministro.

Esto resulta cada vez más útil para resolver los desafíos actuales de seguridad del software. Apenas el mes pasado, el presidente de EE. UU., Joe Biden, emitió una orden ejecutiva sobre la mejora de la ciberseguridad nacional, que menciona explícitamente la adopción de SBOM y la formalización de sus estándares como un objetivo. Puedes leer más sobre nuestra opinión acerca de la orden ejecutiva en nuestro blog sobre los requisitos de seguridad de la cadena de suministro de software.

Snyk y las SBOM

Los archivos de manifiesto que usan los administradores de paquetes contienen listas de software, pero por lo general no se consideran SBOM. Su enfoque es más limitado y está orientado a un caso de uso específico: contienen solo la información necesaria para instalar el software indicado.

Snyk se integra con una amplia variedad de administradores de paquetes y herramientas para desarrolladores para ayudar a identificar vulnerabilidades en los componentes de software utilizados. Para hacerlo, necesitamos generar una SBOM internamente, normalizar la lista de software y ampliarla con metadatos adicionales de otras fuentes. Las herramientas de Snyk se centran principalmente en presentar esa información junto con los datos sobre vulnerabilidades, pero los clientes de Snyk pueden acceder a la SBOM sin procesar mediante nuestros informes integrados o nuestra potente API.

De hecho, puedes pensar en las herramientas cliente de Snyk, como la CLI y los complementos de CI/CD, como generadoras de una SBOM, mientras que el backend de Snyk recibe una SBOM y devuelve datos sobre vulnerabilidades, o automatiza acciones con esos datos para ayudarte a corregir problemas. Esta amplia experiencia es lo que despierta nuestro interés en los estándares emergentes de este ámbito.

Snyk y SPDX

Aunque SPDX lleva varios años disponible como estándar SBOM, el reciente trabajo en el borrador de la especificación v3.0 es muy prometedor. Hemos estado analizando detenidamente la propuesta preliminar de un perfil de vulnerabilidades para SPDX, que permite agregar datos sobre vulnerabilidades (a veces denominados VEX o explotabilidad de vulnerabilidades en el ámbito de las SBOM) junto con la información sobre los componentes de software.

Para ayudar a validar el trabajo en la especificación, creamos una herramienta sencilla llamada snyk2spdx. snyk2spdx tiene un único propósito: consume los datos subyacentes de las pruebas de Snyk (que incluyen la información de la SBOM) y los genera en formato SPDX v3.0, incluido el perfil de vulnerabilidades. Aquí puedes ver el resultado sencillo.

1$ snyk test --json | npx snyk2spdx | jq
2{
3  "id": "SPDXRef-todo-list",
4  "name": "todo-list",
5  "specVersion": "SPDX-3.0",
6  "profile": [
7    "base",
8    "vulnerabilities"
9  ],
10  "dataLicense": "CC0-1.0",
11  "creator": "Organization: Snyk Ltd",
12  "documentNamespace": "spdx.org/spdxdocs/todo-list-2bd968c5-d497-41ec-83d7-5ee652720c53",
13  "description": "Snyk test result for project todo-list in SPDX SBOM format",
14  "created": "2021-05-05T16:20:28Z",
15  "vulnerabilities": [
16

Esto es solo el encabezado; aquí tienes un enlace al resultado completo de la SBOM si te interesa especialmente el formato.

Creamos esta herramienta para experimentar y enviar comentarios sobre el borrador actual de la especificación. SPDX v3.0 sigue evolucionando y todavía no cuenta con un amplio soporte de herramientas ni con esquemas publicados. Sin duda, estas cosas llegarán con el tiempo y, cuando eso ocurra, probablemente incorporaremos este tipo de funcionalidad a la CLI de Snyk y permitiremos usar SPDX en otras partes de Snyk.

Si te interesan las SBOM en general y VEX en particular, snyk2spdx puede ayudarte a empezar a experimentar. Incluso podrías decidir contribuir al trabajo en la especificación o al esfuerzo más amplio de difundirla y desarrollar software en torno a ella.

El futuro

A medida que SPDX recibe más atención, Snyk trabaja en estrecha colaboración con Linux Foundation para mejorar el estándar y ampliar el ecosistema de herramientas. Esta reciente publicación del blog de Linux Foundation resume por qué y cómo la comunidad de código abierto identificó hace más de una década la necesidad de abordar el desafío de las SBOM.

Los estándares, cuando se aplican en el momento y lugar adecuados, pueden impulsar el avance de las industrias. La orden ejecutiva de Biden deja claro que las SBOM tienen un papel clave para ayudar a abordar los desafíos más amplios de seguridad de la cadena de suministro de software. En Snyk, esperamos seguir contribuyendo a los esfuerzos en este ámbito.