コード・レビュー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

誤検知を減らし、効率性を改善するために静的解析をカスタマイズします。カスタマイズされたルールを追加することで、組織のコーディング標準や、フレームワークベースまたはクラウドで提供されるミドルウェアに固有のセキュリティ上の不具合の発見に役立てることができます。ツールのメンターを提供しているグループが、カスタマイズも推進することが多くなります。ルールをカスタマイズすることで、適切なテクノロジー・スタックの使用を明らかに促進し、企業のコード・ベースでよく見られるエラーを回避できます。また、多くの組織では、各人の作業負荷を軽減するために、誤検知の反復を排除し、不適切なチェックをオフにするルールを作成しています。

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

SSGは、組織のコードから排除するべき最も重要な種類のバグのリストを最新の状態に維持し、それを使って変革を推進します。多くの組織は公開ソースから引用した汎用リストをたたき台として使用していますが、OWASP Top 10などのリストに組織のバグ優先順位が反映されることはまずありません。コード・レビュー、テスト、ソフトウェア・コンポジション解析、実際のインシデントから収集した実際のデータから組織固有のリストを作成し、予防対策の優先順位を付ければ、リストの価値が高くなります。毎日生成されるバグ・データをバグ発生数を条件に並べ替えただけでは、これらのデータは頻繁に変化するため、満足のできるリストは作成できません。SSGは、リストを更新した後に「最重要バグ」のレポートを定期的に公開することによって、関心を高めることができます。上位N位のリストで考えられる欠陥は、既知の問題のみがリストに含まれる傾向があることです。リストは作成するだけでは意味がなく、それを使用してバグをつぶすことが重要です。

 

 

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

[CR3.2: 7] 評価結果を総合する能力を開発する。

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

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

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

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

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

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

組織のセキュリティ上安全なコーディング標準の強制施行の部分は、禁止されている関数のリストを作成することから開始できます。組織のセキュリティ上安全なコーディング標準に違反している場合は、そのコードを却下する十分な根拠になります。コーディング標準に関するその他の有用なトピックとして、クラウドAPIの適切な使用、承認された暗号化の使用、メモリのサニタイズなどが挙げられます。標準に関するコード・レビューは客観的なものでなければならず、違反しているコードが悪用可能かどうかについて議論するものではありません。特定のテクノロジー・スタック用の開発者向けのコーディング標準を公開し、コード・レビュー・プロセス中、またはIDEで直接施行できます。標準は推奨事項と禁止事項(使用禁止APIなど)で構成できますが、効果を上げるためには施行する必要があります。