Automatización de SBOM

Por qué dejan de funcionar las SBOM manuales

• Quedan obsoletas en el siguiente build. Las dependencias cambian con cada versión, y una hoja de cálculo solo cambia cuando alguien se acuerda de actualizarla.
• Se quedan en lo que la gente puede ver. Las dependencias directas son fáciles de enumerar. Las dependencias transitivas que hay debajo no lo son, y nadie puede seguirlas a mano.
• Se multiplican. Varios productos con varias versiones con soporte cada uno suponen decenas de archivos, cada uno con su propio responsable y su propia idea de la verdad.
• No responden a la pregunta que importa. Cuando aparece una nueva vulnerabilidad, necesita saber qué versiones contienen el paquete. Buscar en una carpeta de hojas de cálculo es lento, y no puede fiarse de la respuesta.
• No son lo que piden los demás. Los clientes y las herramientas esperan un formato legible por máquina, como CycloneDX o SPDX. Consulte cómo responder a la solicitud de SBOM de un cliente.

Qué hace una buena automatización de SBOM

1. Produce una SBOM para cada build, sin que nadie tenga que ejecutar ni recordar nada.
2. Cubre el árbol completo, dependencias transitivas incluidas, a cualquier profundidad.
3. Vincula cada SBOM a un build, para que sepa qué archivo describe qué versión.
4. Indica lo que no pudo ver, en lugar de presentar una lista parcial como si fuera completa.
5. Exporta un formato estándar, para que la SBOM sirva con la próxima herramienta y el próximo cliente.
6. Sigue vigilando lo que se distribuyó, porque una versión limpia el lunes puede estar afectada el martes.

Tres formas de mantener las SBOM, comparadas

Pregunta	Hoja de cálculo	Escáner en CI	Registrada durante el build
¿Cuándo se actualiza?	Cuando alguien se acuerda	Cuando se ejecuta el paso de escaneo	En cada build
¿De dónde salen los datos?	De las personas	De los lockfiles o del resultado final	De lo que el build descargó realmente
¿Dependencias transitivas?	Rara vez	Las que pueda deducir	A cualquier profundidad
¿Dependencias ocultas, como descargas de scripts de instalación?	No	Se pasan por alto	Registradas
¿Paquetes restaurados desde una caché de CI?	No	Depende de la herramienta	Registrados y marcados como procedentes de caché
¿Monitorización de vulnerabilidades?	Manual	Normalmente, una herramienta aparte	Integrada con CRACI

Automatizar con un escáner es una mejora real frente a una hoja de cálculo, pero sigue deduciendo lo que se incluyó. Para conocer el razonamiento, consulte por qué el build es la fuente de verdad.

Qué pasa con sus hojas de cálculo

Los datos de componentes salen de ellas: las versiones y los paquetes proceden del build, así que nadie tiene que teclearlos. Se queda el conocimiento que solo tiene su equipo, como qué productos existen, quién es su responsable y qué versiones siguen teniendo soporte. Esa es la parte que merece el tiempo de una persona.

Cómo lo aborda CRACI

CRACI sustituye sus runners alojados en GitHub por otros más rápidos y de menor coste, y registra la SBOM mientras se ejecuta cada build. Usted configura runs-on: craci, y sus ejecuciones siguen apareciendo en GitHub. Los builds estándar obtienen una SBOM completa sin configuración. Los builds con registros de paquetes propios o configuraciones de contenedores poco habituales pueden necesitar alguna.

• Registrada, no escaneada. CRACI ve el tráfico que entra en cada build, incluidas las dependencias ocultas que las herramientas basadas en lockfiles pasan por alto. Todos los componentes de la SBOM estaban en el build.
• Un estado de completitud en cada job, para que sepa cuándo un build no se pudo registrar por completo y por qué.
• Exportación en CycloneDX y SPDX, con las dependencias transitivas y las vulnerabilidades encontradas en los componentes.
• Una sola vista de todos los productos. La vista de inventario muestra qué versiones de software están desplegadas en qué productos, y CRACI reevalúa de forma continua las SBOM monitorizadas.

Para implantarlo en equipos con pipelines distintos, consulte la generación de SBOM en todos los equipos de ingeniería.

Automatización de SBOM: preguntas frecuentes

¿Qué es la automatización de SBOM?

Producir una lista de materiales de software como parte del build, de modo que cada versión tenga la suya sin que nadie la cree a mano. Las mejores configuraciones también monitorizan cada SBOM en busca de nuevas vulnerabilidades después de distribuir la versión.

¿Podemos mantener nuestras SBOM en Excel?

Una hoja de cálculo puede servir como primer inventario, pero es difícil de mantener al día y no llega a las dependencias transitivas. Tampoco es un formato de SBOM estándar. Los clientes y las herramientas de seguridad suelen esperar CycloneDX o SPDX, y el Cyber Resilience Act pide un formato de uso común y legible por máquina.

¿La automatización de SBOM exige un paso nuevo en cada pipeline?

Con la mayoría de los generadores, sí: hay que añadir un paso a cada workflow y mantenerlo actualizado. CRACI registra la SBOM en el runner, así que no hay ningún paso que añadir a sus jobs.

¿Qué ecosistemas registra CRACI?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, paquetes de Debian y Ubuntu (apt), paquetes de Alpine (apk) y fuentes Git, además de las descargas de Yocto y OpenEmbedded. Maven y Java están en la hoja de ruta.

¿Con qué sistemas de CI y plataformas es compatible CRACI?

Hoy, con GitHub Actions; otros sistemas de CI están en la hoja de ruta. Los runners son Linux x86-64 y ARM64 hoy, con Windows y macOS en la hoja de ruta.

¿Qué ocurre con los componentes que compramos a proveedores?

Puede añadir las SBOM de los proveedores a CRACI, de modo que los componentes comprados se monitoricen junto con sus propios builds.

¿Cuánto cuesta?

CRACI cobra solo por los minutos de build: $0.002 por vCPU-minuto ($0.004 para un runner predeterminado de 2 vCPU), medido por segundo, sin cuota mensual y sin cargo por SBOM.