mcpField
R
reviewing-dependency-changes

reviewing-dependency-changes

github.com/bitwardenテスト・品質16270 回インストール今日更新
リポジトリ

reviewing-dependency-changes について

コード差分の依存関係変更を確認する Bitwarden のスキルです。新規依存関係の承認、バージョン変更、マニフェストとロックファイルの整合性、自動更新、削除後の参照を確認します。

主な機能

  1. 01新規依存関係と承認根拠の確認
  2. 02メジャー更新とダウングレードの検出
  3. 03マニフェストとロックファイルの照合
  4. 04自動依存関係更新のレビュー
  5. 05削除後に残る参照の検出

活用シーン

  1. 01依存関係を追加する PR のレビュー
  2. 02メジャー更新に移行説明が必要か評価
  3. 03マニフェストとロックファイルの不整合を発見
  4. 04依存関係削除後のコード参照を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bitwarden/ai-plugins --skill reviewing-dependency-changes

インストール後、Claude Code で/reviewing-dependency-changesを入力して読み込まれたか確認します。

詳細

依存関係の変更をレビューする

マニフェストファイルの検出

差分に次のいずれかのファイルが含まれている場合、このスキルを有効にします。

  • package.json、package-lock.json
  • *.csproj、Directory.Packages.props、packages.lock.json
  • Cargo.toml、Cargo.lock
  • go.mod、go.sum
  • requirements.txt、pyproject.toml、poetry.lock
  • Gemfile、Gemfile.lock

領域 1:新しい依存関係

PR でコードベースにこれまで存在しなかった依存関係を追加する場合、Bitwarden の依存関係のレビューと承認プロセスに従い、統合前に AppSec によるレビューと承認を受ける必要があります。これは、すべての新しい依存関係(本番用、開発用、テスト用)に適用されます。

提出者は、パッケージ名/バージョン、エコシステム、追加理由、適用範囲、影響を受ける製品、置き換えるものを提示する必要があります。セキュリティエンジニアは Jira で VULN タスクを作成し、承認を判断する前に、セキュリティ(既知の CVE、悪用可能性)、ライセンスの互換性(MIT/Apache-2.0 などの許容的なライセンスは問題ありません。GPL/AGPL などのコピーレフトライセンスにはフラグを付けます)、メンテナンス状況(アクティブなメンテナー、最近のリリース、セキュリティポリシー)、サプライチェーンリスク(タイポスクワッティング、所有権の変更、難読化されたインストールスクリプト)、推移的依存関係を評価します。

確認項目
  1. これはコードベースにまだ存在しない新規の依存関係ですか?
  2. PR の説明に、プロセスに従ったことを示す承認の証拠が含まれていますか?
承認の証拠

依存関係の承認プロセスに従ったことを示す証拠:

  • PR の説明でVULN タスク(例:VULN-1234)に言及している
  • PR の説明でAppSec の承認または依存関係のレビューのプロセスに明示的に言及している
重要度

依存関係のレビューと承認のプロセスに言及する指摘を出す場合は、投稿されたレビューコメントからレビュアーが正式なドキュメントを確認できるよう、必ずプロセス名に https://bitwarden.atlassian.net/wiki/spaces/APPSEC/pages/2774466657/Dependency+Review+and+Approval へのリンクを設定してください。

  • 承認の証拠が見つからない → ⚠️ 重要:新しい依存関係 <package> が追加されています。Bitwarden では、新しい依存関係の導入前に AppSec の承認が必要です。提出者は AppSec チームに連絡し、依存関係のレビューと承認プロセスを開始してください。
  • 承認を得たかどうか不明 → ❓ 質問:新しい依存関係 <package> について、AppSec の承認を得ましたか?
指摘対象外
  • コードベースにすでに存在する依存関係(バージョンの更新は新しい依存関係ではありません)
  • Renovate/Dependabot が推移的依存関係の更新として追加した依存関係(既存の承認済み依存関係を対象としたステージ 5 の監視に含まれます)

領域 2:メジャーバージョンの更新

メジャーバージョンの更新(例:v2 → v3)により、Bitwarden のコードベースに影響する破壊的変更が導入される可能性があります。

確認項目
  1. これはSemVer のメジャーバージョンの変更ですか?
  2. PR の説明で破壊的変更または移行手順について説明していますか?
重要度
  • 移行についての説明がないメジャーバージョンの更新 → ❓ 質問:<package> が vX から vY(メジャーバージョン)に更新されています。破壊的変更について評価しましたか?
  • バージョンのダウングレード → ⚠️ 重要:<package> が vX から vY にダウングレードされています。これは通常とは異なり、解決済みの脆弱性が再発する可能性があります。

領域 3:ロックファイルの整合性

ロックファイルは、再現可能なビルドを実現します。マニフェストとロックファイルの不整合は、ビルドの信頼性とセキュリティに関わる問題です。

確認事項
シナリオ確認結果
マニフェストが変更され、ロックファイルが更新されていない⚠️ IMPORTANT:ロックファイルがマニフェストの変更を反映するよう更新されていません
ロックファイルが変更され、マニフェストに変更がない❓ QUESTION:対応するマニフェストの変更がないままロックファイルが変更されています。意図的な変更(例:npm audit fix)でしょうか?
ロックファイルが削除された⚠️ IMPORTANT:ロックファイルを削除すると、再現可能なビルドができなくなります
指摘しない事項
  • マニフェストの小さな変更に対する、ロックファイルの大規模な差分。これは通常の動作です。依存関係を1つ追加したり、バージョンを更新したりするだけで、ロックファイルが大きく変わる場合があります。
  • 同じ PR で明確なマニフェストの変更を伴う、ロックファイルのみの変更。

エリア 4:依存関係の自動更新 PR

Renovate と Dependabot による PR は、Bitwarden のステージ 5(モニタリング)プロセスの一部です。既存の承認済み依存関係に対するこれらの自動更新には、異なるレビュー対応が必要です。

検出方法
  • PR の作成者:renovate[bot]、dependabot[bot]、または類似のボットアカウント
  • PR のタイトルパターン:「Update ...」、「Bump ...」、「chore(deps): ...」
レビューの指針
シナリオ対応
既存の依存関係のマイナー/パッチ更新承認プロセスに関する指摘は不要です。ロックファイルの適切な管理と CI の状態に注目してください。
ボットによるメジャーバージョンアップエリア 2 に従って指摘してください。更新元にかかわらず、メジャーバージョンアップには人によるレビューが必要です。
ボットの PR に新しい依存関係が含まれるエリア 1 に従って指摘してください。更新元にかかわらず、新しい依存関係には承認プロセスが必要です。

エリア 5:依存関係の削除

マニフェストから依存関係が削除された場合、削除が完全に行われていることを確認してください。

確認事項
  1. 削除されたパッケージへのコード内の参照が残っていますか?
    • JavaScript/TypeScript:import ... from '<package>'、require('<package>')
    • C#/.NET:using <namespace>、ほかの .csproj ファイル内の参照
    • Rust:use <crate>::、extern crate <crate>
    • Python:import <package>、from <package> import
  2. ビルドファイルやインフラストラクチャファイル内に参照が残っていますか?
    • Dockerfile、docker-compose.yml
    • CI ワークフローファイル(.github/workflows/*.yml)
    • ビルドスクリプト、Makefile、タスクランナー
重要度
  • 使用されていないインポートや参照が残っている → ♻️ DEBT:<package> はマニフェストから削除されていますが、コード内でまだ参照されています。

コメント