CRACI vs. Timesys Vigiles

Det korte svaret

Vigiles er SBOM- og sårbarhetshåndteringsproduktet til Timesys, som Lynx Software Technologies kjøpte i desember 2023; Lynx selger det nå som Lynx Vigiles. Det er bygget for innebygd Linux: Et Yocto-lag, meta-timesys, samler inn metadata om pakkene i imaget ditt og laster dem opp, og Vigiles matcher dem mot en kuratert CVE-database, sporer deretter triage-beslutninger og eksporterer SBOM-, VEX- og sårbarhetsrapporter.

CRACI er en GitHub Actions-runner. BitBake-bygget ditt kjører på den, og mens det kjører, registrerer CRACI hver pakke og kilde bygget hentet, begrenser hvor bygget kan koble seg til, og fortsetter å overvåke SBOM-en for sårbarheter. Begge produktene gir deg en SBOM og CVE-overvåking for et Yocto-image; forskjellen ligger i hvor SBOM-en kommer fra. Vigiles leser det BitBake-metadataene sier går inn i imaget. CRACI registrerer det bygget faktisk hentet inn.

Oversikt

Hva Vigiles gjør bra

Laget for innebygd Linux. Vigiles integreres med Yocto gjennom meta-timesys, og med Buildroot, OpenWrt, Timesys Factory og FreeRTOS, og importerer SBOM-er i SPDX 2.2 til 3.0.1, CycloneDX 1.1 til 1.7 og CSV for alt annet. Lynx sier at Vigiles, lansert i 2019, har behandlet mer enn 90 000 SBOM-er.

Mindre CVE-støy. Vigiles matcher komponenter mot en kuratert CVE-database i stedet for rå offentlige data, noe Lynx sier fjerner de fleste av de falske positivene offentlige data gir. Skanneren kan laste opp hele .config-filene dine for Linux-kjernen og U-Boot, så CVE-er i funksjoner du ikke bygger, filtreres bort. Det betyr noe på innebygd Linux: I eksempelrapporten i README-filen til meta-timesys er 60 av de 62 urettede CVE-ene i kjernen.

Beslutninger som varer på tvers av utgivelser. Team registrerer om hver CVE er affected, fixed, deferred eller not exploitable, og Vigiles beholder disse beslutningene per utgivelse, fremhever CISA Known Exploited Vulnerabilities og eksporterer SBOM-er i CycloneDX, SPDX og SPDX Lite sammen med VEX- og sårbarhetsrapporter. Rapportene viser også CVE-er som allerede er rettet av patcher i bygget ditt, og patcher som er tilgjengelige i laget meta-timesys-security. Lynx nevner EUs CRA og EO 14028 blant standardene produktet hjelper med, og Vigiles kobles til Jira og Okta.

Der CRACI skiller seg ut

SBOM-en fra Vigiles er bare så fullstendig som BitBakes bilde av imaget. README-filen til meta-timesys beskriver det som innsamling av metadata om pakkene som skal installeres, og pakker bygget utenfor BitBake, eller bygget av det, men som mangler i manifestet for rotfilsystemet, må listes opp for hånd. CRACI leser ikke metadata. Det er maskinen bygget kjører på.

Hva Yoctos egen SBOM utelater

Vi har ikke sammenlignet en SBOM fra Vigiles med en fra CRACI. Vi har sammenlignet SBOM-en fra CRACI med Yoctos innebygde SPDX-SBOM, som også genereres fra BitBake-metadata. I et sammenlignende bygg av core-image-sato på en ARM64-runner med 32 vCPU hadde SBOM-en fra CRACI alle komponentene i Yoctos SBOM, pluss 88 den gikk glipp av: vertspakker på byggemaskinen som Ubuntus cpio, GitHub-kilder og GitHub Action-en actions/upload-artifact, og andre kilder og verktøy hentet under bygget. Ingen av dem er installert i imaget, og alle er i den kritiske stien til bygget.

Begge SBOM-ene listet opp de samme 653 Rust crate-versjonene, men Yoctos lister dem bare med filnavn og nedlastings-URL, uten package URL. Sårbarhetsmatching bruker package URL-er, så disse cratene kan ikke overvåkes fra Yoctos SBOM. CRACI registrerer hver eneste av dem med en pkg:cargo package URL.

Kontroll over hva bygget kan nå

En egress-policy på runneren avgjør hvilke verter en jobb kan koble seg til. Den valideres før jobben starter, blokkerer ved feil (fail closed) og sender et varsel ved et brudd. For Yocto legger den til et ekstra lag i tillegg til BitBakes egen BB_ALLOWED_NETWORKS, og en default deny-policy hindrer et kompromittert byggeverktøy i å sende hemmeligheter til en vert bygget ikke trenger.

Provenance og overvåking fra samme registrering

API-et returnerer SBOM-er, nettverksspor og provenance. CRACI signerer ikke provenance. CRACI samler sårbarheter på tvers av bygg og repositorier, fortsetter å vurdere overvåkede SBOM-er på nytt etter hvert som advisories dukker opp, lar sikkerhetsteam triagere funn og sende dem til teamet som eier rettingen, og viser hvilke tidligere bygg som inneholdt en sårbar avhengighet, så du vet hvilken periode du var berørt. CRACI støtter VEX, og det kan sende CRA-varsler om sårbarheter på dine vegne.

Selve bygget, på større runnere

Vigiles kjører ikke bygget ditt; det gjør CRACI. Yocto-bygg kjører på runnere med opptil 32 vCPU og 96 GB RAM, målt per sekund til $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU). I samme core-image-sato-sammenligning tok bygget uten Yoctos SBOM-generering 43 % kortere tid enn bygget med den.

Slik erstatter du Vigiles med CRACI

For Yocto-images bygget i GitHub Actions dekker CRACI det Vigiles kjøpes for: en SBOM for hvert bygg, CVE-overvåking etter utgivelse, triage-beslutninger og VEX. Det legger til det en metadatabasert SBOM ikke kan gi deg: vertspakkene, GitHub-kildene og Actions bygget brukte, og en egress-policy mens det kjører.

Vær klar over hva du gir opp. De kuraterte CVE-dataene og konfigurasjonsfiltrene for kjerne og U-Boot i Vigiles kutter CVE-støy på en måte CRACI ikke gjør. Vigiles rapporterer hvilke CVE-er patchene i bygget ditt allerede retter, noe CRACI ikke registrerer; Yoctos egen SPDX har også disse metadataene fra oppskriftene, så behold create-spdx slått på hvis du er avhengig av det. Vigiles dekker også Buildroot, OpenWrt og FreeRTOS, kjører inne i hvilken som helst CI og importerer SBOM-er i mange formater. CRACI støtter bare GitHub Actions i dag, med GitLab CI og Jenkins på veikartet, så Jenkins- eller GitLab-pipelines må først flyttes til GitHub Actions.

For CRA

Cyber Resilience Act ber produsenter dokumentere komponentene i produktene sine, inkludert en SBOM, og håndtere sårbarheter så lenge et produkt støttes, med rapporteringsplikter fra september 2026. Vigiles hjelper ved å ta vare på SBOM-er, CVE-beslutninger og rapporter per utgivelse. CRACI produserer dokumentasjonen per bygg på hva som gikk inn i firmwaren, med provenance, løpende overvåking og SBOM-eksport som CycloneDX eller SPDX. Det automatiserer en betydelig del av innsynet i programvareleverandørkjeden og dokumentasjonen en produsent trenger for sin bredere CRA-prosess; ingen av verktøyene gjør et produkt samsvarende på egen hånd. Les hva CRA krever.

Slik flytter du et Yocto-bygg til CRACI

Sett runs-on: craci på BitBake-jobben, og velg en runnerstørrelse; workflowen fortsetter å kjøre i GitHub Actions. Yocto-eksempelet i CRACI-dokumentasjonen bygger core-image-sato på den største størrelsen. Se hvordan CRACI fungerer for industriell IoT og forbrukerelektronikk.