Trivy、tfsec 以外の選択肢を探る - セキュリティスキャンツール比較(Grype、Checkov、Snyk、KICS)
2026 年 3 月、Trivy のリリースインフラがサプライチェーン攻撃を受けました。GitHub Actions タグの乗っ取り、偽リリースの配布、Docker Hub への悪意あるイメージの公開が段階的に行われ、2026 年 3 月 25 日時点で脆弱性データベースの更新は停止中です。攻撃の技術的な詳細は 2026 年 3 月 19 日の Trivy 再侵害の概要と対応指針 に詳しくまとめられています。
一方、tfsec は 2023 年 2 月に Trivy への統合が公式に発表され、メンテナンスモードに入っています。最後のリリース v1.28.14(2025 年 5 月)は依存ライブラリの CVE 修正のみで、新しいスキャンルールは 2024 年初頭以降追加されていません。
こうした状況を受けて、Trivy、tfsec 以外のセキュリティスキャンツールにどのような選択肢があるのか調査しました。本記事では、脆弱性スキャン領域と IaC スキャン領域それぞれの代替ツールを比較し、選定基準を整理します。
前提: なぜ今、代替ツールを検討するのか
Trivy のスキャンエンジン自体が侵害されたわけではなく、問題はリリースインフラと配布チャネルにありました。SHA 固定や cosign 検証といった対策を講じれば継続利用は可能です。
しかし、以下の点から Trivy を唯一のスキャンツールとして依存することにはリスクがあります。
- 脆弱性データベースの更新が停止中であり、インシデント発生後に公開された脆弱性を検出できない
- インシデント対応が継続中であり、復旧時期は未定
- 攻撃は Checkmarx KICS や npm パッケージにも波及しており、単一ベンダーへの依存がリスクを集中させる構造が顕在化した
tfsec については、Aqua Security が Trivy への統合方針を明言しており、新規採用の選択肢としては現実的ではありません。
脆弱性スキャンツールの比較
コンテナイメージやアプリケーション依存関係の脆弱性スキャンにおける代替ツールを比較します。
Grype(Anchore)
Grype は Apache 2.0 ライセンスのオープンソース脆弱性スキャナで、依存関係なしの単一バイナリとして配布されます。
強み
- CVSS、EPSS(Exploit Prediction Scoring System)、CISA KEV カタログを組み合わせた複合リスクスコアリングで、脆弱性の優先順位付けが Trivy より精緻
- Syft と連携した SBOM ベースのワークフローをサポート
- インクリメンタルなデータベース更新に対応し、高頻度スキャン環境での帯域消費を抑制
- GitHub Stars 約 11,500。リリース頻度が高く(例: 2026 年 3 月時点で v0.110.0)、コミュニティも活発
制約
- 脆弱性マッチングに特化しており、IaC スキャン、シークレット検出、ライセンスチェックは含まれない
- Trivy の「1 ツールで何でも」というアプローチとは対照的に、スキャン領域ごとに別ツールが必要
向いているケース: オープンソースで、脆弱性の検出精度と優先順位付けを重視するチーム
Docker Scout
Docker Scout は、Docker Hub と Docker Desktop に深く統合されたフリーミアムのスキャンサービスです。
強み
- 再スキャンなしで新しい CVE を検出するイベント駆動型の仕組み
- 脆弱性を解消できるベースイメージのアップグレード推奨を自動提示
- Docker Desktop との統合により、開発者がローカルで即座にスキャン結果を確認可能
制約
- Docker エコシステムへの依存度が高く、Docker Hub を使わない環境では恩恵が限定的
- オープンソースではなく、フリーミアムモデル
- CI/CD 環境での柔軟性は Grype や Trivy に劣る
向いているケース: Docker Hub と Docker Desktop を中心に据えた開発ワークフローのチーム
Snyk Container / Open Source
Snyk は商用ツール(一部フリープランあり)で、開発者体験を重視した設計が特徴です。
強み
- 脆弱なコードが実際に呼び出されているかを分析する**到達可能性分析(Reachability Analysis)**により、誤検知を大幅に削減
- 脆弱性の指摘だけでなく、ベースイメージの変更提案や自動修正 Pull Request を生成
- GitHub、GitLab、Bitbucket 等との統合が充実し、開発者の修正サイクルを短縮
制約
- 商用ライセンスが必要(開発者あたり月額 $25 から、エンタープライズでは年間 $5,000〜$70,000)
- オープンソースプロジェクトでの自由な利用には制限がある
向いているケース: 商用サポートと一元的なダッシュボードを求めるエンタープライズ組織
脆弱性スキャンツール比較表
| 項目 | Grype | Docker Scout | Snyk |
|---|---|---|---|
| ライセンス | Apache 2.0 | フリーミアム | 商用(フリープランあり) |
| スキャン対象 | コンテナ / FS / SBOM | コンテナ(Docker 中心) | コンテナ / OSS 依存関係 |
| 優先順位付け | CVSS + EPSS + KEV | CVSS | CVSS + 到達可能性分析 |
| SBOM 連携 | Syft と統合 | Docker SBOM | Snyk SBOM |
| 自動修正提案 | なし | ベースイメージ推奨 | 自動修正 PR |
| CI/CD 統合 | CLI / GitHub Actions | Docker CLI / GitHub Actions | CLI / 各種 CI 統合 |
| GitHub Stars | 約 11,500 | N/A(非 OSS) | N/A(商用) |
IaC スキャンツールの比較
Terraform、CloudFormation 等の IaC 設定ミスを検出するツールの代替を比較します。
Checkov(Bridgecrew / Palo Alto Networks)
Checkov は、現時点で最も機能が充実したオープンソースの IaC スキャナです。
強み
- 最大の差別化要因はグラフベースのクロスリソース分析。単一リソースの属性だけでなく、リソース間の関係性を検証する(例: S3 バケットの暗号化だけでなく、そのバケットにインターネットゲートウェイから到達可能なルートが存在するかを検出)
- CIS、SOC 2、PCI DSS、NIST、HIPAA をカバーする 1,000 以上のビルトインポリシー
- Terraform、CloudFormation、Kubernetes、Helm、Bicep、OpenTofu 等 12 以上の IaC プラットフォームに対応
- Apache 2.0 ライセンス、8,000 万以上のダウンロード、リリース頻度が非常に高い(2026 年 3 月時点で v3.2.510)
制約
- Python 製のため、バイナリ配布の Go 製ツール(Trivy、tfsec)と比べてインストールと実行環境の依存関係がやや複雑
- グラフベース分析は高機能だが、ルールの自作には学習コストがある
向いているケース: 大規模なクラウドインフラを運用し、リソース間の構成ミスを深く検出したいチーム
KICS(Checkmarx)
KICS は、対応する IaC プラットフォームの多さが特徴のスキャナです。
強み
- 22 以上のプラットフォームに対応(Terraform、CloudFormation、Kubernetes、Ansible、Docker Compose、GitHub Workflows、Pulumi、OpenAPI 等)
- 2,400 以上の Rego ベースのクエリを内蔵
- OPA(Open Policy Agent)の知識があればカスタムルールの作成が容易
制約
- 2026 年 3 月 23 日に GitHub Action が TeamPCP によって侵害された。インシデントが完全に修復されるまでは、タグ参照での利用は避け、SHA 固定で使用するか、CLI 直接実行を検討すべき
- Checkov のグラフベース分析のような、リソース間の関係性を横断的に検証する機能はない
向いているケース: IaC スタックが多様で、OPA/Rego ベースのポリシー管理を組織的に採用しているチーム
その他の IaC スキャンツール
| ツール | 状態 | 備考 |
|---|---|---|
| Terrascan | アーカイブ済み | 2025 年 11 月に Tenable がリポジトリをアーカイブ。新規採用不可 |
| Regula | アーカイブ済み | 2024 年にアーカイブ。実質停止 |
| Conftest | 活発 | OPA/Rego による汎用ポリシーテスト。ルール自作が前提のため、ビルトインポリシーが豊富な Checkov や KICS とは立ち位置が異なる |
IaC スキャンツール比較表
| 項目 | Checkov | KICS | Conftest |
|---|---|---|---|
| ライセンス | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| 対応プラットフォーム数 | 12 以上 | 22 以上 | Rego で任意に定義 |
| ビルトインポリシー数 | 1,000 以上 | 2,400 以上 | なし(自作前提) |
| クロスリソース分析 | あり(グラフベース) | なし | なし |
| コンプライアンス対応 | CIS / SOC 2 / PCI DSS / NIST / HIPAA | CIS / NIST | なし |
| GitHub Stars | 約 8,500 | 約 2,600 | 約 3,100 |
| 2026 年 3 月の侵害影響 | なし | GitHub Action が侵害 | なし |
推奨される組み合わせ
調査結果をもとに、2 つの方針を提示します。
方針 A: Trivy を継続しつつ多層防御を構築
Trivy の「1 ツールで広くカバーする」利便性を維持しながら、リスクを分散する構成です。
| 領域 | ツール | 役割 |
|---|---|---|
| 脆弱性スキャン(主) | Trivy v0.69.3(SHA 固定) | 既存のワークフローを維持 |
| 脆弱性スキャン(副) | Grype | 多層防御。Trivy の DB 停止時のフォールバック |
| IaC スキャン | Checkov | Trivy config を補完するクロスリソース分析 |
Trivy を継続利用する場合は、GitHub 公式ドキュメントの推奨に従い、すべての Action をフルコミット SHA で固定し、コンテナイメージはダイジェストで pull、バイナリは cosign で署名検証する運用が必須です。
方針 B: Trivy から完全に移行
Aqua Security への依存を完全に解消し、単一ベンダーリスクを排除する構成です。
| 領域 | ツール | 役割 |
|---|---|---|
| 脆弱性スキャン | Grype | コンテナ / FS の脆弱性検出 |
| SBOM 生成 | Syft | Grype と連携した SBOM ワークフロー |
| IaC スキャン | Checkov | グラフベース分析による深い IaC 検査 |
この構成はすべて Apache 2.0 ライセンスのオープンソースで構成されます。Trivy のように 1 ツールで完結はしませんが、各ツールが得意領域に特化しているため、スキャン精度の面では有利です。
ツール選定以外に押さえておくべき CI/CD の対策
どのツールを選択しても、CI/CD パイプライン自体の防御策を講じなければ、同種のサプライチェーン攻撃に対して脆弱なままです。今回の Trivy 侵害で浮き彫りになった主な対策を簡潔にまとめます。
- GitHub Actions のフルコミット SHA 固定: 可変タグ(
@v0.34.0等)が攻撃者によって書き換えられたことが今回の侵害の核心。サードパーティ Action は 40 文字のコミット SHA で固定する - OIDC による短期トークンへの移行: GitHub Actions の OIDC を利用し、ランナーに静的な認証情報を渡さない
GITHUB_TOKENの権限最小化:permissionsブロックでデフォルトをreadに制限する- セルフホストランナーのエフェメラル化: ジョブごとにランナーを破棄し、永続データを持たせない
pull_request_targetワークフローの監査: フォークからの PR にシークレットアクセスを許可する設計は見直す
これらの対策の詳細は、2026 年 3 月 19 日の Trivy 再侵害の概要と対応指針や GitHub Actions のセキュリティ強化に関する公式ドキュメントを参照してください。
まとめ
Trivy のスキャンエンジン自体は健全であり、適切な対策を講じれば継続利用は可能です。しかし、脆弱性データベースの更新停止と調査の継続を踏まえると、単一ツールへの依存を解消し、多層防御を構築することが現実的な対応です。
脆弱性スキャン領域では、Grype がオープンソースの代替として最も有力です。EPSS と KEV を組み合わせた複合リスクスコアリングは、Trivy にはない強みです。商用ツールでは Snyk の到達可能性分析と自動修正 PR が、開発者の修正負荷を下げるうえで効果的です。
IaC スキャン領域では、Checkov のグラフベース分析が他のツールにない優位性を持ちます。リソース間の関係性を横断的に検証できるため、単一リソースの属性チェックでは見落としがちな構成ミスを検出できます。
どのツールを選んでも、GitHub Actions の SHA 固定、OIDC への移行、ランナーのエフェメラル化といった CI/CD パイプラインの防御策は必須です。ツールの選定と並行して、パイプラインの運用設計を見直すことを推奨します。
以上、セキュリティスキャナ自体がサプライチェーン攻撃の対象になる時代に備えたい、現場からお送りしました。