CRACI vs Timesys Vigiles

Het korte antwoord

Vigiles is het product voor SBOM's en kwetsbaarheidsbeheer van Timesys, dat Lynx Software Technologies in december 2023 heeft overgenomen; Lynx verkoopt het nu als Lynx Vigiles. Het is gebouwd voor embedded Linux: een Yocto-laag, meta-timesys, verzamelt metadata over de pakketten in uw image en uploadt die, waarna Vigiles ze matcht met een samengestelde CVE-database, triagebeslissingen bijhoudt en SBOM-, VEX- en kwetsbaarheidsrapporten exporteert.

CRACI is een GitHub Actions-runner. Uw BitBake-build draait erop, en terwijl die draait legt CRACI elk pakket en elke bron vast die de build ophaalde, beperkt het waarmee de build verbinding kan maken en blijft het de SBOM monitoren op kwetsbaarheden. Beide producten geven u een SBOM en CVE-monitoring voor een Yocto-image; ze verschillen in waar de SBOM vandaan komt. Vigiles leest wat de metadata van BitBake zegt dat er in het image gaat. CRACI legt vast wat de build daadwerkelijk binnenhaalde.

In één oogopslag

Waar Vigiles sterk in is

Gemaakt voor embedded Linux. Vigiles integreert met Yocto via meta-timesys, en met Buildroot, OpenWrt, Timesys Factory en FreeRTOS, en importeert SBOM's in SPDX 2.2 tot 3.0.1, CycloneDX 1.1 tot 1.7 en CSV voor al het andere. Lynx zegt dat Vigiles, gelanceerd in 2019, meer dan 90.000 SBOM's heeft verwerkt.

Minder CVE-ruis. Vigiles matcht componenten met een samengestelde CVE-database in plaats van ruwe openbare gegevens, wat volgens Lynx de meeste fout-positieven uit openbare gegevens wegneemt. De scanner kan uw volledige .config-bestanden van de Linux-kernel en U-Boot uploaden, zodat CVE's in functies die u niet bouwt worden weggefilterd. Dat is belangrijk op embedded Linux: in het voorbeeldrapport in de README van meta-timesys zitten 60 van de 62 niet-opgeloste CVE's in de kernel.

Beslissingen die over releases heen standhouden. Teams leggen vast of elke CVE affected, fixed, deferred of not exploitable is, en Vigiles bewaart die beslissingen per release, licht CISA Known Exploited Vulnerabilities uit en exporteert SBOM's in CycloneDX, SPDX en SPDX Lite, samen met VEX- en kwetsbaarheidsrapporten. De rapporten tonen ook CVE's die al zijn opgelost door patches in uw build, en patches die beschikbaar zijn in de laag meta-timesys-security. Lynx noemt de EU CRA en EO 14028 onder de standaarden waarbij het helpt, en Vigiles koppelt met Jira en Okta.

Waarin CRACI verschilt

De SBOM van Vigiles is maar zo volledig als de kijk van BitBake op het image. De README van meta-timesys beschrijft dat het metadata verzamelt over de pakketten die worden geïnstalleerd, en pakketten die buiten BitBake zijn gebouwd, of erdoor zijn gebouwd maar in het rootfs-manifest ontbreken, moeten met de hand worden vermeld. CRACI leest geen metadata. Het is de machine waarop de build draait.

Wat de eigen SBOM van Yocto weglaat

We hebben geen SBOM van Vigiles met die van CRACI vergeleken. We hebben die van CRACI vergeleken met de ingebouwde SPDX-SBOM van Yocto, die ook uit de metadata van BitBake wordt gegenereerd. In een vergelijkende build van core-image-sato op een ARM64-runner met 32 vCPU had de SBOM van CRACI elk component uit de SBOM van Yocto, plus 88 die Yocto miste: hostpakketten op de buildmachine zoals cpio van Ubuntu, GitHub-bronnen en de GitHub Action actions/upload-artifact, en andere bronnen en tools die tijdens de build zijn opgehaald. Geen daarvan is in het image geïnstalleerd, en allemaal bevinden ze zich in het kritieke pad van de build.

Beide SBOM's vermeldden dezelfde 653 Rust-crateversies, maar die van Yocto vermeldt ze alleen op bestandsnaam en download-URL, zonder package URL. Het matchen van kwetsbaarheden werkt op package URL's, dus die crates kunnen niet worden gemonitord vanuit de SBOM van Yocto. CRACI legt ze allemaal vast met een pkg:cargo-package URL.

Controle over wat de build kan bereiken

Een egressbeleid op de runner bepaalt met welke hosts een job verbinding mag maken. Het wordt gevalideerd voordat de job start, is fail-closed en stuurt een melding bij een overtreding. Voor Yocto voegt het een tweede laag toe aan BitBake's eigen BB_ALLOWED_NETWORKS, en een beleid dat standaard weigert, blokkeert een gecompromitteerde buildtool die secrets naar een host probeert te sturen die de build niet nodig heeft.

Herkomst en monitoring uit dezelfde vastlegging

De API levert SBOM's, netwerktraces en herkomstgegevens. CRACI ondertekent herkomstgegevens niet. CRACI bundelt kwetsbaarheden over builds en repositories heen, blijft gemonitorde SBOM's opnieuw beoordelen wanneer advisories verschijnen, laat securityteams bevindingen triëren en naar het team sturen dat verantwoordelijk is voor de fix, en toont welke eerdere builds een kwetsbare afhankelijkheid bevatten, zodat u weet in welke periode u getroffen was. CRACI ondersteunt VEX en kan CRA-meldingen van kwetsbaarheden namens u indienen.

De build zelf, op grotere runners

Vigiles draait uw build niet; CRACI wel. Yocto-builds draaien op runners met maximaal 32 vCPU's en 96 GB RAM, per seconde gemeten tegen $0.002 per vCPU-minuut ($0.004 voor een standaardrunner met 2 vCPU). In dezelfde vergelijking van core-image-sato duurde de build zonder de SBOM-generatie van Yocto 43% korter dan de build ermee.

Vigiles vervangen door CRACI

Voor Yocto-images die in GitHub Actions worden gebouwd, dekt CRACI waarvoor Vigiles wordt gekocht: een SBOM voor elke build, CVE-monitoring na de release, triagebeslissingen en VEX. Het voegt toe wat een SBOM op basis van metadata u niet kan geven: de hostpakketten, GitHub-bronnen en Actions die de build gebruikte, en een egressbeleid terwijl die draait.

Wees u bewust van wat u opgeeft. De samengestelde CVE-gegevens en de configuratiefilters voor kernel en U-Boot van Vigiles verminderen CVE-ruis op een manier die CRACI niet biedt. Vigiles rapporteert welke CVE's de patches in uw build al oplossen, wat CRACI niet vastlegt; de eigen SPDX van Yocto bevat die recipe-metadata ook, dus laat create-spdx aanstaan als u daarvan afhankelijk bent. Vigiles dekt ook Buildroot, OpenWrt en FreeRTOS, draait binnen elke CI en importeert SBOM's in veel formaten. CRACI ondersteunt vandaag alleen GitHub Actions, met GitLab CI en Jenkins op de roadmap, dus pipelines op Jenkins of GitLab moeten eerst naar GitHub Actions overstappen.

Voor de CRA

De Cyber Resilience Act vraagt fabrikanten de componenten in hun producten te documenteren, onder meer met een SBOM, en kwetsbaarheden af te handelen zolang een product wordt ondersteund, met meldingsplichten vanaf september 2026. Vigiles helpt door SBOM's, CVE-beslissingen en rapporten per release te bewaren. CRACI levert per build het bewijs van wat er in de firmware is gegaan, met herkomstgegevens, doorlopende monitoring en SBOM-export als CycloneDX of SPDX. Het automatiseert een aanzienlijk deel van het inzicht in de softwareketen en het bewijs dat een fabrikant nodig heeft voor zijn bredere CRA-proces; geen van beide tools maakt een product op zichzelf compliant. Lees wat de CRA vereist.

Een Yocto-build naar CRACI verplaatsen

Stel runs-on: craci in op de BitBake-job en kies een runnergrootte; de workflow blijft in GitHub Actions draaien. Het Yocto-voorbeeld in de CRACI-documentatie bouwt core-image-sato op de grootste maat. Bekijk hoe CRACI werkt voor industrieel IoT en consumentenelektronica.