「もう開発者はシークレットを使うな」　GitHubが「今日できる」4つのセキュリティ対策を紹介

　GitHubは2026年4月1日（米国時間）、オープンソースソフトウェア（OSS）のサプライチェーンを狙った攻撃が増加している件を受け、攻撃の最新動向と開発者に推奨する防御策、GitHubが進めているセキュリティ対策などをブログ記事で紹介した。

【その他の画像】

　GitHubは、攻撃者がAPIキーなどのシークレット（認証情報や秘密鍵）を窃取し、攻撃者が制御するマシンから悪意のあるパッケージを公開するとともに、窃取した認証情報を使って他のプロジェクトにもアクセスし、攻撃を拡散させていることをあらためて報告した。こうした攻撃の多くはCI/CD（継続的インテグレーション／継続的デリバリー）ツール「GitHub Actions」のワークフローを侵害することから始まるという。

●GitHubが「今日できる」としている4つの防御策

　GitHubは、開発者自身がワークフローの穴をふさぐために即座に実施できる防御策として以下を挙げている。

・最重要：コード分析ツール「CodeQL」でGitHub Actionsワークフローをレビューする（パブリックリポジトリでは無料）

・「pull_request_target」トリガーの禁止（※）

・サードパーティーのActionsを利用する際は、バージョン名ではなくフルレングスのコミットSHAでピン留めし、勝手なコード変更が反映されないようにする（このピン留めは開発者自身、または依存関係管理ツール「Dependabot」で行い、外部からのプルリクエスト（PR）による更新は不審なものとして扱う）

・外部から提供されるユーザー入力を参照する際は、スクリプトインジェクションのリスクに注意する

※pull_request_targetを悪用する攻撃は、セキュリティ企業Wiz Cloudによって2026年4月2日に報告されている。

　攻撃が発生した場合、GitHubが侵害された依存関係の情報を「Advisory Database」で公開する。開発者はAdvisory Databaseから直接情報を取得するか、Dependabot（パブリックリポジトリでは無料）を利用して悪意のある依存関係や脆弱（ぜいじゃく）性のある依存関係の通知を受け取れる。

●シークレット排除を軸としたGitHubのセキュリティ対策

　GitHubは、ワークフローにおけるシークレットの使用をなくすため、OpenID Connectトークンによる認可方式を推進している。このトークンにはワークフローのワークロードIDが含まれており、APIキーなどの機密情報を直接扱う必要がなくなる。

　この一環としてGitHubは、OpenSSF（Open Source Security Foundation）と提携し、「Trusted Publishing」（信頼された発行元の検証によってシークレットなしでパッケージを公開する仕組み）というセキュリティ機能をパッケージリポジトリに導入した。この機能は「npm」「PyPI」「NuGet」「RubyGems」「Crates」などのパッケージ管理システムで対応済みとしている。

　Trusted Publishingは、ビルドパイプラインからシークレットを排除するだけでなく、新規公開されたパッケージがTrusted Publishingの使用を停止した場合にシグナルを提供する。コミュニティーはこのシグナルを利用して、パッケージが漏えいした認証情報を使用した攻撃者から提供されたものかどうかを調査できる。

　GitHubはnpmにおけるマルウェア対策にも注力している。1日3万件以上が公開されるnpmの全パッケージバージョンのマルウェアをスキャンし、毎日数百件の悪意のあるコードを検出しているという。誤検知を防ぐために、対応前には人間のレビュアーが確認する対応方法を採っている。

●今後数カ月で予定されるセキュリティ強化

　2025年後半に発生した自己複製ワーム「Shai-Hulud」攻撃を受け、GitHubはnpmのセキュリティロードマップを刷新した。Trusted Publishingの展開加速、マルウェア検出と除去の継続的改善、OSSメンテナーとの連携を進めている。

　直近の攻撃を受けて、GitHub Actionsのセキュリティロードマップも見直しを進めており、既に着手していたセキュリティ機能の開発を加速させている。GitHubは「OSSはグローバルな公共財だ。攻撃の終わりは見えていないが、GitHubはnpm、GitHub Actions、その他あらゆる領域でOSSの防御に取り組む」としている。