採用情報 お問い合わせ

BLOG

Yocto Project

2026 年 10 月 02 日

Yocto Project 5.0 (Scarthgap) での脆弱性チェック

はじめに

Yocto Project 5.0(Scarthgap) では通常、従来の「cve-check.bbclass」を使用して脆弱性チェックを行います。

BitBake 実行時にレシピに記述された脆弱性の情報を解析し脆弱性のチェックを行うため、ビルドプロセスと切り離すことができず、「ビルド後に新たな脆弱性が報告された場合、BitBake を再度実行しない限り、その脆弱性への対応要否をチェックできない」という課題があります。 また、脆弱性チェックの処理は「CPE(Common Platform Enumeration)文字列のパースとマッチング」という複雑でバグが混入しやすいロジックとなっており、脆弱性の判定にバグがあると、誤検知(False Positive)や検知漏れ(False Negative)が発生しても気づきにくいという点も課題となっています。

Scarthgap で出力可能な SBOM は SPDX2.2 となっており、独自に拡張しない限り SBOM 自体に脆弱性情報を埋め込むことはできません。5.0.14 で「create-spdx-3.0.bbclass」がバックポートされており、実験的に SPDX3.0 形式の SBOM を出力することが可能となっていますが、 フォーマットこそ SPDX3.0 になっているものの実装が未熟で必要な情報が欠落しているなどの問題があります。

5.0.15 では「vex.bbclass」がバックポートされ、レシピから脆弱性情報を収集し出力することができるようになっています。これは「Yocto VEX Manifest」と呼ばれ、OpenVEX の仕様に近い構造を持っています。

この機能は create-spdx-3.0.bbclass との連携は実装されていないため、Scarthgap の環境では SPDX3.0 を出力しても脆弱性情報を含めることはできませんが、Wrynose で導入された「sbom-cve-check」は、SBOM と Yocto VEX Manifest を一緒に入力することで脆弱性をチェックすることができます。

sbom-cve-check は Yocto VEX Manifest と組み合わせる場合 SPDX2.2 も処理することができますので、Scarthgap の環境では脆弱性情報を含めることができず、情報の欠落などの問題をかかえる SPDX3.0 を使用するよりも、処理が安定している SPDX2.2 を使用するほうが良いと言えるでしょう。

本稿では Scarthgap で出力した SBOM(SPDX2.2) と Yocto VEX Manifest を使用して、sbom-cve-check による脆弱性チェックを試してみます。

環境のセットアップ

Scarthgap は poky リポジトリによるビルド環境の提供が継続されています。

作業ディレクトリ

作業ディレクトリとして「~/yocto/scarthgap」を使用します。

$ mkdir -p ~/yocto/scarthgap/
$ cd ~/yocto/scarthgap/

poky リポジトリの取得

scarthgap ブランチを指定して git clone します。

$ git clone https://git.yoctoproject.org/poky -b scarthgap

BitBake 実行

初期化スクリプトの実行

初期化スクリプトを実行し BitBake を実行するための環境を設定します。

$ source poky/oe-init-build-env

local.conf の修正

下記を追加して Yocto VEX Manifest の出力を有効化します。

SPDX_INCLUDE_VEX = "current"
INHERIT += "vex"

「SPDX_INCLUDE_VEX = "current"」とすることで評価する VEX の情報を「現在影響を受けている可能性のある CVE」や「まだ評価(トリアージ)されていない CVE」に限定しています。Scarthgap ではこの値を "all"(すべての既知の CVE 情報を網羅する)に設定してしまうと、SPDX ファイルのサイズが 1GB を超えてしまい、生成処理が非常に低速になるという問題があるためです。

Whinlatter(Yocto Project 5.3) 以降では最適化が進むため "all" の使用が推奨されますが、Scarthgap 使用時には "current" を指定するようにすることが推奨されます。

ビルド実行

SBOM 出力はデフォルトで有効になっているので、この状態でイメージをビルドすると Yocto VEX Manifest と SPDX2.2 の SBOM も一緒に出力されます。

$ bitbake core-image-minimal

出力結果

出力される場所は DEPLOY_DIR_IMAGE で指定されたディレクトリで、 今回の環境では「tmp/deploy/images/qemux86-64」になります。

  • core-image-minimal-qemux86-64.rootfs.json: Yocto VEX Manifest
  • core-image-minimal-qemux86-64.rootfs.spdx.tar.zst: SBOM

sbom-cve-check コマンド

インストール

「~/yocto/venv」ディレクトリに Python の仮想環境を作成し、sbom-cve-check をインストールします。

$ python3 -m venv ~/yocto/venv
$ source ~/yocto/venv/bin/activate
$ pip install sbom-cve-check

実行

sbom-cve-check コマンドはアーカイブされたままの SBOM を直接入力することができます。Yocto VEX Manifest は「--yocto-vex-manifest」オプションで指定します。

$ sbom-cve-check \
  --sbom-path core-image-minimal-qemux86-64.rootfs.spdx.tar.zst \
  --yocto-vex-manifest core-image-minimal-qemux86-64.rootfs.json \
  --export-type summary \
  --export-path cve-report-out.txt

初回実行時には脆弱性データベースをダウンロードするため、1 時間程度時間がかかりますがデータベースが存在する状態であれば、1 分程度で脆弱性レポートが作成されます。

実行結果

今回は summary 形式で cve-report-out.txt を出力しました。

Unpatched vulnerabilities in base-files-3.0.14: CVE-2018-6557
Unpatched vulnerabilities in busybox-1.36.1: CVE-2026-38752 CVE-2026-38753 CVE-2026-38755
Unpatched vulnerabilities in glibc-2.39+git: CVE-2010-4756 CVE-2011-0536 CVE-2026-18374 CVE-2026-19499 CVE-2026-19542 CVE-2026-5450 CVE-2026-5928 CVE-2026-6238 CVE-2026-6368 CVE-2026-6791 CVE-2026-77117 CVE-2026-80489 CVE-2026-8674 CVE-2026-86805 CVE-2026-89092 CVE-2026-95818
Unpatched vulnerabilities in linux-yocto-6.6.151+git: CVE-1999-0524 CVE-2010-4563 CVE-2014-8171  ... ( 省略 ) ...
Unpatched vulnerabilities in openssl-3.5.8: CVE-2015-3216
Unpatched vulnerabilities in util-linux-2.39.3: CVE-2026-76642

Linux カーネル (linux-yocto-6.6.151+git) に大量の CVE が存在したため省略しましたが、このようにレポートを得ることができます。

その他の出力形式については、「Yocto Project 6.0(Wrynose) での脆弱性チェック」で触れていますので参考にしてください。

まとめ

Scarthgap の従来の脆弱性チェック機能である「cve-check.bbclass」が抱える課題を回避するために、Wrynose で導入された「sbom-cve-check」による脆弱性チェックを試してみました。

今回は「SPDX_INCLUDE_VEX = "current"」の指定など Scarthgap 環境固有に推奨される設定も紹介しました。

BitBake のビルドプロセスと完全に切り離して脆弱性のチェックを行えるため、ビルド済みの OS イメージに対してデイリーに脆弱性チェックを実施するなど、Scarthgap でも Wrynose と同様に柔軟な運用が可能であることがわかりました。

この記事の著者
三ツ木 祐介 ( みつきん )

2020 年サイバートラスト入社。組み込み Linux に関わる業務に従事している。Yocto Project 公式実践講座 (LFD461-JP)講師。 個人ブログ「みつきんのメモ」にて Yocto Project 関連の情報を発信。 2015 年から CQ 出版のインターフェース誌に寄稿を開始、現在も寄稿を継続している。

本記事に関連するリンク