セキュリティを重視したCI/CDパイプラインの構築

継続的インテグレーション（CI）と継続的デリバリー（CD）は、DevOpsチームに広く浸透したプラクティスです。CI/CDプロセスでは、新しいアプリケーションの構築とデプロイ、またはすでにデプロイ済みのワークロードの更新を行います。そのため、CI/CDの取り組みの多くは、開発スピードの向上に重点を置いています。

しかし、CI/CDのプラクティスで実現できるのは、ワークロードのデプロイだけではありません。たとえば、コードに対するセキュリティテストやソースコードの脆弱性スキャン、その他の重要なチェックを実施してからアプリケーションのコンポーネントをデプロイする、セキュリティを重視したパイプラインとしてCI/CDを活用できます。

セキュリティを重視したCI/CDパイプラインとは

まずは、開発から運用へと直線的に進む経路としてCI/CDパイプラインをイメージしてみましょう。

開発者はビルドから始め、Gitのようなソース管理システムにコードをチェックインします。コードの検証とパッケージ化を行い、Webdeploy.zip（.NETの場合）やDockerコンテナイメージなどのパッケージファイルを、DockerホストやKubernetes環境などの実行環境に公開します。その後、運用チームが引き継いで環境を管理します。

この流れを踏まえて、CI/CDのセキュリティ最適化の考え方である「セキュリティの左シフト」によって、プロセス全体にセキュリティプラクティスを組み込むと、何が変わるかを考えてみましょう。セキュリティにおける左シフトとは、DevOpsサイクルのできるだけ早い段階からセキュリティへの意識を取り入れ、その意識をプロセス全体を通じて保つことです。

ただし、「左シフト」に関するガイダンスの多くは、あらゆるDevOpsの課題（テスト、運用の自動化、およびセキュリティ）を実装担当者に近い段階で扱うという、一般的な考え方を示している点に注意が必要です。左シフトの目的はフィードバックループを短縮し、こうした領域での変更の結果をより早く把握できるようにすることです。

多くの組織では、他のDevOpsプロセスをすでにこのようにシフトしていますが、セキュリティの左シフトはうまく進まない、あるいは実現できていません。そのため、DevOpsのプラクティスにセキュリティを含める重要性を示す言葉として、DevSecOpsが生まれました。

ここでは、CI/CDパイプラインの各段階に組み込める、一般的なセキュリティ機能をいくつか見ていきましょう。

この図が示すように、CI/CDプロセス自体を変更せずに、セキュリティを重視したCI/CDフローを確立できます。このようなセキュリティ重視のフローに移行することで、DevOpsチームはCI/CDの各サイクルにセキュリティ機能を組み込めます。

図に示した主なセキュリティの要素と、CI/CDパイプラインに組み込めるコンポーネント、それらがもたらすセキュリティ上のメリットを詳しく見ていきましょう。

脅威モデリングの自動化

脅威モデリングツールは、既知のセキュリティ上の欠陥や脆弱性などのリスクがないか、アプリケーションを分析します。脅威の特定、認識、予測を支援し、脅威の回避や緩和に向けた先を見越した意思決定を促します。

CI/CDパイプラインの図では、脅威モデリングが最初のステップとして示されていますが、多くの場合、開発プロセスが始まる前に実施されます。理想的には、CI/CDのさまざまな段階で繰り返し実施する必要があります。そこで役立つのが、自動化された脅威モデリングです。

ソフトウェア部品表

ソースコード開発者の間では、外部由来のコードを利用するケースが増えています。そのため、アプリケーションの開発ライフサイクルを通じて、オープンソースのコードスニペットやソフトウェアパッケージ、Dockerコンテナなどのリソースを追跡するのは簡単ではありません。こうした場面で役立つのが、ソフトウェア部品表（SBOM）です。

SBOMを使うと、開発チームはパッケージの場所や依存関係など、ソフトウェアコンポーネントの情報を一覧化し、アプリケーションの構成要素を可視化できます。また、アプリケーション内のパッケージを既知の脆弱性と照合できるため、悪意のあるユーザーがコードをどこでどのように悪用する可能性があるかを特定するのに役立ちます。こうした理由から、SBOMはセキュリティを重視したCI/CDパイプラインに欠かせない要素となっています。

アーティファクトの署名

開発者は、作業を効率化するために、アプリケーション間でアーティファクトを再利用することがよくあります。ソフトウェア開発におけるアーティファクトとは、ソフトウェアそのものや、前述のSBOMのようなソフトウェアに関する成果物を指し、より大きなソフトウェアアプリケーションのライフサイクルに機能や能力をもたらします。

開発コードをビルドまたはコンパイルした結果（CIの成果物）は、アーティファクトと見なせます。その他の一般的なアーティファクトには、.NET向けのNuGetパッケージ、Node.js開発向けのnpm、Java向けのMavenなどがあります。PowerShellやBashのスクリプトもアーティファクトと見なせます。

資産を保護し、その真正性を保証するために、DevOpsエンジニアは作成したソースコードにデジタル署名を付与することを検討できます。Apple App StoreやGoogle Play Storeのような配布プラットフォームを利用するアプリ開発者には、このデジタル署名が必要です。証明書にひも付いたデジタル署名によって、ソースコードを受け取る側はアーティファクトの提供元組織を確認できます。また、権限のない第三者によるコードの改ざんがないことも保証されます。

ただし、デジタル署名のプロセスは複雑で、秘密鍵基盤（PKI）証明書への対応も必要です。幸い、CI/CDパイプラインに自動化ツールを組み込めば、デジタル署名を実装できます。

セキュリティ検証のための単体テスト

単体テストを使うと、開発者は機能するソフトウェアの小さな単位ごとに、品質や実行結果を検証できます。これにより、コードの各部分が期待どおりに動作することを確認できます。主にコードの整合性や機能のテストに使われますが、セキュリティ検証に特化した単体テストも実施できます。

単体テストでは、脅威モデリング分析で検出された既知の脆弱性がないか、各コードスニペットをチェックできます。そのため、脅威モデリングのプロセスにも役立ちます。

Infrastructure as Code（IaC）の分析

Infrastructure as Code（IaC）を使うと、DevOpsチームは必要なインフラの最終状態を定義し、テンプレートベースの方法でデプロイできます。各パブリッククラウドプラットフォームは、Azure（ARM Templates and Bicep）、AWS（CloudFormation）、GCP（Deployment Manager）など、独自のIaCツールを提供しています。

マルチクラウド環境では、複数のテンプレート言語の構文を習得する複雑さを解消する、HashiCorp Terraformのようなクロスプラットフォームソリューションを検討できます。DevOpsチームの大半が開発者出身であれば、Pulumiのようなソリューションも優れた選択肢となるでしょう。Pulumiはテンプレートを使わず、コードライブラリと実際のコードを使用し、JavaScript、Python、DotNetなどの一般的なプログラミング言語に対応しています。複数のクラウドプラットフォームもサポートしています。

IaCのテンプレートファイルはアプリケーションのソースコードに似ており、定義コンポーネントや変数、他のアーティファクトへのリンクを含みます。そのため、IaCにもセキュリティを重視した最適化を適用する必要があります。ここでも、セキュリティプロセスの自動化が効果的です。たとえば、SnykはIaCのセキュリティ脆弱性の分析を自動化し、DevOpsチームが脆弱性を迅速かつ効率的に分析できるよう支援します。

脆弱性スキャンの自動化

脆弱性スキャンを使うと、DevOpsエンジニアはCI/CDパイプラインのプロセスにセキュリティ脆弱性スキャンを組み込めます。一般に、脆弱性スキャンは静的アプリケーションセキュリティテスト（SAST）または動的アプリケーションセキュリティテスト（DAST）として実施されます。

まず、SASTはソースコードを静的にスキャンし、ソース管理の一環としてコードを直接、詳細に検証します。次に、コードのコンパイル後、ソフトウェアパッケージとの統合時に、別の脆弱性スキャンを実行できます。これにより、開発者のソースコードに潜むセキュリティ上の脅威を調べ、Dockerコンテナやソフトウェアライブラリなどの追加パッケージも徹底的にスキャンします。最後に、アプリケーションの公開後にDASTを実行します。ソースコードをスキャンするのではなく、ハッカーや悪意のあるユーザーの動きを模倣して実行中のアプリケーションをテストし、コードの防御力を検証します。

コードのスキャンやスキャンの自動化に役立つツールは数多くあります。たとえば、Snykは、現在利用されている一般的なDevOpsツールやプラットフォーム向けに、強力なコードセキュリティ機能とコードスキャン機能を提供しています。

継続的なセキュリティ

これらは、DevOpsの各サイクルにセキュリティ制御を組み込むための重要な要素です。DevOpsプロセスのできるだけ早い段階からセキュリティ制御を取り入れることを促す、業界で広く知られた「左シフト」の考え方にも沿っています。

その結果、開発サイクルのあらゆる段階を保護する、継続的なセキュリティの実践が可能になります。こうした戦略を取り入れることで、DevOpsチームはセキュリティプラクティスをさらに発展させ、開発と運用（DevOps）を開発、セキュリティ、運用（DevSecOps）へと進化させられます。

DevSecOpsでは、開発の早い段階からDevOpsのあらゆるステージで、セキュリティ検証の仕組みを組み込むことが重要です。たとえば、アーキテクチャ設計の段階で脅威モデリングを始め、ソース管理時やコードのビルド時にセキュリティスキャンを行い、リリース時や運用開始後のワークロードの実行時にもセキュリティを検証できます。

継続的なセキュリティは、ソフトウェア開発ライフサイクル管理に欠かせない要素として組み込むことができますし、そうすべきです。

CI/CDとセキュリティプラクティスの最適化

これまでCI/CDプロセスは、ソフトウェアのリリースを迅速化する目的で使われてきました。しかし、セキュリティプラクティスに組み込み、セキュリティを重視したCI/CDパイプラインへと拡張することで、大きな効果を発揮します。サイバー脅威やサイバー攻撃が絶えず変化する今、ソフトウェアライフサイクルを保護するには、これまで以上に積極的なセキュリティ手法が求められます。

DevSecOpsのエンジニアリングチームに役立つセキュリティガイドラインには、脅威モデリングの自動化、SBOM、アーティファクトの署名、脆弱性スキャンの自動化などがあります。こうした戦略を採用することは、継続的なセキュリティ監視への第一歩です。組織はソフトウェアのリリースを迅速化できるだけでなく、セキュリティのベストプラクティスを取り入れたリリースを実現できます。