ビルドプロセスに環境変数を注入することは standard 現代の実践 CI/CD pipelineチームは環境変数をビルドプロセスに注入し、値をハードコーディングすることなく、秘密情報、トークン、およびランタイム構成をビルドに渡します。一見すると、これはシンプルで安全なパターンに見えます。
しかし実際には、ソフトウェアサプライチェーンにおいて最も過小評価されているリスクの一つとなることが多い。
チームが環境変数をビルドプロセスに注入すると、それらの値は隔離されなくなります。それらは、その内部で実行されるすべてのものからアクセス可能になります。 pipelineビルドスクリプト、CLIツール、サードパーティ製アクション、さらには依存関係もそれらを読み取ることができます。
ここから事態は悪化し始める。
このガイドでは、チームが実際のビルドプロセスに環境変数を注入する方法を解説します。 pipeline漏洩が実際に発生する場所、そして開発速度を落とすことなくビルドプロセスを保護する方法。
環境変数をビルドプロセスに注入するとはどういうことか
本質的に、環境変数を注入するとは、値を渡すことを意味します。 pipeline 実行時にジョブがアクセスできるように、実行時にそれらを保存します。
これらの値には通常、API キー、データベース認証情報、トークン、または環境固有の構成が含まれます。コードに直接保存する代わりに、 CI/CD システムはビルド開始時にそれらを動的にロードします。
これは実際の問題を解決します。コードをクリーンに保ち、重複を避け、同じことを可能にします。 pipeline ステージング環境、テスト環境、本番環境全体で実行できるようにする。
しかし、このモデルは、ビルド環境が制御可能で予測可能であるという、もはや成り立たない前提に基づいている。
モダン pipelineはどちらでもありません。複数のステップ、外部との連携、そしてコードを動的に実行する依存関係が含まれています。そのため、変数が一度注入されると、それはもはや単なる設定ではなくなり、実行コンテキストの一部となります。
ビルドプロセスにおいて環境変数が漏洩する箇所
ほとんどの情報漏洩は、誰かが明示的に秘密を暴露することによって起こるわけではありません。 pipeline開発者が完全には予測できないような挙動を示すことがある。
例えば、開発者はビルドの失敗をデバッグするために詳細なログ出力を有効にする場合があります。CLIツールは出力の一部として環境変数を表示する場合があります。依存関係のあるプロセスは、実行時にプロセス変数にサイレントにアクセスする場合があります。
これらの行動はどれも単独では不審には見えない。しかし、これらが組み合わさることで、複数の情報漏洩経路が生まれる。
秘密は最終的に以下のような場所に行き着く可能性がある：
- 保存およびインデックス化されるビルドログ
- デバッグ出力はチーム間で共有されます
- 外部コードを実行するサードパーティのCIアクション
- インストール時または実行時に実行される依存関係
- ビルド中に生成される一時的な成果物
一度ログに秘密情報が記録されると、それが封じ込められることはほとんどない。ログは複数のシステムにコピー、保存、保持される。その時点で、情報漏洩は元の範囲をはるかに超えて広がる。 pipeline.
そのため、環境変数の漏洩は、被害が発生した後に発見されることが多いのです。
チームがビルドプロセスに環境変数を注入する理由
こうしたリスクにもかかわらず、チームは環境変数の注入に大きく依存している。それには正当な理由がある。
それは可能にします pipeline柔軟性を維持するため。単一のワークフローで、さまざまな環境に適応し、複数のサービスに対して認証を行い、コードを変更することなく動的に動作を変更できます。
変化の激しい DevOps 環境では、この柔軟性が不可欠です。しかし、柔軟性には常にトレードオフが伴います。 pipeline 規模が大きくなるほど、内部で何が起こるかを制御することが難しくなります。追加の手順、統合、または依存関係が増えるごとに、機密データにアクセスできる場所の数が増加します。
その結果、環境変数の注入は、設定の詳細からセキュリティ上の懸念事項へと変化する。
ビルドプロセスに環境変数を注入する際の一般的なリスク
リスクは理論上のものではない。現実に現れる。 pipeline毎日。
ログに漏れ出る秘密
ログは 最も一般的な曝露源デバッグフラグ、CLIツール、スタックトレースは、開発者が気づかないうちに機密情報を明らかにすることがよくあります。
いったん漏洩すると、それらの値はシステム全体に急速に拡散する。
過度に寛容なアクセス
その他にもたくさんのグーグルの pipelineすべての変数をすべてのジョブに公開してしまう。これは不必要なリスクを生み出す。
いずれかの手順が侵害されると、実際には必要のない認証情報にアクセスできてしまう可能性がある。
依存と行為の乱用
モダン pipelineはサードパーティ製のツールや統合機能に大きく依存しています。これらのコンポーネントは、お客様のシークレットと同じ環境内で実行されます。
それらのうちの1つが悪意を持って動作した場合、注入された変数に密かにアクセスすることが可能です。
Hubspot OWASPサプライチェーン攻撃では、ビルドプロセスにおける信頼できるコンポーネントが頻繁に悪用される。環境変数は、しばしば最も容易な標的となる。
コード内のフォールバックシークレット
変数が不足しているためにビルドが失敗した場合、チームはフォールバック値を追加して pipelines 実行中。
時間が経つにつれて、これらの値は commit配備または展開され、長期的な暴露を生み出す。
ビルドプロセスに環境変数を安全に注入するためのベストプラクティス
| カテゴリー | ベストプラクティス: | それが重要な理由 |
|---|---|---|
| 秘密の保管場所 | 保管庫またはCIシークレットマネージャーを使用する | コードへの露出を防ぐ |
| アクセス制御 | ジョブごとにアクセスを制限する | 攻撃対象領域を減らす |
| ロギング | マスクの敏感な値 | 漏れを防ぐ |
| 適用範囲と寿命 | 有効期限の短い認証情報を使用する | 爆発半径を制限する |
| 検証 | 変数が欠落している場合はビルドを失敗させる | 危険なフォールバックを回避する |
なぜ多くの CI/CD セキュリティツールが環境変数リークを見逃す
ほとんどのセキュリティツールは、ビルド完了後にコードや依存関係をスキャンすることに重点を置いている。
しかし、環境変数の漏洩は実行中に発生する。
A pipeline シークレットを正しく挿入しても、ログや実行時動作を通じて漏洩する可能性があります。スキャナーが問題を検出する頃には、シークレットは既に侵害されている可能性があります。
これにより、発見と予防の間にギャップが生じる。
チームには、 pipeline 実行中であって、終了後ではない。
環境変数インジェクションを保護するための推奨事項
実際には、効果的な保護とは、いくつかの一貫した原則に集約される。
秘密は外に保管してください pipeline実行時のみに認証情報を挿入する。アクセス権限は必要最小限の範囲に限定する。可能な限り有効期限の短い認証情報を使用する。
同時に、どのように pipeline機密情報へのアクセス。予期しないアクセスパターンは、情報漏洩が顕在化する前にリスクを示していることが多い。
このアプローチは、セキュリティ対策を事後的な検出から事前的な制御へと移行させるものです。
Xygeniがどのように保護に役立つか CI/CD シークレットインジェクション
Xygeniは、ビルド後のスキャンだけに頼るのではなく、 pipelineは実行時に環境変数を使用します。これには、シークレットがジョブ間でどのように移動するか、ビルド手順がそれらにアクセスする方法、および依存関係が実行環境とどのように相互作用するかが含まれます。
例えば、Xygeniは pipeline 変数を過度に広範囲に公開してしまう場合、ステップが機密値をログに出力するリスクがある場合、または依存関係が予期せず認証情報にアクセスしようとする場合。
同時に、 guardrails 政策を直接実施する pipelineチームは、安全でないビルドをブロックしたり、特定のジョブへの秘密アクセスを制限したり、危険な構成が本番環境に到達する前に防止したりすることができます。
これは CI/CD ワークフローでは、開発者は作業方法を変更する必要はありません。セキュリティはワークフローの一部となります。 pipeline別の手順ではありません。
その結果、チームは機密情報がどのように使用されているかを把握し、その公開方法を制御できるようになり、配信速度を落とすことなく情報漏洩のリスクを軽減できます。
最終的な考え
しかし、それは同時に、しばしば見過ごされがちなリスクをもたらす。
課題は環境変数を使用するかどうかではなく、実行中にそれらの公開をどのように制御するかである。
現代のDevOps環境では、ビルドプロセス中に情報漏洩を防ぐことが、後から検出するよりもはるかに重要である。
