CRACI vs Timesys Vigiles

La risposta breve

Vigiles è il prodotto di SBOM e gestione delle vulnerabilità di Timesys, acquisita da Lynx Software Technologies nel dicembre 2023; oggi Lynx lo vende come Lynx Vigiles. È pensato per Linux embedded: un layer Yocto, meta-timesys, raccoglie i metadati sui pacchetti della Sua immagine e li carica, e Vigiles li confronta con un database CVE curato, quindi traccia le decisioni di triage ed esporta SBOM, VEX e report sulle vulnerabilità.

CRACI è un runner GitHub Actions. La Sua build BitBake gira su di esso e, durante l'esecuzione, CRACI registra ogni pacchetto e sorgente scaricati dalla build, limita dove la build può connettersi e continua a monitorare le vulnerabilità della SBOM. Entrambi i prodotti Le offrono una SBOM e il monitoraggio delle CVE per un'immagine Yocto; la differenza sta nella provenienza della SBOM. Vigiles legge ciò che i metadati di BitBake dicono che entra nell'immagine. CRACI registra ciò che la build ha effettivamente scaricato.

In sintesi

Che cosa fa bene Vigiles

Fatto per Linux embedded. Vigiles si integra con Yocto tramite meta-timesys e con Buildroot, OpenWrt, Timesys Factory e FreeRTOS, e importa SBOM in SPDX da 2.2 a 3.0.1, CycloneDX da 1.1 a 1.7 e CSV per tutto il resto. Lynx afferma che Vigiles, lanciato nel 2019, ha elaborato più di 90.000 SBOM.

Meno rumore sulle CVE. Vigiles confronta i componenti con un database CVE curato anziché con i dati pubblici grezzi, il che secondo Lynx elimina la maggior parte dei falsi positivi prodotti dai dati pubblici. Il suo scanner può caricare i file .config completi del kernel Linux e di U-Boot, così le CVE relative a funzionalità che Lei non compila vengono escluse. Questo conta su Linux embedded: nel report di esempio del README di meta-timesys, 60 delle 62 CVE non corrette riguardano il kernel.

Decisioni che durano tra le release. I team registrano se ogni CVE è affected, fixed, deferred o not exploitable, e Vigiles conserva queste decisioni per release, mette in evidenza le CISA Known Exploited Vulnerabilities ed esporta SBOM in CycloneDX, SPDX e SPDX Lite insieme a VEX e report sulle vulnerabilità. I suoi report mostrano anche le CVE già corrette dalle patch nella Sua build e le patch disponibili nel layer meta-timesys-security. Lynx cita il CRA dell'UE e l'EO 14028 tra gli standard per cui offre supporto, e Vigiles si collega a Jira e Okta.

In che cosa CRACI è diverso

La SBOM di Vigiles non può essere più completa della vista di BitBake sull'immagine. Il README di meta-timesys la descrive come la raccolta di metadati sui pacchetti da installare, e i pacchetti compilati al di fuori di BitBake, o compilati da esso ma assenti dal manifest del root filesystem, vanno elencati a mano. CRACI non legge metadati. È la macchina su cui gira la build.

Che cosa lascia fuori la SBOM di Yocto

Non abbiamo confrontato una SBOM di Vigiles con quella di CRACI. Abbiamo confrontato quella di CRACI con la SBOM SPDX integrata di Yocto, anch'essa generata dai metadati di BitBake. In una build affiancata di core-image-sato su un runner ARM64 da 32 vCPU, la SBOM di CRACI conteneva ogni componente di quella di Yocto, più 88 che le mancavano: pacchetti host sulla macchina di build come cpio di Ubuntu, sorgenti GitHub e la GitHub Action actions/upload-artifact, oltre ad altre sorgenti e strumenti scaricati durante la build. Nessuno di questi è installato nell'immagine, e tutti si trovano nel percorso critico della build.

Entrambe le SBOM elencavano le stesse 653 versioni di crate Rust, ma quella di Yocto le riporta solo con nome del file e URL di download, senza package URL. La corrispondenza delle vulnerabilità si basa sui package URL, quindi quei crate non possono essere monitorati dalla SBOM di Yocto. CRACI li registra tutti con un package URL pkg:cargo.

Controllo su ciò che la build può raggiungere

Una policy di egress sul runner decide a quali host un job può connettersi. Viene convalidata prima dell'avvio del job, opera in modalità fail closed e invia un avviso in caso di violazione. Per Yocto aggiunge un secondo livello a BB_ALLOWED_NETWORKS di BitBake, e una policy a negazione predefinita impedisce a uno strumento di build compromesso di inviare secret a un host di cui la build non ha bisogno.

Provenance e monitoraggio dallo stesso record

L'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance. CRACI aggrega le vulnerabilità tra build e repository, continua a rivalutare le SBOM monitorate man mano che compaiono nuovi advisory, consente ai team di sicurezza di esaminare i risultati e assegnarli al team responsabile della correzione e mostra quali build passate contenevano una dipendenza vulnerabile, così Lei conosce il periodo in cui è stato esposto. CRACI supporta VEX e può inviare per Suo conto le notifiche di vulnerabilità previste dal CRA.

La build stessa, su runner più grandi

Vigiles non esegue la Sua build; CRACI sì. Le build Yocto girano su runner fino a 32 vCPU e 96 GB di RAM, misurate al secondo a $0.002 per vCPU-minuto ($0.004 per un runner predefinito da 2 vCPU). Nello stesso confronto su core-image-sato, la build senza la generazione della SBOM di Yocto ha richiesto il 43% di tempo in meno rispetto alla build con la generazione.

Sostituire Vigiles con CRACI

Per le immagini Yocto compilate in GitHub Actions, CRACI copre ciò per cui si acquista Vigiles: una SBOM per ogni build, monitoraggio delle CVE dopo la release, decisioni di triage e VEX. Aggiunge ciò che una SBOM basata sui metadati non può offrire: i pacchetti host, le sorgenti GitHub e le Actions usati dalla build, e una policy di egress durante l'esecuzione.

Abbia ben chiaro a che cosa rinuncia. I dati CVE curati di Vigiles e i filtri di configurazione di kernel e U-Boot riducono il rumore sulle CVE in un modo che CRACI non offre. Vigiles riporta quali CVE sono già corrette dalle patch nella Sua build, cosa che CRACI non registra; anche l'SPDX di Yocto riporta questi metadati delle ricette, quindi mantenga attivo create-spdx se ne dipende. Vigiles copre anche Buildroot, OpenWrt e FreeRTOS, gira all'interno di qualsiasi CI e importa SBOM in molti formati. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap, quindi le pipeline Jenkins o GitLab dovrebbero prima passare a GitHub Actions.

Per il CRA

Il Cyber Resilience Act chiede ai fabbricanti di documentare i componenti dei loro prodotti, compresa una SBOM, e di gestire le vulnerabilità per tutto il periodo in cui un prodotto è supportato, con obblighi di segnalazione da settembre 2026. Vigiles aiuta conservando SBOM, decisioni sulle CVE e report per release. CRACI produce le evidenze per build di ciò che è entrato nel firmware, con provenance, monitoraggio continuo ed esportazione delle SBOM in CycloneDX o SPDX. Automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui un fabbricante ha bisogno per il suo più ampio processo CRA; nessuno dei due strumenti da solo rende conforme un prodotto. Legga che cosa richiede il CRA.

Spostare una build Yocto su CRACI

Imposti runs-on: craci sul job BitBake e scelga una dimensione del runner; il workflow continua a girare in GitHub Actions. L'esempio Yocto nella documentazione di CRACI compila core-image-sato sulla dimensione più grande. Veda come funziona CRACI per l'IoT industriale e l'elettronica di consumo.