---
title: "Grypeとは：Syftと組むコンテナ・SBOMの脆弱性スキャンとCIで止める条件、Trivyとの選び分け【v0.121】"
url: "https://www.issoh.co.jp/tech/details/19196/"
published: 2026-11-02
updated: 2026-11-02
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# Grypeとは：Syftと組むコンテナ・SBOMの脆弱性スキャンとCIで止める条件、Trivyとの選び分け【v0.121】

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リポジトリ](https://github.com/anchore/grype)はApache-2.0ライセンスで公開されており、2026年11月2日時点のスター数は13,155、最新版は2026年10月19日公開の[v0.121.0](https://github.com/anchore/grype/releases/tag/v0.121.0)です。商用製品に組み込んでも利用料はかかりません。

同じAnchoreの[Syft](https://github.com/anchore/syft)はSBOMを作る側のツールで、同日にv1.55.0が出ています。Grypeは内部でSyftのカタログ機能を使ってパッケージを洗い出し、その一覧を脆弱性DBと照合します。つまり「部品表を作る」のがSyft、「部品表から既知の脆弱性を探す」のがGrypeという分担です。SBOMそのものの目的やCycloneDX・SPDXの違いは[SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断](https://www.issoh.co.jp/tech/details/13457/)で整理しています。

### スキャン対象はコンテナイメージ・ディレクトリ・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との違い](https://www.issoh.co.jp/tech/details/16216/)に詳しく書いています。

## Grypeのインストールから初回スキャンまでをコマンドで試す手順

### インストールスクリプト・Docker・Homebrew・wingetの4経路と署名検証

[公式のインストール手順](https://oss.anchore.com/docs/installation/grype/)で「公式」とされているのは、インストールスクリプトと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が自動でダウンロードされます。続けて結果が表形式で出力されます。[結果の読み方の公式ガイド](https://oss.anchore.com/docs/guides/vulnerability/interpreting-results/)では、列は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.json
```

EPSSは[FIRSTが公開する指標](https://www.first.org/epss/)で、今後30日以内に悪用される確率の推定値です。RISKはCVSS・EPSS・ランサムウェアでの利用実績を合わせた0.0〜100.0の値で、[CISAのKEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)に載った脆弱性は最大の脅威として扱われます。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リファレンス](https://oss.anchore.com/docs/reference/grype/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`と組み合わせるのが現実的です。修正版の無い脆弱性で毎回ビルドが止まると、開発者は閾値を下げるか、スキャン自体を外す方向に動きます。[フィルタの公式ガイド](https://oss.anchore.com/docs/guides/vulnerability/filter-results/)のとおり、このオプションによる除外対象はnot-fixed・wont-fix・unknownの3状態です。除いた分は週次のJSON出力で別途追います。

### GitHub Actionsのscan-action：既定の失敗条件はmedium以上

[anchore/scan-action](https://github.com/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の既存タグが書き換えられる事案](https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23)が起きています。経緯は[Trivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定まで](https://www.issoh.co.jp/tech/details/10398/)の該当章で経緯を確認できる構成です。スキャナは秘密情報の近くで動くため、Grypeでも同じ対策が要ります。なお`config`入力を指定すると`.grype.yaml`の自動検出が止まる点にも注意してください。

### 脆弱性DBが5日を超えると失敗する仕様と閉域網での更新・取り込み手順

[脆弱性DBの公式ガイド](https://oss.anchore.com/docs/guides/vulnerability/database/)では、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で絞る方法

### 無視ルールに理由と修正状態を書き、例外を棚卸しできる形にする

[設定リファレンス](https://oss.anchore.com/docs/reference/grype/configuration/)の`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の仕様](https://github.com/openvex/spec)に沿った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/libcrypto1.1@1.1.1k-r0" } ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}
```

```
grype myapp:1.4.0 --vex ./myapp.vex.json
```

justificationには仕様が定める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との違い](https://www.issoh.co.jp/tech/details/12926/)にあります。

### 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のタイプ別に選定基準を解説](https://www.issoh.co.jp/column/details/16506/)を参照してください。

### 検出結果を誰が直すかと対応期限を決めないまま導入して形骸化する失敗パターン

よくある失敗は、スキャンをCIに入れたものの、検出の担当者と期限を決めていないケースです。初回で数百件が出て、閾値をcriticalに上げ、それでも止まるので`fail-build: false`にする。この流れで3か月後には誰も結果を見なくなります。

導入前に「RISKが一定以上の検出は何営業日で対応するか」「wont-fixは誰が承認して無視ルールに入れるか」を決めておく必要がありますので、導入前に担当者間で合意してください。スキャン結果だけでなく、公開中のWebアプリケーションに実際に攻撃が通るかを確かめたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で外部からの検査と組み合わせると、Grypeの検出のうちどれが本当に危ないかを絞り込めます。継続的な脆弱性管理の全体像は[CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断](https://www.issoh.co.jp/tech/details/13277/)が参考になります。

## よくある質問

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対応】](https://www.issoh.co.jp/tech/details/10398/)：IaCやシークレットまで1本で見たい場合の選択肢です
- [SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説](https://www.issoh.co.jp/tech/details/13457/)：Syftで作るSBOMの目的と形式を確認できます
- [OSV-Scannerの使い方｜インストール・コマンド・GitHub Actions設定とTrivyとの違い【v2.7.0】](https://www.issoh.co.jp/tech/details/12926/)：ソースの依存定義を中心に調べる別のスキャナです
- [Snykとは？CLIでの脆弱性スキャンとCI組み込み・料金の実額を実装視点で解説](https://www.issoh.co.jp/tech/details/17518/)：修正PRの自動作成まで求める場合の有償の選択肢です
- [SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説](https://www.issoh.co.jp/tech/details/16216/)：Grypeが担う領域の位置づけを整理できます

---

出典: [Grypeとは：Syftと組むコンテナ・SBOMの脆弱性スキャンとCIで止める条件、Trivyとの選び分け【v0.121】](<https://www.issoh.co.jp/tech/details/19196/>)（株式会社一創）