SBOM práctico: genera un inventario de dependencias y analiza vulnerabilidades

Cuando aparece una vulnerabilidad en una biblioteca, la primera pregunta no es «¿qué tan grave es?», sino «¿en cuáles productos y versiones la usamos?». Si la respuesta depende de buscar a mano en repositorios y contenedores, el equipo pierde las primeras horas de respuesta. Un Software Bill of Materials (SBOM) es un inventario de los componentes de una versión concreta del software, con sus relaciones y datos de identificación.

El tema ha madurado. La guía de elementos mínimos de CISA pide asociar un SBOM a cada versión o actualización, incluir dependencias transitivas e indicar explícitamente lo que se desconoce. Para dirección de tecnología, el valor no está en producir un JSON para archivarlo: está en poder responder con evidencia qué producto podría estar afectado y a quién llamar.

Tutorial: genera y analiza un SBOM de un proyecto

Este ejemplo usa Syft para generar un SBOM CycloneDX y Grype para comparar sus componentes con una base de vulnerabilidades conocidas. Instala ambas herramientas siguiendo sus instrucciones oficiales y trabaja sobre un proyecto propio o una imagen que estés autorizado a analizar.

1. Elige el artefacto correcto

Si quieres conocer lo que se entrega a producción, analiza la imagen o el paquete construido, no solo el código fuente: el artefacto puede incorporar paquetes del sistema y dependencias que no figuran en el repositorio. Si aún no tienes un artefacto, empieza por el directorio del proyecto y documenta esa limitación. Syft admite directorios e imágenes de contenedor.

2. Guarda el inventario en un formato estándar

syft ./mi-proyecto -o cyclonedx-json=./sbom.cdx.json

El comando produce un archivo que puedes asociar con la versión analizada. Anota también el identificador del commit o el digest de la imagen; un SBOM sin vínculo inequívoco con el artefacto pierde utilidad. Revisa que incluya las bibliotecas que sabes que usa la aplicación y que no esté vacío. La salida de la herramienta es un punto de partida, no una prueba de cobertura completa.

3. Busca coincidencias con vulnerabilidades conocidas

grype sbom:./sbom.cdx.json

Grype admite SBOM en CycloneDX y SPDX. El resultado ofrece candidatos para investigar. Una coincidencia no demuestra por sí sola que el código vulnerable sea alcanzable ni que el producto esté explotado. Antes de priorizar, revisa la versión exacta, el contexto de ejecución, la disponibilidad de corrección y la exposición del producto.

La prueba que evita un SBOM de adorno

Escoge una dependencia conocida de tu aplicación y verifica que el inventario la muestre con nombre, versión y relación con el producto. Luego escoge una dependencia transitiva y comprueba si aparece. Si falta, investiga si el gestor de paquetes, el tipo de artefacto o la configuración del análisis limitan la detección. No rellenes huecos con una falsa certeza: la guía de CISA propone registrar los known unknowns, es decir, partes de la composición todavía no identificadas.

Finalmente, pregunta a soporte y seguridad cuánto tardarían en encontrar todos los productos que incluyen esa dependencia. Si el inventario no permite responder por versión y propietario, el siguiente paso no es comprar otra herramienta: es conectar el SBOM con el catálogo de productos, el pipeline de entrega y la gestión de incidentes.

Cómo integrarlo en el ciclo de entrega

1. Genera el SBOM al construir una versión o imagen nueva.
2. Guárdalo con el identificador del artefacto, fecha, responsable y formato.
3. Analiza vulnerabilidades, registra decisiones y vuelve a consultar cuando aparezcan avisos nuevos.
4. Entrega el inventario a quienes necesitan evaluar el producto, con controles de acceso si corresponde.

Mi criterio es medir el programa por la rapidez y precisión de sus respuestas: «¿qué versiones usan el componente X?», «¿qué sabemos que falta en el inventario?» y «¿quién decide la mitigación?». Un archivo generado automáticamente puede contestar la primera solo si se conserva actualizado y se valida. La guía conjunta de CISA y agencias internacionales sitúa la generación, el análisis y el intercambio dentro de procesos operativos, no como una tarea aislada. Si tu producto se ofrece en la UE, esta trazabilidad también ayuda a preparar el flujo de reporte de vulnerabilidades del CRA.

Fuentes: CISA, elementos mínimos de SBOM; visión conjunta de SBOM; Syft; Grype.