reviewing-code

コードレビュー

コードベース全体ではなく、依頼された変更をレビューします。修正を依頼されていない限り、読み取り専用として扱います。セキュリティの基本事項を踏まえた通常のコードレビューを行います。セキュリティが主な目的または受け入れ基準である場合は、このワークフローを本格的なセキュリティ監査へ拡張せず、代わりに auditing-code-security を使用します。

ワークフロー

1. 依頼とリポジトリまたは PR のコンテキストから、正確な対象と比較基点を特定します。対象ブランチのマージベースを使用し、main と決めつけないでください。差分がない場合は、より広いファイル監査の範囲を明示します。
2. 依頼、Issue／PR のコンテキスト、テスト、ドキュメント、周辺コードから、意図された動作を推測します。重要な前提にはその旨を明記します。
3. 変更された動作を、関連する呼び出し元、契約、状態、エラー、下流の利用者まで追跡します。変更によって発生、悪化、または到達可能になった問題を報告し、直接関連する既存の問題とは分けます。
4. 妥当な範囲で、次の点を確認します。
   • 正確性、境界条件、状態遷移、再試行、並行処理、部分的な失敗、クリーンアップ
   • 進捗のない反復処理が停止する条件と、その最悪の場合の時間、リソース、コスト、副作用
   • インターフェース、スキーマ、マイグレーション、ジョブ、キャッシュ、機能フラグ、権限、設定
   • セキュリティの基本事項：影響を受ける資産と信頼境界、認証／認可とテナントまたはオブジェクトの所有権、ソースからシンクまでのバリデーションとインジェクション、シークレット、ログ、機密データ、依存関係と設定の露出
   • 反復処理、I/O、クエリ、ブロッキング、リーク、想定されるスケール
   • 変更された動作と具体的なエラーパスに対するテスト。保守性については、実際のコストやリスクにつながる場合に限る
5. 可能であれば、対象を絞ったチェックを実行します。チェックに合格しても正しさが証明されるわけではありませんが、判断材料になります。
6. 関連する差分、直接影響を受ける契約や呼び出し元、対象を絞った検証結果を確認したら終了します。確認済みの指摘、推測に基づくリスク、未検証の範囲を区別します。

修正を依頼された場合は、まず指摘内容を確認してから、範囲を限定したエッジケースや失敗時の処理には hardening-code-paths を使用します。推測に基づくコメントや好みだけのコメントを引き継がないでください。セキュリティアラートに脅威を重視した到達可能性分析が必要な場合は、まず auditing-code-security を使用します。修正後は差分と検証結果を改めてレビューします。

指摘事項

確認済みの指摘を、重要度の高い順に先頭から記載します。

• Critical： 深刻なセキュリティ影響、データ損失、または本番環境での広範な障害。
• Major： マージを阻止すべき、重要な正確性、信頼性、セキュリティ、または保守性のリスク。
• Minor： 修正する価値のある、実際に発生する低リスクの不具合。

各指摘には、可能な場合はファイル名と行番号、具体的な発生条件、影響、実行可能な修正案を含めます。依頼がない限り、些細な指摘は省略します。検証を経て残る指摘がない場合は、その旨を述べ、重要な残存リスクや実施できなかったチェックを明記します。

マージ可否の判定は、PR／MR または明示的にマージ可能性を問われた場合にのみ提示します。判定は次のいずれかです：Approve、Approve with minor comments、Request changes、Needs more context。