2026.07.03 セキュリティ

OSV-Scannerとは？Google製OSS脆弱性スキャナの使い方とTrivyとの違い

OSV-Scannerは、Googleが開発したオープンソースの脆弱性スキャナです。プロジェクトの依存関係やコンテナイメージを脆弱性データベースOSV.devと照合し、既知の脆弱性を無料で検出できます。本記事では、OSV-Scannerの仕組みとV2系で追加されたコンテナスキャン・ガイド付き修正の機能、インストールから基本コマンド・GitHub Actions連携までの使い方、Trivyとの違いと採用判断の基準を、公式ドキュメントと最新リリース情報にもとづいて解説します。

目次

まとめ：OSV-Scannerの導入判断とOSS脆弱性管理の結論

OSV-Scannerは、Apache 2.0ライセンスで公開された無料の脆弱性スキャナで、npmやpip、Mavenなど11以上の言語エコシステムの依存関係を1コマンドで検査できます。2025年3月公開のV2.0.0以降はコンテナイメージのレイヤー単位解析と、修正バージョンを提案するガイド付き修正（fixコマンド）に対応し、検出から修正までを1つのツールで扱えるようになりました。

採用判断の結論を先に示します。依存パッケージの脆弱性検出と修正支援が目的ならOSV-Scannerを選び、IaCの設定ミスやシークレット検出まで1本のツールに集約したい場合はTrivyを選ぶ、というのが役割に即した使い分けです。導入は数分で終わるため、まず手元のリポジトリをスキャンし、その後にCI/CDへの組み込みと定期実行を設計する順序を推奨します。fixコマンドを信頼できるコードベース以外へ実行しない、という運用条件も本文で示します。

OSV-Scannerの仕組みとOSV.devデータベースの信頼性

GoogleがOSSとして公開した経緯とApache 2.0ライセンスの範囲

OSV-Scannerは2022年12月にGoogleが初版を公開したGo製のコマンドラインツールで、GitHub上でスター数1万を超えるプロジェクトに成長しています。ライセンスはApache 2.0のため、商用プロジェクトでの利用・改変・再配布に追加費用は発生せず、アカウント登録やスキャン回数の制限もありません。

2025年3月17日にはメジャーバージョンアップとなるV2.0.0が公開され、その後もマイナーリリースが継続しています。執筆時点の最新リリースはv2.4.0で、後述するCI連携やコンテナ運用に関わる改善が加わっています。

OSV.devが集約する脆弱性情報源とCVE・GHSA識別子との対応

照合先のOSV.devは、GitHub Security AdvisoriesやRustSec Advisory Database、Ubuntuのセキュリティ通知など、各エコシステムの一次情報源から脆弱性情報を集約したオープンなデータベースです。誰でもアドバイザリの修正を提案できるため、誤登録が是正されやすい構造です。

各レコードはOSVフォーマットという機械可読形式で記述され、影響を受けるバージョン範囲が一意に定義されています。CVEやGHSAの識別子とも相互に対応づけられており、検出結果から公式アドバイザリへ直接たどれます。2025年に発覚したReact・Next.jsの重大脆弱性のように、広く使われるOSSの欠陥は自社の開発物へ短期間で波及するため、一次情報源と直結したデータベースで照合できる意味は小さくありません。

対応する11以上の言語エコシステムとロックファイル形式の範囲

公式ドキュメントによると、対応言語はC/C++、Dart、Elixir、Go、Java、JavaScript、PHP、Python、R、Ruby、Rustの11言語に及びます。パッケージマネージャではnpm・yarn・pip・Maven・Goモジュール・cargo・gem・composer・NuGetなどを扱い、読み取れるロックファイル形式は19種類以上です。

ソースコードのマニフェストとロックファイルに加えて、Linuxディストリビューションのパッケージ、コンテナイメージ、SPDX・CycloneDX形式のSBOM、gitリポジトリのコミット情報も検査対象にできます。package-lock.jsonしか置いていないフロントエンド案件から、pom.xmlを持つJava基幹システムまで1つのツールで横断できます。

V2系リリースで追加された主要機能とv2.4.0までの変更点

OSV-SCALIBR統合による依存関係抽出エンジンの強化点

V2.0.0の中核は、2025年1月にオープンソース化されたソフトウェア構成分析ライブラリ「OSV-SCALIBR」の統合です。依存関係の抽出処理がこのライブラリへ置き換わり、OSV-ScannerはOSV-SCALIBRの公式コマンドラインフロントエンドという位置づけになりました。

統合によって、ソースマニフェストやロックファイルだけでなく、Go・Java・Node.js・Pythonのビルド済みアーティファクトからも依存関係を抽出できるようになっています。ロックファイルが手元にないビルド成果物の検収時にも脆弱性照合が成立する点は、V1に対する実務上の明確な前進です。

Debian・Ubuntu・Alpine対応のレイヤー単位コンテナスキャン

V2ではコンテナイメージのスキャンが全面的に書き直され、Debian・Ubuntu・Alpineベースのイメージについてレイヤー単位の解析に対応しました。脆弱なパッケージがどのレイヤーで導入されたか、各レイヤーがどのコマンドで作られたかを特定できるため、修正すべき箇所がDockerfileの書き方のどの命令に由来するのかを直接突き止められます。

deps.devの実験的APIを利用したベースイメージの識別機能も加わり、脆弱性の責任がベースイメージ側にあるのか自前のレイヤーにあるのかを切り分けられます。実行環境に影響しにくい脆弱性を除外するフィルタリングも備えるため、フラットにイメージ全体を走査するスキャナと比べて通知のノイズが減ります。

インタラクティブHTMLレポートとfixコマンドのガイド付き修正

スキャン結果の出力には、深刻度別の内訳やパッケージごとの絞り込みができるインタラクティブなHTML形式が追加されました。非エンジニアへの共有や検収資料としての保存に向く形式です。従来どおりJSON・SARIF形式の出力にも対応し、他ツールとの連携も維持されています。

fixコマンドによるガイド付き修正は、依存の深さ・深刻度・修正の投資対効果といった基準で優先順位を付け、更新すべきパッケージと推奨バージョンを提案する機能です。npmではロックファイルを直接書き換えるin-placeと、マニフェスト経由で再解決するrelockの2戦略、MavenではV2.0.0からpom.xmlの依存バージョンを上書きするoverride戦略に対応しました。なおfix系の一部オプションにはexperimental接頭辞が付き、公式はメジャーバージョン内でも仕様変更がありうる実験的機能と位置づけています。

v2.4.0までのバージョンアップで変わった運用上のポイント

V2.0.0以降のマイナーリリースでも、運用に直結する改善が続いています。執筆時点の最新版v2.4.0では、DockerイメージとGitHub Actionに:v2のようなメジャーバージョンタグが付与されるようになり、パッチ更新のたびに参照先を書き換えずにメジャーバージョン固定で追従する運用が組めるようになりました。

それ以前のリリースでは、スキャン出力に含まれる改行文字を無害化してGitHub Actionsのワークフローコマンドインジェクションを防ぐ修正や、Homebrewでインストールしたパッケージのスキャン対応などが入っています。V2.0.0時点の紹介記事だけを参照してバージョンを固定すると、この種のセキュリティ修正を取り込めないため、導入時は最新リリースのチェンジログを確認する運用を推奨します。

OSV-Scannerのインストール手順と基本コマンドの実行方法

Homebrew・Scoop・WinGet・go installによる環境別の導入手順

環境別の代表的なインストール方法は次のとおりです。

  • macOS / Linux：brew install osv-scanner
  • Windows（Scoop）：scoop install osv-scanner
  • Windows（WinGet）：winget install Google.OSVScanner
  • Go環境：go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest

GitHub ReleasesのOS別ビルド済みバイナリや、GitHub Container Registryで配布されるDockerイメージも選べます。go installを使う場合はモジュールパスにv2が含まれる点に注意してください。V1時代のパスのままでは旧系列が入ります。

scan sourceとscan imageの基本的な実行コマンドと出力形式

V2はサブコマンド構成で、ソースコードのスキャンとコンテナイメージのスキャンを明示的に使い分けます。実行手順は次の2段階です。

  1. プロジェクトの検査：osv-scanner scan source -r 対象ディレクトリ を実行すると、package.jsonやgo.mod、pom.xmlなどの対応ファイルを再帰的に検出して照合します。
  2. イメージの検査：osv-scanner scan image イメージ名:タグ で、レイヤー情報つきの解析結果を取得します。タグの指定は必須です。

結果は標準ではテーブル形式で表示され、--format=jsonや--format=sarif、前述のHTML形式へ切り替えられます。脆弱性が見つかった場合は非ゼロの終了コードを返すため、CIの合否判定にそのまま使えます。

SBOM読み取り・ライセンス確認・オフラインスキャンの実行方法

依存関係の一覧を直接持たない場合でも、SPDXまたはCycloneDX形式のSBOMファイルを入力にして照合できます。取引先からSBOMの提出だけを受けているケースで、手元のソースなしに脆弱性の有無を確かめられる使い方です。

--licensesフラグを付けるとdeps.devのデータで依存パッケージのライセンス一覧を取得でき、--licenses="MIT,Apache-2.0"のように許可リストを渡せば違反だけを抽出できます。ネットワークに出られない環境向けには、--offline --download-offline-databasesで事前に脆弱性データベースを取得しておき、以後は通信なしでスキャンするオフラインモードが用意されています。

GitHub Actionsと開発フローへ組み込む継続スキャンの設計

再利用可能ワークフローとして呼び出すGitHub Actionsの設定

公式のosv-scanner-actionは、通常のアクションのようにstepへ記述するのではなく、再利用可能ワークフロー（reusable workflow）をジョブレベルでuses指定して呼び出す構成を取ります。プルリクエストのトリガーに加えてscheduleで週次のcronを併記し、コード変更がない期間に新たに公開された脆弱性も検知する構成が、公式ドキュメントの示す設定例です。

v2.4.0以降はアクション側にもメジャーバージョンタグが付いたため、@v2で参照してパッチ更新へ自動追従させる指定が選べます。GitHub ActionsによるCI/CD自動化の基本を押さえたうえで、テスト・ビルドと並ぶ必須ジョブの1つとして脆弱性スキャンを配置する設計が定着しつつあります。

pre-commitフックと定期実行を組み合わせた継続的な監視

コミット前の早期検知には、pre-commitフックとしての組み込みが公式にサポートされています。.pre-commit-config.yamlにリポジトリとバージョン（例：rev: v2.2.4以降）を指定するだけで、開発者の手元で依存追加の直後に検査が走ります。

実務ではpre-commitだけに寄せず、役割を分けた多段構成を推奨します。手元のフックは開発者への即時フィードバック、プルリクエスト時のスキャンはマージ可否の判定、定期実行は公開済みコードに対する新規開示の監視、という3層です。osv-reporter-actionを使えば、定期実行の結果から新たに増えた検出だけを追跡できます。

Trivyとの比較で判断するOSV-Scannerの採用基準と限界

データソースと検査対象で見るOSV-ScannerとTrivyの機能比較

両者の主な違いを表に整理します。

比較観点 OSV-Scanner Trivy
開発元 Google Aqua Security
主データソース OSV.dev NVDなど複数DB
検査対象の中心 OSS依存・コンテナ 依存・IaC・設定ミス
シークレット検出 なし あり
修正支援 fixで提案・書換 検出中心
ライセンス Apache 2.0 Apache 2.0

判断を言い切ると、アプリケーションの依存パッケージ管理が目的ならOSV-Scannerで足ります。一方、TerraformやKubernetesマニフェストの設定ミス、ハードコードされた認証情報の検出まで1本に集約したいなら、検査対象の広いTrivyが候補です。依存管理はOSV-Scanner、インフラ監査はTrivyという併用も成立します。

fixコマンドを信頼できないコードベースへ実行しない運用条件

fixコマンドには、公式ドキュメントが明記するリスクがあります。修正の解決過程でパッケージマネージャがスクリプトを実行したり、プロジェクトに指定された外部レジストリへ接続したりする可能性があるため、出所を確認していないコードベースに対して実行してはいけません。外部から受領した検証前のリポジトリにいきなりfixをかける手順は、それ自体が攻撃の入口になります。

もう1つの失敗パターンは、CIパイプライン内でfixを自動実行し、ロックファイルの書き換えを無人でマージする構成です。依存の更新は破壊的変更を含むことがあり、テストが薄いプロジェクトでは検知されないまま本番へ届きます。fixの提案はプルリクエストとして人のレビューを通す、この条件を外れる自動化は採用しない、というのが安全側の結論です。

受託開発の納品物検収へスキャンレポートを組み込む発注者側の視点

OSS依存の脆弱性は、納品の時点では存在せず運用中に公開されることが珍しくありません。発注者の立場では、検収時にOSV-ScannerのスキャンレポートをJSONまたはHTML形式で提出させる、保守契約に定期スキャンと対応期限を明記する、という2点を契約段階で決めておくと、公開後の責任分界が明確になります。スキャン自体は無料のため、ベンダー側に追加のツール費用は発生しません。

開発を外部へ委託する場合は、こうした脆弱性管理を開発工程に最初から組み込めるかどうかが委託先選定の分かれ目になります。株式会社一創のWebシステム開発では、要件定義から保守運用までを一貫して請け負う体制を取っており、依存関係の管理を含む開発体制の相談を受け付けています。

OSV-Scannerの導入と運用に関するよくある質問と回答

OSV-Scannerの導入検討で実際に検索されている疑問を5つ取り上げ、簡潔に回答します。

OSV-Scannerは無料で商用利用できますか？

無料で商用利用できます。ライセンスはApache 2.0で、利用・改変・再配布のいずれも許諾されており、スキャン回数の上限やアカウント登録の要件もありません。照合先のOSV.devデータベースも公開されているため、ツール本体・データの両方に費用が発生しない構成です。社内利用の場合はApache 2.0の表示義務など一般的な条件のみ確認してください。

OSV-ScannerとTrivyはどちらを選ぶべきですか？

目的で分かれます。アプリケーションの依存パッケージの脆弱性検出と修正提案が目的ならOSV-Scanner、IaCの設定ミスやシークレット検出まで1本のツールで済ませたいならTrivyという分担が基本です。検査領域の重なりが部分的なため、依存管理をOSV-Scanner、インフラ監査をTrivyと分ける併用も実務では成立します。

スキャン時にソースコードが外部へ送信されますか？

ソースコード本体は送信されません。照合時にOSV.devなどへ送られるのは、パッケージ名・バージョンなど照合に必要な情報です。それでも外部通信自体を遮断したい場合は、脆弱性データベースを事前取得して通信なしで照合するオフラインモード（--offlineフラグ）を使えば、閉域環境でもスキャンが成立します。

Windows環境でもOSV-Scannerは動作しますか？

動作します。ScoopまたはWinGet経由でインストールでき、GitHub ReleasesにはWindows向けのビルド済みバイナリも用意されています。Go環境があればgo installでの導入も可能です。コンテナイメージのスキャンを行う場合のみ、イメージの取得にdockerコマンドが参照されるため、Docker Desktopなどの実行環境を別途整えてください。

OSV-Scannerで検知できない脆弱性はありますか？

あります。検出対象はOSV.devに登録済みの既知脆弱性に限られるため、未公開のゼロデイや、自社で書いた独自コードの欠陥は検知できません。また検出された脆弱性が実際に呼び出されるコード経路にあるかを判定する到達可能性分析は、公式ロードマップ上の今後の対応項目です。静的解析やペネトレーションテストと役割を分けて併用してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る