Solicitudes de SBOM de clientes: cómo responder

¿Suministra componentes o software embebido a fabricantes? Consulte la guía de SBOM para proveedores, que trata los contratos, VEX y una SBOM por versión de software entregada.

Por qué los clientes lo piden ahora

• El Cyber Resilience Act. Los fabricantes que venden en la UE necesitan una SBOM de su propio producto y deben actuar con diligencia con los componentes que incorporan, de modo que la pregunta se traslada a lo largo de la cadena de suministro.
• NIS2. Las entidades esenciales e importantes deben abordar la seguridad de la cadena de suministro. La directiva no menciona las SBOM, pero una SBOM es una forma de que un comprador vea lo que distribuye un proveedor. Consulte las SBOM como evidencia de NIS2, ISO 27001 y SOC 2.
• Normas sectoriales. La sección 524B de la FDA exige una SBOM para los ciberdispositivos, y otros sectores tienen sus propias normas.
• Su propio trabajo con vulnerabilidades. Un cliente que sabe qué contiene su producto puede saber si una nueva CVE le afecta sin abrir una incidencia de soporte.

Qué acordar antes de enviar nada

Pregunta	Por qué importa
¿Qué producto y qué versión?	Una SBOM describe una sola versión. Envíe la que ejecuta el cliente, no el último build.
¿Qué formato?	La mayoría de las solicitudes aceptan CycloneDX o SPDX. Pregunte si necesitan una versión concreta.
¿Con qué profundidad?	Las dependencias de primer nivel pueden no bastar. Cuente con que le pidan las transitivas.
¿Una vez o con cada versión?	Un contrato puede exigir una SBOM nueva por versión, lo que descarta cualquier proceso manual.
¿En qué condiciones?	Una SBOM muestra cómo está construido su producto. Acuerde las condiciones de confidencialidad y cómo se entrega el archivo.

Qué contiene una buena respuesta

• Una SBOM en el formato acordado, de la versión exacta que ejecuta el cliente.
• Cada componente con su nombre, versión, proveedor, licencia y un identificador de paquete.
• Las relaciones de dependencia, para poder rastrear un paquete transitivo hasta lo que lo incorporó.
• La fecha, la herramienta que la generó y el build del que procede.
• Una nota honesta sobre todo lo que la SBOM no cubre (vea completitud de la SBOM).

Para ver cómo son los archivos, consulte ejemplos de SBOM. Sobre los dos formatos, consulte CycloneDX vs SPDX. Para saber qué comprobará probablemente el cliente al recibirla, consulte la lista de comprobación de calidad de SBOM.

Errores que acaban pasando factura

• Enviar el último build en lugar del distribuido. Los builds no son reproducibles por defecto, así que compilar de nuevo el mismo commit no garantiza la misma SBOM. Solo la SBOM del build que generó la versión muestra lo que recibió el cliente.
• Montarla a mano para la ocasión. Satisface la solicitud una vez, y tendrá que repetirlo para el próximo cliente y la próxima versión. Consulte automatización de SBOM.
• Prometer más de lo que puede repetir. «Enviaremos una con cada versión» es una frase fácil de poner en un contrato y difícil de cumplir sin automatización.
• Dar por terminado el asunto con la SBOM. La siguiente pregunta es «¿les afecta esta CVE?», y llega cuando llega la próxima gran vulnerabilidad.

Cómo estar preparado para la próxima solicitud

Las solicitudes se vuelven fáciles cuando la SBOM ya existe. Genere una para cada versión en el pipeline que la compila, consérvela con la versión y monitorícela en busca de nuevas vulnerabilidades. Así, una solicitud se resuelve con una descarga y una nota breve, y puede responder a la siguiente pregunta a partir del mismo registro.

Cómo lo aborda CRACI

CRACI registra una SBOM de cada build de GitHub Actions que se ejecuta en sus runners, de modo que cada versión ya tiene la suya cuando alguien la pide.

• Exportación en CycloneDX o SPDX, con las dependencias transitivas y las vulnerabilidades encontradas en los componentes.
• Evidencia del propio build. Todos los componentes de la SBOM estaban en el build, y se registran las dependencias ocultas que las herramientas basadas en lockfiles pasan por alto.
• Un estado de completitud en cada job, para que sepa lo que envía antes de enviarlo.
• Historial de builds. Puede ver los builds anteriores y sus SBOM, y qué builds contenían una dependencia vulnerable, dentro de su periodo de retención.
• Respuestas a la siguiente pregunta. CRACI reevalúa de forma continua las SBOM monitorizadas, es compatible con VEX y muestra qué productos ejecutan qué versiones en la vista de inventario.

Solicitudes de SBOM de clientes: preguntas frecuentes

¿Estamos obligados a dar nuestra SBOM a los clientes?

Depende de su mercado y de sus contratos. El Cyber Resilience Act incluye la SBOM en la documentación técnica, que se entrega a una autoridad de vigilancia del mercado cuando la solicita, y no obliga a publicarla. El derecho de un cliente a recibirla suele proceder del contrato, así que compruebe lo que ha acordado.

¿Qué formato de SBOM debemos enviar?

CycloneDX o SPDX, el que pida el cliente. Si no tiene preferencia, cualquiera de los dos sirve. Pregunte si sus herramientas necesitan una versión concreta.

¿Debemos incluir las dependencias transitivas?

El Cyber Resilience Act pide, como mínimo, las dependencias de primer nivel, pero muchos compradores esperan el árbol completo, y las vulnerabilidades suelen estar en paquetes transitivos. Una SBOM completa es la respuesta más segura.

¿Debe entregarse la SBOM al cliente bajo un NDA?

Es una decisión suya y de su cliente. Una SBOM muestra de qué está hecho su producto, por lo que muchos proveedores la comparten en el marco de su contrato vigente o de un NDA en lugar de publicarla.

¿Con qué frecuencia debemos enviar una SBOM actualizada?

Con la que acuerden. Las dependencias cambian con cada versión, así que una SBOM nueva por versión es lo honesto por defecto, y eso solo es práctico si la SBOM sale del build.

¿Y si el cliente pregunta por una versión anterior?

Necesita la SBOM del build que generó esa versión. CRACI conserva el historial de builds dentro de su periodo de retención, 180 días por defecto, con retención personalizada en Enterprise, así que exporte todo lo que deba conservar durante más tiempo.

Nunca hemos hecho una SBOM. ¿Por dónde empezamos?

Empiece por la versión que ejecuta su cliente y una herramienta que trabaje a partir de su build real. Si usa GitHub Actions, trasladar el build a los runners de CRACI le da una SBOM registrada desde la primera ejecución.