dependency-scanning

依存関係のスキャン

このスキルを使うと、エージェントはプロジェクトの直接依存関係と推移的依存関係を分析し、既知のセキュリティ脆弱性、古くなったパッケージ、ライセンスコンプライアンスの問題を特定できます。エージェントはマニフェストファイルとロックファイルを解析し、脆弱性データベース（NVD、GitHub Advisory、OSV）を照会して、CVE 識別子と修正ガイダンスを含む構造化レポートを作成します。また、標準形式のソフトウェア部品表（SBOM）を生成することもできます。

ワークフロー

1. パッケージエコシステムとマニフェストファイルを検出する — package.json や package-lock.json（Node.js）、requirements.txt や Pipfile.lock（Python）、pom.xml や build.gradle（Java）、go.sum（Go）、Gemfile.lock（Ruby）などの依存関係マニフェストを特定し、プロジェクトの言語エコシステムを識別します。複数のマニフェストを含むモノレポ構造も検出します。

2. 依存関係ツリー全体を解決する — ロックファイルを解析して、推移的依存関係を含む完全な依存関係グラフを構築します。依存関係の深さ、共有されている下位依存関係、バージョン制約を特定します。コード内で使用されているものの、マニフェストに記載されていない幻の依存関係にフラグを付けます。

3. 脆弱性データベースと照合してスキャンする — 解決された各パッケージとバージョンについて、National Vulnerability Database（NVD）、GitHub Advisory Database、OSV を照会します。CPE または PURL 識別子を使って結果を照合します。利用可能な場合は、CVE ID、CVSS スコア、深刻度、影響を受けるバージョン範囲、修正済みバージョンを記録します。

4. ライセンスコンプライアンスを評価する — 各依存関係で宣言されているライセンスを抽出し、プロジェクトのライセンスポリシーと比較します。プロプライエタリプロジェクトでコピーレフトライセンス（GPL、AGPL）にフラグを付け、ライセンスが宣言されていないパッケージを特定し、直接依存関係と推移的依存関係の間でライセンスが競合していないか検出します。

5. SBOM と脆弱性レポートを生成する — CycloneDX または SPDX 形式のソフトウェア部品表を作成します。深刻度順に並べた脆弱性レポートを生成し、CVE 識別子、影響を受ける依存関係のパス、利用可能な修正バージョン、脆弱なコードパスに到達可能かどうかを記載します。

6. 修正を提案して適用する — 破壊的変更を伴わずに脆弱性を解消するために必要な最小バージョンへのアップグレードを提案します。可能な場合は、更新されたマニフェストファイルとロックファイルを自動生成します。修正が利用できない場合はその旨を示し、代替パッケージや回避策を提案します。

対応技術

• Node.js：npm audit、yarn audit、Snyk、Dependabot
• Python：pip-audit、Safety、Snyk、Dependabot
• Java：OWASP Dependency-Check、Snyk、Maven Enforcer Plugin
• Go：govulncheck、Nancy、Snyk
• コンテナ：Trivy、Grype（イメージ内の OS パッケージとアプリケーション依存関係をスキャン）
• SBOM 形式：CycloneDX（JSON/XML）、SPDX（JSON/Tag-Value）
• CI/CD 統合：GitHub Actions、GitLab CI、Jenkins、CircleCI

使用方法

プロジェクトディレクトリまたは特定のマニフェストファイルのパスをエージェントに指定します。必要に応じて、ライセンスポリシーまたは準拠対象の標準を指定します。エージェントは完全なスキャンを実行し、優先度順の脆弱性レポートを提供します。

プロンプトの例：

Scan the Node.js project in /app for dependency vulnerabilities. Generate a CycloneDX SBOM and flag any GPL-licensed transitive dependencies.

例

例 1：Node.js プロジェクトのスキャン

コマンド：

npm audit --json > audit-report.json

脆弱性レポート（抜粋）：

#	深刻度	パッケージ	インストール済み	修正済み	CVE	依存関係のパス
1	重大	jsonwebtoken	8.5.1	9.0.0	CVE-2022-23529	直接
2	高	minimatch	3.0.4	3.0.5	CVE-2022-3517	express > send > mime > minimatch
3	高	qs	6.5.2	6.5.3	CVE-2022-24999	express > qs
4	中	semver	5.7.1	5.7.2	CVE-2022-25883	nodemon > semver
5	低	cookie	0.4.1	0.4.2	CVE-2024-47764	express > cookie

package.json に自動生成された修正：

{
  "dependencies": {
    "jsonwebtoken": "^9.0.0",
    "express": "^4.19.2"
  },
  "overrides": {
    "minimatch": "3.0.5",
    "semver": "5.7.2"
  }
}

例 2：pip-audit による Python プロジェクトのスキャン

コマンド：

pip-audit -r requirements.txt --format json --output audit.json --fix --dry-run

脆弱性レポート（抜粋）：

#	重大度	パッケージ	インストール済み	修正済みバージョン	CVE	説明
1	Critical	cryptography	38.0.0	41.0.6	CVE-2023-49083	PKCS7 証明書の読み込み時に発生する NULL ポインターの参照外し
2	High	requests	2.28.0	2.31.0	CVE-2023-32681	リダイレクト先のホストへの Proxy-Authorization ヘッダーの漏えい
3	High	Jinja2	3.1.1	3.1.3	CVE-2024-22195	xmlattr フィルターを介したクロスサイトスクリプティング
4	Medium	setuptools	65.0.0	70.0.0	CVE-2024-6345	ダウンロード関数を介したリモートコード実行

自動生成された requirements.txt（修正済み）：

cryptography==41.0.6    # was 38.0.0 — fixes CVE-2023-49083
requests==2.31.0        # was 2.28.0 — fixes CVE-2023-32681
Jinja2==3.1.3           # was 3.1.1 — fixes CVE-2024-22195
setuptools>=70.0.0      # was 65.0.0 — fixes CVE-2024-6345
Flask==3.0.0
gunicorn==21.2.0

ベストプラクティス

• CI ビルドのたびにスキャンする — 依存関係のスキャンを CI パイプラインに組み込み、デプロイ後ではなく、コードがマージされる前に新たな脆弱性を検出できるようにします。
• 依存関係のバージョンを固定し、ロックファイルを使用する — ロックファイルを使った再現可能なビルドにより、CI でスキャンしたバージョンと本番環境にデプロイされるバージョンが確実に一致します。
• 推移的依存関係を監視する — 一般的なプロジェクトで見つかる脆弱性の 80% 以上は、推移的依存関係に起因します。直接依存関係だけでなく、依存関係ツリー全体を必ず解決してスキャンしてください。
• 更新 PR を自動化する — Dependabot、Renovate、または Snyk を使用して、修正版が利用可能になったときにプルリクエストを自動的に作成し、脆弱性にさらされる期間を短縮します。
• ライセンスの許可リストを管理する — 承認済みライセンスのリスト（MIT、Apache-2.0、BSD など）を定義し、許可されていないライセンスの依存関係が追加された場合にビルドをブロックします。
• リリースごとに SBOM を生成する — サプライチェーンの透明性とインシデント対応を支援するため、CycloneDX または SPDX の SBOM をリリース成果物とともに保存します。

安全上の境界

• ユーザーが所有している、または評価する明示的な許可を得ているシステムのみを対象とし、テスト前に承認された範囲を記録してください。
• 受動的な検査、または読み取り専用の検査から始めてください。アクティブスキャン、エクスプロイト、負荷の生成、または影響を伴う修復を行う前に、明示的な承認を得てください。
• 秘密情報を公開したり、無関係なデータを抽出したり、本番環境の制御を弱めたり、承認された対象の範囲を超えたりしないでください。
• 証拠を保全し、影響を最小限に抑え、不安定な状態になった場合は停止し、重要な変更ごとにロールバックまたは封じ込めの手順を提示してください。

エッジケース

• 修正プログラムが提供されていない脆弱性 — CVE が存在しても、修正版がリリースされていない場合は、脆弱なコードパスにアプリケーションから到達できるかを評価してください。到達可能であれば、依存関係の置き換え、またはローカルパッチの適用を検討してください。
• 複数のエコシステムが混在するモノレポ — 1 つのリポジトリに、マニフェストが個別に管理された Node.js、Python、Go のサービスが含まれていることがあります。各エコシステムを個別にスキャンし、統合レポートを作成してください。
• プライベートレジストリと内部パッケージ — プライベート npm レジストリや内部 PyPI サーバーでホストされているパッケージは、公開の脆弱性データベースには表示されません。プライベートアドバイザリーフィードを管理するか、カスタムデータソースに対応した Trivy などのツールで内部パッケージをスキャンしてください。
• オーバーライドによるバージョンの競合 — npm の overrides や pip の constraints を使って推移的依存関係を新しいバージョンに強制すると、実行時の互換性が損なわれる可能性があります。自動修正を適用した後は、必ずテストスイートを実行してください。
• アーカイブ済み、またはメンテナンスされていない依存関係 — 既知の CVE がないパッケージでも、アクティブなメンテナーがいない場合があります。メンテナンスされていないパッケージはサプライチェーンのリスクとして扱い、アクティブにメンテナンスされている代替パッケージへの移行を計画してください。