Lista de materiales de software (SBOM)

Una lista de materiales de software (SBOM) es un inventario formal y legible por máquinas de cada componente de una pieza de software: bibliotecas, sus versiones, licencias e información del proveedor.

Al igual que la etiqueta de un alimento enumera sus ingredientes, una SBOM le permite responder en segundos: ¿este producto contiene la versión vulnerable de X? Sin ella, esa pregunta puede requerir días de investigación manual.

Cuando aparece una vulnerabilidad crítica, la primera pregunta operativa es el alcance de la exposición: ¿cuáles de nuestros productos incluyen el componente afectado?

Durante el incidente de Log4Shell, las organizaciones con SBOM consultaron su inventario y priorizaron las medidas en cuestión de horas. Las que no tenían SBOM pasaron semanas buscando con grep en directorios de compilación. Cada vez más, los reguladores y los grandes compradores exigen SBOM como condición de contratación.

• Análisis rápido del impacto de las vulnerabilidades
• Cumplimiento de licencias y seguimiento de obligaciones
• Transparencia de la cadena de suministro para clientes y auditores

Dominan dos estándares abiertos. Normalmente, las herramientas pueden convertir uno al otro.

• SPDX — un estándar de Linux Foundation, sólido en materia de licencias y ampliamente aceptado por los reguladores
• CycloneDX — un estándar de OWASP, centrado en la seguridad y compatible con datos de vulnerabilidades y relaciones entre dependencias

Evite inventar su propio formato; los consumidores y los analizadores esperan estos formatos.

Cada entrada de componente debe contener suficiente información de identidad para poder compararla con fuentes de vulnerabilidades. Estos son los campos principales:

• nombre y versión — exactos, no un rango
• PURL (URL de paquete) — un identificador universal como pkg:npm/lodash@4.17.21
• hash — para verificar la integridad
• licencia — identificador de licencia SPDX
• proveedor — quién lo produjo

Genere SBOM automáticamente a partir del código fuente o de un artefacto compilado. Syft es un generador común para distintos ecosistemas que produce ambos estándares.

Una SBOM generada en distintas etapas captura realidades diferentes.

• SBOM de código fuente — lo que declara el manifiesto; puede omitir código incluido en paquetes o incorporado mediante vendoring
• SBOM de compilación — lo que incorporó realmente la compilación; es la más precisa para una versión
• SBOM de tiempo de ejecución / implementada — lo que está presente realmente en la imagen en ejecución, incluidos los paquetes del sistema operativo

Para garantizar la seguridad de la cadena de suministro, genérela durante la compilación a partir del artefacto real y analice también el contenedor final para detectar paquetes del sistema operativo.

Una SBOM se vuelve especialmente útil cuando se proporciona a un motor de comparación que asocia los componentes con CVE conocidas. Esto desacopla la generación del análisis: puede analizar una SBOM antigua el día en que se divulga una nueva CVE.

Una SBOM puede mostrar un componente vulnerable que en realidad no es explotable en su producto (la función vulnerable nunca se llama). Un documento VEX (Vulnerability Exploitability eXchange) registra esa evaluación.

VEX reduce el ruido: en lugar de que cada cliente entre en pánico por una CVE incluida en la lista, puede publicar una declaración de not_affected con su justificación, o de affected con las medidas de corrección. Convierte un inventario sin procesar en una priorización práctica.

Una SBOM solo es confiable si es auténtica y está vinculada al artefacto exacto que describe. Fírmela y adjúntela como una atestación, no como un archivo suelto.

Las SBOM manuales quedan obsoletas de inmediato. Integre la generación en el flujo para que cada versión produzca y almacene una como artefacto de compilación, idealmente firmada y analizada en el mismo trabajo.

• Genérela a partir del artefacto compilado, no solo del repositorio
• Almacene las SBOM en un registro consultable identificado por versión
• Vuelva a analizar las SBOM almacenadas periódicamente con fuentes de CVE actualizadas
• Bloquee las publicaciones según el resultado del análisis de vulnerabilidades

Las SBOM fallan silenciosamente cuando se tratan como un simple requisito que marcar.

• Obsoleta — se genera una vez y nunca vuelve a generarse
• Incompleta — omite paquetes del sistema operativo y código enlazado estáticamente o incorporado mediante vendoring
• Sin verificar — no hay ningún hash que la vincule al artefacto implementado
• Sin uso — se produce, pero nunca se analiza ni se consulta

El objetivo es una SBOM precisa, regenerada, firmada y analizada continuamente, no un archivo JSON aislado.

Aplique lo aprendido a un escenario de incidente.

Ahora puede inventariar el contenido de su software y actuar en consecuencia.

• Una SBOM es una lista legible por máquinas de cada componente, en formato SPDX o CycloneDX
• Identifique los componentes mediante su PURL, versión, hash y licencia
• Genérela durante la compilación y pásela después a un motor de comparación (grype, osv-scanner) para detectar CVE
• Utilice VEX para declarar la explotabilidad real y reducir las falsas alarmas
• Firme y automatice el proceso en CI; vuelva a analizar las SBOM almacenadas con fuentes nuevas

A continuación: demostrar el origen de los artefactos mediante su firma.