Yocto SBOM 與在 CRACI 上建置

如何以 Yocto 產生 SBOM

OpenEmbedded 建置系統透過 create-spdx 類別寫出 SPDX SBOM。是否預設啟用，以及寫出哪個 SPDX 版本，取決於 Yocto 的版本：

• Kirkstone（4.0）：預設停用。請加入 INHERIT += "create-spdx"。SPDX 2.2。
• Nanbield（4.3）：自此版本起，預設啟用 SBOM 產生。
• Scarthgap（5.0）：預設啟用，SPDX 2.2。可透過 create-spdx-3.0 類別使用 SPDX 3.0。
• Styhead（5.1）及之後：預設啟用，SPDX 3.0。

您可以在 conf/local.conf 等設定檔中設定。在目前的版本中，通常不需要額外加入任何設定；若要停用，請使用 INHERIT_DISTRO:remove = "create-spdx"。

# conf/local.conf

# Kirkstone (4.0): SBOM generation is off by default, so turn it on
INHERIT += "create-spdx"

# Scarthgap (5.0): switch the output from SPDX 2.2 to SPDX 3.0
INHERIT_DISTRO:remove = "create-spdx"
INHERIT_DISTRO:append = " create-spdx-3.0"

# Any release: indented JSON you can read in an editor
SPDX_PRETTY = "1"

其他 SPDX_ 變數可加入更多細節。SPDX_INCLUDE_SOURCES 會描述每個主機工具與目標套件背後的原始碼檔案，這會讓輸出大幅增加。近期的版本還加入了核心組態、PACKAGECONFIG 功能、供應商資訊，以及 Cargo、Go、PyPI、npm 與 CPAN 來源之套件 URL 的選項。

SBOM 檔案的存放位置

建置映像檔後，最上層的 SBOM 會出現在映像檔旁，也就是建置目錄內 IMAGE-MACHINE.spdx.json 位於 tmp/deploy/images/MACHINE/ 中。相關檔案則位於同一目錄以及 tmp/deploy/spdx 中。在 Kirkstone 上，各 recipe 的文件會以 IMAGE-MACHINE.spdx.tar.zst 封存檔提供。

bitbake core-image-minimal

# The image SBOM
ls tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.spdx.json

# Per-recipe and package documents
ls tmp/deploy/spdx/

# Current releases: an SBOM for one recipe, from its metadata only
bitbake busybox -c create_recipe_sbom

使用 meta-cyclonedx 產生 CycloneDX

Yocto 本身只寫出 SPDX。若需要 CycloneDX，meta-cyclonedx layer 會從映像檔的根檔案系統產生 SBOM，並另外產生一個 VEX 檔案，列出建置系統已知的已修補與已忽略 CVE。請取出對應您版本的 layer 分支，將其加入您的 layers，並繼承其類別：

# In your sources directory, on the branch for your release
git clone https://github.com/iris-GmbH/meta-cyclonedx.git
cd meta-cyclonedx
git checkout scarthgap

# conf/bblayers.conf
BBLAYERS += "${BSPDIR}/sources/meta-cyclonedx"

# conf/local.conf
INHERIT += "cyclonedx-export"
# Optional: include build-time packages, not only what is in the image
CYCLONEDX_RUNTIME_PACKAGES_ONLY = "0"

檔案會存放在映像檔旁的 DEPLOY_DIR_IMAGE 中，副檔名為 .cyclonedx.bom.json 與 .cyclonedx.vex.json。預設為 CycloneDX 1.6，可透過 CYCLONEDX_SPEC_VERSION 設定。預設只包含執行階段套件，這能讓 SBOM 保持精簡，但可能遺漏未以套件形式安裝、卻進入映像檔的元件。

Yocto 的 SBOM 遺漏了什麼

Yocto 的 SBOM 對 BitBake 所建置的內容相當周全。在 SPDX 3 中，它涵蓋映像檔、每個 recipe（包括建置時使用的 native recipe）、其原始碼、已套用的修補程式，以及標示為已修正的漏洞。以 core-image-sato 而言，總共有 1,632 個獨立檔案。為了了解它遺漏了什麼，我們在 CRACI 執行器（原生 ARM64、32 vCPU）上建置該映像檔，並在將所有檔案中的名稱正規化之後，逐一元件比較 Yocto 的 SBOM 與 CRACI 記錄的 SBOM。

CRACI SBOM 中的 953 個元件裡，有 865 個也出現在 Yocto 的 SBOM 中。沒有任何元件只出現在 Yocto 的 SBOM 中。差異在於 Yocto 看不到的內容，以及它如何識別所列出的內容。

沒有套件 URL 的 Rust crate

兩份 SBOM 都包含 559 個 Rust crate 的相同 653 個版本，例如 cairo-rs 與 zune-jpeg，它們由 librsvg 編譯進去。Yocto 只在使用它們的 recipe 內，將每個 crate 列為一個 .crate 檔案與一個 crates.io 下載 URL。沒有任何一個帶有 pkg:cargo 套件 URL。CRACI 則為每個 crate 都記錄了套件 URL。

這決定了您能否監控它們的漏洞。漏洞比對以套件 URL 為依據：針對某個 crate 的資安公告會以 pkg:cargo/... 指稱它，而另一個 recipe 原始碼清單中的檔案名稱，無法讓 SBOM 與漏洞工具進行比對。僅憑 Yocto 的 SBOM，映像檔中有漏洞的 crate 不會被回報。

有了 CRACI 的 SBOM，每個 crate 都會與資安公告比對，建置中的每個套件都會顯示其漏洞狀態，而且在建置完成很久之後，CRACI 仍會在新的資安公告發布時持續重新評估 SBOM。

只有 CRACI 找到的內容

Yocto SBOM 遺漏的 88 個元件，來自 BitBake 中繼資料之外：

• 23 個主機套件，安裝在建置機器上，例如 Ubuntu 的 cpio 2.15、libc6、locales 與 python3-jinja2。BitBake 執行時會用到它們，而 Yocto 的 SBOM 並未列出。
• 10 個 GitHub 來源，包括 patchelf、btrfs-progs 與 GitHub Action actions/upload-artifact，並固定於工作流程執行時的 commit
• 建置期間取用的其他來源與工具，例如 pseudo-prebuilt、tzdata，以及 hatchling 與 setuptools_scm 等 Python 建置工具

這些都沒有安裝在映像檔中，但全部都位於建置的關鍵路徑上：遭入侵的主機工具或 Action，即使從未成為映像檔的一部分，也能危害您的映像檔。CRACI 之所以能列出它們，是因為它看得到進入建置的流量。

內建 SBOM 的成本

Yocto 的 SBOM 產生並非沒有代價。在同一台 32 vCPU 執行器上，啟用它的建置花了 155 min 40 s，並將 SBOM 寫成 1,632 個獨立的 SPDX 檔案。不啟用它、改由 CRACI 記錄的建置，則花了 88 min 48 s。以 CRACI 每 vCPU 分鐘 $0.002 的費率計算，每次建置約為 $9.96 對 $5.68，這還不包括您的團隊等待的時間。

與 GitHub 託管執行器相比，差距更大。拜更快的硬體、更短的排隊時間與快取之賜，CRACI 執行建置的速度約為兩倍，因此同樣啟用 Yocto SBOM 的建置，在 GitHub 託管的 32 核心 ARM64 執行器上約需 5 h 11 min。以每分鐘 $0.050 計算，即為 $15.60。CRACI 建置的成本為 $5.68：少了 64%，約便宜 2.7 倍。GitHub 牌價為 2026 年 9 月的資料，未計入內含的免費額度。

Yocto 的 SPDX 輸出確實帶有 CRACI 不會記錄的資訊，例如 recipe 套用的修補程式，以及它標示為已修正的 CVE。如果您的流程依賴這些資訊，請保持 create-spdx 啟用，並搭配使用 CRACI 的 SBOM。如果不需要，CRACI 的 SBOM 本身就涵蓋了 Yocto SBOM 的所有元件，而且更多。

這對供應鏈安全為何重要

進入建置的內容，決定了建置產出的內容，無論它是否安裝在映像檔中。攻擊者很清楚這一點，而近期的供應鏈攻擊正是從建置切入：

• 攻擊藏身於建置之中。xz utils 後門（CVE-2024-3094）存在於 5.6.0 與 5.6.1 版。其觸發機制位於發布的 tarball 中，而不是 Git 儲存庫，惡意程式碼則在函式庫建置時被植入。閱讀原始碼並不會發現它；確切知道建置取用了哪個 tarball 才能發現。
• CI 相依套件也是攻擊目標。2025 年 3 月，CISA 通報 GitHub Action tj-actions/changed-files 的所有版本遭入侵長達三天。Action 在您的建置作業內執行，這正是 CRACI 會列出您的工作流程所使用的 Action，並固定於實際執行之 commit 的原因。
• Rust crate 會消失在二進位檔中。Cargo 會將 crate 編譯進使用它們的程式中，因此有漏洞的 crate 會隨映像檔出貨，卻從未以套件形式出現。如果 SBOM 只以檔案名稱列出它，漏洞工具也無法比對。事後掃描完成的二進位檔只能推測其中包含什麼；記錄建置則不需要推測。
• 看不到的東西就無法應變。當某個 crate 或建置工具發布資安公告時，您需要知道哪些建置使用了它。CRACI 會保留每次建置的 SBOM，並顯示哪些建置包含有漏洞的相依套件（無論是直接或遞移），讓您知道受影響的期間。這只有在每個元件都有可供比對的套件 URL 時才能做到。
• 建置只應連線到它需要的地方。CRACI 的對外連線政策會阻擋連往建置不需要之主機的連線，因此試圖將您的機密傳送到攻擊者伺服器的遭入侵相依套件會被阻止，即使是從未見過的攻擊也一樣。

客戶以及 Cyber Resilience Act（CRA）等法規，也要求連網裝置的製造商了解其產品中包含了什麼。涵蓋整個建置的 SBOM，就是在被要求時站得住腳的佐證資料。

為什麼 Yocto 建置很難在 CI 中執行

完整的映像檔建置需要從原始碼編譯工具鏈、核心與數百個套件。在多數 CI 服務提供的標準 2 核心執行器上，這可能需要數小時，因此許多嵌入式團隊會在桌下或機櫃中放一台專用的建置伺服器，而這台伺服器又成了一台需要修補、備份並向稽核人員說明的機器。

Yocto 建置也會下載大量內容：來自上游專案與鏡像站的原始碼 tarball、Git 儲存庫與修補程式。這些下載內容正是您的 SBOM 必須說明的，也是 Cyber Resilience Act（CRA）等法規要求連網裝置製造商了解並持續追蹤的。

CRACI 為 Yocto 建置帶來什麼

為 BitBake 量身打造的執行器規格

CRACI 執行器可從 1 擴展到 32 個運算單位，每個單位為 1 vCPU 與 3 GB RAM。Yocto 建置可以直接在工作流程中要求最大規格：32 vCPU 與 96 GB RAM。作業在隔離的虛擬機器中執行，執行記錄仍會像其他 Actions 作業一樣顯示在 GitHub 中。

分鐘數按秒計量，並以每 vCPU 分鐘計費，因此大型執行器每分鐘的費用較高，但完成得更快。目前的費率請參閱價格方案。

由您決定的網路存取

BitBake 本身已可透過 BB_ALLOWED_NETWORKS 將其 fetcher 限制在一份主機清單內。CRACI 則在執行器上加入第二道控管：一項在作業開始前檢查、並採失效即封鎖（fail closed）設計的對外連線政策，因此即使 recipe、腳本或遭入侵的工具繞過 fetcher，仍然無法連線到您未允許的主機。CRACI 會在違反政策時向您發出警示。

建置取用內容的記錄

CRACI 會觀察作業傳送至套件與原始碼主機的流量，並將其記錄為建置佐證資料。對 Yocto 建置而言，這代表在 Yocto 自行寫出的 SBOM 之外，還有一份獨立記錄，說明實際透過網路取得了哪些原始碼。

最精簡的工作流程

CRACI 文件中的 Yocto 範例會建置 core-image-sato，目標機器為 qemux86-64。對 CRACI 而言，重要的部分是執行器規格，以及使用官方 Yocto 原始碼鏡像站的 fetcher 設定：

jobs:
  build:
    runs-on: craci
    steps:
      - uses: cracicorp/setup@v1
        with:
          size: "32"
      # install the host packages from the Yocto quick start, then:
      - run: |
          echo 'SOURCE_MIRROR_URL = "https://downloads.yoctoproject.org/mirror/sources/"' >> conf/local.conf
          echo 'BB_ALLOWED_NETWORKS = "downloads.yoctoproject.org"' >> conf/local.conf
          bitbake core-image-sato

文件指南中有完整的工作流程，包括主機相依套件與語系設定，而執行器設定參考文件列出了所有設定選項。

須知事項

• 建置從 GitHub Actions 觸發，在 CRACI 位於歐洲基礎設施上的代管執行器中執行。客戶自架執行器與其他 CI 系統已列入產品藍圖。
• 請將 BitBake 指向 CRACI 看得到的鏡像站（例如官方 Yocto 原始碼鏡像站），而不是任意主機。文件指南中有可正常運作的設定範例。
• 在多次執行之間保留下載目錄與 shared state 快取，是讓重複建置變快的關鍵。
• 原生 ARM64 執行器的費率與 x86-64 相同。

正在為歐盟市場打造連網裝置嗎？請閱讀CRA 的要求，以及 CRACI 如何應用於工業物聯網與消費性電子產品。正在使用 Black Duck 嗎？請閱讀Black Duck 的 BitBake 偵測器有何不同。正在比較 Yocto SBOM 工具嗎？請參閱 CRACI 與 Timesys Vigiles 比較.

Yocto SBOM 與 CRACI：常見問題

Yocto 會產生 SBOM 嗎？

會。自 Yocto 4.3（Nanbield）起，OpenEmbedded 建置系統預設會透過 create-spdx 類別產生 SPDX 格式的 SBOM。針對映像檔，它會將 IMAGE-MACHINE.spdx.json 寫入 tmp/deploy/images/MACHINE/，涵蓋元件、授權、相依套件、原始碼、已套用的修補程式與已修正的漏洞。在 Kirkstone（4.0）上，請加入 INHERIT += "create-spdx" 來啟用。

Yocto 產生的是哪個 SPDX 版本？

自 Yocto 5.1（Styhead）起預設為 SPDX 3.0，取代了先前預設的 2.2。Scarthgap（5.0）預設產生 SPDX 2.2，可透過 create-spdx-3.0 類別切換為 3.0。

如何從 Yocto 取得 CycloneDX 格式的 SBOM？

加入對應您版本分支的 meta-cyclonedx layer，並繼承 cyclonedx-export（寫在 local.conf 中）。它會在映像檔旁寫入 .cyclonedx.bom.json SBOM 與 .cyclonedx.vex.json 檔案，預設為 CycloneDX 1.6。

Yocto 的 SBOM 遺漏了什麼？

在 core-image-sato 的並列建置中，CRACI 記錄的 SBOM 包含 Yocto SBOM 中全部 865 個元件，另外還多出 88 個：建置機器上的主機套件（例如 Ubuntu 的 cpio）、GitHub 原始碼與 Actions，以及建置期間取用的其他來源。Yocto 也只以檔案名稱與下載 URL 列出其 653 個 Rust crate 版本，沒有漏洞比對所依賴的套件 URL。至於通用掃描工具為何遺漏得更多，請參閱SBOM 掃描工具為何會遺漏 Yocto 建置中的內容。

可以監控 Yocto 建置中的漏洞嗎？

可以，透過 CRACI。漏洞比對以套件 URL 為依據，而 Yocto 內建的 SBOM 只以檔案名稱與下載 URL 列出 Rust crate，因此無法比對。CRACI 會以資安公告所依據的套件 URL（pkg:cargo、pkg:deb）記錄 Rust crate 與建置機器的套件，包括 core-image-sato 中全部 653 個 crate 版本。它會顯示每個套件的漏洞狀態，並在新的資安公告發布時持續重新評估 SBOM。

CRACI 能取代 Yocto 的 SBOM 嗎？

就供應鏈涵蓋範圍而言，可以。在同一項比較中，CRACI 的 SBOM 包含 Yocto 內建 SBOM 中的所有元件，另外多出 88 個，每個 Rust crate 也都有套件 URL；而且不啟用 Yocto SBOM 產生功能的建置，所需時間少了 43%。不過，Yocto 的 SPDX 輸出仍帶有 CRACI 不會記錄的 recipe 中繼資料，例如已套用的修補程式，以及 recipe 標示為已修正的 CVE。如果您依賴這些資訊，請保持 create-spdx 啟用。

CRACI 執行器能處理完整的 Yocto 映像檔建置嗎？

CRACI 執行器最高可達 32 vCPU 與 96 GB RAM，可在工作流程中設定。CRACI 文件中有一個 Yocto 範例，以最大規格建置 core-image-sato。

在 CRACI 上的 Yocto 建置使用哪一種 CI？

GitHub Actions。您的工作流程在 CRACI 的代管執行器上執行，執行記錄會像其他 Actions 作業一樣顯示在 GitHub 中。其他 CI 系統與客戶自架執行器已列入產品藍圖。