CRACI vs. Timesys Vigiles

Die kurze Antwort

Vigiles ist das Produkt für SBOM- und Schwachstellenmanagement von Timesys, das Lynx Software Technologies im Dezember 2023 übernommen hat; Lynx verkauft es heute als Lynx Vigiles. Es ist für Embedded Linux gebaut: Ein Yocto-Layer, meta-timesys, sammelt Metadaten über die Pakete in Ihrem Image und lädt sie hoch. Vigiles gleicht sie mit einer kuratierten CVE-Datenbank ab, verfolgt dann Triage-Entscheidungen und exportiert SBOM-, VEX- und Schwachstellenberichte.

CRACI ist ein GitHub-Actions-Runner. Ihr BitBake-Build läuft darauf, und währenddessen zeichnet CRACI jedes Paket und jede Quelle auf, die der Build geladen hat, begrenzt, wohin sich der Build verbinden kann, und überwacht die SBOM weiter auf Schwachstellen. Beide Produkte liefern für ein Yocto-Image eine SBOM und CVE-Überwachung; sie unterscheiden sich darin, woher die SBOM stammt. Vigiles liest, was laut den BitBake-Metadaten in das Image einfließt. CRACI zeichnet auf, was der Build tatsächlich geladen hat.

Auf einen Blick

Was Vigiles gut kann

Für Embedded Linux gemacht. Vigiles integriert sich über meta-timesys in Yocto sowie in Buildroot, OpenWrt, Timesys Factory und FreeRTOS und importiert für alles andere SBOMs in SPDX 2.2 bis 3.0.1, CycloneDX 1.1 bis 1.7 und CSV. Laut Lynx hat das 2019 eingeführte Vigiles mehr als 90.000 SBOMs verarbeitet.

Weniger CVE-Rauschen. Vigiles gleicht Komponenten mit einer kuratierten CVE-Datenbank ab statt mit rohen öffentlichen Daten, was laut Lynx die meisten False Positives öffentlicher Daten beseitigt. Der Scanner kann Ihre vollständigen .config-Dateien für Linux-Kernel und U-Boot hochladen, sodass CVEs in Funktionen, die Sie nicht bauen, herausgefiltert werden. Das ist bei Embedded Linux wichtig: Im Beispielbericht in der README von meta-timesys liegen 60 der 62 nicht behobenen CVEs im Kernel.

Entscheidungen, die über Releases hinweg gelten. Teams halten für jede CVE fest, ob sie als betroffen, behoben, zurückgestellt oder nicht ausnutzbar gilt, und Vigiles bewahrt diese Entscheidungen pro Release auf, hebt CISA Known Exploited Vulnerabilities hervor und exportiert SBOMs in CycloneDX, SPDX und SPDX Lite sowie VEX und Schwachstellenberichte. Seine Berichte zeigen außerdem CVEs, die Patches in Ihrem Build bereits beheben, und Patches, die im Layer meta-timesys-security verfügbar sind. Lynx nennt den EU CRA und EO 14028 unter den Standards, bei denen es hilft, und Vigiles bindet Jira und Okta an.

Worin sich CRACI unterscheidet

Die SBOM von Vigiles ist nur so vollständig wie die Sicht von BitBake auf das Image. Die README von meta-timesys beschreibt das Vorgehen als Sammeln von Metadaten über die zu installierenden Pakete, und Pakete, die außerhalb von BitBake gebaut wurden oder von ihm gebaut wurden, aber im Manifest des Root-Dateisystems fehlen, müssen von Hand aufgeführt werden. CRACI liest keine Metadaten. Es ist die Maschine, auf der der Build läuft.

Was Yoctos eigene SBOM auslässt

Wir haben keine Vigiles-SBOM mit der von CRACI verglichen. Verglichen haben wir die SBOM von CRACI mit Yoctos integrierter SPDX-SBOM, die ebenfalls aus den BitBake-Metadaten erzeugt wird. In einem direkten Vergleichs-Build von core-image-sato auf einem ARM64-Runner mit 32 vCPU enthielt die SBOM von CRACI jede Komponente aus Yoctos SBOM, plus 88, die dort fehlten: Host-Pakete auf der Build-Maschine wie Ubuntus cpio, GitHub-Quellen und die GitHub Action actions/upload-artifact sowie weitere Quellen und Tools, die während des Builds geladen wurden. Keine davon ist im Image installiert, und alle liegen auf dem kritischen Pfad des Builds.

Beide SBOMs führten dieselben 653 Rust-Crate-Versionen auf, doch Yoctos SBOM nennt sie nur mit Dateiname und Download-URL, ohne Package URL. Der Schwachstellenabgleich arbeitet mit Package URLs, diese Crates lassen sich aus Yoctos SBOM also nicht überwachen. CRACI zeichnet jede von ihnen mit einer pkg:cargo-Package-URL auf.

Kontrolle darüber, was der Build erreichen kann

Eine Egress-Richtlinie am Runner entscheidet, mit welchen Hosts sich ein Job verbinden darf. Sie wird vor dem Start des Jobs validiert, blockiert im Zweifel (fail closed) und sendet bei einem Verstoß eine Warnung. Für Yocto ergänzt sie BitBakes eigenes BB_ALLOWED_NETWORKS um eine zweite Ebene, und eine standardmäßig sperrende Richtlinie hindert ein kompromittiertes Build-Tool daran, Secrets an einen Host zu senden, den der Build nicht braucht.

Provenienz und Überwachung aus derselben Aufzeichnung

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen, bewertet überwachte SBOMs laufend neu, sobald Advisories erscheinen, lässt Sicherheitsteams Befunde sichten und an das Team weiterleiten, das für die Behebung zuständig ist, und zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren. CRACI unterstützt VEX und kann CRA-Schwachstellenmeldungen in Ihrem Namen einreichen.

Der Build selbst, auf größeren Runnern

Vigiles führt Ihren Build nicht aus; CRACI schon. Yocto-Builds laufen auf Runnern mit bis zu 32 vCPUs und 96 GB RAM, sekundengenau abgerechnet zu $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPU). Im selben Vergleich von core-image-sato brauchte der Build ohne Yoctos SBOM-Generierung 43 % weniger Zeit als der Build mit ihr.

Vigiles durch CRACI ersetzen

Für Yocto-Images, die in GitHub Actions gebaut werden, deckt CRACI ab, wofür Vigiles gekauft wird: eine SBOM für jeden Build, CVE-Überwachung nach dem Release, Triage-Entscheidungen und VEX. Es ergänzt, was eine metadatenbasierte SBOM nicht liefern kann: die Host-Pakete, GitHub-Quellen und Actions, die der Build genutzt hat, und eine Egress-Richtlinie während des Laufs.

Machen Sie sich klar, worauf Sie verzichten. Die kuratierten CVE-Daten von Vigiles und die Konfigurationsfilter für Kernel und U-Boot reduzieren das CVE-Rauschen auf eine Weise, die CRACI nicht bietet. Vigiles meldet, welche CVEs die Patches in Ihrem Build bereits beheben, was CRACI nicht aufzeichnet; Yoctos eigenes SPDX enthält diese Rezept-Metadaten ebenfalls, lassen Sie create-spdx also aktiviert, wenn Sie darauf angewiesen sind. Vigiles deckt außerdem Buildroot, OpenWrt und FreeRTOS ab, läuft in jedem CI und importiert SBOMs in vielen Formaten. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap, Jenkins- oder GitLab-Pipelines müssten also zuerst zu GitHub Actions umziehen.

Für den CRA

Der Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, einschließlich einer SBOM, und Schwachstellen zu behandeln, solange ein Produkt unterstützt wird, mit Meldepflichten ab September 2026. Vigiles hilft, indem es SBOMs, CVE-Entscheidungen und Berichte pro Release bewahrt. CRACI erzeugt die Nachweise pro Build darüber, was in die Firmware eingeflossen ist, mit Provenienz, laufender Überwachung und SBOM-Export als CycloneDX oder SPDX. Es automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die ein Hersteller für seinen umfassenderen CRA-Prozess braucht; keines der Tools macht ein Produkt allein konform. Lesen Sie, was der CRA verlangt.

Einen Yocto-Build auf CRACI umziehen

Setzen Sie runs-on: craci beim BitBake-Job und wählen Sie eine Runner-Größe; der Workflow läuft weiter in GitHub Actions. Das Yocto-Beispiel in der CRACI-Dokumentation baut core-image-sato auf der größten Runner-Größe. Sehen Sie, wie CRACI für Industrial IoT und Unterhaltungselektronik funktioniert.