---
title: "YoctoのCVEチェック手順：cve-check廃止後のsbom-cve-checkとYocto-VEX-Checkの使い分け"
url: "https://www.issoh.co.jp/tech/details/10914/"
published: 2026-02-10
updated: 2026-11-11
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# YoctoのCVEチェック手順：cve-check廃止後のsbom-cve-checkとYocto-VEX-Checkの使い分け

YoctoでCVEチェックをかける手段は、使っているリリースで変わりました。5.0 Scarthgapから5.3 Whinlatterまでの系列では、標準の`cve-check`クラスがビルド中にNVDと照合します。2026年のLTS版6.0 Wrynoseでこのクラスは削除され、Bootlinの`sbom-cve-check`が公式の後継になっています。この記事では、版ごとの設定と出力、誤検知の直し方、出荷後のSBOMの再スキャンを、OE-coreのソースと公式ドキュメントで確かめた内容で整理します。外部ツールYocto-VEX-Checkの今の扱いと、EUサイバーレジリエンス法（CRA）の報告義務との関係も扱います。

## まとめ：Yoctoの版ごとのCVEチェック手段

| リリース               | サポート      | ビルド時のチェック           | 出荷後の再スキャン          |
| ------------------ | --------- | ------------------- | ------------------ |
| 6.1 Blacksail      | 2027年4月まで | sbom-cve-check（同梱）  | sbom-cve-check CLI |
| 6.0 Wrynose（LTS）   | 2030年4月まで | sbom-cve-check（同梱）  | sbom-cve-check CLI |
| 5.0 Scarthgap（LTS） | 2028年4月まで | cve-check、または追加レイヤー | sbom-cve-check CLI |
| 4.0 Kirkstone      | EOL       | cve-check           | sbom-cve-checkは非対応 |

- 6.0以降で `INHERIT += "cve-check"` は使えません。設定フラグメント `core/yocto/sbom-cve-check` を有効にすると、イメージごとにcve-check互換のJSONとCVE情報入りのSPDX 3.0が出ます。
- 5.0では従来のcve-checkが今も動きます。sbom-cve-checkへ寄せたい場合はBootlinのmeta-sbom-cve-checkレイヤーを足し、SPDXを3.0へ切り替えます。
- 出荷済みイメージのSBOMは、PyPIのsbom-cve-check（2026年11月2日の1.4.0が最新）でビルド環境なしに再スキャンできます。1.4.0からOpenVEX形式でも書き出せます。
- Linuxカーネルは件数が多いので、コンパイルしたソースだけを対象にする設定と `improve_kernel_cve_report.py` で誤検知を削ります。
- Yocto-VEX-Checkは2025年3月以降更新がなく、入力のSPDX 2.2も6.0で生成されなくなりました。新規に組むならsbom-cve-checkを選びます。

## Yoctoの版ごとに使えるCVEチェックの手段

判断の起点は、OE-coreで2026年4月10日に入ったコミット[00de455](https://git.openembedded.org/openembedded-core/commit/?id=00de455)です。cve-check.bbclassとNVD取得用のレシピが削除され、6.0に含まれました。コミットメッセージは、sbom-cve-checkがOE-coreに取り込まれたのでcve-checkは不要になり、Wrynoseの4年間のサポート期間中に保守しなくて済むよう削除する、と説明しています。同じ6.0でSPDX 2.2の生成も削除されました。

サポート期限は[Yocto ProjectのReleases表](https://wiki.yoctoproject.org/wiki/Releases)の値です。2026年10月にリリースされた6.1 Blacksailは6か月サポートの通常版で、長く保守する製品の土台にはLTSの6.0か5.0を選びます。OE-coreのタグで見ると、2026年11月時点の最新ポイントリリースは6.0.4と5.0.21です。Kirkstone（4.0）は2026年4月の4.0.35が最後のポイントリリースで、Whinlatter（5.3）とともにReleases表ではEOLになっています。

注意点が1つあります。2026年11月11日時点でも、[6.0版のSecurity Manual](https://docs.yoctoproject.org/6.0/security-manual/vulnerabilities.html)は `INHERIT += "cve-check"` の手順を載せたままです。sbom-cve-checkの手順は開発版（6.1-tip）のドキュメントにあります。6.0のビルドで版付きドキュメントのとおりに設定すると、削除済みのクラスを読みにいって止まります。

## Scarthgap（5.0）でcve-checkを実行する手順

5.0の手順は[5.0版のDevelopment Tasks Manual](https://docs.yoctoproject.org/5.0/dev-manual/vulnerabilities.html)にあります。レシピ名と版をNVDのデータと照合し、各CVEを Patched／Unpatched／Ignored に分類する仕組みです。

### cve-checkの有効化設定とイメージ検査

`conf/local.conf` に次の2行を足します。2行目は、OE-coreが影響なしと判断済みの古いCVEをまとめて除外する設定です。

```
INHERIT += "cve-check"
include conf/distro/include/cve-extra-exclusions.inc
```

あとは普段どおりイメージをビルドすれば検査も走ります。ビルド済みの環境で検査だけをやり直す場合と、特定のレシピだけを見る場合は次のとおりです。

```
$ bitbake core-image-minimal
$ bitbake --runall cve_check core-image-minimal
$ bitbake -c cve_check openssl busybox
```

5.0の環境で、後述のvexクラスとcve-checkを同時に有効にすると、vex.bbclassが「互換性のない組み合わせ」としてレシピをスキップします。どちらか一方だけを有効にしてください。

### レポートの出力先と読み方

| 出力    | 場所                             | 中身                |
| ----- | ------------------------------ | ----------------- |
| 全体の要約 | `tmp/log/cve/cve-summary.json` | ビルドした全レシピ         |
| レシピ別  | `tmp/deploy/cve/<レシピ名>`        | CVEごとの状態とCVSS     |
| イメージ別 | `tmp/deploy/images/<マシン名>/`    | .cve（テキスト）と .json |
| 警告の詳細 | レシピの `temp/cve.log`            | Unpatchedの一覧      |

Unpatchedが見つかると、ビルドログに `do_cve_check: Found unpatched CVE (CVE-2019-6293)` のような警告が出ます。この警告はビルドを止めないので、CIで判定したい場合はイメージ別のJSONを読んで `"status": "Unpatched"` の件数を数えるジョブを別に置きます。Unpatchedは「パッチが当たっていない」という意味で、自社製品に影響するとは限りません。設定で外した機能のCVEも含まれるので、後述の誤検知の節の手順で理由を付けて Ignored に振り分けます。

### NVDデータベースの取得とAPIキー

5.0のcve-checkは、`cve-update-nvd2-native` レシピがNVDのAPI 2.0からデータを取り、`DL_DIR/CVE_CHECK/nvdcve_2-2.db` に保存します。[変数リファレンス](https://docs.yoctoproject.org/5.0/ref-manual/variables.html)によると、更新間隔の `CVE_DB_UPDATE_INTERVAL` は既定で86400秒（1日1回）、0で毎回更新、負の値で更新しません。APIキーなしでも動きますが、レシピのコメントは、NVDで発行したキーを `NVDCVE_API_KEY` に設定するとレート制限が緩くなると説明しています。初回の全件取得やCIで毎回取り直す運用では設定しておきます。

```
NVDCVE_API_KEY = "<NVDで発行したキー>"
CVE_DB_UPDATE_INTERVAL = "86400"
```

リリース判定に使うレポートは、取得したDBの日付とセットで残してください。NVDのデータは毎日変わるので、同じイメージでも検査した日によって結果が変わります。

## Yocto 6.0以降でsbom-cve-checkを有効にする手順

6.0以降は、ビルドが作るSPDX 3.0のSBOMをsbom-cve-checkが読み、NVDとCVE ProjectのCVEリストに照合します。レシピの `CVE_STATUS` やパッチの情報はSBOMの注釈として渡ります。

### sbom-cve-checkの有効化フラグメント

ビルドディレクトリで次のどちらかを実行します。

```
$ bitbake-config-build enable-fragment core/yocto/sbom-cve-check
# または conf/local.conf などに追記
OE_FRAGMENTS += "core/yocto/sbom-cve-check"
```

フラグメント（`meta/conf/fragments/yocto/sbom-cve-check.conf`）が入れる設定は次のとおりです。

- `INHERIT += "create-spdx"` と `IMAGE_CLASSES:append = " sbom-cve-check"`
- NVDとCVEリストの取得レシピを `AUTOREV` で常に最新にする設定
- `SPDX_INCLUDE_VEX = "all"`（既定の current は上流で未修正のものだけをSBOMに入れる）
- `SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"`（カーネルの絞り込み用）

NVDのデータは、fkie-cadが公開しているnvd-json-data-feedsのGitリポジトリから取ります。6.1のフラグメントには、2つの取得レシピの `SRC_URI` からタグ指定を外す行が増えています。コメントによると、タグ指定が残っていると `AUTOREV` で `do_unpack` が失敗するためです。6.0.4のフラグメントにこの行はないので、6.0系で最新のDBを取れているかは、取得レシピのログで確かめてください。

ビルド中の検査は `--offline-mode` と `--disable-auto-updates` を付けて走るので、DBはビルド時に取得したリビジョンで固定されます。同梱のツールは6.0.4・6.1とも `python3-sbom-cve-check_1.3.5` で、PyPIの最新1.4.0ではありません。OpenVEX出力などの新機能を使うなら後述のCLIを使います。

### sbom-cve-checkの出力ファイルと形式設定

ビルドが終わると `DEPLOY_DIR_IMAGE` に2つのファイルが出ます。cve-check互換の `<イメージ名>-<マシン名>.rootfs.sbom-cve-check.yocto.json` と、CVE情報を書き足したSPDX 3.0の `.rootfs.sbom-cve-check.spdx.json` です。cve-check向けに書いた集計スクリプトは、読むファイル名を差し替えればそのまま使えます。

出力の種類は `SBOM_CVE_CHECK_EXPORT_VARS` で変えられます。OE-coreの `sbom-cve-check-common.bbclass` には、人が読む要約を `.cve.txt` で出す定義が用意されていますが、既定では無効です。

```
SBOM_CVE_CHECK_EXPORT_VARS:append = " SBOM_CVE_CHECK_EXPORT_SUMMARY"
SBOM_CVE_CHECK_EXTRA_ARGS = "--export-filter-min-cvss-score 7.0"
SBOM_CVE_CHECK_SHOW_WARNINGS = "1"
```

`SBOM_CVE_CHECK_EXTRA_ARGS` はsbom-cve-checkへ追加の引数を渡す変数です。`SBOM_CVE_CHECK_SHOW_WARNINGS` の既定値は “1” で、Unpatchedがあると `do_sbom_cve_check: glibc-2.43+git: Found unpatched CVEs: ...` の形で警告が出ます。この警告はcve-check互換JSONの出力が有効なときだけ出るので、`SBOM_CVE_CHECK_EXPORT_VARS` を上書きするときは `SBOM_CVE_CHECK_EXPORT_CVECHECK` を外さないでください。

### sbom-cve-check-recipeの検査範囲と実行設定

cve-checkの `bitbake -c cve_check <レシピ名>` に当たる機能として、6.0以降のOE-coreには `sbom-cve-check-recipe` クラスがあります。ソース上の定義では、レシピのSBOMを作る `do_create_recipe_sbom` の後に `do_sbom_cve_check_recipe` タスクが走り、検査範囲は依存を含めたtargetとnativeの両方です。

```
INHERIT += "sbom-cve-check-recipe"
$ bitbake -c sbom_cve_check_recipe openssl
```

依存のnativeツールまで数えるので、件数はイメージ単位より多くなります。クラスのコメントも多くの用途ではイメージ単位の検査を勧めており、レシピの版上げで新しいCVEが増えないかを確かめる用途に絞るのが妥当です。

## 出荷後にSBOMを再スキャンする手順

CVEは出荷後も毎日増えます。ビルドディレクトリを保持せずに再スキャンできるよう、出荷時のSBOMを保管し、sbom-cve-checkのCLIで定期的に照合し直します。Yocto-VEX-Checkが担おうとしていたのもこの役割でした。

### sbom-cve-check CLIのインストールとSBOM照合

[PyPI](https://pypi.org/project/sbom-cve-check/)の最新は2026年11月2日の1.4.0で、Python 3.10以上が必要です。ライセンスはGPL-2.0-or-laterです。1.4.0の `--help` で確かめた主なオプションを使うと、保管したSBOMを次のように再スキャンできます。

```
$ python3 -m venv .venv && . .venv/bin/activate
$ pip install "sbom-cve-check[extra]==1.4.0"
$ sbom-cve-check \
    --sbom-path core-image-minimal-qemux86-64.rootfs.spdx.json \
    --export-type yocto-cve-check-manifest \
    --export-path cve-2026-11-11.json \
    --export-filter-vulnerable
```

`--export-type` は csv／summary／spdx3／yocto-cve-check-manifest／openvex の5種類です。Gitで取得するDBは既定で自動更新されます。監査で結果を再現する必要があるときは、`--disable-auto-updates` で更新を止め、`--gen-repro-config` で使った設定をTOMLに書き出しておきます。CIで重大度の高いものだけを拾うなら `--export-filter-min-cvss-score 7.0` のように閾値を付けます。

### sbom-cve-check 1.4.0のOpenVEX出力

[1.4.0の変更履歴](https://github.com/bootlin/sbom-cve-check/blob/main/CHANGELOG.md)によると、`openvex` 出力と `--export-author` オプションが追加され、OpenVEX v0.2.0の文書を直接生成できるようになりました。同じ版で、Yoctoのvexマニフェストから作る判定（Unpatched・Ignoredとその理由）の誤りも修正されています。

```
$ sbom-cve-check \
    --sbom-path core-image-minimal-qemux86-64.rootfs.spdx.json \
    --export-type openvex \
    --export-author "Example Corp PSIRT" \
    --export-path core-image-minimal.openvex.json
```

顧客から「このCVEは御社製品に影響するか」と聞かれたときに返す文書を、ビルドの判定から機械的に作れます。ただし判定の中身はレシピ側の `CVE_STATUS` の質で決まります。理由を付けずに除外したCVEは、OpenVEXにしても根拠のない not\_affected になるだけです。

### Scarthgap（5.0）で使う追加レイヤーと設定

5.0のOE-coreにはsbom-cve-checkクラスがないため、Bootlinの[meta-sbom-cve-check](https://github.com/bootlin/meta-sbom-cve-check)を `bblayers.conf` に足します。READMEの対応版はScarthgap・Walnascar・Whinlatterで、5.0ではSPDX 2.2を外して3.0を有効にし、vexクラスをグローバルに有効にするのが条件です。

```
INHERIT:remove = "create-spdx"
INHERIT += "create-spdx-3.0"
SPDX_INCLUDE_VEX = "current"
INHERIT += "vex"
IMAGE_CLASSES:append = " sbom-cve-check"
```

[sbom-cve-checkのドキュメント](https://sbom-cve-check.readthedocs.io/en/latest/sbom.html)は、Scarthgapの対応をyocto-5.0.14以降としています。5.0で `SPDX_INCLUDE_VEX` を all にしないのは、Whinlatter（5.3）より前ではSPDXの生成が非常に遅くなり、ファイルが1GBを超えることがあると同ドキュメントが警告しているためです。この構成ではcve-checkを外します（前述のとおりvexクラスと同時には使えません）。

## 誤検知を減らす設定：CVE\_PRODUCT・CVE\_STATUS・パッチのCVEタグ

cve-checkでもsbom-cve-checkでも、照合はレシピ名（`BPN`）と版で行われます。誤検知と見逃しの多くはこの対応付けのずれなので、[公式のSecurity Manual](https://docs.yoctoproject.org/security-manual/vulnerabilities.html)が挙げる4つの手段で直します。

| 症状                 | 直す変数・書き方                                        |
| ------------------ | ----------------------------------------------- |
| 同名の別製品のCVEが出る      | `CVE_PRODUCT = "flex_project:flex westes:flex"` |
| 版の表記が合わず漏れる        | `CVE_VERSION`                                   |
| パッチで直したのにUnpatched | パッチ先頭に `CVE: CVE-2022-3341`                     |
| 影響しない理由がある         | `CVE_STATUS[CVE-ID] = "状態: 理由"`                 |

`CVE_STATUS` の状態は `meta/conf/cve-check-map.conf` で Patched／Unpatched／Ignored に対応付けられています。たとえば `cpe-incorrect`（CPEの誤り）や `not-applicable-config`（設定で機能を外している）は Ignored です。同じ理由のCVEが多いときは `CVE_STATUS_GROUPS` でまとめます。

```
CVE_STATUS[CVE-2016-10642] = "cpe-incorrect: npm経由でcmakeを入れるパッケージ固有の問題"
CVE_STATUS_GROUPS += "CVE_STATUS_CONFIG"
CVE_STATUS_CONFIG = "CVE-2023-0001 CVE-2023-0002"
CVE_STATUS_CONFIG[status] = "not-applicable-config: 該当機能をPACKAGECONFIGで無効化"
```

レシピ単位で検査ごと外す `CVE_CHECK_SKIP_RECIPE` もありますが、指定したレシピはCVE照合をスキップするため、検出されなかったことを修正済みの証拠にはできません。製品として出荷するイメージに入るレシピには使わないでください。NVDの登録内容自体が間違っている場合、公式ドキュメントはレシピ側で回避し続けるよりNVDへ修正を報告することを勧めています。

## Linuxカーネルの大量CVEを絞り込む方法

LinuxカーネルがCVE採番機関（CNA）になってから、カーネルのCVEは件数が急増しました。カーネルは設定でビルドするファイルが変わるため、版だけの照合では、コンパイルしていないソースに関するCVEもUnpatchedとして報告されることがあります。OE-coreには、これを減らすスクリプトが2つありましたが、6.0.2以降は1つになっています。

| スクリプト                           | 同梱されている版            | 役割                      |
| ------------------------------- | ------------------- | ----------------------- |
| generate-cve-exclusions.py      | 5.0〜6.0.1（6.0.2で削除） | カーネル版から CVE\_STATUS を生成 |
| improve\_kernel\_cve\_report.py | 5.0・6.0・6.1         | コンパイル済みファイルで判定し直す       |

`generate-cve-exclusions.py` は、2026年5月28日のコミット[596ad6c3](https://git.openembedded.org/openembedded-core/commit/?id=596ad6c3)で削除され、6.0.2以降と6.1には入っていません。コミットメッセージは、sbom-cve-checkが照合に使うcvelistV5はカーネルCNAの `vulns` リポジトリから作られており、NVDもカーネルのCVEに同じ情報を付けているので、除外リストは不要になったと説明しています。開発版のSecurity Manualは2026年11月時点でもこのスクリプトの手順を載せていますが、6.0.2以降では使いません。使うのは、5.0でcve-checkを回しながら独自カーネルを載せている場合です。cvelistV5を取得して自社カーネルの版で除外リストを作り、レシピから読み込みます（5.0には6.6用の `cve-exclusion_6.6.inc` が同梱）。

```
$ git clone https://github.com/CVEProject/cvelistV5 ~/cvelistV5
$ cd openembedded-core/meta/recipes-kernel/linux/
$ ./generate-cve-exclusions.py ~/cvelistV5 6.12.27 > ~/meta-custom/recipes-kernel/linux/cve-exclusion_6.12.inc
# カーネルのレシピまたは .bbappend に追記
include cve-exclusion_6.12.inc
```

もう1つの `improve_kernel_cve_report.py` は、カーネルCNAが公開する `vulns` リポジトリの情報と、実際にコンパイルしたソースの一覧を突き合わせてレポートを書き直します。公式ドキュメントは、これで誤検知が70〜80%減ると説明しています。コンパイル済みソースの一覧はデバッグ情報から取るため、カーネル側の準備が要ります。

```
KERNEL_EXTRA_FEATURES:append = " features/debug/debug-kernel.scc"
SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"

$ git clone https://git.kernel.org/pub/scm/linux/security/vulns.git ~/vulns
$ python3 openembedded-core/scripts/contrib/improve_kernel_cve_report.py \
    --spdx tmp/deploy/spdx/3.0.1/qemux86_64/recipes/recipe-linux-yocto.spdx.json \
    --datadir ~/vulns \
    --old-cve-report tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.sbom-cve-check.yocto.json
```

このスクリプトはビルドから切り離して実行できるので、出荷後の定期スキャンにも組み込めます。そのためには、カーネルのSPDX（`recipe-linux-yocto.spdx.json`）か `linux-yocto-debugsources.json.zstd` を、イメージのSBOMと一緒にビルドディレクトリの外へ保管しておきます。sbom-cve-check本体も、[ドキュメント](https://sbom-cve-check.readthedocs.io/en/latest/sbom.html)のとおり `CONFIG_DEBUG_INFO` などデバッグ情報を有効にしたカーネルなら同じ絞り込みができます。

## Yocto-VEX-Checkの仕組みと現在の扱い

Yocto-VEX-Checkは、Marta Rybczyńska氏が2024年5月31日にOE-coreのメーリングリストへRFCとして提案した外部ツールです。ビルドが出したメタデータだけを持ち出し、ビルドディレクトリなしで最新のCVE情報と照合し直すことを狙っていました。2025年2月25日に開発元のブログで使い方が公開されています。

### 入力ファイルとwrap-yocto-vex-check.pyのオプション

入力はvexクラスが出す `cve-summary.json` と、ビルドディレクトリ内のSPDX 2.2アーカイブです。照合先はNVDか、CVE ProjectのCVEリスト（cvelistV5）を選びます。READMEに載っている実行形式は次のとおりです。

```
./wrap-yocto-vex-check.py \
  -i ../build/tmp/log/cve/cve-summary.json \
  -o out-check \
  -t tmp-check \
  -b ../build/tmp \
  -db ../cvelistV5-overrides/ \
  -db-type CVE
```

`-b` はSPDXアーカイブを含むビルドディレクトリ、`-db` はNVDのDBファイルかCVEリストのgitリポジトリです。READMEは冒頭で「開発中でファイル形式やオプションは頻繁に変わる」と警告しており、ライセンスはMITです。

### 入手経路・更新状況とsbom-cve-checkへの置き換え

開発元ブログが案内している `gitlab.com/syslinbit/public/yocto-vex-check` は、GitLabのサインイン画面へ転送され、匿名ではクローンできません。公開されている複製は `gitlab.com/ygreky/public/yocto-vex-check` で、最新のコミットは2025年3月6日のLICENSEファイル追加です。推奨されていたCVEリストの修正版フォーク `mrybczyn/cvelistV5-overrides` も、GitHub上の最終pushは2025年3月11日です。

入力のSPDX 2.2は6.0で生成されなくなったので、6.0以降のビルドにYocto-VEX-Checkを前提にしたパイプラインを持ち込むのはやめるべきです。5.0で組んだCIジョブを移すときは、次の対応表で書き換えます。

| やりたいこと     | Yocto-VEX-Check      | sbom-cve-check               |
| ---------- | -------------------- | ---------------------------- |
| 部品リストの入力   | \-b（SPDX 2.2）        | –sbom-path（SPDX 3.0／2.2）     |
| Yocto固有の判定 | \-i cve-summary.json | SBOM内の注釈、–yocto-vex-manifest |
| DBの選択      | \-db／-db-type        | 既定でNVD・CVEリスト、–add-db        |
| 件数の集計      | cve-report.py -s     | –export-type summary         |
| VEX文書の出力   | OpenVEXに近い独自形式       | –export-type openvex（1.4.0〜） |
| 製品名の補正     | overridesフォーク        | 内蔵のproducts DB               |

過去にアーカイブしたSPDX 2.2の資産は、sbom-cve-checkも `--sbom-type spdx2` で読めます（`.spdx.tar.zst` の展開に tar と zstd が必要）。ただしSPDX 2.2にはYoctoのCVE判定がほとんど入らないので、同じビルドでvexクラスが出したJSONも `--yocto-vex-manifest` で渡し、`CVE_STATUS` の判定を引き継いでください。

## VEXの書き方とCRAで求められること

SBOMは「何が入っているか」、VEXは「その脆弱性が自社製品に効くか」を機械可読で表します。両者の関係と作り方は[SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説](/tech/details/13457/)で整理しています。

### VEXのステータスと判定理由の選び方

[OpenVEX仕様（v0.2.0）](https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md)のステータスは not\_affected（対応不要）・affected（修正や緩和が必要）・fixed（この版で修正済み）・under\_investigation（調査中）の4つです。sbom-cve-checkの `--export-filter-vex-status` はこの4つで出力を絞り込みます。

not\_affected には、機械可読の判定理由（justification）か自由記述の impact\_statement のどちらかが必須です。仕様は自動処理の妨げになるとして impact\_statement だけの利用を強く非推奨としています。justificationの値は次の5つで、仕様は下の2つについて「決定的な証明が難しい」と注記しています。

| justification                                           | 意味         | Yoctoで根拠にできるもの       |
| ------------------------------------------------------- | ---------- | -------------------- |
| component\_not\_present                                 | 部品が入っていない  | イメージのSBOM            |
| vulnerable\_code\_not\_present                          | 該当コードを含まない | カーネル設定・PACKAGECONFIG |
| vulnerable\_code\_not\_in\_execute\_path                | 含むが呼ばれない   | 設計資料                 |
| vulnerable\_code\_cannot\_be\_controlled\_by\_adversary | 攻撃者が制御できない | 文章での説明               |
| inline\_mitigations\_already\_exist                     | 緩和策がある     | 文章での説明               |

Yoctoの `cve-check-map.conf` では、`not-applicable-config` がVEXの vulnerableCodeNotPresent に対応付けられています。除外はカーネル設定のように根拠をファイルで示せるものから使い、「攻撃者が制御できない」を理由にする除外は、根拠を文章で残せる場合に限るべきです。

### CRAの報告義務（2026年9月適用）とVEXの関係

[欧州委員会のCRA要約ページ](https://digital-strategy.ec.europa.eu/en/policies/cra-summary)によると、CRAは2024年12月10日に発効し、第14条の報告義務は2026年9月11日から適用されています。全面適用は2027年12月11日です。製造者は、自社製品に含まれる悪用が確認された脆弱性を把握した場合、遅滞なく、遅くとも24時間以内に早期警告、72時間以内に本通知を行い、是正措置が利用可能になってから14日以内に最終報告を提出します。提出先は、ENISAが構築し[2026年9月11日から稼働しているSingle Reporting Platform](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)です。報告義務は2027年12月11日より前に市場に出た製品にも及びます。

24時間の起算点はCVEの公開時ではなく、製造者が悪用を認識した時点です。それでも、該当パッケージがどの出荷イメージに入っているかをすぐ引けなければ期限内に早期警告は出せません。出荷イメージごとのSBOMと定期照合の結果が、その特定の材料になります。附属書I第2部は、構成要素と脆弱性の特定・文書化と、少なくともトップレベルの依存関係を含むSBOMの作成を求めています。同部に「VEX」という語はなく、名指しで求めている形式はSBOMです。VEXは、各CVEが製品に影響するかの判断を顧客や当局に機械可読で伝える手段として使われています。CRA全体の要件は[ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断](/tech/details/16232/)で扱っています。組み込み機器でのSBOM運用やCRA対応の仕組みづくりは、[AI・IoTソリューションの開発支援](/service/ai/iot/)でも相談を受けています。

## よくある質問

### Yocto 6.0で INHERIT += “cve-check” を書くとどうなりますか？

cve-check.bbclass自体が6.0で削除されているため、クラスが見つからずにパースの段階で止まります。設定から外し、`core/yocto/sbom-cve-check` フラグメントを有効にしてください。6.0版のSecurity Manualは2026年11月時点でも旧手順を載せているので、手順は開発版のドキュメントを見ます。

### cve-checkとsbom-cve-checkで判定結果は変わりますか？

レシピの `CVE_STATUS`・`CVE_PRODUCT`・パッチのCVEタグはどちらも使うので、判定の材料は同じです。違いは照合先のDBとカーネルの扱いで、sbom-cve-checkはNVDに加えてCVEリストを照合し、コンパイルしていないカーネルのファイルに関わるCVEを外せます。移行時は同じレシピ・製品設定のイメージを使い、cve-check用とvex／sbom-cve-check用のビルド設定を分けて結果を比較してください。

### Yocto-VEX-Checkは今から導入すべきですか？

新規導入はおすすめしません。最新コミットは2025年3月で、開発元ブログが案内する旧URLは匿名で取得できず、入力のSPDX 2.2も6.0で生成されなくなりました。ビルド後の再スキャンはsbom-cve-checkのCLIで実現できます。

### CRAではVEXの提出が義務ですか？

附属書I第2部が名指しで求めている形式はSBOMで、VEXという語はありません。求められているのは構成要素と脆弱性の特定・文書化、遅滞のない修正、修正済み脆弱性の情報公開などです。VEXはその判断を機械可読で伝える手段で、sbom-cve-check 1.4.0ならビルドの判定からOpenVEX文書を作れます。

### sbom-cve-checkはYocto以外のSBOMにも使えますか？

入力形式はSPDX 3.0のJSON-LDと、Yoctoが生成したSPDX 2.2です。ドキュメントは、Yocto以外のツールが生成したSPDX 2.2は現時点で未対応としています。CycloneDXを読むコンテナ向けのスキャナが必要なら、[Grype](/tech/details/19196/)やTrivyのほうが合います。

## 関連記事

- [SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説](/tech/details/13457/)
- [ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断](/tech/details/16232/)
- [SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説](/tech/details/16216/)
- [Grypeとは：Syftと組むコンテナ・SBOMの脆弱性スキャンとCIで止める条件、Trivyとの選び分け【v0.121】](/tech/details/19196/)
- [OSV-Scannerの使い方｜インストール・コマンド・GitHub Actions設定とTrivyとの違い【v2.7.0】](/tech/details/12926/)

---

出典: [YoctoのCVEチェック手順：cve-check廃止後のsbom-cve-checkとYocto-VEX-Checkの使い分け](<https://www.issoh.co.jp/tech/details/10914/>)（株式会社一創）