CI/CD（継続的インテグレーション/継続的デリバリまたはデプロイ）パイプラインは、すべての DevOps プロセスを支える基盤です。そのため、DevOps を導入している組織にとって、CI/CD パイプラインのすべての段階、そしてパイプラインを構成するすべてのツールと環境を保護することは重要な課題です。

この記事では、CI/CD のセキュリティが重要な理由と、パイプライン全体でセキュリティを維持するためのベストプラクティスについて、基本的な情報をご紹介します。

CI/CD のセキュリティとは

CI/CD のセキュリティは、CI/CD パイプラインの各段階についてセキュリティリスクを洗い出して緩和策を講じるプロセスであり、複数の段階で構成されます。

CI/CD の具体的なセキュリティは、CI/CD の運用方法によって異なります。CI/CD パイプラインは基本的に、ソースコード管理、ビルド、テスト、デプロイの 4 つの段階で構成され、そこにいくつかの機能ブランチが含まれることもあります。機能ブランチが含まれる場合、パイプラインが複雑になり、セキュリティリスクも増します。また、ターゲットの本番環境が複数ある場合も（Windows サーバーと Linux サーバーなど）、1 種類の環境のみにアプリケーションをデプロイする場合と比べて CI/CD パイプラインが複雑になり、セキュリティリスクが増します。

そのため、CI/CD セキュリティのアプローチは、CI/CD プロセスの構成と、各段階で使用するツールによって決まります。いずれにしても、CI/CD パイプラインを保護するために重要なのは、パイプライン上でコードが辿るすべての段階で、考え得るすべてのリスクを緩和することです。

CI/CD のセキュリティ脅威

パイプラインの構成を確認したら、CI/CD の運用に影響を及ぼす可能性のあるセキュリティ脅威を洗い出して、それぞれ必要な対策を検討します。

CI/CD のあらゆるセキュリティリスクを事前に特定することはできなくても、以下のような一般的なリスクは押さえておきましょう。

• サードパーティのソース（オープンソースプロジェクトなど）から CI/CD パイプラインに、セキュリティに問題のあるコードがインポートされる
• ソースコードリポジトリやビルドツールに不正アクセスされて、アプリケーションに悪質なコードが挿入される
• 攻撃者に開発/テスト環境に侵入され、重要なセキュリティテストが無効にされて、パイプラインのテスト段階でセキュリティ違反を検出できなくなる
• IaC テンプレートにパスワードをハードコーディングしているなど、パイプライン内のシークレット管理が甘いため、攻撃者が機密情報に不正アクセスして悪用し、攻撃を実行できる状態にある

CI/CD パイプラインの保護方法

CI/CD のセキュリティ脅威は、パイプラインの各段階、ソフトウェアスタックのさまざまな層に影響を及ぼすため、CI/CD パイプラインの保護は多重防御のアプローチで行うことが重要です。そのためには、各種の脅威を検出できるツールやプロセスを導入する必要があります。

CI/CD のセキュリティリスクの検出と対処には、主に以下のカテゴリのツールとベストプラクティスが役立ちます。

ソースコンポジション解析

ソースコンポジション解析（SCA）では、ソースコードをスキャンして、サードパーティのモジュールやライブラリ（オープンソースプロジェクトからインポートしたものなど）に起因する脆弱性を特定できます。CI/CD パイプラインの開始時点で SCA ツールを使ってソースリポジトリをスキャンすると、未解決の依存関係が検出されるので、本番アプリケーションにセキュリティの脆弱性が入り込むのを防ぐことができます。

静的アプリケーションセキュリティテスト

静的アプリケーションセキュリティテスト（SAST）は、開発者が記述したソースコードの脆弱性チェックを自身で行うものであり、SCA の補完的な役割を果たします。つまり、SCA ツールで、既知の脆弱性のデータベースに基づいてサードパーティコードの脆弱性を特定し、SAST ツールで、カスタムコードを独自に解析し、不適切な入力検証など、セキュリティの問題を検出します。

CI/CD パイプラインの開始時点で SCA に加えて SAST を実行することにより、ソースコードのリスクを 2 層で防御できます。

CI/CD アクセス制御

アクセス制御によって、CI/CD パイプライン内のツールやリソースにアクセスできるユーザーを管理することは、開発環境で悪質なコードが挿入されるのを防ぐために不可欠です。2020 年に猛威を振るった SolarWinds 攻撃ではまさにこの手口が使われました。

このようなリスクに対処するには、パスワードやアクセスキーなどを使ったアクセス制御によって、CI/CD パイプラインで使用する各ツールを保護し、必要なチームメンバーだけにアクセスを許可するよう権限を細かく設定する必要があります。すべての開発者とエンジニアにすべての CI/CD リソースへのアクセスを許可すれば管理は楽ですが、それはお勧めできません。最小権限の原則から外れ、アカウントの侵害によって攻撃者が CI/CD 環境全体に危害を加えるリスクが大幅に高まります。

シークレット管理と CI/CD

パスワードやアクセスキーといったシークレットは、コードの統合やビルド、テスト環境や本番環境へのアプリケーションのデプロイなど、CI/CD プロセスの複数の段階で頻繁に必要になります。

一般的に、これらのシークレットを共有する最も簡単な方法は、CI/CD の構成ファイルや、アプリケーション環境のプロビジョニングに使用する IaC テンプレートにハードコーディングすることです。しかし、この場合も、楽な方法はセキュリティ面で問題があります。ハードコーディングしたシークレットは、構成ファイルや IaC テンプレートを表示できれば誰でも簡単にアクセスできてしまい、重大なセキュリティリスクにつながります。

より安全な方法は、セキュリティに配慮したシークレット管理ツールで機密情報を保管し、CI/CD の運用中に必要なときだけ共有することです。

レジストリスキャン

CI/CD パイプラインでコンテナを使ってアプリケーションをデプロイする場合は、コンテナイメージがレジストリに入ったらコンテナイメージの自動スキャンを実行することによって防御層をさらに追加できます。レジストリスキャンではコンテナ内の脆弱性がチェックされるため、CI/CD パイプラインで前の段階のセキュリティテストをすり抜けた悪質なコードを検出できます。

レジストリスキャンが重要な大きな理由は、パイプラインのソースコード開発の段階ではなく、その後コンテナに組み込まれる依存関係の中に脆弱性が入り込むことがあるためです。このような脆弱性は、ソースコードのみをスキャンする SCA や SAST ツールでは検出できません。レジストリスキャンであれば通常は検出できます。

ランタイムセキュリティ

アプリケーション環境の実行中に脅威を検出するランタイムセキュリティは、CI/CD パイプラインの最後の重要な段階である本番環境へのデプロイでの脅威対応に役立ちます。また、早い段階からセキュリティを組み込む「シフトレフト」戦略として、開発/テスト環境に適用することもできます。

ランタイムセキュリティの実装には、アプリケーションログ、ネットワークメトリクス、監査ログなど、さまざまなツールとデータソースが必要です。ランタイムセキュリティのアプローチは、コンテナを使用するかどうかや使用するオーケストレータなど、実行環境によって異なります。いずれにしても重要なのは、脅威が拡散する前にそれを検出することです。

CI/CD パイプラインのセキュリティが低いと、アプリケーションのセキュリティも低下します。アクセス制御、シークレット管理、レジストリスキャンなどの手法を取り入れて、パイプラインのすべての段階でセキュリティリスクを緩和すれば、セキュリティに問題のあるコードが後の段階に悪影響を及ぼすリスクを最小限に抑えることができます。