CICD-SEC-9 不適切なアーティファクト完全性バリデーション (Improper Artifact Integrity Validation)
PreviousCICD-SEC-8 サードパーティサービスの無秩序な使用 (Ungoverned Usage of 3rd Party Services)NextCICD-SEC-10 不十分なログ記録と可視化 (Insufficient Logging and Visibility)
Last updated
Last updated
不適切なアーティファクト完全性バリデーションのリスクがあると、コードやアーティファクトのバリデーションを確実にするためのメカニズムが不十分であるために、CI/CD プロセスのいずれかのシステムにアクセスできる攻撃者が悪意のある (一見無害なように見える) コードやアーティファクトをパイプラインにプッシュできてしまいます。
CI/CD プロセスは複数のステップで構成され、最終的にはエンジニアのワークステーションから本番環境に至るまでコードを運ぶ責任があります。各ステップには複数のリソースが供給されます。内部リソースとアーティファクトを、リモートロケーションからフェッチしたサードパーティおよびアーティファクトと組み合わせます。最終的なリソースは複数のステップにまたがり複数の貢献者によって提供される複数のソースに依存しているという事実は、この最終的なリソースが改竄される可能性のある複数のエントリポイントを作り出します。
改竄されたリソースが何の疑いも持たれず、セキュリティゲートにも引っかかることもなく、デリバリプロセスにうまく侵入できたとしたら、正当なリソースを装って本番環境に至るまでパイプラインを流れ続けることになるでしょう。
不適切なアーティファクト完全性バリデーションはソフトウェアデリバリプロセス内に足掛かりを持つ攻撃者によって悪用され、悪意のあるアーティファクトをパイプライン経由で出荷され、最終的には CI/CD プロセス内のシステムか、より悪いことに本番環境で悪意のあるコートが実行される可能性があります。
不適切なアーティファクト完全性バリデーションのリスクを防止するには、ソフトウェアデリバリチェーン内のさまざまなシステムとステージにわたって一連の対策が必要です。以下のような対策を検討します。
開発から本番環境に至るまでリソースの完全性を検証するプロセスと技法を実装します。リソースが生成される際、そのプロセスには外部のリソース署名インフラストラクチャを使用してそのリソースに署名することが含まれます。パイプラインの後続のステップでリソースを使用する前に、署名機関に対してリソースの完全性を検証すべきです。このコンテキストで考慮すべき一般的な対策をいくつか以下に示します。
コード署名 - SCM ソリューションは貢献者ごとに一意のキーを使用してコミットに署名する機能を提供します。この手段を利用して、署名されていないコミットがパイプラインを流れていくことを防止できます。
アーティファクト検証ソフトウェア - コードとアーティファクトへの署名および検証のためのツールを使用することで、検証されていないソフトウェアがパイプラインにデリバリされることを防止できます。そのようなプロジェクトの例として , , があります。いずれも Linux Foundation によるものです。
構成ドリフト検出 - 構成ドリフト (署名された IAC テンプレートを使用して管理されていないクラウド環境のリソースなど) を検出することを目的とした対策です。信頼できないソースやプロセスによってデプロイされたリソースを示す可能性があります。
ビルドパイプラインやデプロイパイプラインからフェッチされるサードパーティリソース (ビルドプロセスの一部としてインポートおよび実行されるスクリプトなど) は同様のロジックに従うべきです。サードパーティリソースを使用する前に、リソースのハッシュを計算し、リソースプロバイダの公式に公開されたハッシュと相互参照すべきです。
SolarWinds ビルドシステムのハックは、 SolarWinds を介して 18,000 の組織にマルウェアを拡散するために使用されました。Orion ソフトウェアのコードはビルドプロセス中にビルドシステムで変更され、コードベースに痕跡を残しませんでした。
CI で使用される一般的なコードカバレッジツールである Codecov が侵害され、ビルドから環境変数を窃取するために使用されました。攻撃者は Codecov スクリプトをホストしている GCP (Google Cloud Platform) アカウントへのアクセスを取得し、それを改変して悪意のあるコードを含めました。この攻撃は顧客が GitHub に保存されているスクリプトと GCP アカウントからダウンロードしたスクリプトのハッシュを比較することによって特定されました。
PHP git リポジトリに仕掛けられたバックドアは、最終的に PHP の正式版としてすべての PHP ユーザーに拡散されました。攻撃者は悪意のあるレビューされていないコードを PHP メインブランチに直接プッシュし、既知の PHP 貢献者によって作成されたかのようにコードをコミットしました。
攻撃者は Webmin ビルドサーバーを侵害し、アプリケーションのスクリプトの一つにバックドアを追加しました。ソース管理システムではなく、ローカルバックアップからコードが復元された事実により、侵害されたビルドサーバーが廃止された後もバックドアは存続し続けました。Webmin ユーザーはバックドアが削除されるまで 15 か月以上にわたってサプライチェーン攻撃による RCE の影響を受けていました。