CRACI frente a Timesys Vigiles

La respuesta corta

Vigiles es el producto de gestión de SBOM y vulnerabilidades de Timesys, que Lynx Software Technologies adquirió en diciembre de 2023; Lynx lo vende ahora como Lynx Vigiles. Está hecho para Linux embebido: una capa de Yocto, meta-timesys, recopila metadatos sobre los paquetes de su imagen y los sube, y Vigiles los coteja con una base de datos de CVE curada, y después hace el seguimiento de las decisiones de triaje y exporta SBOM, VEX e informes de vulnerabilidades.

CRACI es un runner de GitHub Actions. Su build de BitBake se ejecuta en él y, mientras tanto, CRACI registra cada paquete y fuente que descargó el build, limita a dónde puede conectarse el build y sigue monitorizando la SBOM en busca de vulnerabilidades. Ambos productos le ofrecen una SBOM y monitorización de CVE para una imagen de Yocto; se diferencian en de dónde sale la SBOM. Vigiles lee lo que los metadatos de BitBake dicen que entra en la imagen. CRACI registra lo que el build incorporó realmente.

De un vistazo

Lo que Vigiles hace bien

Hecho para Linux embebido. Vigiles se integra con Yocto mediante meta-timesys, y con Buildroot, OpenWrt, Timesys Factory y FreeRTOS, e importa SBOM en SPDX de 2.2 a 3.0.1, CycloneDX de 1.1 a 1.7 y CSV para todo lo demás. Lynx dice que Vigiles, lanzado en 2019, ha procesado más de 90.000 SBOM.

Menos ruido de CVE. Vigiles coteja los componentes con una base de datos de CVE curada en lugar de con datos públicos sin procesar, lo que según Lynx elimina la mayoría de los falsos positivos que producen los datos públicos. Su escáner puede subir los archivos .config completos de su kernel de Linux y de U-Boot, de modo que se filtran los CVE de funciones que usted no compila. Eso importa en Linux embebido: en el informe de ejemplo del README de meta-timesys, 60 de los 62 CVE sin corregir están en el kernel.

Decisiones que perduran entre versiones. Los equipos registran si cada CVE es affected, fixed, deferred o not exploitable, y Vigiles conserva esas decisiones por versión, destaca las CISA Known Exploited Vulnerabilities y exporta SBOM en CycloneDX, SPDX y SPDX Lite junto con VEX e informes de vulnerabilidades. Sus informes también muestran los CVE ya corregidos por parches en su build y los parches disponibles en la capa meta-timesys-security. Lynx cita el CRA de la UE y la EO 14028 entre las normas con las que ayuda, y Vigiles se conecta a Jira y Okta.

En qué se diferencia CRACI

La SBOM de Vigiles solo es tan completa como la visión que BitBake tiene de la imagen. El README de meta-timesys la describe como una recopilación de metadatos sobre los paquetes que se van a instalar, y los paquetes compilados fuera de BitBake, o compilados por él pero ausentes del manifiesto del sistema de archivos raíz, se tienen que enumerar a mano. CRACI no lee metadatos. Es la máquina en la que se ejecuta el build.

Lo que deja fuera la SBOM propia de Yocto

No hemos comparado una SBOM de Vigiles con la de CRACI. Hemos comparado la de CRACI con la SBOM SPDX integrada de Yocto, que también se genera a partir de los metadatos de BitBake. En un build comparado de core-image-sato en un runner ARM64 de 32 vCPU, la SBOM de CRACI contenía todos los componentes de la SBOM de Yocto, más 88 que esta pasó por alto: paquetes del host en la máquina de build, como cpio de Ubuntu, fuentes de GitHub y la GitHub Action actions/upload-artifact, y otras fuentes y herramientas descargadas durante el build. Ninguno de ellos está instalado en la imagen, y todos están en la ruta crítica del build.

Ambas SBOM enumeraban las mismas 653 versiones de crates de Rust, pero la de Yocto las enumera solo por nombre de archivo y URL de descarga, sin package URL. El cotejo de vulnerabilidades funciona con package URL, así que esos crates no se pueden monitorizar desde la SBOM de Yocto. CRACI registra cada uno de ellos con una package URL pkg:cargo.

Control sobre lo que el build puede alcanzar

Una política de egress en el runner decide a qué hosts puede conectarse un job. Se valida antes de que empiece el job, bloquea si falla y envía una alerta ante una infracción. Para Yocto añade una segunda capa al propio BB_ALLOWED_NETWORKS de BitBake, y una política de denegación por defecto impide que una herramienta de build comprometida envíe secretos a un host que el build no necesita.

Procedencia y monitorización a partir del mismo registro

La API devuelve SBOM, trazas de red y procedencia. CRACI no firma la procedencia. CRACI agrega las vulnerabilidades de todos los builds y repositorios, sigue reevaluando las SBOM monitorizadas a medida que aparecen avisos, permite a los equipos de seguridad hacer el triaje de los hallazgos y enviarlos al equipo responsable de la corrección, y muestra qué builds anteriores contenían una dependencia vulnerable, para que usted sepa durante qué periodo estuvo afectado. CRACI es compatible con VEX y puede presentar las notificaciones de vulnerabilidades del CRA en su nombre.

El propio build, en runners más grandes

Vigiles no ejecuta su build; CRACI, sí. Los builds de Yocto se ejecutan en runners de hasta 32 vCPU y 96 GB de RAM, medidos por segundo a $0.002 por vCPU-minuto ($0.004 para un runner de 2 vCPU por defecto). En la misma comparación de core-image-sato, el build sin la generación de SBOM de Yocto tardó un 43 % menos que el build con ella.

Sustituir Vigiles por CRACI

Para las imágenes de Yocto compiladas en GitHub Actions, CRACI cubre aquello para lo que se compra Vigiles: una SBOM para cada build, monitorización de CVE tras el lanzamiento, decisiones de triaje y VEX. Añade lo que una SBOM basada en metadatos no puede darle: los paquetes del host, las fuentes de GitHub y las Actions que utilizó el build, y una política de egress mientras se ejecuta.

Tenga claro a qué renuncia. Los datos de CVE curados de Vigiles y sus filtros de configuración de kernel y U-Boot reducen el ruido de CVE de una forma que CRACI no ofrece. Vigiles informa de qué CVE corrigen ya los parches de su build, algo que CRACI no registra; el SPDX propio de Yocto también incluye esos metadatos de las recetas, así que mantenga create-spdx activado si depende de ellos. Vigiles también cubre Buildroot, OpenWrt y FreeRTOS, se ejecuta dentro de cualquier CI e importa SBOM en muchos formatos. CRACI solo es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta, así que los pipelines de Jenkins o GitLab tendrían que migrar primero a GitHub Actions.

Para el CRA

El Cyber Resilience Act pide a los fabricantes que documenten los componentes de sus productos, incluida una SBOM, y que gestionen las vulnerabilidades mientras el producto tenga soporte, con obligaciones de notificación desde septiembre de 2026. Vigiles ayuda conservando las SBOM, las decisiones sobre CVE y los informes por versión. CRACI produce la evidencia por build de lo que entró en el firmware, con procedencia, monitorización continua y exportación de SBOM en CycloneDX o SPDX. Automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro de software que un fabricante necesita para su proceso más amplio del CRA; ninguna de las dos herramientas hace que un producto cumpla por sí sola. Lea qué exige el CRA.

Trasladar un build de Yocto a CRACI

Configure runs-on: craci en el job de BitBake y elija un tamaño de runner; el workflow sigue ejecutándose en GitHub Actions. El ejemplo de Yocto en la documentación de CRACI compila core-image-sato en el tamaño más grande. Vea cómo funciona CRACI para el IoT industrial y la electrónica de consumo.