つまり、コンプライアンスは単なる事務作業ではない。DevSecOpsのワークフローの中で、コンプライアンスは手を汚しているのだ。コンプライアンスを障害物と考えるのではなく、開発ライフサイクルに統合されたガードレールと考えるのだ。自動化、セキュリティの早期統合、コラボレーションの促進など、DevSecOpsを実践している場合、コンプライアンス要件は多くの場合、そのまま取り込まれる。しかし、コンプライアンス要件によって状況は一変する。

コード・エディターからデプロイされたアプリケーションまで、あなたが影響を感じる場所を分解してみよう。

コンプライアンスと開発ワークフローの関係

コンプライアンス要件は、ソフトウェア開発ライフサイクル（SDLC）全体に現れます：

1. 計画と設計：セキュリティ要件（データの暗号化、アクセス制御など）は、後から追加するのではなく、前もって検討する必要がある。脅威モデリングは設計フェーズの一部になるかもしれない。
2. コーディング：セキュアコーディング標準が必須となる。特定のガイドライン（OWASPトップ10の緩和策など）に従ったり、承認されたライブラリのみを使用したりする必要があるかもしれない。SASTのようなツールは、IDEで直接フィードバックを提供する。
3. 建設とテスト： ここが自動化の本番だ。CI/CDパイプラインが重要な実施ポイントになる。
   
   • SAST（静的アプリケーション・セキュリティ・テスト）：ソースコードが実行される前に、脆弱性をスキャンする。
   • SCA（ソフトウェア構成分析）：オープンソースの依存関係に既知の脆弱性やライセンス問題がないかチェックする（そう、ライセンスコンプライアンスはしばしばセキュリティフレームワークの一部なのだ）。
   • 秘密の検出：コードや設定ファイルにハードコードされた認証情報（APIキーやパスワード）がないかスキャンします。
   • IaC（Infrastructure as Code）スキャン：インフラをデプロイする前に、TerraformやCloudFormationなどに設定ミスがないかチェックする。
4. 配備：重大な脆弱性が発見された場合、セキュリティゲートによって配備が妨げられる可能性がある。変更管理プロセスでは、多くの場合、コンプライアンス上の理由から文書化と承認が必要となる。
5. 運用と監視：継続的なモニタリング、ロギング、アラートは、インシデントの検出とコンプライアンスの証明に不可欠です。実行中のアプリケーション（DAST）やクラウドインフラストラクチャ（CSPM）の定期的な脆弱性スキャンが必要になることも多い。

CI/CDパイプラインの変更

あなたのCI/CDパイプラインは、純粋なビルド＆デプロイエンジンからコンプライアンス実施メカニズムに変わります。ご期待ください：

• より自動化されたスキャン・ステージ：SAST、SCA、IaCスキャンが標準的なパイプラインステップに。
• セキュリティゲート：スキャンによって重大性の高い問題やポリシー違反が検出されると、ビルドが失敗する可能性がある。
• 証拠収集：パイプラインログ、スキャン結果、承認が監査証拠となり、自動的にキャプチャされます。
• ポリシー・アズ・コード（PaC）：Open Policy Agent（OPA）のようなツールは、パイプライン内でプログラム的にセキュリティポリシーを定義し、実施するために使用されるかもしれません。
• 標準化されたベースイメージ：承認され、ハード化されたコンテナ・ベース・イメージの使用が標準となる。

ゴールは物事を遅らせることではなく、本番に打撃を与える前に問題を発見し、その過程で監査人が必要とする証拠を作成することだ。

デフのペインポイントと摩擦

現実問題として、コンプライアンスの統合は必ずしも順風満帆ではない。よくあるフラストレーションは以下のようなものだ：

• アラート疲労：不適切に設定されたツールは、開発者に無関係なアラートや偽陽性を氾濫させ、時間を浪費させ、ツールに対する信頼を損なう。Aikido 、これを避けるためにルールを厳しく審査している。）
• パイプラインのブロック：厳しすぎるセキュリティゲートは、正当なデプロイをブロックし、開発速度を低下させる。適切なバランスを見つけることが重要だ。
• コンテキストの切り替え：IDE、CI/CD ツール、個別のセキュリティダッシュボードを行き来すると、集中力が途切れる。統合されたツール（IDEプラグインやPRコメントのような）は大いに役立つ。
• 要件を理解する：抽象的なコンプライアンス管理（「最小特権を保証する」）を具体的なコーディング作業に置き換えることは、混乱を招く可能性がある。明確なガイダンスと例が必要です。
• 「セキュリティ劇場」：その理由を理解することなく、単にチェックボックスにチェックを入れるために管理策を導入することは無意味であり、憤りを生む。

重要なのは、現実のリスクに焦点を当て、開発者の既存のワークフローにツールをシームレスに統合しながら、コンプライアンスをインテリジェントに導入することである。

ワークフロー調整のクイックウィン

海を沸騰させる必要はない。現実的な第一歩をご紹介しよう：

1. スキャナーの早期統合： 今すぐCIパイプラインにSASTとSCAのスキャンを追加する。問題のログを取ることから始め、重要な発見に対しては徐々にビルドの警告や失敗を可能にする。
2. 影響の大きい分野に集中する：依存関係にある既知の脆弱性の秘密検知とパッチ適用を優先する。これらは、一般的な監査の失敗であり、真のセキュリティリスクである。
3. 開発者にやさしいツールを使う：IDEやコード・リポジトリと統合し、開発者が作業する場所に直接フィードバックを提供するツールを選ぶ。コンテキストの切り替えを最小限にする。(ヒント：Aikido 😉）。
4. エビデンスの自動化：スキャンレポートとログを自動的に保存するようにパイプラインツールを設定する。これにより、監査時の手作業を削減できます。
5. 教育から始める：具体的な管理が必要な理由を説明する。コンプライアンス要件を具体的なセキュリティリスク（データ漏えいの防止など）に関連付ける。

コンプライアンスは基本的にDevSecOpsに統合される。CI/CDパイプラインにステップを追加し、特定のコーディングプラクティスを要求し、自動化に大きく依存する。それは摩擦を引き起こす可能性がありますが、開発者のエクスペリエンスと自動化に焦点を当てた思慮深い実装が必要です。 

さて、第1章の最後のセクションに移る。これがセクション1.3の草稿だ：