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.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です。cve-check.bbclassとNVD取得用のレシピが削除され、6.0に含まれました。コミットメッセージは、sbom-cve-checkがOE-coreに取り込まれたのでcve-checkは不要になり、Wrynoseの4年間のサポート期間中に保守しなくて済むよう削除する、と説明しています。同じ6.0でSPDX 2.2の生成も削除されました。

サポート期限はYocto Projectの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は INHERIT += "cve-check" の手順を載せたままです。sbom-cve-checkの手順は開発版（6.1-tip）のドキュメントにあります。6.0のビルドで版付きドキュメントのとおりに設定すると、削除済みのクラスを読みにいって止まります。

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

5.0の手順は5.0版のDevelopment Tasks Manualにあります。レシピ名と版を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が「互換性のない組み合わせ」としてレシピをスキップします。どちらか一方だけを有効にしてください。

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

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 に保存します。変数リファレンスによると、更新間隔の 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の最新は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の変更履歴によると、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を 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のドキュメントは、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が挙げる4つの手段で直します。

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 は、2026年5月28日のコミット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本体も、ドキュメントのとおり 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ジョブを移すときは、次の対応表で書き換えます。

過去にアーカイブした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とは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説で整理しています。

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

OpenVEX仕様（v0.2.0）のステータスは 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つについて「決定的な証明が難しい」と注記しています。

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

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

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

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

関連記事

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