主要な検証ポイントを調べる

  • 6 分

継続的なセキュリティ検証は、開発から運用までの各ステップで統合して、アプリケーションがライフサイクル全体にわたってセキュリティで保護されるようにする必要があります。 このアプローチにより、セキュリティ チームが開発と対話する方法が変わり、各リリースの手動承認から CI/CD プロセス全体の継続的な監視と監査に移行します。

セキュリティ対話の変革

従来のアプローチ: セキュリティ チームは、運用環境に進む前に、各リリースを手動で確認して承認します。 これにより、ボトルネックが発生し、リリースが遅れ、最新の展開頻度ではスケーリングされません。

セキュリティで保護された DevOps アプローチ: セキュリティ チームは、個々のリリースではなく CI/CD プロセス自体に同意します。 セキュリティ要件を定義し、自動検証を実装し、プロセスを継続的に監視します。 セキュリティは、別のゲートではなく統合されます。

このシフトの利点:

  • リリースは、セキュリティ基準を満たすと自動的に続行されます。
  • セキュリティ チームは、個々の変更を確認するのではなく、プロセスの改善に重点を置きます。
  • セキュリティ検証は、1 日に複数のデプロイをサポートするようにスケーリングされます。
  • 監査証跡はセキュリティ検証を自動的に文書化します。
  • セキュリティの問題は、レビュー時ではなく、すぐに検出されます。

パイプライン内の重要な検証ポイント

次の図は、アプリケーションを一から構築するための CI/CD パイプラインの重要な検証ポイントを示しています。

IDE、プル要求、継続的インテグレーション、開発環境、およびテスト ステージ全体のセキュリティ検証ポイントを示すフローチャート。

段階的な実装: プラットフォームとアプリケーションのライフサイクル ステージに応じて、セキュリティ検証ツールを徐々に実装できます。 この段階的なアプローチは、製品が成熟していて、サイトまたはアプリケーションに対してセキュリティ検証を以前に実行していない場合に特に重要です。 すべてのセキュリティ チェックを一度に導入すると、チームが結果に圧倒される可能性があります。

優先順位付け戦略: 既存のアプリケーションでセキュリティ検証を実装する場合:

  1. 最も重要なセキュリティ チェック (シークレット検出、既知の脆弱性) から始めます。
  2. まず、リスクの高い領域の調査結果に対処します。
  3. カバレッジを徐々に拡張し、追加のセキュリティ チェックを行います。
  4. チェックを追加する前に、誤検知を減らすためのツールを調整します。
  5. セキュリティ自動化の価値を示すことで、開発者の信頼を築く。

IDE と pull request の検証

開発者がコードを共有リポジトリにコミットする前に、セキュリティ検証が開始されます。 この "左シフト" アプローチでは、修正が最も簡単でコストが最も低い場合に、できるだけ早く問題をキャッチします。

IDE レベルのセキュリティ チェック

IDE での静的コード分析: IDE に統合された静的コード分析ツールは、セキュリティの脆弱性が CI/CD プロセスに導入されないようにするための防御の最初の行を提供します。

リアルタイムフィードバック: 開発者は、コードの記述時にセキュリティの問題に関するフィードバックをすぐに受け取ります。

  • セキュリティの脆弱性は、コード エディターで直接強調表示されます。
  • セキュリティで保護されたコーディングプラクティスに関する提案は、開発者の種類として表示されます。
  • 一般的なセキュリティの問題に対するクイック修正は、1 回のクリックで利用できます。
  • 説明は、開発者が特定のパターンが問題である理由を理解するのに役立ちます。

IDE セキュリティ ツールの例:

  • Visual Studio Code のセキュリティ拡張機能: Snyk、SonarLint、GitHub Copilot などの拡張機能は、コーディング時にセキュリティ ガイダンスを提供します。
  • IntelliJ IDEA セキュリティ プラグイン: セキュリティに重点を置いたプラグインは、コードをリアルタイムで分析します。
  • Visual Studio セキュリティ アナライザー: 組み込みのアナライザーは、開発中にセキュリティの問題を検出します。

IDE レベルのチェックの利点:

  • 問題は、数日または数週間後ではなく、コードを記述するときにキャッチされます。
  • 開発者は、すぐにフィードバックを得て、セキュリティで保護されたコーディングプラクティスを学習します。
  • コードがコミットされる前にセキュリティの問題が修正され、パイプラインのエラーが減ります。
  • フィードバック ループは、時間または日ではなく、秒単位で測定されます。

リポジトリのコミット コントロール

脆弱なコードがコードベースに入らないようにします。 中央リポジトリにコードをコミットするプロセスには、セキュリティの脆弱性が導入されないようにするコントロールが必要です。

Git ブランチ ポリシー: ブランチ ポリシーを使用して Azure DevOps、GitHub、または同様のプラットフォームで Git ソース管理を使用すると、セキュリティ検証を適用するゲート コミット エクスペリエンスが提供されます。

ブランチ保護の適用: 共有ブランチ (メインや開発など) でブランチ ポリシーを有効にするには、マージ プロセスを開始するためのプル要求が必要です。 保護されたブランチへの直接コミットはブロックされ、すべてのコード変更が検証プロセスを通過します。

Pull request の要件: プル要求では、セキュリティに関連するいくつかの要件を適用する必要があります。

コード レビューの要件:

  • 少なくとも 1 人の他の開発者がコードの変更を確認する必要があります。
  • この手動レビューは、自動化されたツールが見逃す可能性があるセキュリティの問題を特定するために重要です。
  • レビュー担当者は、次のようなセキュリティ上の懸念事項を特に探す必要があります。
    • 適切な入力検証。
    • 適切な認証と承認のチェック。
    • 機密データの安全な処理。
    • セキュリティ ライブラリとフレームワークの正しい使用。
    • ハードコーディングされたシークレットまたは資格情報がない。

作業項目リンケージ:

  • コミットは、監査のために作業項目 (ストーリー、タスク、バグ) にリンクする必要があります。
  • このリンケージは、コード変更が行われた理由を説明します。
  • 監査証跡は、セキュリティ チームがインシデント調査中の変更のコンテキストを理解するのに役立ちます。
  • 作業項目リンケージにより、要件からデプロイまでの追跡可能性が可能になります。

継続的インテグレーション (CI) ビルド要件:

  • プル要求をマージするには、CI ビルド プロセスが成功する必要があります。
  • CI ビルドには、自動化されたセキュリティ チェックが含まれています (次のセクションで説明します)。
  • 失敗したセキュリティ チェックによってマージがブロックされ、脆弱なコードがメイン ブランチに入るのを防ぎます。
  • ビルド結果はプル要求に表示され、レビュー担当者のセキュリティ コンテキストが提供されます。

状態チェック:

  • 外部セキュリティ ツールは、プル要求の状態チェックを報告できます。
  • マージする前に、必要なすべての状態チェックに合格する必要があります。
  • セキュリティ チームは、パイプライン定義を変更することなく、新しい必須チェックを追加できます。

ブランチ ポリシー構成の例:

Azure DevOps または GitHub では、ブランチ ポリシーで次のものが必要になる場合があります。

  • レビュー担当者の承認は 1 つ以上必要です（重要なブランチの場合は 2 つ）。
  • すべての変更にリンクされた作業項目。
  • ビルド検証が成功しました。
  • マージする前に、すべてのコメントが解決されました。
  • 最新情報が組み込まれているブランチ（マージする前に最新の変更を取り込む必要があります）。
  • セキュリティ ツールによる状態チェックに合格することが必要です。

pull request 検証の利点:

  • セキュリティ チェックは、コードが共有コードベースに入る前に行われます。
  • 複数のパースペクティブで、セキュリティの問題に関するコードを確認します。
  • リスクの高い変更を承認したユーザーは監査証跡に記録されます。
  • 開発者は、通常のワークフロー内でセキュリティ に関するフィードバックを受け取ります。
  • チームは、コード レビューを通じてセキュリティ認識の文化を構築します。

プル要求の自動セキュリティ チェック:

プル要求は、自動セキュリティ分析をトリガーできます。

  • 静的分析: コードがスキャンされ、セキュリティの脆弱性が検出されます。
  • 依存関係チェック: 新規または更新された依存関係は、既知の脆弱性をチェックします。
  • シークレット検出: スキャンでは、誤ってコミットされた資格情報が検出されます。
  • コード品質チェック: 分析は、セキュリティの問題につながる可能性があるコード品質の問題を識別します。

結果は pull request インターフェイスに直接表示され、レビュー担当者と作成者はマージ前に問題に対処できます。