開発基盤が標的化する背景
GitHubは内部リポジトリへの不正アクセス疑惑を調査中であり、攻撃者側は約4000件の窃取を主張している。真偽や影響範囲は未確定だが、ソースコード管理基盤が直接狙われる状況は情シスにとって現実的なリスクである。内部リポジトリには設計情報や未公開の修正内容、運用手順、インフラ構成、APIキーや秘密鍵などが混在し、漏えいは二次攻撃の起点となる。
特にCI/CD設定やデプロイ手順が露見すると、成果物改ざんやバックドア混入などサプライチェーン攻撃に波及し得る。コード流出は情報漏えいにとどまらず、信頼と供給継続性を揺るがすインシデントとして扱うべきである。
想定すべき侵入経路と被害像
侵入経路は大きく3つに整理できる。第一にアカウント侵害であり、フィッシング、認証情報の使い回し、トークン窃取、MFA疲労攻撃などで正規ユーザーとして侵入される。開発者は権限が広く、単一アカウントが広範なリポジトリ閲覧や設定変更に直結しやすい。
第二にOAuthアプリや連携ツールの悪用である。過大権限のアプリや侵害された連携サービスがあると、リポジトリ内容の吸い上げが一気に進む。第三にCI/CDやRunner経由の横展開であり、シークレットや署名情報、デプロイ鍵が狙われ、成果物に改変を混入されると利用者側まで被害が拡大する。
情シスが取るべき初動対応
クラウド側の調査状況に依存せず、自社の影響確認を並行実施する。監査ログで不審IP、短時間の大量clone/アーカイブ、深夜帯アクセス、権限変更、普段使わないクライアントからの操作を確認し、重要リポジトリの操作にアラートを設定する。検知から封じ込めまでの時間短縮が重要である。
次に資格情報を総点検し、疑わしいセッション無効化、Personal Access Token、Deploy Key、GitHub App鍵、CIシークレットを優先度順にローテーションする。漏えい確定を待たず「可能性があるなら回す」判断が被害長期化を防ぐ。併せて管理者権限、チーム権限、外部コラボレータ、Actions実行権限やパッケージ公開権限を棚卸しし、最小権限へ寄せる。
再発防止の要点：ゼロトラスト前提の開発運用
中長期では開発基盤を信頼前提で扱わず、ゼロトラストの原則を適用する。MFA必須化に加え、可能ならフィッシング耐性の高い認証方式や条件付きアクセスを導入し、状況に応じた追加防御を行う。Actions/CIでは外部PRにシークレットを渡さない、承認フローを設ける、トークン権限を最小化する、重要資産に触れるRunnerを分離するといったガードレールが要点である。
シークレット管理は標準化し、リポジトリに置かない運用、過去コミット混入の発見と失効、集中型シークレット管理への移行を進める。調査では「読まれた可能性」を前提に、顧客環境接続鍵や未公開脆弱性情報、依存パッケージ公開権限など悪用可能性の高い要素から優先的に封じ込めるべきである。