2026 年 09 月 30 日
Yocto Project 6.0 (Wrynose) での脆弱性チェック
はじめに
Yocto Project 6.0(Wrynose) では従来の「cve-check.bbclass」が廃止され、新たに「sbom-cve-check.bbclass」が導入されました。
これにより、「ビルド後に新たな脆弱性が報告された場合、BitBake を再度実行しない限り、その脆弱性への対応要否をチェックできない」という従来の大きな課題が解決されます。
Wrynose では正式に SPDX3.0 形式の SBOM の出力に対応し、BitBake 実行時に SBOM に脆弱性の情報を埋め込むことができるようになりました。 sbom-cve-check.bbclass は BitBake 実行時に「sbom-cve-check コマンド」を呼び出して SBOM に対して脆弱性のチェックを行います。 sbom-cve-check コマンドは BitBake 環境以外でもインストールして使用することが可能であるため、Wrynose で出力した SBOM があれば、BitBake を実行しなくても新たな脆弱性に対応が必要かを判断することができるようになります。
本稿では sbom-cve-check.bbclass の機能を有効化して Wrynose の環境で脆弱性のチェックを試してみます。
環境のセットアップ
Yocto Project5.3(Whinlatter) で poky リポジトリによるビルド環境の提供が廃止されたため、次のどちらかの方法で環境をセットアップする必要があります。
本稿では bitbake-setup を使用して環境をセットアップします。
作業ディレクトリ
作業ディレクトリとして「~/yocto/wrynose」を使用します。
$ mkdir -p ~/yocto/wrynose $ cd ~/yocto/wrynose
bitbake-setup のインストール
bitbake-setup は pip でインストール可能になっています。
「~/yocto/venv」ディレクトリに Python の仮想環境を作成し、bitbake-setup をインストールします。
$ python3 -m venv ~/yocto/venv $ source ~/yocto/venv/bin/activate $ pip install bitbake-setup
「deactivate」で仮想環境から抜けることができます。
セットアップの作成
今回作成するセットアップの構成は以下のようにします。
| 設定項目 | 値 |
|---|---|
| コンフィグレーション | poky-wrynose |
| bitbake コンフィグレーション | poky |
| DISTRO | poky |
| MACHINE | qemuarm64 |
| ディレクトリ | poky-wrynose-cve-check |
bitbake-setup ではプロンプトでインタラクティブに環境を設定しますが、予め使用したい設定が決まっている場合は以下のようにしてプロンプトをスキップすることが可能です。
$ bitbake-setup \
init --non-interactive poky-wrynose \
poky \
distro/poky \
machine/qemuarm64 \
--setup-dir-name poky-wrynose-cve-check
BitBake 実行
初期化スクリプトの実行
初期化スクリプトを実行し BitBake を実行するための環境を設定します。
$ source ~/yocto/wrynose/bitbake-builds/poky-wrynose-cve-check/build/init-build-env
脆弱性チェックの有効化
「core/yocto/sbom-cve-check」フラグメントを有効化して、ビルドプロセスに脆弱性チェックを組み込みます。
$ bitbake-config-build enable-fragment core/yocto/sbom-cve-check
ビルド実行
イメージをビルドすると脆弱性レポートも一緒に生成されます。
$ bitbake core-image-minimal
ビルド結果
ビルドログを見ると unpatched な脆弱性を警告として表示します。詳細はレポートを参照することになりますが、どのコンポーネントを重点的に調査するべきかこの時点で把握できます。
WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: acl-2.3.2: Found unpatched CVEs: CVE-2026-54369, CVE-2026-54370 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: attr-2.5.2: Found unpatched CVEs: CVE-2026-54371 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: busybox-1.37.0: Found unpatched CVEs: CVE-2026-38752, CVE-2026-38753, CVE-2026-38755 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: glibc-2.43+git: Found unpatched CVEs: CVE-2010-4756, CVE-2011-0536, CVE-2025-0577, CVE-2026-18374, CVE-2026-19499, CVE-2026-19542, CVE-2026-77117, CVE-2026-80489, CVE-2026-8674, CVE-2026-86805, CVE-2026-89092, CVE-2026-95818 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: openssl-3.5.8: Found unpatched CVEs: CVE-2015-3216 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: tar-1.35: Found unpatched CVEs: CVE-2026-18477, CVE-2026-18508 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: util-linux-2.41.5: Found unpatched CVEs: CVE-2026-76642 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: util-linux-libuuid-2.41.5: Found unpatched CVEs: CVE-2026-76642 WARNING: core-image-minimal-1.0-r0 do_sbom_cve_check: zlib-1.3.2: Found unpatched CVEs: CVE-2026-85091
単にツールを実行するだけではなくビルドログに必要な情報を出力するようになっています。
脆弱性データベースへのアクセス
次のコマンドを実行して BitBake のビルド時の統計情報 (buildstats) から特に時間のかかったタスクを抽出します。
$ pushd ./tmp/buildstats/< 最後のタイムスタンプ >/ $ find . -type f -not -name "log" | xargs grep "Elapsed time:" | sed 's/:Elapsed time: / /' | sort -n -k 2 -r | head -n 5 $ popd
筆者の環境では次のような結果が得られました。
./build_stats 13171.61 seconds ./sbom-cve-check-update-cvelist-native-2026-08-03-r0/do_fetch 7103.68 seconds ./llvm-native-22.1.8-r0/do_compile 6481.10 seconds ./sbom-cve-check-update-nvd-native-2026.08.03-000011-r0/do_fetch 4956.62 seconds ./clang-native-22.1.8-r0/do_compile 2829.27 seconds
1 行目はビルド全体にかかった時間で、注目すべきは以下のタスクです。
- sbom-cve-check-update-cvelist-native-2026-08-03-r0/do_fetch 7103.68 seconds
- sbom-cve-check-update-nvd-native-2026.08.03-000011-r0/do_fetch 4956.62 seconds
sbom-cve-check に関連するレシピの do_fetch タスクに時間がかかっていることがわかります。
これらの結果は最終的に「tmp/deploy/sbom-cve-check/databases」に格納されるようになっています。 ストレージの消費量を確認すると筆者の環境で7.5G 消費していることがわかります。
$ du -sh tmp/deploy/sbom-cve-check/databases 7.5G tmp/deploy/sbom-cve-check/databases
レシピ名から推測できる通りこれらは脆弱性データベースとなる「CVE リスト」と「NVD」のデータになります。 実際のデータは大量の JSON ファイルです。
脆弱性チェックを有効化した後の初回のビルドでは脆弱性データベースを取得するために非常に長い時間かかりますが、 これらのレシピの SRC_URI で指定されたデータの取得元が git リポジトリであるため、 次回のデータベースアクセス時には差分のみのダウンロードとなり、ここまで時間がかかることはありません。
脆弱性レポート
デフォルトでは DEPLOY_DIR_IMAGE に以下の 2 つのファイルが作成されます。
- < イメージ名 >-< マシン名 >.rootfs.sbom-cve-check.yocto.json
- < イメージ名 >-< マシン名 >.rootfs.sbom-cve-check.spdx.json
それぞれの役割は以下のようになっています。
| ファイル形式 | 特徴・役割 | 主な用途 |
|---|---|---|
| .sbom-cve-check.yocto.json | 脆弱性情報だけに特化した、シンプルで読みやすい概要レポート | 開発チーム内でのクイックな脆弱性監査・トリアージ |
| .sbom-cve-check.spdx.json | SBOM（部品構成表）と脆弱性情報を国際規格で一本化させた総合レポート | 顧客へのセキュリティエビデンス提出、外部システム連携 |
Yocto 形式の脆弱性レポートである「core-image-minimal-qemuarm64.rootfs.sbom-cve-check.yocto.json」の中からビルドログにあった「CVE-2026-54369」のレポートを抽出してみます。
$ jq '.package[] | {name, version, issue: .issue[]?} | select(.issue.id == "CVE-2026-54369")' \
core-image-minimal-qemuarm64.rootfs.sbom-cve-check.yocto.json
結果は以下のようになりました。シンプルな JSON ファイルなので「jq」コマンドなどで抽出できます。
{
"name": "acl",
"version": "2.3.2",
"issue": {
"id": "CVE-2026-54369",
"status": "Unpatched",
"link": "https://nvd.nist.gov/vuln/detail/CVE-2026-54369",
"summary": "acl before version 2.4.0 contains a symlink traversal vulnerability in the libacl pathname-based functions acl_get_file(), acl_set_file(), acl_extended_file(), and acl_delete_def_file() that allows local attackers to escalate privileges by replacing any pathname component with a symbolic link. Attackers who control any component of a pathname processed by a privileged caller can redirect ACL read or write operations to arbitrary files or directories, enabling unauthorized manipulation of access control lists and local privilege escalation.",
"scorev2": "0.0",
"scorev3": "7.1",
"scorev4": "8.4",
"modified": "2026-09-14T13:18:40.000",
"vector": "LOCAL",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"detail": "version-in-range",
"description": "Needs backporting (fixed from 2.4.0)"
}
}
sbom-cve-check コマンド
前述の通り、sbom-cve-check コマンドは BitBake 環境がなくても使用可能です。Wrynose で出力された SBOM があれば新たに報告された脆弱性について BitBake を実行しなくてもチェックすることができます。
sbom-cve-check コマンド自体は柔軟に設計されており、JSON 形式以外のレポート出力や、VEX アノテーションによる元の情報を書き換えずに脆弱性をトリアージを行うこともできるようになっています。
インストール
Python の仮想環境に sbom-cve-check をインストールします。
$ source ~/yocto/venv/bin/activate $ pip3 install sbom-cve-check
実行
sbom-cve-check を実行してみます。
まずは、脆弱性レポートが保存されているディレクトリに移動します。
$ cd ~/yocto/wrynose/bitbake-builds/poky-wrynose-cve-check/build/tmp/deploy/images/qemuarm64
ここでは CSV 形式でレポートを出力します。
$ sbom-cve-check \ --sbom-path core-image-minimal-qemuarm64.rootfs.spdx.json \ --databases-dir ~/yocto/wrynose/bitbake-builds/poky-wrynose-cve-check/build/tmp/deploy/sbom-cve-check/databases \ --disable-auto-updates \ --export-type csv \ --export-path cve-report.csv
スタンドアロンで実行する場合、デフォルトでは「 ~/.cache/sbom_cve_check/databases」に脆弱性データベースを取得します。 BitBake 実行時と同様に初回実行時は 1 時間程度かそれ以上かかってしまうので今回は「--databases-dir」で BitBake 環境で取得したデータベースを指定しています。 そのままでは最新の脆弱性データを取得するためにデータベースを更新しようとしますが、BitBake 環境のデータベースを勝手に更新すると不整合が発生する可能性があるため「--disable-auto-updates」オプションを指定して更新を抑制しています。
完全にスタンドアロンな環境で実行する場合にはこれらのオプションは不要です。
実行結果
作成された CSV 形式のレポートは以下のようになっています。
$ head -n5 cve-report.csv build,package names,version,vendor-product,vuln-id,scorev2,scorev3,scorev4,status,statement,notes,obsolete assessments acl,libacl1,2.3.2,acl,CVE-2009-4411,3.7,,,fixed,,version-not-in-range, acl,libacl1,2.3.2,acl,CVE-2026-54369,,7.1,8.4,affected,Needs backporting (fixed from 2.4.0),version-in-range, acl,libacl1,2.3.2,acl,CVE-2026-54370,,6.3,7.2,affected,Needs backporting (fixed from 2.4.0),version-in-range, attr,libattr1,2.5.2,attr,CVE-2026-54371,,7.1,8.4,affected,Needs backporting (fixed from 2.6.0),version-in-range,
出力形式
sbom-cve-check コマンドでは以下の形式のレポート出力に対応しています。
| 形式名 (export-type) | 出力ファイルの本質・特徴 | 主なユースケース |
|---|---|---|
| csv | 各項目を "," で分割したテキスト | セキュリティ監査、会議での報告、手動トリアージ管理 |
| summary | 対応が必要な脆弱性のサマリを含んだプレーンテキスト | CI/CD の進捗ログ出力、デイリースキャンの要約確認 |
| spdx3 | SPDX3.0 に準拠した JSON-LD | サプライチェーンへの成果物提出、他のセキュリティツールとのシステム連携 |
| yocto-cve-check-manifest | cve-check.bbclass の出力結果と互換性を持つ JSON | 既存の運用への組み込み |
まとめ
Wrynose で導入された「sbom-cve-check」を使用してみました。 BitBake 環境では「core/yocto/sbom-cve-check」フラグメントを有効化するだけで使用することができ、 スタンドアロンで sbom-cve-check コマンドを使用する場合にも pip コマンドにより簡単に導入し使用することができます。
初回実行時には脆弱性データベースを取得するため 1 時間程度の長い時間がかかりますが、一度環境を構築してしまえば次回以降は軽快に動作します。
BitBake のビルドプロセスと脆弱性チェックを分離したことにより、脆弱性の管理について柔軟に運用することができるようになりました。
