現在、サプライチェーン攻撃（特に 継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインをターゲットにした攻撃）が増加しています。このような攻撃を他人事と考えるのは簡単ですが、自社もサプライチェーンの一部であるという現実を直視する必要があります。社内使用や顧客へのサービスの一環としてのソフトウェア開発や提供、またこれらの製品としての販売には必ずリスクが存在します。
組織でAzure DevOpsやGitHub EnterpriseなどのCI/CDツールを使用している場合、攻撃者はこれらのシステムを悪用してコードを侵害したり、インフラストラクチャを使用してネットワークにアクセスしたりする可能性があります。CI/CDパイプラインのセキュリティ保護はもはやオプションではありません。それは必須条件なのです。これは、使用状況を継続的に監査し、SIEMソリューションにて監査ログを収集して、ログに悪意のあるアクティビティが記録されていないか積極的に監視することで、侵害やセキュリティインシデントを防止することの必要性を示しています。
Sumo LogicによるAzure DevOpsおよびGitHub向けの即時利用可能なSIEMルールは、ノイズを排除し、脅威を検出してソフトウェアサプライチェーンの制御と可視性を高めることにより、このプロセスを簡素化します。
サプライチェーン攻撃の定義
近年、サプライチェーンへの攻撃が大々的に報道されています。その注目すべき例としては次のようなものがあります。
- 約18,000もの被害組織に壊滅的な影響を与えた ソーラーウィンズ攻撃。
- 通信、金融、および重要なインフラストラクチャ企業への攻撃につながった、 金融ソフトウェアX_TRADERの侵害 。
- 攻撃者が管理ソフトウェアを侵害し、約1,500人の顧客に対してランサムウェア攻撃を実行した Kaseyaの侵害。
サプライチェーン攻撃 にはさまざまな形態が存在します。攻撃の手口は、サービスプロバイダの資格情報の盗難（2013年に起きた Targetの空調請負業者経由による侵害など）から、多くのベンダーのソフトウェアで使用されているオープンソースコードにおける脆弱性の悪用（ log4jなど）まで、さまざまです。
この記事を読み進めることで、ソフトウェアの開発および配布中に発生し得る攻撃について学びましょう。これらの攻撃では、信頼されたソフトウェアに対して悪意のあるコードが実行され、それが潜在的に武器化されることで危害が発生します。
つまり、サプライチェーン攻撃は信頼を悪用した攻撃なのです。攻撃者は、ソフトウェアやサービスを提供する企業に悪意はなく、これらがセキュリティ対策に真摯に取り組んでいるであろう、というユーザーの暗黙の信頼を悪用します。
攻撃者がCI/CDパイプラインを悪用してサプライチェーン攻撃を行う方法
上に挙げた注目度の高い攻撃において、攻撃者がどのように目的を達成したかを考えてみましょう。これらすべてのケースにおいて、攻撃者はソフトウェアのビルドまたは配布プロセスの1段階を乗っ取り、悪意のあるコードを導入しています。攻撃者がこれらのシステムに侵入するために使用した方法を詳しく見てみましょう。
- ソーラーウィンズ：「（攻撃者は）Orionのビルドサーバーの1つに侵入し、アップデートモジュールの1つにバックドアを埋め込みました。デジタル署名を含むアップデートは侵害された後、フォーチュン500企業を含む約18,000社のソーラーウィンズ顧客に配布され、同社のウェブサイトを通じて利用可能になりました。」
- 3CX：（X_TRADER攻撃により可能になったサプライチェーン攻撃）：「最終的に、攻撃者はWindowsとmacOS両方のビルド環境の侵害に成功しました。Windowsのビルド環境で、攻撃者はTAXHAULランチャーとCOLDCATダウンローダーを展開し、これらがIKEEXTサービスを介したDLL検索順序ハイジャックの実行により永続化され、LocalSystem権限で実行されました。macOSのビルドサーバーは、Launch Daemonsを永続化メカニズムとして使用するPOOLRATバックドアにより侵害されました。」
- Kaseya：「REvilの攻撃者は、KaseyaのVSAリモート管理サービスを悪用することで、マネージドサービスプロバイダの顧客と、KaseyaのVSAリモート監視および管理プラットフォーム（オンサイトバージョン）の企業ユーザーをターゲットにした、悪意のあるアップデートパッケージをリリースしました。」
Sumo LogicのAzure DevOpsおよびGitHubルール
Sumo Logic Threat Labsチームは、 Sumo Logic Cloud SIEM にて、CI/CD環境内で攻撃者のアクティビティを監視および検出するのに役立つ2つのルールセットをリリースしました。
- GitHubルール：GitHubにおける不審なアクティビティを検出するために設計されたルールセット。2024年12月6日リリース。
- Azure DevOpsルール： MicrosoftによるAzure DevOps向けのSentinelルールに基づいたルールセット。IBMのX-Force Redによる優れた論文「Hiding in the Clouds: Abusing Azure DevOps Services to Bypass Microsoft Sentinel Analytic Rules」にて提供の調整ガイダンス付。 2025年3月13日リリース。
Sumo LogicのAzure DevOpsおよびGitHubルールを使い始める方法
Sumo Logic Cloud SIEMをご利用の環境では、すでにAzure DevOpsとGitHubのルールが有効になっています。これらのルールを活用するには、CI/CDプラットフォームからログが収集されていることを確認します。以下より、ログ収集を行うための簡単なチュートリアルをご覧ください。
Azure DevOpsにおけるログ収集
Azure DevOpsのログを収集するには、次のことを行います。
- Azure DevOps組織で監査を有効にします。
- 監査ログがAzureイベントハブにストリーミングされるように設定します。
- Sumo Logic Hosted Collectorを使用してイベントハブからログを収集します。
詳細な手順については、 Azure DevOps組織で監査を有効にし、 監査ログを Azureイベントハブにストリーミングするように設定する方法を記したMicrosoftドキュメントをご参照ください。また、Azureイベントハブからのログ収集の詳細については、 Sumo Logicのヘルプトピック「Azureイベントハブソース」 をご参照の上、作成したログソースで「Cloud SIEMに転送」が有効になっていることをご確認ください。
GitHubにおけるログ収集
注：GitHubルールは、GitHub Enterpriseの監査ログ専用に開発されています。
GitHubのログを収集するには、次のことを行います。
- GitHubのログをAWS S3バケットにストリーミングします。
- Sumo Logic Hosted Collector経由でS3からGitHubのログを収集します。
設定の際は、GitHubのトピック 「Amazon S3へのストリーミング設定」 に従って、S3へのログストリーミングを設定します。次に、 Sumo Logicのヘルプトピック「Amazon S3ソース」 を使用して、S3バケットからのログ収集を設定します。ログソースを設定する際には、必ず以下のフィールドを追加してください。
| フィールド名 | フィールド値 |
| _siemForward | true |
| _parser | /Parsers/System/Github/GitHub Enterprise Audit |
設定例 – Amazon S3ログソース経由によるGitHubログ収集
Sumo LogicのCloud SIEMルールが検出する攻撃者のテクニック
Sumo LogicのCloud SIEMルールは、CI/CD環境におけるさまざまな攻撃テクニックを検出します。以下は、Azure DevOpsおよびGitHubルールによって検出される主な攻撃者戦術です。
テクニック：プルリクエストレビューのバイパス
検出ルール：
- Azure DevOps – 初めて確認されたプルリクエストポリシーのバイパス
- GitHub – プルリクエストレビュー要件の削除
CI/CDパイプラインはスピードを重視して構築されているため、開発者は1日に複数回コードの更新を本番環境にプッシュすることができます。迅速なリリースサイクルは組織およびその顧客にメリットをもたらす一方で、開発者が一方的にバグのあるコードや悪意のあるコードを本番環境にプッシュするリスクを高めます。
このリスクを軽減する1つの方法として、ビルド／リリースパイプラインに進む前にプルリクエストの承認を必要とするピアレビューの実行が挙げられます。
OWASPトップ10 CI/CDセキュリティリスクによると、レビュープロセスのバイパスは、CI/CDにおいて最大のリスクとなります。このリスクの実例は2021年3月、PHPコードベースに 承認されていない変更 が加えられた際に発生しました。
レビューのバイパスが正当化される場合のため、Azure DevOpsでは 「バイパスポリシー」の設定を介してプルリクエストポリシーをバイパスするオプションを提供しています。組織には、一時的なプルリクエストポリシーのバイパスを行う正当な理由が存在する場合があります。バイパスポリシーが許可された場合には、不正使用がないことを確認するため、監視を行う必要があります。
Azure DevOpsルール「初めて確認されたプルリクエストポリシーのバイパス」では、過去90日間にプルリクエストのバイパスが確認されていない場合に、ユーザーによるプルリクエストのバイパスがSOCアナリストに警告されます。ルールがトリガーされた場合、SOCアナリストは、プルリクエストのバイパスが予期されていたかどうかを判断し、プルリクエストのバイパスを実行したユーザーを調査することで、アカウントの侵害やその他の内部脅威アクティビティの兆候があるかどうかを確認する必要があります。
初めて確認されたプルリクエストポリシーのバイパスルールおよびログサンプル
GitHubルール「PRレビュー要件の削除」というルールも、プルリクエストレビューのバイパスを監視するものですが、これはリポジトリからレビュー要件を完全に削除することによって行われます。
PRレビュー要件の削除ルールおよびログサンプル
テクニック：特権グループへのメンバーシップの変更
検出ルール：
- Azure DevOps – 管理者グループへの変更
- GitHub – 管理者の追加または招待
2019年5月、 Stack Overflowネットワークが攻撃者によって侵害されたとき、攻撃者 は「Stack Exchangeネットワーク内のすべてのサイトに対するモデレーターおよび開発者レベルのアクセス権を取得」しました。結果として、攻撃者は184人のStack Overflowユーザーのソースコードと個人情報（PII）を抽出することに成功しました。
ユーザーによる管理者権限の取得は、当該ユーザーに重大な影響力を与えるため、注視する必要があります。OWASPは、不十分なIDおよびアクセス管理を、CI/CDパイプライン上の2番目に大きなリスクとしてランク付けしています。このリスクには、最小特権の原則の不遵守を始めとし、CI/CDパイプライン侵害を引き起こす可能性のある不適切なID管理のさまざまなケースが含まれます。
Azure DevOpsルール「管理者グループへの変更」では、ユーザーがAzure DevOps内の複数の特権グループ（プロジェクト管理者、プロジェクトコレクション管理者、プロジェクトコレクションサービスアカウント、ビルド管理者、およびプロジェクトコレクションビルド管理者など）に追加された際、SOCアナリストへの通知が行われます。
このルールがトリガーされた場合、SOCアナリストはグループの変更が承認された変更であったかどうかを判断し（例：CI/CDが変更管理の範囲内にある場合には対応する変更管理チケットを確認する、など）、変更を行ったユーザーを調査することでアカウント侵害の兆候があるかどうかを確認する必要があります。
管理者グループへの変更ルールおよびログサンプル
同様にGitHubルール「管理者の追加または招待」は、名前のとおり、新しい管理者の追加または招待を検出します。
管理者の追加または招待ルールおよびログサンプル
テクニック：悪意のあるツールの統合
検出ルール：
- Azure DevOps – First Seen – 新しい拡張機能のインストール
- GitHub – アプリケーションとAPIの初インタラクション
コードチェックやリソース管理、Secret置換などの機能を追加するためにCI/CD環境に統合することができるツールには豊富なエコシステムが存在します。残念ながら、これらのツールやサービスも攻撃ベクトルとなり得るのです。
2020年7月、静的解析やSAST、コードカバレッジ、IaC分析などの機能を提供するDeepSource GitHubアプリケーションの資格情報が侵害され、アプリユーザーの 資格情報を侵害 するために使用されました。
Azure DevOpsプラットフォームには、拡張機能マーケットプレイスが含まれています。DeepSourceの例で示されているように、拡張機能のインストールおよび使用は、拡張機能自体からの悪意のあるコードの侵入や、攻撃者が拡張機能を介してDevOps環境の足掛かりを得ることによる侵入リスクにつながります。OWASPは、「サードパーティサービスの不適切な使用」に該当するこのリスクを、最も一般的なリスクの8番目としてランク付けしています。
Azure DevOpsルール「新しい拡張機能のインストール」は、Azure DevOps組織に新しい拡張機能（対90日間のベースライン）がインストールされた際にトリガーされます。このルールがトリガーされた場合、SOCアナリストは、（変更管理チケットなどを通じて）これが既知の変更であるかどうか、また拡張機能が組織内での使用を承認されているかどうかを調査する必要があります。
新しく確認された拡張機能ルールおよびログサンプル
GitHubルール「アプリケーションとAPIの初インタラクション」では、過去90日間にGitHub APIの使用が確認されていないアプリケーションが監視されます。この検出は、「新しく確認された拡張機能」よりも広範囲に及ぶものであり、拡張機能だけでなく、APIとインタラクションを行う未知のアプリケーションもトリガーします。
アプリケーションとAPIの初インタラクションルールおよびログサンプル
CI/CD環境のログ記録は、セキュリティを監視する上できわめて重要となります。OWASPもこれに同意しており、次の理由から 「不十分なログ記録および可視性」をリスクの10番目としてランク付けしています。「不十分なログ記録および可視性によるリスクは、攻撃者に対し、攻撃キルチェーンのどの段階においても検出されることなく、CI/CD環境内で悪意のあるアクティビティを実行することを可能とします。これは、インシデント後の調査において、攻撃者のテクニックや戦術、および手順（TTP）を特定することが不可能になることを意味します。」
Sumo LogicでCI/CD環境を保護
サプライチェーン攻撃の脅威が増大する中、CI/CD環境は格好のターゲットとなります。Sumo LogicのCloud SIEMルールを使用し、CI/CDエコシステムを積極的に監視することにより、本格的な侵害につながる前に不審なアクティビティを検出して対応することが可能となります。
Sumo Logic Cloud SIEMの詳細については、 製品の内容 をご覧いただくか、 インタラクティブデモをクリックしてください。
