reviewing-dependencies

依存関係の脆弱性対応ワークフロー

ステップ 1：アラートを収集する

# List all open Dependabot alerts sorted by severity
gh api /repos/{owner}/{repo}/dependabot/alerts --jq '.[] | select(.state == "open") | {number, severity: .security_vulnerability.severity, package: .security_vulnerability.package.name, ecosystem: .security_vulnerability.package.ecosystem, summary: .security_advisory.summary}'

# Filter by severity
gh api "/repos/{owner}/{repo}/dependabot/alerts?severity=critical&state=open"

# Get full details for a specific alert
gh api /repos/{owner}/{repo}/dependabot/alerts/{alert_number}

ステップ 2：影響を評価する

各アラートについて、次の点を確認します。

1. 脆弱なコードパスに到達できますか？ — アプリケーションは、実際に依存関係の脆弱な関数や機能を使用していますか？
2. 直接依存関係ですか、それとも推移的依存関係ですか？ — 推移的な脆弱性は修正が難しい場合がありますが、実際のリスクをもたらします。
3. CVSS スコアとエクスプロイトの有無はどうなっていますか？（有効な深刻度について、triaging-security-findings で定義されている CVSS の規約に従ってスコアを評価します。）CVSS が高く、公開エクスプロイトがある場合は、直ちに対応する必要があります。CVSS が中程度で、既知のエクスプロイトがない場合は、対応を予定に組み込めます。
4. 影響を受けるバージョンと修正済みバージョンはどれですか？ — 更新がマイナーバージョンの引き上げで済むのか、互換性を破る変更を伴うのかを確認します。

ステップ 3：対応を決定する

状況	対応
修正があり、マイナーバージョンの引き上げで済む	直ちに更新する
修正があり、メジャーバージョンの引き上げが必要	互換性を破る変更を評価し、更新を予定に組み込む
修正がなく、コードパスに到達できる	回避策を実装するか、依存関係を置き換える
修正がなく、コードパスに到達できない	記録して監視し、見直し日を設定する
推移的依存関係に脆弱性がある	overrides/resolutions を使って修正済みバージョンを固定する

推移的依存関係のリスク

直接依存関係は package.json や .csproj ファイルで確認できますが、依存関係の依存関係である推移的依存関係は依存関係ツリーの大半を占める一方、見落とされがちです。

推移的依存関係が重要な理由：

• 深くネストされた依存関係の脆弱性も、直接依存関係の脆弱性と同じように悪用される可能性があります
• 推移的依存関係は、継続的に監視される可能性が低くなります
• 推移的依存関係を更新するには、その依存関係を取り込んでいる直接依存関係の更新が必要な場合があります

調査方法：

# npm: Show full dependency tree
npm ls --all

# npm: Find which direct dependency pulls in a vulnerable transitive
npm ls <vulnerable-package>

# .NET: List all vulnerable packages including transitive
dotnet list package --vulnerable --include-transitive

# .NET: Show dependency graph
dotnet list package --include-transitive

依存関係の健全性評価

依存関係の採用または継続使用を評価する際は、次の点を確認します。

基準	良い兆候	注意すべき兆候
メンテナンス	定期的なコミット、問題への迅速な対応	12 か月以上コミットがない、未対応の問題がある
脆弱性の履歴	CVE が少なく、修正が迅速	CVE が繰り返し発生し、対応が遅い
メンテナーの人数	複数のアクティブなメンテナー	メンテナーが 1 人のみで、バス係数が 1
コミュニティ	ダウンロード数が多く、アクティブユーザーがいる	うたわれている対象範囲に対して採用が非常に少ない
ライセンス	プロジェクトと互換性がある（MIT、Apache-2.0）	制限が厳しい、または曖昧なライセンス
セキュリティ対策	署名済みリリース、セキュリティポリシー、2FA	セキュリティポリシーがなく、署名済みリリースもない

Aikido 連携

Aikido は、Bitwarden のコンテナーおよびオープンソース依存関係スキャナーです。接続されたリポジトリを継続的にスキャンし、SAST、IaC、シークレットの結果と同じフィードにオープンソース（SCA）およびコンテナーの検出結果を表示します。

aikido:issues スキル（aikido_issues_list）を使用して検出結果を照会し、該当するリポジトリに範囲を絞り、issue_types を open_source（依存関係の CVE）と docker_container（コンテナーイメージの脆弱性）にフィルタリングします。cloud_instance は、クラウド VM／インスタンスの検出結果を示す Aikido の別の課題タイプであり、依存関係およびコンテナーのレビューの対象外です。

呼び出し元から Aikido のエビデンスが提供されている場合は、それを使用してください。提供されていない場合は aikido:issues を照会し、利用できない場合は、そのデータなしで処理を続行せず、ユーザーに伝えてください。

# Use the aikido:issues skill, e.g.:
# issue_types: ["open_source"], repo_name: "<repo>"       -> dependency CVEs
# issue_types: ["docker_container"], repo_name: "<repo>"  -> container image vulnerabilities

Aikido の出力の解釈：

• 各検出結果には、課題のタイトル、タイプ、重大度（および重大度ラベル）、修正ガイダンス、SLA 期限が含まれます
• out_of_sla: true を使用して、修正 SLA の期限をすでに過ぎた検出結果に重点を置きます
• トリアージは、他の Aikido の検出結果と同じ Jira ベースのフローに従います。triaging-security-findings スキルを参照してください

プラットフォーム固有のガイダンス

NuGet（.NET）

# Check for vulnerable packages
dotnet list package --vulnerable

# Include transitive dependencies
dotnet list package --vulnerable --include-transitive

# Check for outdated packages
dotnet list package --outdated

NuGet 固有の注意事項：

• .NET Framework のパッケージは、.NET Core とは異なる脆弱性プロファイルを持つ場合があります
• 推移的な依存関係の解決を改善するには、packages.config よりも .csproj の PackageReference を推奨します
• 複数のプロジェクトからなるソリューションでは、バージョン管理を一元化するために Directory.Packages.props を使用します

npm（Node.js）

# Run security audit
npm audit

# Auto-fix where possible
npm audit fix

# Force fixes (may introduce breaking changes)
npm audit fix --force

# Check lockfile integrity
npm ci  # Installs exactly from lockfile, fails if lockfile is out of date

npm 固有の注意事項：

• package-lock.json をコミットし、同期を保つ必要があります
• 推移的な依存関係のバージョンを強制するには、package.json の overrides を使用します：

  {
    "overrides": {
      "vulnerable-package": ">=2.0.0"
    }
  }
  

• 依存関係の postinstall スクリプトに注意してください。これらは npm install 中に任意のコードを実行します

SBOM の概念

ソフトウェア部品表（SBOM）は、ソフトウェア成果物に含まれるすべてのコンポーネントの一覧です。SBOM を理解すると、サプライチェーンのリスクを判断しやすくなります。

• 含まれる内容： パッケージ名、バージョン、ライセンス、関係（直接依存か推移的依存か）
• 重要な理由： 新しい CVE が公開された際に迅速に対応でき、影響を受けるプロジェクトをただちに特定できます
• 標準形式： SPDX、CycloneDX
• GitHub との連携： GitHub は依存関係グラフを自動生成し、Dependabot はこれをアラートに使用します

重要なルール

• 重大または高リスクの Dependabot アラートを、文書化された正当な理由なしに無視しないでください。 脆弱なコードパスに到達できないように見える場合でも、その理由を記録してください。
• 固定するより更新を優先してください。 脆弱なバージョンを固定して回避策を追加すると、技術的負債が蓄積します。修正が利用可能になったら更新してください。
• 推移的依存関係のツリー全体を評価してください。 直接依存のパッケージが安全でも、その推移的依存関係は安全でない可能性があります。
• 新しい依存関係を採用する前にレビューしてください。 新しいパッケージを追加する前に、上記の健全性基準を確認してください。依存関係が増えるほど、攻撃対象領域も広がります。
• 依存関係をロックしてください。 ロックファイル（package-lock.json、packages.lock.json）は必ずコミットしてください。CI/CD では npm install ではなく npm ci を使用してください。