CRACI vs Timesys Vigiles

簡短回答

Vigiles 是 Timesys 的 SBOM 與漏洞管理產品，Lynx Software Technologies 於 2023 年 12 月收購 Timesys，現以 Lynx Vigiles 之名銷售。它專為嵌入式 Linux 打造：Yocto layer meta-timesys 會收集映像檔中套件的中繼資料並上傳，Vigiles 再將其與經篩選整理的 CVE 資料庫比對，接著追蹤分級研判決策，並匯出 SBOM、VEX 與漏洞報告。

CRACI 是 GitHub Actions 執行器。您的 BitBake 建置在其上執行，執行期間 CRACI 會記錄建置擷取的每一個套件與來源、限制建置能連線的位置，並持續監控 該 SBOM 的漏洞。兩種產品都能為 Yocto 映像檔提供 SBOM 與 CVE 監控；差別在於 SBOM 的來源。Vigiles 讀取的是 BitBake 中繼資料所說會放進映像檔的內容；CRACI 記錄的則是建置實際拉入的內容。

重點一覽

Vigiles 的強項

專為嵌入式 Linux 打造。Vigiles 透過 meta-timesys 與 Yocto 整合，也支援 Buildroot、OpenWrt、Timesys Factory 與 FreeRTOS，並能匯入 SPDX 2.2 至 3.0.1、CycloneDX 1.1 至 1.7 格式的 SBOM，其他情況則可使用 CSV。Lynx 表示，自 2019 年推出以來，Vigiles 已處理超過 90,000 份 SBOM。

減少 CVE 雜訊。Vigiles 將元件與經篩選整理的 CVE 資料庫比對，而不是直接使用公開原始資料；Lynx 表示，這能排除公開資料所產生的大部分誤報。它的掃描器可上傳完整的 Linux kernel 與 U-Boot .config 檔案，從而篩除您未建置之功能中的 CVE。這在嵌入式 Linux 上很重要：在 meta-timesys README 的範例報告中，62 個未修正的 CVE 裡有 60 個位於 kernel。

跨版本延續的決策。團隊可記錄每個 CVE 是受影響、已修正、延後還是不可利用，Vigiles 會依版本保存這些決策、標示 CISA Known Exploited Vulnerabilities，並以 CycloneDX、SPDX 與 SPDX Lite 匯出 SBOM，同時提供 VEX 與漏洞報告。它的報告也會顯示已由您建置中的修補程式修正的 CVE，以及 meta-timesys-security layer 中可用的修補程式。Lynx 將歐盟 CRA 與 EO 14028 列為它可協助因應的標準，Vigiles 也能連接 Jira 與 Okta。

CRACI 的不同之處

Vigiles 的 SBOM 完整程度，取決於 BitBake 對映像檔的掌握。meta-timesys README 描述它收集的是待安裝套件的中繼資料，而在 BitBake 之外建置的套件，或由 BitBake 建置但未列在根檔案系統 manifest 中的套件，都必須手動列出。CRACI 不讀取中繼資料，它就是建置執行所在的機器。

Yocto 自身 SBOM 遺漏的內容

我們尚未比較過 Vigiles 的 SBOM 與 CRACI 的 SBOM。我們比較過的是 CRACI 與 Yocto 內建的 SPDX SBOM，後者同樣是從 BitBake 中繼資料產生。在一次於 32 vCPU ARM64 執行器上進行的 core-image-sato 並列建置中，CRACI 的 SBOM 包含 Yocto SBOM 中的所有元件， 另外還多了 Yocto 遺漏的 88 個：建置機器上的主機套件（例如 Ubuntu 的 cpio）、GitHub 來源與 GitHub Action actions/upload-artifact，以及建置期間擷取的其他來源與工具。這些都沒有安裝在映像檔中，但全都位於建置的關鍵路徑上。

兩份 SBOM 都列出了相同的 653 個 Rust crate 版本，但 Yocto 只以檔名與下載 URL 列出，沒有 package URL。漏洞比對依賴 package URL，因此無法從 Yocto 的 SBOM 監控這些 crate。 CRACI 則以 pkg:cargo package URL 記錄每一個 crate。 關於映像檔掃描器、二進位分析與 Yocto 的 cve-check 如何比較，請參閱為什麼 SBOM 掃描器會漏掉 Yocto 建置中的內容。

控管建置能連到哪裡

執行器上的對外連線政策決定作業可以連線到哪些主機。政策會在作業開始前驗證，採失效即封鎖（fail closed），並在違規時發出警示。對 Yocto 而言，它在 BitBake 本身的 BB_ALLOWED_NETWORKS 之外再加上一層防護，而預設拒絕的政策能阻止遭入侵的建置工具將機密傳送到建置不需要的主機。

來源證明與監控出自同一份紀錄

API 會回傳 SBOM、網路追蹤與來源證明（provenance）。CRACI 不會簽署來源證明。CRACI 會跨建置與儲存庫彙整漏洞，在資安公告發布時持續重新評估受監控的 SBOM，讓資安團隊分級研判發現並分派給負責修正的團隊，並顯示過去哪些建置包含有漏洞的相依套件，讓您知道受影響的期間。CRACI 支援 VEX， 並會為您準備 CRA 漏洞通報的內容，供您提交。

建置本身，在更大的執行器上

Vigiles 不會執行您的建置；CRACI 會。Yocto 建置可在最多 32 vCPU 與 96 GB RAM 的執行器上執行， 按秒計費，每 vCPU 分鐘 $0.002（預設 2 vCPU 執行器為 $0.004）。在同一次 core-image-sato 比較中，未啟用 Yocto SBOM 產生的建置，比啟用時少花了 43% 的時間。

以 CRACI 取代 Vigiles

對於在 GitHub Actions 中建置的 Yocto 映像檔，CRACI 涵蓋了企業購買 Vigiles 的用途：每次建置的 SBOM、發布後的 CVE 監控、分級研判決策與 VEX。它還補上以中繼資料為基礎的 SBOM 無法提供的內容：建置所使用的主機套件、GitHub 來源與 Actions，以及執行期間的對外連線政策。

也請清楚了解您會放棄什麼。Vigiles 經篩選整理的 CVE 資料，以及 kernel 與 U-Boot 設定篩選，能以 CRACI 做不到的方式減少 CVE 雜訊。Vigiles 會回報您建置中的修補程式已修正哪些 CVE，CRACI 則不記錄這項資訊；Yocto 自身的 SPDX 也帶有這類 recipe 中繼資料，因此若您仰賴它，請保持 create-spdx 開啟。Vigiles 也涵蓋 Buildroot、OpenWrt 與 FreeRTOS，可在任何 CI 中執行，並能匯入多種格式的 SBOM。CRACI 目前僅支援 GitHub Actions，GitLab CI 與 Jenkins 已列入產品藍圖，因此 Jenkins 或 GitLab 管線需要先移轉到 GitHub Actions。

關於 CRA

Cyber Resilience Act（CRA）要求製造商記錄產品中的元件（包括 SBOM），並在產品支援期間持續處理漏洞，通報義務自 2026 年 9 月起生效。 Vigiles 能依版本保存 SBOM、CVE 決策與報告，藉此提供協助。CRACI 則產出每次建置的佐證資料，說明韌體中放入了什麼，並提供來源證明、持續監控，以及以 CycloneDX 或 SPDX 匯出 SBOM。它將製造商在更廣泛的 CRA 流程中所需的軟體供應鏈可視性與佐證資料，自動化了相當大的一部分；兩種工具都無法單獨讓產品符合法規。請閱讀 CRA 的要求。

將 Yocto 建置移到 CRACI

在 BitBake 作業上設定 runs-on: craci 並選擇執行器規格；工作流程會繼續在 GitHub Actions 中執行。CRACI 文件中的 Yocto 範例 在最大規格上建置 core-image-sato。了解 CRACI 如何應用於 工業 IoT與消費性電子產品。