コード・レビュー

コード・レビューには、コード・レビュー・ツールの使用、カスタマイズされたルールの作成、異なる役割によって使用されるツールのプロファイルのカスタマイズ(開発者や監査者など)、手動の解析、結果の追跡と測定が含まれます。

コード・レビュー・レベル1

[CR1.2: 82] SSGが単発のコード・レビューを実施する。

SSGは、高リスク・アプリケーションに対し任意のタイミングで単発のコード・レビューを行います。たとえば、SSGは、高リスク・アプリケーションの設計レビューに続いて、コード・レビューを実施します。より高い成熟度レベルでは、このような非公式な方法ではなく、系統的な手法を取ります。SSGによるレビューでは、特定のツールやサービスを使用したり、手動で実施できますが、事前予防的である必要があります。新しいテクノロジーが登場すると、コード・レビューの手法も新しくする必要がある場合があります。

[CR1.4: 76] 手動のレビューに加えて自動化されたツールを使用する。

静的な解析をコード・レビュー・プロセスに統合して、コード・レビューの効率性と一貫性を向上します。自動化されたツールを使用することによって、人間による判定を代替するものではありませんが、レビュアーがセキュリティの専門家でない場合に、レビュー・プロセスを定義し、セキュリティの専門知識を活用することができます。特に新しい言語が使用されている場合は、特定のツールでポートフォリオ全体に対応できない場合もありますが、コード・レビューを実施しない理由にはなりません。企業は、ソフトウェア・セキュリティのための公式のコード・レビュー・プロセスの一貫として、外部のサービス・プロバイダーを使用することができます。このサービスは、ソフトウェア開発中に適用されたより大規模なSSDLに明示的に接続されている必要がありますが、デプロイメント・パスに対し「セキュリティのチェック・ボックスをオンにする」だけのサービスでは目的を果たせません。

[CR1.5: 40] すべてのプロジェクトのコード・レビューを必須事項に設定する。

コード・レビューは、SSGが管轄するすべてのプロジェクトの必須のリリース・ゲートになります。コード・レビューを実施していなかったり、許容できない結果の場合は、リリースを中止するか、延期します。すべてのプロジェクトに対しコード・レビューを実施する必要がありますが、レビュー・プロセスはプロジェクトの種類によって異なります。たとえば、低リスク・プロジェクトのレビューでは、自動化を使用する割合が増え、高リスク・プロジェクトでは、レビューアがレビューにかける時間に制約がない場合もあります。ほとんどの場合、許容可能な標準を最低限に引き下げ、合格しなかったプロジェクトには、修正と納品前の再評価が強制されます。CI/CD自動化速度で実行できるよう、ほとんどのルールをオフに設定したコード・レビュー・ツールを使用してコード・レビューを実施しても、十分な欠陥検出機能は発揮できません。

[CR1.6: 44] 中央集中管理されたレポート体制を使用してナレッジ・ループを閉じ、トレーニングを推進する。

コード・レビュー中に検出されたバグは、集中管理されたレポジトリに保管され、追跡されます。このレポジトリを使用することで、組織のサマリー・レポートとトレンド・レポートを作成できます。コード・レビュー情報は、セキュリティ組織の他の部分からの入力(ペネトレーション・テスト、セキュリティ・テスト、ブラックボックス・テスト、ホワイトボックス・テストなど)を含むCISOレベルのダッシュボードに取り込まれます。SSGは、レポートを使用して、進捗を証明し、トレーニング・カリキュラムを推進することもできます([SM2.5 指標を特定し、それを使用して予算を確保する]を参照)。各バグは、トレーニングで使用できる良い例になります。

コード・レビュー・レベル2

[CR2.5: 28] ツールのメンターを任命する。

メンターは、コード・レビュー・ツールの活用方法を開発者に示します。SSGがツールに最も熟練している従業員である場合は、事務局の運営時間中に適切な構成を判断したり、結果の解釈方法を開発者に指導できます。または、SSGのメンバーが、開発チームが初めてレビューを実施する間、同席することもできます。ツールのメンターを使用することで、中央管理されたツールの使用を、長期的にわたって開発組織内に普及させることができます。中央管理されたツールのインストール方法やURLを提供するだけでは、メンターが存在するとはみなされません。

[CR2.6: 20] ルールがカスタマイズされた自動化ツールを使用している。

誤検知を減らし、効率性を改善するために静的解析をカスタマイズします。組織のコーディング標準や、カスタム・ミドルウェア用にカスタマイズされたルールを使用します。関連のないチェックは無効にします。ツールのメンターを提供しているグループが、カスタマイズも推進することが多くなります。ルールをカスタマイズすることで、適切なテクノロジー・スタックの使用を明らかに促進し、企業のコード・ベースでよく見られるエラーを回避できます。

[CR2.7: 25] 上位N位の考えられるバグ・リストを作成する (実際のデータを使用することが推奨されます)。

SSGは、組織のコードから排除するべき最も重要な種類のバグのリストを管理し、それを使って変革を推進します。公開ソースから引用した汎用リストをたたき台として使用することに問題はありませんが、コード・レビュー、テスト、実際のインシデントから収集した実際のデータから組織固有のリストが作成できれば、有効性がはるかに高くなります。SSGは、定期的にこのリストを更新し、「最重要バグ」のレポートを公開できます。(リストのその他の使用法については、 [T1.6 会社の履歴に合わせた教材を作成し、使用する]を参照してください。) 特定のサービスやツールに制限されないよう、複数のツールや実際のコード・ベースを使用して、上位N位のリストを作成する企業もあります。上位N位のリストで考えられる欠陥は、既知の問題のみがリストに含まれ、「街灯の下で鍵を探す」状態になることです。たとえば、OWASP Top 10に、組織のバグ属性が反映されることはまずありません。毎日生成されるバグ・データをバグ発生数を条件に並べ替えただけでは、これらのデータは頻繁に変化するため、満足のできる上位N位のリストは作成できません。バグをつぶすためには、上位N位のバグ・リストを使用するべきです。

 

 

コード・レビュー・レベル3

[CR3.2: 4] ファクトリーの構築。

1つのレポートと修正プロセスに複数の解析技法からの結果が含まれるよう、評価結果を統合します。SSGは、複数の検出方法を自動的に呼び出すスクリプトを作成したり、単一のダウンストリーム・レビューやレポート・ソリューションに入力できる形式に結果を統合できます。解析エンジンで静的解析と動的解析を統合したり、モバイル手法や標準手法などの異なるレビュー・ストリームをファクトリーに統合することができます。このアクティビティの難しい点は、矛盾する用語を使用する異なるソースからの脆弱性情報を正規化することです。CWEのような標準化された分類法を正規化に使用することができる場合もあります。複数の情報源を組み合わせることで、より多くの情報を基にした、より的確なリスク低減意思決定が可能になります。

[CR3.3: 1] コード・ベース全体から特定のバグを排除する能力を構築する。

新しい種類のバグが検出されると、SSGは、その検出ルールを作成し、そのルールを使って、コード・ベース全体からの新しいバグのすべての発生を検出します。そのライフサイクルのコード・レビュー部分がすべてのプロジェクトに周知されるまで待たなくても、その種類のバグを根絶することが可能です。ソフトウェア・アプリケーションの数が少ない企業の方が、大量の大規模アプリケーションを使用している企業に比べて、このアクティビティは実行しやすくなります。

[CR3.4: 4] 悪意のあるコードの検出を自動化する。

自動化されたコード・レビューを使用して、悪意のある社内開発者や、アウトソース・プロバイダーが作成した危険なコードを特定します。ターゲットとなる悪意のあるコードとしては、ワーム・ホール、ロジック・ボム、タイム・ボム、不正な通信チャンネル、プログラム・ロジックの難読化、ダイナミック・コード・インジェクションなどが挙げられます。既成の自動化製品を使っても、悪意があるように見える一般的な構成を検出できることはありますが、組織のコード・ベース内の許容される、または許容されないコード・パターンをコード化するために使用できる静的解析ツールのためにカスタマイズされたルールがすぐに必要になります。悪意のあるコードのための手動のコード・レビューを足がかりとして行うことは有効ですが、このアクティビティを遂行するには不十分です。

[CR3.5: 3] コーディング標準を強制的に施行する。

組織のセキュリティ上安全なコーディング標準に違反している場合は、そのコードを却下する十分な根拠になります。コード・レビューは客観的なものであり、違反しているコードが悪用可能かどうかについて議論する場ではありません。標準の強制施行は、禁止されている関数のリストを作成することから開始できます。特定のテクノロジー・スタック(C++、Spring、Swiftなど)用の開発者向けのコーディング標準を公開し、コード・レビュー・プロセス中、またはIDEで直接施行できます。標準は推奨事項と禁止事項(使用禁止APIなど)で構成できます。