【無料】OSS脆弱性スキャナー｜npm/Pythonの依存を貼るだけ即チェック

依存関係を貼って10秒、脆弱性が混じっていないかを判定するブラウザ完結スキャナー

package.json、requirements.txt、pyproject.tomlのいずれかを下のテキストエリアに貼り付けて「スキャン」を押すと、依存している外部ライブラリに既知の脆弱性が残っていないかをその場で判定します。アカウント登録もインストールも不要、ブラウザだけで動きます。

作った動機はこの半年の事件です。axios（週間1億DL）の汚染、LiteLLMの乗っ取り、Trivyから連鎖した4OSSの陥落、GlassWormによる不可視マルウェアと、OSSサプライチェーン攻撃が日常風景になりました。「うちのプロジェクトは大丈夫か」を、CLIを叩かずに10秒で確認したくて作ったのが本ツールです。

サンプル3種類は「npm」「pip」「Poetry」のボタンから読み込めます。手元のファイルがなくても挙動だけ確認できます。

OSSサプライチェーン汚染スキャナー

データソース: OSV.dev（Google・CC BY 4.0）／検索結果はクライアント側で実行され、貼り付けた内容はOSV.dev以外には送信されません。

そもそも何をやっているのか——出てきた用語のおさらい

スキャナーを触ってみて「結果に出てくるCVEとかGHSAとかOSVって何？」「package.jsonに書いてある依存関係って結局なに？」と思った方向けに、この記事に出てくる主な用語を一段下のレベルで整理しておきます。普段からCIにスキャナーを組み込んで使っているエンジニアは、この節は読み飛ばしても問題ありません。

ひと続きの流れに直すと、「自分のプロジェクトが借りている部品（依存関係）の一覧（package.json 等）を見て、それぞれの部品に振られたセキュリティの傷の番号（CVE / GHSA）が、巨大な傷リスト（OSV）に登録されていないか照合する」のがこのスキャナーの仕事です。サプライチェーン攻撃は、その「借りている部品」自体に毒を入れる手口。家の鍵を作る業者ごと買収されてしまうイメージです。

普段からCIに npm audit や Trivy を組み込んでいるチームは、この処理が裏で常時走っているわけで、本ツールはその「裏で動いている処理」を、ブラウザで1回だけ手動で叩いてみる窓口と捉えるとイメージが合います。

なぜブラウザ完結にこだわったか

同じことをするツールはすでに山ほどあります。npm audit、pip-audit、Trivy、Snyk、Dependabot。本職のエンジニアならどれかしらをCIに組み込んでいるはずです。

それでも、実務でこの種のツールが欲しくなるのは、CIに組み込まれた監視とは別の文脈です。

• ・ 取引先から受け取ったpackage.jsonの中身を、PRレビュー前にざっと見たい
• ・ OSSサプライチェーン攻撃のニュースを見た直後、社内Slackで「うちのプロダクト大丈夫？」と聞かれたとき
• ・ GitHubで気になったライブラリのリポジトリを見つけて、依存の健康診断だけ先にやりたい
• ・ 非エンジニアの上司や、業務委託のフリーランスが書いたコードをチェックしたい

どれも「ローカルにツールを入れるほどじゃない」「VPN・社内プロキシでCLIが弾かれる」「権限がない」という、軽い摩擦のあるシーンです。ブラウザに貼って押すだけ、にしておけば10秒で済みます。

もうひとつの理由は、本サイトで書いてきた個別の攻撃事件と紐付けたかったからです。axios・LiteLLM・Trivy・GlassWorm・TeamPCPと、過去記事は単体で読んでも事件のあらすじしか分かりません。「で、自分はどうチェックするのか」の出口がなかった。このツールがその出口になります。

裏側の仕組み——全部ブラウザの中で動いている

このツールにはサーバーがありません。HTMLとJavaScriptだけで構成されており、貼り付けた内容はOSV.dev の公開APIに直接送られて、その結果がブラウザ側で整形されます。Google・GitHub・PyPA・Rust Foundationなどが運営する脆弱性データベースで、認証不要・CORS対応済み・1リクエスト最大1,000パッケージまで投げられます。

処理の流れはこの4ステップです。

③のバージョン正規化が、実装でいちばん厄介でした。^1.7.7 のような範囲指定はOSV.devが受け付けないので、こちらで具体的なバージョン番号に変換する必要があります。SemVer範囲の「最低互換バージョン」を取れる関数semver.minVersion()を使って、安全側に倒して問い合わせています。

結果として、たとえば"axios": "^1.7.7"と書いてあっても「1.7.7 として」問い合わせます。実際にインストールされたバージョン（1.7.9とか1.8.2）と微妙にズレますが、ロックファイルなしでも最低限の警告は出せます。ロックファイル（package-lock.json、poetry.lock等）を見ない範囲では、これが落とし所だと判断しました。

突合本体のコードはこの程度の短さです（全コードはツール本体のHTMLソースに含まれています）。

// 依存関係を OSV.dev に1リクエストで投げる
const queries = deps.map(d => ({
  package: { name: d.name, ecosystem: d.ecosystem }, // npm / PyPI
  version: d.resolvedVersion,                         // semver.minVersion() で正規化済み
}));

const res = await fetch("https://api.osv.dev/v1/querybatch", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ queries }),
});
const { results } = await res.json();
// results[i] が deps[i] に対応。vulns 配列が空でなければ脆弱性あり。

バックエンドAPIを立てていないのは、コストもあるのですが、それ以上に「貼り付けた内容をこちらのサーバーに送る必要がない」点が大きい。プロプライエタリな社内コードのpackage.jsonでも、OSV.devを経由する以外はどこにも保存されません。データソースの透明性をそのまま使えるのがOSV.dev経由の利点です。

対応している入力形式の細かい話

package.json（npm / yarn / pnpm 共通）

dependencies、devDependencies、optionalDependencies、peerDependenciesを全て拾います。workspaces（ローカル参照）とnpm:プレフィックス（パッケージエイリアス）は除外。git+ssh://等のVCS指定もスキップします。

requirements.txt（pip / pip-tools / pipenv-lock経由のexport）

== >= ~= != を解釈します。同一行の複数指定（django>=4.0,<5.0）はカンマで分割して最低バージョンを採用。-r（他ファイル参照）、-e（編集可能インストール）、--index-url等のオプション行はスキップ。コメント行（# 始まり）も無視します。

pyproject.toml（Poetry / uv / Rye / PEP 621）

2つの書式が混在しているのが厄介で、両方サポートしました。

• ▸ PEP 621標準（uv / Rye / Hatch等）: [project].dependencies 配列と [project.optional-dependencies]。中身は"requests>=2.28.0"のようなPEP 508文字列。
• ▸ Poetry形式: [tool.poetry.dependencies] オブジェクトと [tool.poetry.group.*.dependencies]。値はSemVer風文字列（"^2.28.0"）または { version = "...", extras = [...] } のテーブル形式。

TOMLパーサには軽量なsmol-tomlを採用しました。pythonキーや、{path = "..."}、{git = "..."}のローカル/VCS参照は突合対象外として除外しています。

このツールではわからないこと

使いどころを誤ると過信に繋がるので、見えていない範囲を先に並べておきます。

• ? 推移的依存（依存の依存）は見えません。トップレベルの依存だけが対象です。package-lock.jsonやpoetry.lockを貼れば全依存をスキャンできますが、本ツールはサイズが軽い宣言ファイルだけを想定しています
• ? ロックファイルなしのバージョンは最低互換版で評価しています。実際にインストールされたバージョンとは微妙にズレます。0day直撃の判定には使えないと考えてください
• ? 未公開の脆弱性は当然出ません。OSV.devに登録されてから反映されるまでにはタイムラグがあります
• ? マルウェア混入そのものは検知できません。汚染パッケージにCVEやGHSAが振られていればヒットしますが、サプライチェーン攻撃の初動24時間は無防備です。GlassWormのような不可視マルウェアも対象外です

本格的にやるなら、CIにnpm auditやTrivyを組み込み、SBOM運用とロックファイルのコミットを徹底するのが筋です。このツールはあくまで「貼って10秒で雰囲気をつかむ」用途と割り切ってください。

2025〜2026年のサプライチェーン攻撃事例

本サイトで追ってきた直近の攻撃事例を時系列で並べておきます。各事件の検知方法や影響範囲は、それぞれの記事に書いています。

パターンは毎回違いますが、起点は同じです。「信頼しているパッケージのバージョンを上げたら、いつの間にか別の人が中身を書き換えていた」。普段触らない依存ファイルを定期的に確認する習慣がそのまま防衛線になります。

追加してほしい機能・要望

現状の優先実装は「3形式のテキスト貼り付け」までで、以下は次の更新で考えています。

• ▸ package-lock.jsonとpoetry.lock対応（推移的依存も含めたスキャン）
• ▸ Gemfile / Cargo.toml / go.mod対応
• ▸ GitHub URL貼り付けでリポジトリ直接スキャン（CORS対応の関係でAPIプロキシが必要）

必要そうなものがあれば、本記事のコメントやお問い合わせから教えてもらえると、優先度を組み替えます。

参照元・ライセンス

• • 脆弱性データ: OSV.dev（運営: Google、GitHub Security Advisory・PyPA・Rust Foundation等のソースを統合、CC BY 4.0）
• • API仕様: OSV API Documentation
• • SemVer解釈ライブラリ: node-semver（npm Inc., ISCライセンス）
• • TOMLパーサ: smol-toml（Cynthia Rey, BSD-3-Clauseライセンス）
• • 外部CDN: esm.sh （ESMモジュール配信）

OSV.devの脆弱性メタデータはCC BY 4.0の下に再配布されています。本ツールはOSV.dev/Googleの提供サービスではなく、本サイトが独立に提供するクライアントです。