セキュリティスイープ
一つの質問に的確に答える：これらのプロジェクトは、今すぐに対処すべき依存関係の脆弱性にさらされているか？ 「今すぐに対処すべき」とは、カタログ化されリーチ可能であるか、まだ完全に監査データベースに伝播していない、実際に発生しているインシデントのいずれかを意味します。
単なる npm audit よりも優れている点は、リサーチレイヤーです。アドバイザリデータベースは開示に遅れをとり、悪意のあるパッケージインシデントはしばしば公開停止（問い合わせ可能なアドバイザリなし）によって処理されます。そのため、このスイープは決定論的ツールと、現在活発に悪用されているものに関するライブ調査を組み合わせ、ロックファイルを直接チェックします。これは最も高速で信頼性の高いシグナルであり、どの監査ツールも提供してくれません。
デフォルトでは読み取り専用：調査して報告します。修正案を提案するだけに留め、ユーザーの了承なしにバージョンアップを適用しないでください（ビルドが壊れる可能性があります）。
使用するタイミング
- 「セキュリティを調査して」「脆弱な依存関係をチェックして」「セキュリティスイープを実行して」
- 「私たちは <特定のCVE、GHSA、パッケージ侵害の話> の影響を受けていますか？」 — ユーザーが何かを読んで、自分のプロジェクトに影響があるか知りたい場合
- 定期的なチェック（
scheduleスキルと組み合わせて、クラウドでの定期スイープを実行 — 最後の節を参照）
ステップ 1 — スコープ
何をスイープするか決定します。デフォルトは現在のプロジェクト。ユーザーの表現が広い場合（「私たちのプロジェクト」「全部」「フリート」）は、複数リポジトリのスイープを提案します。
- 現在のプロジェクト：現在いるリポジトリ
- 複数リポジトリ：現在のリポジトリの隣にある兄弟リポジトリを列挙します。つまり、現在のgitルートの親ディレクトリ（通常は
~/projects/*/または~/src/*/）。ディレクトリを走査する前にユーザーと確認し、推測で行わないこと。間違った推測は長時間のスキャンを無駄にします。各リポジトリについて、マニフェスト（下記）からエコシステムを検出し、順にスイープし、プロジェクトごとにレポートします。
ステップ 2 — エコシステムの検出とロックファイルの特定
プロジェクトごとに、エコシステムはそのロックファイルが存在すれば検出されます：
| エコシステム | マニフェスト / ロックファイル | 通常の場所 |
|---|---|---|
| npm | package-lock.json | frontend/ またはリポジトリルート |
| Go | go.mod / go.sum | backend/ またはリポジトリルート |
| Python | poetry.lock, requirements.txt, uv.lock | リポジトリルート |
| Swift/SPM | Package.resolved | ios/ または .xcodeproj |
スキャンするのはマニフェストではなくロックファイルです。実際にインストールされた正確な推移的バージョンが固定されています。
ステップ 3 — 決定論的ベースライン（エコシステムごと）
エコシステム独自のツールを実行します。これらはアドバイザリデータベースに既にあるものすべてを捕捉します。利用可能な場合はリーチアビリティ分析（コードが実際に到達できる脆弱性のみを報告）を持つツールを優先します。
- npm:
cd <dir> && npm audit --omit=dev --audit-level=high（ユーザーに出荷されるもの）および通常のnpm audit（全件、情報提供用）。リーチアビリティなし — 過剰報告のため、本番環境の結果に重み付け。 - Go:
govulncheck ./...— リーチアビリティ分析を行う（呼び出されたコードの脆弱性のみフラグ）；一度go install golang.org/x/vuln/cmd/govulncheck@latestでインストール。これらのツールのゴールドスタンダード。 - Python:
pip-audit（またはpip-audit -r requirements.txt） - どのエコシステムでも、ツールがない場合: ロックファイルに対して
osv-scannerを、インストール不要でコンテナ経由で実行：<runtime> run --rm -v "$PWD:/src:ro" ghcr.io/google/osv-scanner:latest scan --lockfile=/src/<lockfile>。最も広範なデータベース；Swift/SPMのフォールバック（ファーストパーティのツールが薄い）。
各ツールの報告内容を取得します。本番環境/リーチ可能なものと開発/ビルド時のものを区別します — 出荷されないビルドツールの high は、ランタイム依存関係の finding と同じではありません。
ステップ 4 — アクティブな脅威環境の調査（付加価値）
これが単なる監査ではできないことです。WebSearch / WebFetch を使用して現在アクティブなものを見つけ、名前をステップ5に持ち帰ります。
- プロジェクトのエコシステムにおける最近のサプライチェーンインシデント：最近の npm/PyPI/Go での侵害やマルウェアキャンペーンを検索；GitHub Advisory Database (github.com/advisories) と OSV (osv.dev) で、ステップ2で見つけたパッケージに関連する最近公開されたエントリを確認します。
- ユーザーが特定の CVE / GHSA / インシデントを指定した場合、権威あるアドバイザリを取得し、影響を受ける正確なパッケージ名とバージョン範囲を抽出します — それをロックファイルと照合します。
- 一次情報源（アドバイザリ、メンテナの投稿、レジストリのセキュリティ通知）を集約型の見出しより優先し、未確認の場合はその旨を記載します。
最新の状態に保つ：すべての主張に日付をつけ、調査ウィンドウを記載します（例：「過去約8週間に開示されたアクティブなインシデント」）。
ステップ 5 — 名前をロックファイルと直接クロスリファレンス
ステップ4で得られたすべてのパッケージについて、監査ツールを待たずに自分で固定されたツリーを確認します。これが先行指標のステップです：
# npm
cd <dir> && npm ls <package>
grep -n '"<package>"' package-lock.json
# Go
grep -n '<module-path>' go.sum
# Python
grep -in '<package>' poetry.lock requirements.txt uv.lock 2>/dev/null
# Swift
grep -rn '<package>' --include=Package.resolved .
次に、固定されたバージョンをアドバイザリの影響範囲と比較します。名前ごとに3つの結果：露出あり（存在し範囲内）、問題なし（存在しない、または存在するが範囲外）、不確か（完全に解決できなかった推移的バージョン — さらに調査するかフラグを立てる）。
ステップ 6 — 報告
プロジェクトごとに、最初に結論、次に証拠：
- 露出あり — パッケージ、固定バージョン、アドバイザリ/インシデント、本番環境でリーチ可能かどうか、具体的な修正（対象を絞ったバージョンアップ；決して盲目的な
npm audit fixはしない）。侵害されたバージョンがインストールされた可能性がある場合、その postinstall がすでに実行された可能性に注意 —ignore-scriptsがデフォルトで重要である最大の理由。 - 問題なし — 調査したアクティブな脅威をチェックし、存在しなかった。何をチェックしたかを言及し、「問題なし」に意味を持たせる。
- 不確か / カバーされていない — ツールが薄いエコシステム（Swift）、未解決の推移的依存関係、範囲を確認できなかった調査結果。完全カバーを暗示せず、ギャップを特定する。
すべてを見つけたと暗示しないこと。実際にスイープしたウィンドウとエコシステムを明記します。
構成
- 定期スイープ: このスキルの手順を
scheduleスキルに渡して、週次クラウド実行をリポジトリ全体で行うようにします。これにより、新しいインシデントが誰かが次に確認するのを待つことなく、数日以内に捕捉されます。 - リリース前またはプッシュ前: スコープを限定した単一プロジェクトのスイープを実行します。プロジェクトに
make audit/make secret-scanのプリプッシュステップがあれば、それと自然に組み合わせられます。
注意事項
- 監査ツールは遅行指標です。ニュースとこのスキルのステップ4が先行指標です。これらが矛盾する場合 — 研究ではパッケージが侵害されていると言っているがツールは沈黙している — 直接のロックファイルチェックを信頼し、現在進行中として扱います。
npm auditはアドバイザリの深刻度を報告しますが、あなたの悪用可能性（リーチアビリティ分析なし）は報告しません — 過剰報告します。govulncheckはその逆で、エコシステムが提供する場合に優先すべきモデルです。- このスキルは露出を回答します。修正（バージョンアップ、固定、スコープ指定のスクリプト例外に対する
npm rebuild）は別の、ユーザー承認済みのステップです — 修正策を提示し、プロンプトなしで適用しないでください。