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では、レシピごとのドキュメントは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レイヤーがイメージのルートファイルシステムからSBOMを生成し、さらにビルドシステムが把握しているパッチ適用済みおよび無視されたCVEを記載した別のVEXファイルを生成します。ご利用のリリースに対応するレイヤーのブランチをチェックアウトし、レイヤーに追加して、そのクラスを継承します。

# 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では、イメージ、ビルド時のネイティブレシピを含むすべてのレシピ、そのソース、適用されたパッチ、修正済みとされた脆弱性を記載します。core-image-satoでは1,632の個別ファイルになりました。何が含まれないかを確認するため、CRACIのランナー（ネイティブARM64、32vCPU）でイメージをビルドし、それらすべてのファイルにわたって名前を正規化したうえで、YoctoのSBOMとCRACIが記録したSBOMをコンポーネント単位で比較しました。

CRACIのSBOMにある953のコンポーネントのうち、865はYoctoのSBOMにも含まれていました。Yoctoのみに含まれるものはありませんでした。違いは、Yoctoが把握できないもの、そしてYoctoが記載しているものの識別方法にあります。

パッケージURLのないRustクレート

どちらのSBOMにも、cairo-rsやzune-jpegなど559のRustクレート（librsvgが組み込むもの）の、同じ653のバージョンが含まれています。Yoctoはそれぞれを、それを使用するレシピの中で、.crateファイルとcrates.ioのダウンロードURLとしてのみ記載しています。pkg:cargoのパッケージURLを持つものは1つもありません。CRACIはすべてのクレートをパッケージURL付きで記録します。

これが、脆弱性を監視できるかどうかを左右します。脆弱性の照合はパッケージURLに基づいて行われます。クレートに関するアドバイザリはpkg:cargo/...として対象を指定しますが、別のレシピのソース一覧にあるファイル名では、SBOMツールや脆弱性ツールが照合する手がかりがありません。YoctoのSBOMだけでは、イメージ内の脆弱なクレートは報告されないままになります。

CRACIのSBOMでは、すべてのクレートがアドバイザリと照合され、ビルド内の各パッケージに脆弱性ステータスが表示されます。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など。ワークフローが実行したコミットに固定されています
• ビルド中に取得されたその他のソースとツール：pseudo-prebuilt、tzdata、hatchlingやsetuptools_scmなどのPythonビルドツール

これらはいずれもイメージにはインストールされませんが、すべてビルドのクリティカルパス上にあります。侵害されたホストツールやActionは、イメージの一部になることなくイメージを侵害できます。CRACIがこれらを記載できるのは、ビルドに入ってくる通信を見ているからです。

組み込みSBOMのコスト

YoctoのSBOM生成は無料ではありません。同じ32vCPUのランナーで、SBOM生成ありのビルドは155 min 40 sかかり、SBOMを1,632の個別のSPDXファイルとして書き出しました。SBOM生成なしでCRACIが記録したビルドは88 min 48 sでした。CRACIの料金である1vCPU分あたり$0.002で計算すると、ビルドあたり約$9.96対$5.68です。これには、チームが待つ時間は含まれていません。

GitHubホステッドランナーと比べると、差はさらに広がります。CRACIは高速なハードウェア、短いキュー待ち時間、キャッシュにより、ビルドを約2倍の速さで実行します。そのため、YoctoのSBOM生成ありの同じビルドをGitHubホステッドの32コアARM64ランナーで実行すると約5 h 11 minかかります。1分あたり$0.050で$15.60です。CRACIでのビルドは$5.68で、64%安く、約2.7分の1のコストです。GitHubの定価は2026年9月時点のもので、無料枠の適用前です。

YoctoのSPDX出力には、レシピが適用するパッチや修正済みとしたCVEなど、CRACIが記録しない情報も含まれます。プロセスがそれらに依存している場合は、create-spdxを有効のままにして、CRACIのSBOMと併用してください。そうでなければ、CRACIのSBOMだけで、YoctoのSBOMにあるすべてのコンポーネントとそれ以上をカバーできます。

サプライチェーンセキュリティにとって重要な理由

ビルドに何が入るかが、イメージにインストールされるかどうかにかかわらず、ビルドから何が出てくるかを決めます。攻撃者はこれを知っており、最近のサプライチェーン攻撃はビルドから侵入しています。

• 攻撃はビルドに潜みます。xz utilsのバックドア（CVE-2024-3094）はバージョン5.6.0と5.6.1に含まれていました。そのトリガーはGitリポジトリではなくリリースのtarballにあり、悪意のあるコードはライブラリのビルド中に組み込まれました。ソースを読んでも見つかりませんでしたが、ビルドがどのtarballを取得したかを正確に把握していれば見つけられます。
• CIの依存関係も標的になります。2025年3月、CISAはGitHub Actionのtj-actions/changed-filesの全バージョンが3日間にわたって侵害されたと報告しました。Actionはビルドジョブの中で実行されます。だからこそCRACIは、ワークフローが使用したActionsを、実行されたコミットに固定して記載します。
• Rustクレートはバイナリの中に消えます。Cargoはクレートをそれを使うプログラムにコンパイルするため、脆弱なクレートはパッケージとして現れることなくイメージに含まれて出荷されます。SBOMがそれをファイル名でしか記載していなければ、脆弱性ツールも照合できません。完成したバイナリを事後にスキャンする方法では何が入ったかを推測するしかありませんが、ビルドを記録すれば推測は不要です。
• 見えないものには対応できません。クレートやビルドツールについてアドバイザリが出たとき、どのビルドがそれを使っていたかを知る必要があります。CRACIはすべてのビルドのSBOMを保持し、脆弱な依存関係（直接・推移的）を含んでいたビルドを示すため、影響を受けていた期間がわかります。これが機能するのは、すべてのコンポーネントに照合用のパッケージURLがある場合だけです。
• ビルドは必要なものにだけ接続すべきです。CRACIのエグレスポリシーは、ビルドに不要なホストへの接続をブロックします。そのため、シークレットを攻撃者のサーバーに送信しようとする侵害された依存関係は、誰も見たことのない攻撃であっても阻止されます。

顧客や、Cyber Resilience Actなどの規制も、コネクテッドデバイスのメーカーに対し、製品に何が含まれているかを把握することを求めています。ビルド全体をカバーするSBOMは、求められたときに通用するエビデンスです。

YoctoビルドをCIで実行するのが難しい理由

イメージ全体のビルドでは、ツールチェーン、カーネル、数百のパッケージをソースからコンパイルします。多くのCIサービスが提供する標準的な2コアのランナーでは数時間かかることもあるため、多くの組み込みチームは専用のビルドサーバーを机の下やラックに置いています。そのサーバーもまた、パッチ適用やバックアップ、監査人への説明が必要なマシンの1台になります。

Yoctoのビルドは、上流プロジェクトやミラーからソースのtarball、Gitリポジトリ、パッチを大量にダウンロードします。そのダウンロードこそがSBOMで説明すべきものであり、Cyber Resilience Actなどの規制がコネクテッドデバイスのメーカーに把握と追跡を求めているものです。

CRACIがYoctoビルドにもたらすもの

BitBakeに見合ったサイズのランナー

CRACIのランナーは1〜32コンピュートユニットまで拡張でき、各ユニットは1vCPUとRAM 3GBです。Yoctoビルドは、ワークフロー自体から最大サイズの32vCPU・RAM 96GBを指定できます。ジョブは分離された仮想マシンで実行され、実行結果はほかのActionsジョブと同様にGitHubに表示されます。

利用時間は秒単位で計測され、vCPU分単位で課金されるため、大きなランナーは1分あたりのコストが高い分、早く終わります。最新の料金は料金をご覧ください。

アクセス先はお客様が決める

BitBakeは、BB_ALLOWED_NETWORKSでフェッチャーの接続先をホストのリストに制限できます。CRACIはランナー側に2つ目の制御を加えます。ジョブの開始前にチェックされ、フェイルクローズで動作するエグレスポリシーです。フェッチャーを迂回するレシピ、スクリプト、侵害されたツールも、許可していないホストには接続できません。CRACIはポリシー違反を通知します。

ビルドが取得したものの記録

CRACIは、ジョブがパッケージホストやソースホストに送る通信を監視し、ビルドのエビデンスとして記録します。Yoctoビルドでは、Yocto自身が書き出すSBOMとは独立した、実際にネットワーク経由で取得されたソースの記録が得られます。

最小構成のワークフロー

CRACIドキュメントのYoctoの例では、core-image-satoをqemux86-64向けにビルドします。CRACIにとって重要なのは、ランナーのサイズと、Yocto公式のソースミラーを使用するフェッチャーの設定です。

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の取得先は、任意のホストではなく、Yocto公式のソースミラーなどCRACIが把握できるミラーに向けてください。動作する設定はドキュメントのガイドに掲載されています。
• ダウンロードディレクトリと共有ステートキャッシュを実行間で保持することで、2回目以降のビルドが高速になります。
• ネイティブARM64ランナーは、x86-64と同じ料金で利用できます。

EU市場向けにコネクテッドデバイスを開発していますか？CRAの要件と、産業用IoTやコンシューマーエレクトロニクスでのCRACIの活用をご覧ください。Black Duckをお使いですか？Black DuckのBitBakeディテクターとの違いをご覧ください。Yocto SBOMツールを比較していますか？こちらもご覧ください： CRACIとTimesys Vigilesの比較.

Yocto SBOMとCRACIに関するよくあるご質問

YoctoはSBOMを生成しますか？

はい。OpenEmbeddedビルドシステムは、Yocto 4.3（Nanbield）以降、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レイヤーを追加し、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は、653のRustクレートのバージョンをファイル名とダウンロードURLだけで記載しており、脆弱性の照合に必要なパッケージURLがありません。汎用スキャナーがさらに多くを見落とす理由は、SBOMスキャナーがYoctoビルドの中身を見落とす理由をご覧ください。

Yoctoビルドの脆弱性を監視できますか？

はい、CRACIで可能です。脆弱性の照合はパッケージURLに基づいて行われますが、Yocto組み込みのSBOMはRustクレートをファイル名とダウンロードURLでしか記載していないため、照合できません。CRACIは、Rustクレートとビルドマシンのパッケージを、アドバイザリの公開に使われるパッケージURL（pkg:cargo、pkg:deb）付きで記録します。core-image-satoの653のクレートのバージョンもすべて対象です。各パッケージの脆弱性ステータスを表示し、新たなアドバイザリが公開されるたびにSBOMを再評価し続けます。

CRACIはYocto SBOMの代わりになりますか？

サプライチェーンのカバレッジという点では、なります。同じ比較で、CRACIのSBOMにはYocto組み込みのSBOMにあるすべてのコンポーネント、さらに88のコンポーネント、そしてすべてのRustクレートのパッケージURLが含まれており、YoctoのSBOM生成を行わないビルドは所要時間が43%短くなりました。ただし、YoctoのSPDX出力には、適用されたパッチやレシピが修正済みとしたCVEなど、CRACIが記録しないレシピのメタデータが含まれます。それらに依存している場合は、create-spdxを有効のままにしてください。

CRACIのランナーでYoctoイメージ全体をビルドできますか？

CRACIのランナーは最大32vCPU・RAM 96GBまで、ワークフローから設定できます。CRACIのドキュメントには、最大サイズでcore-image-satoをビルドするYoctoの例が掲載されています。

CRACIでのYoctoビルドにはどのCIを使いますか？

GitHub Actionsです。ワークフローはCRACIのマネージドランナーで実行され、実行結果はほかのActionsジョブと同様にGitHubに表示されます。ほかのCIシステムと顧客ホスト型のランナーはロードマップに掲載されています。