Grype（グライプ）は、Anchoreが開発するオープンソースの脆弱性スキャナです。コンテナイメージ、ソースのディレクトリ、SBOMファイルを読み、含まれるパッケージを脆弱性データベースと突き合わせます。この記事では2026年11月時点の最新版v0.121系を前提に、インストールから初回スキャン、Syftと組むSBOM起点の運用、CIでビルドを止める条件、誤検知の例外管理、Trivyとの選び分けまでをコマンドと設定ファイル付きで説明します。
まとめ：Grypeを入れる前に決める設定とTrivyとの使い分けの結論
GrypeはSBOMを入力にした脆弱性の突き合わせと、EPSS・KEVを加味したRISK順の並べ替えに強いツールです。IaCの設定ミスやシークレットの検出は持たないため、それらも1本で済ませたい現場ではTrivyのほうが手数は少なくなります。
導入時に決めるのは次の4点です。CLIの--fail-onは既定で未設定なので、閾値を書かない限りCIは止まりません。逆にGitHub Actionsのanchore/scan-actionは既定でmedium以上を検出すると失敗します。脆弱性DBはビルドから5日（120時間）を超えるとスキャン自体が失敗する仕様です。直せない検出は.grype.yamlの無視ルールかOpenVEXで、理由を残したまま除外します。
SBOMを社内で作り、それを起点に脆弱性を追いたいならGrypeを採用します。コンテナの脆弱性だけを見たい小規模チームで、すでにTrivyが動いているなら、Grypeを追加する必要はありません。
Grypeの仕組みと対象範囲：Syftで部品を洗い出しDBと突き合わせる流れ
Anchore製OSSのGrypeとSyftの役割分担、Apache-2.0の範囲
GrypeのGitHubリポジトリはApache-2.0ライセンスで公開されており、2026年11月2日時点のスター数は13,155、最新版は2026年10月19日公開のv0.121.0です。商用製品に組み込んでも利用料はかかりません。
同じAnchoreのSyftはSBOMを作る側のツールで、同日にv1.55.0が出ています。Grypeは内部でSyftのカタログ機能を使ってパッケージを洗い出し、その一覧を脆弱性DBと照合します。つまり「部品表を作る」のがSyft、「部品表から既知の脆弱性を探す」のがGrypeという分担です。SBOMそのものの目的やCycloneDX・SPDXの違いはSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断で整理しています。
スキャン対象はコンテナイメージ・ディレクトリ・SBOMの3種類
公式READMEが示す入力は、grype alpine:latestのようなイメージ名、grype ./my-projectのようなディレクトリ、grype sbom:./sbom.jsonのようなSBOMファイルです。イメージはDocker・OCI・Singularityの形式に対応し、Linuxではpodmanの保存領域も--from containers-storageで読めます。
判定に使われるのはパッケージ名と版の組です。OSパッケージ（apk・deb・rpm）は配布元のセキュリティ情報と照合され、言語パッケージ（npm・PyPI・Maven など）はGitHub Advisoryなどと照合されます。自分で書いたアプリケーションコードの欠陥は見ません。そこはSASTの守備範囲で、両者の違いはSCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違いに詳しく書いています。
Grypeのインストールから初回スキャンまでをコマンドで試す手順
インストールスクリプト・Docker・Homebrew・wingetの4経路と署名検証
公式のインストール手順で「公式」とされているのは、インストールスクリプトとDockerイメージ（anchore/grype）の2つです。Homebrew・Scoop・winget・MacPortsはコミュニティビルドと明記されています。Windows向けのバイナリも提供されています。
# Linux・macOS：公式スクリプトで /usr/local/bin に入れる
curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin
# Windows（コミュニティビルド）
winget install Anchore.Grype
# Docker で動かす場合
docker pull anchore/grype
# 版の確認
grype versionインストールスクリプトに-vを付けると、ダウンロードした成果物の署名をcosignで検証します。事前にcosignを入れておくことが検証の前提条件です。CIのランナーに毎回入れるなら、版を固定したうえで署名検証まで行う構成にしておくと、配布経路が乗っ取られたときの被害を抑えられます。
alpineイメージを調べる初回スキャンとEPSS・RISK列の読み方
最初のスキャンでは脆弱性DBが自動でダウンロードされます。続けて結果が表形式で出力されます。結果の読み方の公式ガイドでは、列はNAME・INSTALLED・FIXED-IN・TYPE・VULNERABILITY・SEVERITY・EPSS・RISKの8つと、KEVなどを示す注釈列です。
# イメージを調べる（既定は RISK の高い順に並ぶ）
grype alpine:latest
# CVSSの深刻度順に並べ替える
grype alpine:latest --sort-by severity
# JSON で保存して後工程で集計する
grype alpine:latest -o json --file grype-result.jsonEPSSはFIRSTが公開する指標で、今後30日以内に悪用される確率の推定値です。RISKはCVSS・EPSS・ランサムウェアでの利用実績を合わせた0.0〜100.0の値で、CISAのKEVカタログに載った脆弱性は最大の脅威として扱われます。FIXED-INが空なら修正版なし、(won't fix)なら配布元が直さない方針です。深刻度がCriticalでもRISKが一桁なら後回しにしてよい、という判断をRISK列が支えてくれます。
SyftでSBOMを作ってからGrypeに渡す2段構えのスキャン手順
ビルドのたびにイメージを直接スキャンすると、毎回パッケージの洗い出しから始まります。リリース時にSyftでSBOMを作って保管しておけば、後日DBが更新されたときにSBOMだけを再スキャンし、過去のリリースに新しいCVEが該当するかを調べられます。
# 1. SyftでCycloneDX形式のSBOMを作る
syft myapp:1.4.0 -o cyclonedx-json=./sbom.cdx.json
# 2. SBOMをGrypeでスキャンする（イメージの再取得は不要）
grype sbom:./sbom.cdx.json
# 3. 標準入力から渡すこともできる
cat ./sbom.cdx.json | grype他のツールで作ったSBOMにCPE情報が無い場合は、--add-cpes-if-noneを付けるとパッケージ情報からCPEを補います。ただしCPEでの一致は誤検知が増えるため、このフラグは取りこぼしが疑われるときだけ使います。
CIでビルドを止める条件：–fail-onの終了コード2とscan-actionの既定値
–fail-onとonly-fixedで直せる高リスクだけを止める設定例
CLIリファレンスによると、--fail-onは指定した深刻度以上の脆弱性が見つかったときに終了コードを2にします。v0.121.0のソースでも、この判定を終了コード2に割り当てる実装です。終了コード1は実行時エラーと区別されるので、CI側で「脆弱性で落ちたのか、スキャンが壊れたのか」を分けて通知できます。
# .grype.yaml（リポジトリ直下に置くと自動で読み込まれる）
fail-on-severity: high # high 以上で終了コード2
only-fixed: true # 修正版がある脆弱性だけを判定対象にする
output: table
db:
max-allowed-built-age: 120h # 既定値。延ばすと古いDBで合格してしまう実務ではonly-fixed: trueと組み合わせるのが現実的です。修正版の無い脆弱性で毎回ビルドが止まると、開発者は閾値を下げるか、スキャン自体を外す方向に動きます。フィルタの公式ガイドのとおり、このオプションによる除外対象はnot-fixed・wont-fix・unknownの3状態です。除いた分は週次のJSON出力で別途追います。
GitHub Actionsのscan-action：既定の失敗条件はmedium以上
anchore/scan-actionのREADMEでは、fail-buildの既定値がtrue、severity-cutoffの既定値がmediumです。CLIでは止まらなかったリポジトリが、Actionに置き換えた途端に赤くなるのはこの差によります。出力の既定はSARIFなので、GitHubのCode scanningにそのまま載せられます。
name: grype-scan
on: [pull_request]
permissions:
contents: read
security-events: write
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: docker build -t localbuild/myapp:pr .
- uses: anchore/scan-action@27805bf3b4e84b4a5c980df22ed233c00390a439 # v7.4.2
id: scan
with:
image: "localbuild/myapp:pr"
severity-cutoff: high
only-fixed: true
cache-db: true
- uses: github/codeql-action/upload-sarif@v4
if: always()
with:
sarif_file: ${{ steps.scan.outputs.sarif }}Actionの固定にはタグではなくコミットハッシュを指定する方針です。2026年3月にはTrivyの配布経路が侵害され、trivy-actionの既存タグが書き換えられる事案が起きています。経緯はTrivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定までの該当章で経緯を確認できる構成です。スキャナは秘密情報の近くで動くため、Grypeでも同じ対策が要ります。なおconfig入力を指定すると.grype.yamlの自動検出が止まる点にも注意してください。
脆弱性DBが5日を超えると失敗する仕様と閉域網での更新・取り込み手順
脆弱性DBの公式ガイドでは、DBのビルドから5日を超えるとスキャンが自動的に失敗すると書かれています。設定上はdb.validate-ageが既定でtrue、max-allowed-built-ageが120時間です。ダウンロード元はhttps://grype.anchore.io/databasesで、キャッシュは~/.cache/grype/dbに置かれます。
インターネットに出られない環境では、外で取得したDBアーカイブをgrype db importで取り込み、grype db statusで版と作成日時を確かめます。期限切れの回避としてvalidate-age: falseにする例を見かけますが、古いDBで「脆弱性ゼロ」と出るほうが危険です。取り込みの運用が週1回を超えて空くなら、閉域網でのGrype採用自体を見直します。
誤検知と例外の管理：.grype.yamlの無視ルールとOpenVEXで絞る方法
無視ルールに理由と修正状態を書き、例外を棚卸しできる形にする
設定リファレンスのignoreは、ルールの全条件に一致した検出だけを除外します。指定できるのは脆弱性ID、修正状態（fixed・not-fixed・wont-fix・unknown）、パッケージ名・版・種別・場所などです。reasonは一致判定に使われないメモ欄ですが、半年後に「なぜ外したか」を説明できるよう必ず書きます。
ignore:
# 配布元が修正しない方針のもの。ベースイメージ更新時に見直す
- vulnerability: CVE-2021-3712
fix-state: wont-fix
package:
name: libcrypto1.1
type: apk
reason: "配布元がwon't fix。2026-11 ベースイメージ更新時に再評価"パッケージ名だけ、場所だけで広く外すルールは、別の重大な脆弱性まで隠します。IDとパッケージの両方を指定するのが基本です。除外された項目は表形式なら--show-suppressedで(suppressed)付きで確認できますが、JSONやSARIFには効きません。棚卸しはJSON出力のappliedIgnoreRulesを集計して行います。
OpenVEXのnot_affectedで影響なしの判断を機械に伝える手順
無視ルールは自分のリポジトリでしか効きません。顧客や他チームにも「この脆弱性は該当しない」と伝えたい場合は、OpenVEXの仕様に沿ったVEX文書を作り、--vexで渡します。Grypeは既定でステータスがnot_affectedとfixedの検出を無視リストへ移します。
{
"@context": "https://openvex.dev/ns/v0.2.0",
"@id": "https://example.com/vex/myapp-1.4.0",
"author": "myapp security team",
"timestamp": "2026-11-02T00:00:00Z",
"version": 1,
"statements": [
{
"vulnerability": { "name": "CVE-2021-3712" },
"products": [
{
"@id": "pkg:oci/myapp@sha256:...",
"subcomponents": [ { "@id": "pkg:apk/alpine/[email protected]" } ]
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path"
}
]
}grype myapp:1.4.0 --vex ./myapp.vex.jsonjustificationには仕様が定める5種類（component_not_present・vulnerable_code_not_present・vulnerable_code_not_in_execute_path など）から根拠に合うものを選びます。affectedとunder_investigationの文は、設定でvex-addを指定したときだけ結果に追加されます。
GrypeとTrivy・OSV-Scannerの選び分けと採用を見送る場面の判断基準
Grype・Trivy・OSV-Scannerの検査範囲・SBOM・CI連携比較表
3つとも無償のOSSで、コンテナとSBOMの脆弱性は調べられます。差が出るのは検査範囲と、結果の並べ方です。版は2026年11月2日時点の最新です。
| 観点 | Grype | Trivy | OSV-Scanner |
|---|---|---|---|
| 最新版 | v0.121.0 | v0.76.1 | v2系 |
| IaC・シークレット検出 | なし | あり | なし |
| SBOMの生成 | Syftに分離 | 本体で可能 | なし |
| 結果の並べ方 | RISK順（EPSS・KEV加味） | 深刻度で絞り込み | パッケージ単位 |
| 閾値超過時の終了コード | 2 | 指定値 | 1 |
| GitHub Action | anchore/scan-action | trivy-action | 公式ワークフロー |
Trivyの終了コードは--exit-codeで任意に決める方式です。OSV-ScannerはGoogleのOSV.devを照合先にし、ソースの依存定義に強いツールで、詳細はOSV-Scannerの使い方とTrivyとの違いにあります。
Grypeを選ぶ条件と、Trivy1本で足りるため採用しない条件
Grypeを選ぶのは、リリースごとにSBOMを保管し、後から新しいCVEの該当を追う運用を組む場合です。Syftで作るSBOMとGrypeの照合は同じ開発元で揃っており、EU CRAなどでSBOMの提出を求められる製品では、この2段構えが説明しやすくなります。検出件数が多く、深刻度だけでは直す順番が決まらない現場でも、RISK列の並びが効きます。
採用しないのは、TerraformやKubernetesマニフェストの設定ミスまで1つのツールで見たい場合です。Grypeを入れてもIaC用に別ツールが要り、CIのジョブとDBの更新が2系統になります。すでにTrivyが動いていて、SBOMを外部に出す予定も無いなら、Grypeを足す効果は小さいと判断します。SBOMツール全体の比較はSBOMツールの比較と選び方｜生成・管理・SCAのタイプ別に選定基準を解説を参照してください。
検出結果を誰が直すかと対応期限を決めないまま導入して形骸化する失敗パターン
よくある失敗は、スキャンをCIに入れたものの、検出の担当者と期限を決めていないケースです。初回で数百件が出て、閾値をcriticalに上げ、それでも止まるのでfail-build: falseにする。この流れで3か月後には誰も結果を見なくなります。
導入前に「RISKが一定以上の検出は何営業日で対応するか」「wont-fixは誰が承認して無視ルールに入れるか」を決めておく必要がありますので、導入前に担当者間で合意してください。スキャン結果だけでなく、公開中のWebアプリケーションに実際に攻撃が通るかを確かめたい場合は、脆弱性診断・セキュリティ診断で外部からの検査と組み合わせると、Grypeの検出のうちどれが本当に危ないかを絞り込めます。継続的な脆弱性管理の全体像はCTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断が参考になります。
よくある質問
Grypeを調べている開発者から出やすい質問に、公式ドキュメントの記述をもとに答えます。
Grypeの読み方は何ですか？
日本語では「グライプ」と読みます。コマンド名は小文字のgrypeで、同じAnchoreがSBOM生成ツールとして公開しているSyftとセットで紹介されることが多い名称です。Trivy（トリヴィ）と並べて比較される場面もよくあります。
Grypeは無料で商用利用できますか？
本体はApache-2.0ライセンスのOSSなので、社内システムや商用製品のCIで使っても利用料はかかりません。GitHub Actionのanchore/scan-actionはMITライセンスです。Anchoreには有償のEnterprise製品がありますが、Grype単体の利用には契約は不要です。ライセンス表示の義務は配布物にGrypeを同梱する場合に生じます。
GrypeとSyftはどちらを入れればよいですか？
脆弱性を調べたいだけならGrypeだけで動きます。Grypeは内部でSyftの機能を使ってパッケージを洗い出すためです。SBOMをファイルとして保管したい、顧客や監査に提出したいという要件があるときにSyftを追加し、SyftのSBOMをGrypeに渡す構成にします。
Grypeの結果に誤検知が多いときはどうすればよいですか？
まずJSON出力でmatch typeを確認します。公式ガイドではexact-direct-matchとexact-indirect-matchは信頼度が高く、cpe-matchは検証が必要とされています。Javaは既定でCPE一致を使わない設定です。確認のうえ誤検知と判断したものは、.grype.yamlの無視ルールに理由付きで登録します。
Grypeはプライベートレジストリのイメージも調べられますか？
プライベートレジストリのイメージも検査対象です。--from registryを指定すると、Dockerデーモンを使わずにレジストリから直接イメージを取得する方式です。認証は設定ファイルのregistry.authに、レジストリごとのユーザー名とパスワード、またはトークンを書いて渡します。社内CAを使うレジストリならregistry.ca-certで証明書を指定します。ビルド済みのローカルイメージを調べる場合は--from dockerです。
関連記事
- Trivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定まで【v0.76対応】：IaCやシークレットまで1本で見たい場合の選択肢です
- SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説：Syftで作るSBOMの目的と形式を確認できます
- OSV-Scannerの使い方｜インストール・コマンド・GitHub Actions設定とTrivyとの違い【v2.7.0】：ソースの依存定義を中心に調べる別のスキャナです
- Snykとは？CLIでの脆弱性スキャンとCI組み込み・料金の実額を実装視点で解説：修正PRの自動作成まで求める場合の有償の選択肢です
- SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説：Grypeが担う領域の位置づけを整理できます
