※このブログはこちらの英語ブログ（2026年5月18日公開）をベースに日本向けに作成しています。
概要
2025年後半以降、「TeamPCP」と名乗る攻撃者グループが、高速ソフトウェア展開のために構築されたツールをマルウェア配信のメカニズムとして悪用しています。
このグループは様々な手法を用いますが、最も影響力の大きい手法は、標的組織のCI/CDパイプライン内でGitHubの機能を悪用するものです。
パイプラインで使用されるツールへのアクセスを利用して、認証情報を盗むマルウェアを配布しました。このマルウェアは、パッケージレジストリトークン、クラウド認証情報、SSHキー、Git認証情報、個人アクセストークン、およびCI/CD環境で利用可能なあらゆる秘密情報を吸い上げます。
この記事では、以下の点について見ていきます。
GitHub Actions の
pull_request_targetトリガーを悪用した攻撃メカニズムOSS開発・保守担当者のアカウントを狙うその他の攻撃
サプライチェーンリスクを最小限に抑える方法
現代のソフトウェア開発における自動化の罠
現代のソフトウェアプログラムには、数十から数百ものオープンソースソフトウェアパッケージ、ライブラリ、フレームワークが含まれる場合があります。そして、これらのコンポーネントは依存関係があります。複雑な依存関係を考慮して、セキュリティ修正プログラムの適用や機能追加等を実施するためには、自動化が不可欠です。
環境へのトレードオフが存在します。こうした自動化されたアップデート機能は、逆にマルウェア配信システムとして悪用される可能性があります。攻撃者は、正規のアップデートにバックドアや認証情報を窃取するマルウェアを仕込む可能性があるのです。
pull_request_targetトリガーの危険性
GitHub Actionsにおいて、攻撃者はpull_request_targetトリガーを悪用した数年前から存在する手法を再利用しています。ハッキングコミュニティは、pull_request_target機能を悪用する行為を「Pwn Request」と呼んでおり、GiHubは2021年と2025年に不正使用について警告を発しています。
pull_request_targetトリガーの本来の役割
オープンソース開発においては、外部の人が元のリポジトリを自分の環境にコピー（フォーク）し、提案（プルリクエスト）を行うことがあります。
pull_request_targetはこの提案を受け取った際に、自動テストやメンテナンスの処理を実行するためのGitHubの機能です。提案者の環境ではなく、「元のリポジトリ」の環境で処理を実行することが特徴です。- なぜ悪用されるのか
元のリポジトリで自動処理を行うためには、「アクセストークン」が必要になることがあります。これらはGitHub Actionsワークフロー内に保存されており、特に有効期限が長く広範囲の権限を持つトークンは格好の標的となります。
TeamPCP（別名：DeadCatx3、PCPcatなど）の脅威
TeamPCPは2025年後半に浮上した金銭目的のサイバー犯罪グループです。彼らはGitHub設定の既知の弱点を悪用してリポジトリへの初期アクセスを獲得し、広く利用されているソフトウェアに対して悪意のあるアップデートを配布します。これにより、侵害されたデバイス上のあらゆる認証情報やAPIキー等が盗まれ、二次的な攻撃へと繋がります。
OSS開発・保守担当者への絶え間ない攻撃
このようなシステム設定上の脆弱性だけではなく、OSS開発・保守担当者のアカウントを狙った攻撃も複数存在します。以下はその例です。
2025年9月 (npm):
著名なnpm開発・保守担当者が「2FAの期限切れ」を装うフィッシングメールに騙され、アカウントが侵害されました。結果として、少なくとも18のパッケージに暗号通貨の送金先を書き換えるコードが混入されました。
2025年7月 (PyPi):
PyPiユーザーを狙った中間者（AitM）型フィッシング攻撃により4つのアカウントが侵害され、悪意のあるAPIトークンが作成されて num2words パッケージの不正バージョンが公開されました。PyPiはフィッシング耐性のある認証が必須であれば、この攻撃は成功しなかっただろうと指摘しました。
推奨事項
OSSや自動化された開発プロセスを含むサプライチェーンリスクへの対策は多岐に及びます。本ブログでは、推奨対策の一例と参考となるURLを紹介します。
冷却期間 (Cooldown period) を設ける:
最新バージョンのインストールを遅らせる「n-1パッチ戦略」を採用します。例えば、pnpm 11.0 ではデフォルトでリリースから24時間はインストールを保留し、悪意のあるパッケージがレジストリから発見・削除される猶予を与えます。
ソフトウェア部品表 (SBOMs) の活用:
ソフトウェアを構成する依存関係を機械可読な形でリスト化します。インシデント発生時に、侵害されたコンポーネントが自社環境にダウンロード・展開されたかを迅速に特定し、認証情報のリセットなどの修復を早めることができます。
依存関係の監査 (SCAツールの利用):
npm audit や、...Snyk、Socket.devなどのソフトウェアコンポジション解析（SCA）ツールを使用して、依存関係に潜む脆弱性やリスクを分析します。
GitHub Actions の保護強化:
不要な場合は pull_request_targetトリガーを削除してください。また、アカウントが侵害されてワークフローのタグが書き換えられるのを防ぐため、**依存関係のバージョン指定にはタグではなくSHAハッシュ値を使用する（SHA pinning）**ことが推奨されます。
開発者と保守担当者のアカウント保護:
認証情報窃取を防ぐため、パスキー（FIDO2/WebAuthn）などのフィッシング耐性のある認証をポリシーとして強制してください。また、プルリクエストのマージには複数の承認を必須とし、すべてのコミットとプルリクエストにデジタル署名を求めることで、不正な変更を防いでください。
参考URL
TeamPCP攻撃で使用されるTTP（戦術、技術、手順）の詳細（Oktaソリューションのご契約のあるお客様のみ、Security Trust Centerより参照可能です）
ソフトウェアサプライチェーン攻撃からの防御 - サイバーセキュリティインフラストラクチャセキュリティ庁（CISA）：
サプライチェーンにおけるソフトウェアセキュリティ - 米国国立標準技術研究所 (NIST)
サプライチェーンセキュリティに関するガイダンス - 英国国家サイバーセキュリティセンター（NCSC）：
https://www.ncsc.gov.uk/collection/supply-chain-security
ソフトウェアサプライチェーンセキュリティチートシート - オープンワールドワイドアプリケーションセキュリティプロジェクト（OWASP）：
https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.h
