SBOMスキャナーがYoctoビルドの中身を見逃す理由

Yoctoビルドは、スキャナーの想定とどう違うのか

Yoctoビルドは、パッケージマネージャーによるインストールではありません。デバイスに入るものの大部分は、ビルド時に BitBakeの中で、5つのレイヤーで決まります。スキャナーは事後に1つのレイヤーを見て、残りを推測するしかありません。

1. ビルドホスト

BitBakeはビルドマシンのツールを使って動作します。HOSTTOOLS変数には、ビルドタスクが呼び出せるビルドホスト上のツールが列挙され、 ビルドシステムはそれらへのシンボリックリンクを${TMPDIR}/hosttoolsに作成します。BitBakeはまた、 -nativeと-crossのレシピで独自のツールもビルドします。ホストツールはイメージに影響を与えますが、 設計上、イメージの一部にはなりません。

2. 取得

レシピはSRC_URIでソースを指定し、フェッチャーがそれをDL_DIRにダウンロードします。フェッチャーは まずDL_DIRを探し、次にPREMIRRORS、次にアップストリーム、最後にMIRRORSを探します。Rustクレートは crate://フェッチャーで取得され、-crates.incファイルに列挙されます。このファイルは cargo-update-recipe-cratesがCargo.lockから生成します。Goモジュールは go-modクラスで取得されるか、go-vendorでベンダリングされます。BB_NO_NETWORKと BB_ALLOWED_NETWORKSは、フェッチャーの接続先を制御します。

3. レシピとパッチ

各レシピはPVでアップストリームのバージョンを固定し、その上にパッチを適用します。ヘッダーにCVE: 行があるパッチは、そのCVEをパッチ済みとしてマークします。バージョン番号はアップストリームのままなので、レシピは修正済みなのに バージョンはそう示さない、ということが起こります。

4. コンパイル済みコード

静的ライブラリ（-staticdevパッケージ）、Rustクレート、Goモジュールは、それらを使うバイナリの中に入ります。 カーネルとそのモジュールは製品固有の設定からビルドされるため、同じカーネルバージョンを使う2つのプラットフォームでも 含まれるコードは異なります。

5. イメージ

ルートファイルシステムです。イメージ機能package-managementは、パッケージ管理ツールをインストールし、 パッケージマネージャーのデータベースを保持します。これがないと、パッケージマネージャーのデータファイルはルート ファイルシステムから削除されます。本番イメージではよくあることです。

shared state（sstate）キャッシュ

BitBakeは、タスクを実行する代わりに、shared state（共有ステート）キャッシュからタスクの出力を復元できます。Yoctoの概要マニュアルは はっきりこう述べています。ビルド済みのオブジェクトがあればコンパイラーは不要で、「したがって、コンパイラーはダウンロードさえ されません」。sstateから復元されたタスクは取得、コンパイル、インストールを省略します。これは、それらの手順の監視に依存する あらゆるツールにとって重要です。詳しくは後述のキャッシュの節で説明します。

イメージやファイルシステムのスキャナーが大部分を見逃す理由

• パッケージデータベースがない。package-managementなしでビルドされた本番イメージでは、 スキャナーに読むべき一覧がないため、ファイルのヒューリスティクスに頼るか、ほとんど何も報告しません。結果は完全に見えて ほぼ空です。
• 静的コードとベンダリングされたコード。/usr/bin/fooにコンパイルされた静的ライブラリやクレートは、 パッケージの記録を残しません。librsvgがその例です。現在のoe-coreのレシピには350を超えるRustクレートが列挙されていますが、 デバイス上では1つの共有ライブラリです。
• ビルドホストと取得されたツール。これらはイメージに含まれないため、イメージのスキャンにも決して現れません。しかし、 侵害されたホストツールやGitHub Actionはイメージを侵害しえます。xz utilsのバックドア（CVE-2024-3094）は、 Gitリポジトリではなくリリースのtarballから、ライブラリのビルド中に組み込まれました。2025年3月、CISAは、 GitHub Action tj-actions/changed-filesのすべてのバージョンが3日間侵害されていたと報告しました。
• 適用済みのパッチ。イメージには、アップストリームのバージョンのopensslと記載されています。レシピは、そのバージョンに影響する CVEの修正を適用し、パッチにCVE:のタグを付けました。それでもバージョン範囲の照合は、これを検出します。 これはディストリビューションのバックポート問題のYocto版であり、 脆弱性ノイズを減らす方法で扱うノイズの主な発生源の1つです。

結果は、欠けたコンポーネントと誤った検出結果が混ざったものになり、どれがどちらなのかは結果からはわかりません。 同じ議論は、DockerイメージのSBOMのコンテナにも、 オープンソースのSBOMジェネレーターの言語プロジェクトにも当てはまります。

ファームウェアのバイナリスキャンが推測に頼らざるをえない理由

バイナリ解析は、抽出したファームウェア内の文字列、シンボル、コードシグネチャを既知のコンポーネントと照合し、 バージョンを推測します。バイナリに明確な手がかりがあれば、これは機能します。Yoctoイメージでは、推測に頼らざるをえないことがよくあります。

• バージョン文字列のない、ストリップされたバイナリ
• ライブラリの境界が失われた、静的リンクされたコード
• クレートの境界が1つの実行ファイルに消える、コンパイル済みのRust
• バージョン番号には現れない、バックポートされたパッチ
• 設定によってコンパイルに含まれた、または除外されたカーネルコード

バイナリ解析は、自社でビルドしていないファームウェアに適したツールです。サプライヤーのバイナリBLOB、購入したモジュール、 評価中のデバイスなどです。ビルドが手元にないなら、バイナリを解析するしか方法はありません。判断基準はシンプルです。 自社でビルドするなら記録し、受け取るだけなら解析したうえで、サプライヤーにそのビルドのSBOMを求めてください。

Yocto自身のSBOMとCVEのツールが優れている点

Yocto ProjectのSBOMへの取り組みは優れたエンジニアリングであり、外部のツールには知りえないことを知っています。そのドキュメントは SBOMを「使用したすべてのコンポーネント、そのライセンス、依存関係、ソース、それらに適用された変更、 修正された既知の脆弱性の記述」としています。

リリース別のcreate-spdx

• 4.3（Nanbield）：SPDX生成がデフォルトで有効になりました。
• 5.1（Styhead）：2.2に代わってSPDX 3.0がデフォルトになり、外部のCVEツールに必要な情報を渡すvexクラスが加わりました。
• 5.3（Whinlatter）：SPDX_INCLUDE_COMPILED_SOURCESが加わり、コンパイルに使われたソースだけを含められるようになりました。
• 6.0（Wrynose、長期サポート）：SPDX 2.2が削除され、SPDX_INCLUDE_KERNEL_CONFIGとSPDX_INCLUDE_PACKAGECONFIGが追加されました。Cargo、Go、PyPI、npm、CPANのクラスでビルドされたレシピには、エコシステムのパッケージURLが付きます。

SBOMは、BitBakeがホスト向けにビルドするネイティブツールも含め、BitBakeがビルドするものを対象とします。レシピがあるものについては 網羅的です。

SBOM内のVEXとしてのCVEステータス

SPDX 3では、ビルドシステムが各レシピのCVEステータスをVEXの関係として書き出します。パッチ済みのCVEは「fixed」となり パッチファイルにリンクされ、未パッチのものは「affected」、無視されたものは「not affected」となり、理由がインパクト ステートメントになります。SPDX_INCLUDE_VEXで含める範囲を設定します。none、current（デフォルト。 アップストリームのソースでまだ修正されていない脆弱性）、allのいずれかです。

CVE_STATUSとパッチのタグ

CVE_STATUSは、CVEごとの判断を、理由と任意の説明として記録します。理由は、 パッチ済み（backported-patch、cpe-stable-backport、fixed-versionなど）、 未パッチ（vulnerable-investigating）、無視（cpe-incorrect、disputed、 not-applicable-config、not-applicable-platform、upstream-wontfix）に対応します。 CVE_STATUS_GROUPSは1つの判断をCVEのグループに適用し、CVE_PRODUCTは照合に使う製品名を 設定します。

# In a recipe or .bbappend
CVE_STATUS[CVE-2020-15523] = "not-applicable-platform: Issue only applies on Windows"

# In the header of a patch file
CVE: CVE-2022-3341
Upstream-Status: Backport [link to the upstream commit]

cve-checkからsbom-cve-checkへ

cve-checkは、レシピ名（CVE_PRODUCT）とバージョンを脆弱性データと照合していました。 5.2のリリースノートは、2024年初めからNVDのメンテナーが多くのCVEに影響を受けるCPEの注記を付けなくなったため、 「現在のCVEレポートは良好に見えるかもしれないが、実際には一部の脆弱性がまったく報告されていない」と警告しています。 5.2ではまた、NVDに代わってFKIEのフィードがデフォルトになりました。Yocto 6.0はcve-checkを削除し、 sbom-cve-checkクラスに置き換えました。このクラスは、Bootlinの sbom-cve-checkを SPDX出力に対して実行します。5.0から5.3ではcve-checkがまだ使えますが、レガシーとして扱ってください。

YoctoのSBOMが届かないところ

Yoctoに見えないのは、BitBakeのメタデータの外にあるものすべてです。私たちはcore-image-satoを、 32 vCPUのネイティブARM64ランナーで2回ビルドしました。1回はYoctoのSBOM生成あり、1回はなしです。そして、 1,632ファイルとして書き出されたYoctoのSPDX 3.0.1 SBOMと、CRACIが記録したCycloneDX SBOMを比較しました。

• コンポーネント。CRACIが記録したSBOMには、YoctoのSBOMにあるすべてのコンポーネントに加え、YoctoのSBOMにない88のコンポーネントが含まれていました。 ビルドマシン上の23のホストパッケージ（Ubuntuのcpioなど）、GitHub Action actions/upload-artifactを含む10のGitHubソース、ビルド中に取得された55のその他のソースとツールです。
• Rustクレート。どちらも同じ653のRustクレートのバージョンを記載していました。私たちがビルドしたリリースでは、YoctoのSBOMは それらを.crateファイルとダウンロード場所だけで記載し、pkg:cargoのパッケージURLがなかったため、 アドバイザリと照合できませんでした。Yocto 6.0以降、Cargoクラスでビルドされたレシピには、 pkg:cargo/librsvgのように、レシピ自体のパッケージURLが付きます。現在のコードでも、個々のクレートのダウンロードには パッケージURLがありません。ご利用のリリースが何を書き出すか確認してください。
• コスト。YoctoのSBOM生成ありのビルドは155分40秒かかり、1,632のSPDXファイルを書き出しました。生成なしでは 88分48秒で、43%短くなりました。SPDX_INCLUDE_SOURCES、 SPDX_INCLUDE_COMPILED_SOURCES、SPDX_INCLUDE_KERNEL_CONFIG、 SPDX_INCLUDE_PACKAGECONFIGが有効だったため、デフォルト設定ならコストはもっと低くなります。Yocto自身のドキュメントも、 コンパイル済みソースを含めると、core-image-minimalの非圧縮のSBOMは「数百メガバイトから数ギガバイトに 膨らむことがある」と警告しています。

cmake、llvm、ninja、qemuなどのネイティブレシピは、YoctoのSBOMに含まれています。 手法、両方のSBOM、レポート全文はCRACIでのYoctoビルドにあります。

LinuxカーネルのCVE：設定ごとの問題

Linuxカーネルプロジェクトは2024年2月13日にCVE Numbering Authorityになったと発表し、修正に対して積極的に CVEを割り当てています。そのCVEドキュメントは、特定のCVEが該当するかどうかは「Linuxのユーザーが判断すること」だと 述べています。「私たちはあなたのユースケースを知らず、あなたがカーネルのどの部分を使っているかも知らない」からです。

そのため、カーネルバージョンでの照合は数百件の検出結果を生み、その大半は、ご利用の設定では決してコンパイルされないコードに関するものです。 4つのハードウェアプラットフォームと4つのカーネル設定は、同じカーネルバージョンから4つの異なる答えを生みます。 対処法は4つあります。

1. バージョン照合のみ。そのバージョンのすべてのCVEが報告されます。ノイズは最大です。
2. キュレーションした除外リスト。カーネルのCVEデータから生成したCVE_STATUSのエントリです。 2026年5月、oe-coreはlinux-yocto向けに生成していたリストを削除しました。sbom-cve-checkが、 カーネルが提供するCVEリストからこれを自ら行い、CVEレポートは変わらず、SPDXは20 MB近く小さくなるためです。
3. コンパイルされたもので絞り込む。カーネルのレシピでSPDX_INCLUDE_COMPILED_SOURCESを有効にすると、 improve_kernel_cve_report.pyが、CVEの影響を受けるファイルがカーネルのビルドに使われたかどうかを確認します。 Yoctoのセキュリティマニュアルによれば、これは「CVEの誤検知を70%-80%削減する」とされています。
4. 設定を記録する。SPDX_INCLUDE_KERNEL_CONFIG（6.0）はカーネル設定をSBOMに書き込むため、後から答えを確認できます。

具体例。ネットワークドライバーにあるカーネルのCVEが1件。プラットフォームAはドライバーをビルドし、プラットフォームBはビルドしません。

プラットフォーム	ドライバーをコンパイル？	バージョン照合	コンパイル済みソースのフィルター
A	はい	報告される	報告される：影響を受けるファイルがビルドされた
B	いいえ	報告される	報告されない：影響を受けるファイルはビルドされていない

現時点でプラットフォームごとのカーネルCVEレポートを得るには、Yoctoのコンパイル済みソースのツールをマシン設定ごとに1回実行してください。 答えを決めるのは設定なので、レポートは各設定のビルドから得る必要があります。

キャッシュ、ミラー、ベンダリング：どの記録方式でも注意が必要な点

• sstateや中身のあるDL_DIRからすべてを復元するビルドは、ほとんど何も取得しません。 取得を捉える記録方式は、そのキャッシュとともにエビデンスを引き継がなければ、記録が縮んでしまいます。
• 事前にベンダリングされたtarballを指すレシピでは、ダウンロードが1つ見えるだけで、その中のクレートやモジュールは見えません。
• 何を使う場合でも、リリースイメージは既知のキャッシュ状態からビルドし、自社で管理するミラーを維持し、ビルド間でコンポーネント数を 比較してください。

CRACIでは、CIキャッシュから復元されたパッケージもSBOMに残り、各ジョブの完全性の状態が、記録で 捉えられなかったものを示します。

何を実行すべきか：判断表

状況	使うもの	得られるもの	まだ足りないもの
GitHub Actionsでイメージをビルドしている	ビルドを記録する（CRACI）。パッチとCVEのステータスに依存している場合はcreate-spdxを残す	ホストパッケージ、取得されたソースとActions、クレートごとのpkg:cargo URL、継続的な監視	設定ごとのカーネルのフィルタリング：Yoctoのツールを使う
ほかのCIシステムやビルドサーバーでYoctoをビルドしている	create-spdxとsbom-cve-check（古いリリースではcve-check）、コンパイル済みソースによるカーネルのフィルタリング	レシピ、パッチ、VEXとしてのCVEステータス	ホストパッケージと取得されたツールのインベントリ（別途管理）
自社でビルドしていないファームウェアを受け取る	バイナリ解析と、サプライヤーからのビルドSBOM	バイナリから推測されたコンポーネント	バージョン、パッチ、ビルドの入力に関する確実性
プラットフォームごとのカーネルCVEが必要	Yoctoのコンパイル済みソースのツールを、マシン設定ごとに	各設定がビルドするコードのCVE	カーネル以外のコンポーネント（SBOMから）
イメージスキャナーしかない	パッケージデータベースが残っていれば、インストール済みパッケージに使う	ランタイムのパッケージ一覧の一部	コンパイルで組み込まれたもの、パッチが当てられたもの、ビルドホストに残ったものすべて。クリーンな結果はエビデンスではない

各手法に見えるもの

コンポーネントの種類	イメージスキャナー	バイナリ解析	Yocto create-spdx	ビルドの記録（CRACI）
インストール済みパッケージ	パッケージデータベースが残っている場合のみ	ファイルから推測	はい	はい、ビルドが取得したソースから
静的ライブラリ	いいえ	シグネチャから推測	はい、レシピとして	はい、ビルドが取得したソースから
Rustクレート	いいえ	推測。クレートの境界は消える	.crateのダウンロードとして。クレートごとのパッケージURLはなし	はい、それぞれpkg:cargoのパッケージURL付き
Goモジュール	いいえ	バイナリから推測	レシピのモジュールのダウンロードとして	はい、ビルド中に取得された場合
適用済みのパッチとCVEステータス	いいえ	いいえ	はい、VEXとして	いいえ
カーネル設定	いいえ	いいえ	はい、SPDX_INCLUDE_KERNEL_CONFIG（6.0）で	いいえ
ビルドマシン上のホストツール	いいえ	いいえ	いいえ（ネイティブレシピは、はい）	はい
レシピの外で取得されたビルドツールと、GitHub Actions	いいえ	いいえ	いいえ	はい

CRACIの位置づけ

GitHub Actionsで実行するYoctoビルドでは、CRACIがランナーになり、最大32 vCPUと96 GBのRAMを備えます。CRACIは、 ホストパッケージ、GitHubのソースとActions、その他の取得されたソースを含め、ビルドが取り込んだものを、すべてのRustクレートの パッケージURLとともに記録します。公開した比較では、YoctoのSBOMにあるすべてのコンポーネントに加え、YoctoのSBOMにない88のコンポーネントを記録しました。 コンポーネントをアドバイザリと照合し、新たなアドバイザリが公開されるたびにSBOMを再評価し続け、脆弱な依存関係を含んでいた ビルドを示します。

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

サプライチェーンのカバレッジという点では、CRACIのSBOMはcreate-spdxの代わりになります。ただし、YoctoのSPDXには、 適用されたパッチと修正済みとマークされたCVEが含まれ、これらはCRACIでは記録されません。それらに依存している場合は、create-spdxを 有効のままにしてください。CRACIのドキュメントには、core-image-satoをビルドする例があります。一般に記録がスキャンに勝る理由は ビルド時のSBOMで、Yoctoのツールの比較は 組み込みセキュリティツールの比較と CRACIとTimesys Vigilesの比較で紹介しています。

CRACIが適さない場合

• CVE_STATUSの判断や、パッチ済みまたは無視されたCVEのVEXなど、パッチレベルのCVEステータスに依存している場合。これはYoctoのSPDXにあるので、残してください。
• 設定ごとのカーネルCVEレポートが今すぐ必要な場合。Yoctoのコンパイル済みソースのツールを使ってください。
• ファームウェアを自社でビルドしていない場合。バイナリ解析を使ってください。
• YoctoビルドをGitHub Actions以外で実行している、または自社のインフラで実行する必要がある場合。CRACIは現在、欧州のインフラ上でマネージドランナーを 提供しています。ほかのCIシステムと顧客ホスト型のランナーはロードマップに掲載されています。
• YoctoジョブのSBOMが、特にSPDX形式で必要な場合。公開した比較でのCRACIのSBOMはCycloneDXでした。Yocto自身のSBOMはSPDXです。

EU市場向けにコネクテッドデバイスを開発していますか？CRAの要件、 VEXの仕組み、そしてCRACIが通信・ネットワーク機器、 産業用IoT、 コンシューマーエレクトロニクスにどう適合するかをご覧ください。

Yocto CVE checkとSBOM：よくある質問

なぜ私たちのSCAツールでは、Yoctoベースの製品をスキャンできないのですか？

多くのSCAツールはマニフェスト、lockfile、イメージのパッケージデータベースを読み取りますが、Yoctoビルドは中身をBitBakeの中で決めるからです。本番イメージではパッケージデータベースが削除されることが多く、静的ライブラリとRustクレートはバイナリにコンパイルされ、レシピのパッチはアップストリームのバージョン番号をそのまま残し、ビルドホストのツールはイメージに含まれません。

YoctoイメージやファームウェアをTrivy、Grype、バイナリスキャナーでスキャンできますか？

できますが、得られるのは部分的な答えです。イメージスキャナーは、パッケージデータベースが残っていればインストール済みパッケージを読み取りますが、コンパイルで組み込まれたものは見逃します。バイナリスキャナーは文字列とシグネチャからコンポーネントを推測するため、ストリップされたバイナリ、静的コード、コンパイル済みのRustでは推測に頼らざるをえません。どちらも、ビルドホストやレシピが適用したパッチは見えません。

YoctoのSBOMにはRustクレートとGoモジュールが含まれますか？

それらを使うレシピのソースとして記載されます。私たちがビルドしたリリースでは、各Rustクレートはダウンロード場所付きの.crateのダウンロードとして記載され、pkg:cargoのパッケージURLはありませんでした。Yocto 6.0以降、CargoクラスとGoクラスでビルドされたレシピにはエコシステムのパッケージURLが付きますが、それはレシピ自体のもので、個々のクレートやモジュールのダウンロードのものではありません。

Yoctoのレシピですでにパッチを当てたCVEを、スキャナーが報告するのはなぜですか？

スキャナーがバージョン番号を照合するからです。Yoctoのレシピはアップストリームのバージョンを維持し、セキュリティ修正をパッチとして適用します。パッチにはCVE:行でタグが付けられるか、CVE_STATUSに記録されます。バージョン範囲の照合ではパッチは見えません。Yocto自身のSPDXは、それらのCVEを修正済みとして、パッチファイルへのリンク付きで記録します。

Yoctoでcve-checkに代わったものは何ですか？

Yocto 6.0のsbom-cve-checkクラスです。ビルドのSPDX出力に対してBootlinのsbom-cve-checkを実行します。リリース5.0から5.3には、レシピ名とバージョンを照合するcve-checkがまだあります。5.2のリリースノートは、多くのCVEにCPEデータが付かなくなったため、そのレポートは脆弱性を見逃す可能性があると警告しています。

自社のカーネル設定に対するLinuxカーネルのCVEを得るにはどうすればよいですか？

カーネルのレシピでSPDX_INCLUDE_COMPILED_SOURCESを有効にし、improve_kernel_cve_report.pyを実行します。これは、各CVEの影響を受けるファイルがコンパイルされたかどうかを確認します。Yoctoのセキュリティマニュアルによれば、CVEの誤検知を70%から80%削減します。設定ごとにビルドされるコードが異なるため、マシン設定ごとに実行してください。

shared stateキャッシュはSBOMに影響しますか？

影響することがあります。sstateから復元されたタスクは取得とコンパイルを省略するため、それらの手順の監視に依存するツールに見えるものは少なくなります。Yoctoのcreate-spdxはレシピのメタデータをもとに動作します。どの手法でも、リリースイメージは既知のキャッシュ状態からビルドし、ビルド間でコンポーネント数を比較してください。

Yocto組み込みのSBOMでCRAには十分ですか？

CRAは少なくともトップレベルの依存関係を対象とするSBOMを求めており、YoctoのSBOMはBitBakeがビルドするものについては網羅的です。ただし、ビルドマシン上のホストパッケージ、GitHub Actions、レシピの外で取得されたツールは記載されません。それで十分かどうかはご自身の判断です。SBOMはプロセスのエビデンスであり、それだけでコンプライアンスになるわけではありません。