SailPointのGitHubリポジトリに不正アクセス、第三者 アプリの脆弱性が原因

サマリー

• SailPointは2026年4月20日、一部のGitHubリポジトリに対する不正アクセスを検知しました。
• 同社のインシデント対応チームは、不正な活動を速やかに停止し、問題を解決したとしています。
• 原因は、第三者アプリケーションの脆弱性と説明されており、当該脆弱性は修正済みです。
• 外部のサイバーセキュリティ対応企業の支援を受けた調査の結果、本番環境およびステージング環境の顧客データにアクセスされた証拠は確認されていません。
• SailPointのサービス停止も確認されていません。
• アクセスされたリポジトリ内に何らかの情報が含まれていた顧客には、個別に通知済みです。
• 一般の顧客に対しては、現時点で追加対応は不要と案内されています。
• 情報システム部門では、GitHubなどの開発基盤に連携する第三者アプリ、OAuth App、GitHub App、CI/CD連携、シークレット管理の棚卸しが重要です。

SailPointがGitHubリポジトリへの不正アクセスを公表

アイデンティティセキュリティ企業のSailPointは、2026年5月8日に米証券取引委員会へ提出したForm 8-Kで、同社の一部GitHubリポジトリに対する不正アクセスを検知したと公表しました。

不正アクセスを検知したのは2026年4月20日です。同社によると、インシデント対応チームが不正な活動を速やかに停止し、問題を解決しました。原因は第三者アプリケーションの脆弱性であり、すでに修正されています。

原因は第三者アプリケーションの脆弱性

SailPointは、今回の根本原因を第三者アプリケーションの脆弱性と説明しています。GitHubそのものの脆弱性が悪用されたのか、GitHubと連携していたアプリケーションや開発支援ツールが悪用されたのかについては、公表資料からは特定できません。

ただし、GitHubのような開発基盤では、ソースコード管理だけでなく、CI/CD、チケット管理、コードレビュー、セキュリティスキャン、SaaS監視、通知、デプロイ自動化など、多数の外部アプリケーションが接続されます。これらの連携アプリが広い権限を持っている場合、アプリ側の脆弱性や設定不備が、リポジトリへの不正アクセスにつながる可能性があります。

本件では、第三者アプリケーションの脆弱性は修正済みとされています。ただし、一般企業にとって重要なのは、単に脆弱性を修正することだけではありません。どのアプリが、どのリポジトリに、どの権限で接続されているかを日常的に把握できる状態にしておくことです。

ソースコード管理環境は攻撃者にとって価値が高い

GitHubなどのソースコード管理環境は、攻撃者にとって価値の高い標的です。ソースコードそのものだけでなく、環境変数、APIキー、アクセストークン、接続先情報、内部システム名、ライブラリのバージョン、CI/CDワークフロー、デプロイ手順が含まれていることがあるためです。

近年は、認証情報を直接盗むだけでなく、ソフトウェアサプライチェーンの侵害を目的としてリポジトリが狙われるケースも増えています。攻撃者がリポジトリの内容を把握できれば、脆弱な依存関係の特定、ビルドパイプラインへの介入、開発者を狙ったフィッシング、秘密情報の探索など、次の攻撃につなげやすくなります。

今回のSailPointの事案では、サービス停止や本番・ステージング環境の顧客データへのアクセスは確認されていません。しかし、リポジトリへの不正アクセスそのものは、開発基盤の保護と第三者アプリ管理の重要性を示す事案です。

情報システム部門が確認すべきポイント

情報システム部門がまず確認すべきなのは、GitHub、GitLab、Bitbucket、Azure DevOpsなどの開発基盤に接続されている第三者アプリケーションの棚卸しです。開発部門が便利なツールを個別に導入している場合、管理部門が把握していないOAuth AppやGitHub Appが残っていることがあります。

確認すべき項目は、連携アプリの所有者、用途、付与されている権限、アクセス可能なリポジトリ、最終利用日、管理者承認の有無、退職者や異動者に紐づいた認可が残っていないかです。特に、全リポジトリへのアクセス権限、書き込み権限、Webhook作成権限、ActionsやSecretsへのアクセス権限を持つアプリは、優先して見直す必要があります。

また、外部アプリの権限は最小化するべきです。読み取りだけで足りるアプリに書き込み権限を与えない、特定リポジトリだけでよいアプリに全組織権限を与えない、利用目的が不明なアプリは削除する、といった基本的な管理が被害範囲の限定につながります。

シークレット管理とリポジトリ内の機密情報確認が必要

リポジトリ不正アクセスの調査では、ソースコードそのものよりも、シークレットが含まれていなかったかを優先して確認する必要があります。APIキー、クラウドアクセスキー、データベース接続文字列、署名鍵、Webhookシークレット、CI/CDトークン、SaaS連携トークンなどが含まれていた場合、リポジトリ外の環境に被害が広がる恐れがあります。

そのため、インシデント発生時には、リポジトリ内のシークレットスキャン、過去コミット履歴の確認、GitHub Actions Secretsや環境変数の確認、CI/CDサービス側のトークン確認を行うべきです。シークレットが含まれていた可能性がある場合は、削除だけでなく、該当する認証情報のローテーションが必要です。

また、平時からリポジトリに秘密情報を置かない設計にしておくことが重要です。シークレット管理サービスを利用し、開発者がローカル環境や設定ファイルに認証情報を残さない運用を徹底する必要があります。

CI/CDとサプライチェーンの観点でも確認が必要

GitHubリポジトリが不正アクセスを受けた場合、コードが閲覧されたかだけでなく、変更された可能性も確認する必要があります。攻撃者がワークフロー定義、依存関係、ビルドスクリプト、テストコード、デプロイ設定を変更した場合、後続のビルドやリリースに悪意ある処理が混入する恐れがあります。

情報システム部門と開発部門は、該当期間中のコミット、プルリクエスト、ブランチ作成、タグ作成、リリース、Actions実行履歴、Webhook変更、デプロイ履歴を確認する必要があります。特に、署名されていないコミット、通常とは異なるユーザーによる変更、夜間や休日の操作、不審なワークフロー実行は重点的に見るべきです。

あわせて、ブランチ保護、必須レビュー、CODEOWNERS、コミット署名、環境ごとの承認、デプロイ前の二者承認を有効化しておくと、リポジトリ侵害時の改ざんリスクを下げられます。

第三者アプリの脆弱性は自社管理外でも影響する

今回のように第三者アプリケーションの脆弱性が原因とされる場合、利用企業側からは直接修正できない領域もあります。しかし、第三者アプリにどの権限を与えるか、どの範囲まで接続を許可するか、異常があった場合にどう検知するかは、自社側で管理できます。

SaaSや開発支援ツールの連携では、導入時の承認だけでなく、継続的な確認が必要です。導入時には必要だったアプリが、数か月後には利用されていないこともあります。不要な連携が残り続けると、攻撃面だけが増えます。

特に開発基盤は、情報システム部門の管理外で運用されやすい領域です。開発部門の俊敏性を損なわずに安全性を確保するには、禁止ではなく、承認済みアプリの一覧化、権限テンプレート、定期レビュー、例外申請、監査ログ確認を組み合わせた運用が現実的です。

利用企業が過度に慌てる必要はないが確認は必要

SailPointは、一般の顧客に対して現時点で追加対応は不要と案内しています。公表資料上も、本番環境やステージング環境の顧客データへのアクセス、サービス停止は確認されていません。

ただし、SailPointのようなアイデンティティセキュリティ製品は、企業のアクセス管理や権限管理に関わる重要な領域です。利用企業は、SailPointから個別通知を受けていないか、管理者向けポータルや契約窓口に案内が届いていないかを確認しておくべきです。

また、自社側でもSailPoint連携アカウント、API連携、管理者権限、SCIMやコネクタ設定、監査ログを確認し、通常と異なる操作がないかを確認しておくと安心です。これはSailPoint固有の問題というより、重要SaaSでインシデントが公表された際の基本動作として整理しておくべき対応です。

出典

SailPoint Form 8-K 2026年5月8日提出 SEC EDGAR

SecurityWeek SailPoint Discloses GitHub Repository Hack

SailPoint 公式サイト

SailPoint Identity Security Cloud 製品情報