GitHubにおけるオープンソースサプライチェーンのセキュリティ確保
GitHubは、GitHub Actionsワークフローを起点とするオープンソースサプライチェーン攻撃の新たなパターンに対し、CodeQLによるワークフロー検査やOpenID Connectトークンを用いた信頼できる公開（trusted publishing）などの具体的な対策と、npmなど主要パッケージリポジトリでのマルウェアスキャン強化を通じて、セキュリティ向上に取り組んでいる。
キーポイント
攻撃の新たなパターン
攻撃者はGitHub Actionsワークフローを侵害し、APIキーなどのシークレットを窃取することで、攻撃者制御下のマシンから悪意のあるパッケージを公開し、さらなるプロジェクトへのアクセスを得て攻撃を拡散させている。
開発者が取るべき即時対策
公開リポジトリで無料利用可能なCodeQLによるワークフロー実装のレビュー、pull_request_targetでのワークフロー起動の回避、サードパーティActionsの完全なコミットSHAへのピン留め、ユーザー提供コンテンツ参照時のスクリプトインジェクションへの警戒が推奨されている。
GitHubのセキュリティ強化策
ワークフロー内でのシークレット使用の代わりに、ワークフローのワークロードIDを含むOpenID Connectトークンを使用する「信頼できる公開（trusted publishing）」を、OpenSSFと連携しnpm、PyPI、NuGetなどの主要パッケージリポジトリでサポートしている。
継続的な監視と検知
GitHubはAdvisory Databaseで侵害された依存関係に関する情報を公開し、Dependabotなどのツールによる通知を提供するとともに、世界最大のパッケージリポジトリであるnpmにおいて、公開される全パッケージバージョンのマルウェアスキャンを毎日実施している。
影響分析・編集コメントを表示
影響分析
この記事は、オープンソースソフトウェアの開発と流通の基盤を支えるGitHubプラットフォーム自体が攻撃の主要経路となっている現実を明らかにし、業界全体のセキュリティ意識を根本から問い直す契機となる。GitHubが自社プラットフォームの脆弱性を公に認めつつ、開発者向けの具体的な防御策と、パッケージエコシステム全体を巻き込んだ構造的な解決策（信頼できる公開）を同時に提示している点は、単なる技術的アドバイスを超えた責任あるプラットフォーム運営のモデルを示している。
編集コメント
技術的な詳細と実践的なアドバイスに富み、開発者コミュニティにとって即座に活用可能な価値が高い。プラットフォーム提供者としての自省と責任ある対応が感じられる良質の技術ブログ記事。
過去1年間で、オープンソースサプライチェーンへの攻撃に新たなパターンが現れています。攻撃者は、シークレット（APIキーなど）の窃取に焦点を当てています。これにより、攻撃者が制御するマシンから悪意のあるパッケージを公開すると同時に、より多くのプロジェクトにアクセス権を獲得して攻撃を拡大することが目的です。
こうした攻撃は、多くの場合GitHub Actionsのワークフローを侵害することから始まります。
本日から実施できるGitHub Actionsワークフローのセキュリティ確保策、GitHubがオープンソースのセキュリティ確保のために行ってきた取り組み、そして今後数ヶ月間に予定されているさらなるセキュリティ強化について説明します。
本日から実施できること
これらの攻撃の多くは、悪用可能なGitHub Actionsワークフローを探すことから始まります。
最も重要な対策は、CodeQLを有効にしてGitHub Actionsワークフローの実装をレビューすることです（パブリックリポジトリでは無料で利用可能）。これにより、ワークフローがセキュリティのベストプラクティスに従っているかを確認できます。
次に、詳細なアクションセキュリティガイドを確認してください。特に以下の点に注意が必要です：
pull_request_targetでワークフローをトリガーしないでください。- サードパーティのアクションは完全なコミットSHAにピン留めしてください。
- このピン留めは、あなた自身またはDependabotによって行うべきです。この内容を更新する外部のプルリクエストには注意が必要です。
- ユーザーが提出したコンテンツを参照する際のスクリプトインジェクションに注意してください。
攻撃が発生した場合、私たちは侵害された依存関係に関する情報をアドバイザリデータベースで公開します。アドバイザリデータベースから最新情報を直接取得するか、Dependabot（パブリックリポジトリでも無料）などのツールを使用して、悪意のあるまたは脆弱な依存関係が検出された際に通知を受け取ることができます。
私たちが行ってきたこと
これらの攻撃は同じパターンに従っています。攻撃者が制御するマシンから悪意のあるパッケージを公開するためにシークレットを窃取し、さらにその悪意のあるパッケージを使用してより多くのプロジェクトへのアクセス権を獲得し、攻撃を拡大します。
ワークフローでシークレットを使用する代わりに、ワークフローのワークロードIDを含むOpenID Connectトークンを使用してアクティビティを承認することができます。私たちは、クラウドプロバイダー、パッケージリポジトリ、その他のホスト型サービスを含む多くのシステムと連携し、この方法でActionsとの統合を進めてきました。
具体的には、GitHubはOpenSSFと提携し、パッケージリポジトリにおいて「信頼できる公開」と呼ばれるこのセキュリティ機能をサポートしています。これは現在、npm、PyPI、NuGet、RubyGems、Crates、その他のパッケージリポジトリでサポートされています。信頼できる公開は、ビルドパイプラインからシークレットを削除するだけでなく、新しく公開されたパッケージが信頼できる公開の使用を停止した際に貴重なシグナルを提供します。コミュニティはこのシグナルを用いて、そのパッケージが窃取された認証情報を使用する攻撃者由来のものかどうかを調査します。
npmは世界最大のパッケージリポジトリで、毎日3万以上のパッケージが公開されています。私たちはすべてのnpmパッケージバージョンをマルウェアについてスキャンし、攻撃の進化に合わせて検出方法を常に更新・改善しています。毎日数百の新規公開パッケージに悪意のあるコードが含まれているため、検出時には措置を講じる前に人間がレビューを行い、真陽性であることを確認します。この規模では、たとえ1%の誤検出率でも、毎日数百の正当な公開を妨害することになってしまいます。
今後数ヶ月間に予想されること
2025年後半のShai-Hulud攻撃は、npmのセキュリティロードマップの見直しを促しました。これについては、「より安全なnpmサプライチェーンのための私たちの計画」と「サプライチェーンセキュリティの強化：次のマルウェアキャンペーンへの準備」で説明しています。Shai-Huludへの対応として、私たちはnpmの信頼できる公開などの機能の展開を加速し、マルウェア検出と削除の作業を継続するとともに、どのnpmセキュリティ機能が最も大きな効果をもたらすかについてオープンソースメンテナーと協議してきました。コミュニティが変更の必要性に同意した場合でも、その変更は人々のワークフローの変更を必要とし、最悪の場合、後方互換性を損なう可能性があります。私たちは可能な限りスムーズな移行を提供できるよう努めています。
同様に、最近の一連の攻撃を受けて、私たちはGitHub Actionsのセキュリティロードマップを見直し、すでに進行中のアクションセキュリティ機能の展開を加速しています。コミュニティディスカッションの投稿で、GitHub Actionsセキュリティロードマップに関するフィードバックを提供することができます。
今後どう進めるか？
オープンソースは世界的な公共財であり、人類が成し遂げた最も偉大な共同プロジェクトの一つです。オープンソースへの攻撃はまだ終わっていませんが、GitHubはnpm、Actions、あるいは次に来るどんなものに対しても、それを守り抜くことを約束します。これらのセキュリティ機能を展開していくにあたり、何が最も効果的であり、より安全な未来への移行をどのように管理すべきかについて、皆様のフィードバックを心待ちにしています。
この投稿「GitHubにおけるオープンソースサプライチェーンのセキュリティ確保」は、The GitHub Blogで最初に公開されました。
原文を表示
Over the past year, a new pattern has emerged in attacks on the open source supply chain. Attackers are focusing on exfiltrating secrets (like API keys) in order to both publish malicious packages from an attacker-controlled machine as well as gain access to more projects in order to propagate the attack.
These attacks often start by compromising a workflow on GitHub Actions.
Let’s talk through what you can do today to secure your GitHub Actions workflows, what work GitHub has been doing to secure open source, and what to expect in the coming months for further security enhancements.
What you can do today
Many of these attacks start by looking for exploitable GitHub Actions workflows.
The most critical action you can take is to enable CodeQL to review your GitHub Actions workflow implementation (available for free on public repositories) to inspect your workflows for security best practices.
Next, review our detailed actions security guidance. In particular:
Don’t trigger workflows on pull_request_target.
Pin third-party Actions to full-length commit SHAs.
This pinning should be done by you or Dependabot; be suspicious of external pull requests that update this content.
Look out for script injection when referencing user-submitted content.
When an attack happens, we publish information about compromised dependencies in our Advisory Database. You can get up-to-date information directly from the Advisory Database or use tools like Dependabot (also free for public repositories) to notify you when you have malicious or vulnerable dependencies.
What we’ve done
These attacks follow the same pattern: they focus on exfiltrating secrets to publish malicious packages from an attacker-controlled machine, as well as using those malicious packages to gain access to more projects to propagate the attack.
Instead of using secrets in your workflows, you can use an OpenID Connect token that contains the workload identity of the workflow to authorize activities. We’ve worked with many systems to integrate with Actions this way, including cloud providers, package repositories, and other hosted services.
Specifically, GitHub partners with the OpenSSF to support this security capability, called trusted publishing, in package repositories, which is now supported across npm, PyPI, NuGet, RubyGems, Crates, and other package repositories. Not only does trusted publishing remove secrets from build pipelines, it also provides a valuable signal when a newly published package stops using trusted publishing: the community uses this signal to investigate if the package came from an attacker using exfiltrated credentials.
npm is the largest package repository in the world, with over 30,000 packages published each day. We scan every npm package version for malware, and our detections are constantly updated and improved as attacks evolve. Hundreds of newly published packages contain malicious code daily, so when detected, a human reviews to confirm it’s a true positive before we take action. At this scale, even a 1% false-positive rate would disrupt hundreds of legitimate publishes daily.
What to expect in the coming months
In late 2025 the Shai-Hulud attacks motivated a revamped security roadmap for npm, which we talked about in Our plan for a more secure npm supply chain and Strengthening supply chain security: Preparing for the next malware campaign. In response to Shai-Hulud we accelerated the roll-out of capabilities like npm trusted publishing, continued work on malware detection and removal, and engaged with open source maintainers on what npm security capabilities would have the biggest positive impact. Even when the community agrees a change must be made, those changes can mean that people need to change their workflow, or worse, cause backwards incompatibility. We’re working to provide as smooth a transition as possible.
Similarly, with the most recent round of attacks we are revisiting our security roadmap for GitHub Actions and accelerating actions security capabilities where work was already underway. You can give us feedback on the GitHub Actions security roadmap in the community discussion post.
Where do we go from here?
Open source is a global public good and one of humanity’s greatest collaborative projects. We have not seen the end of attacks on open source, but GitHub is committed to defending it across npm, actions, or whatever comes next. As we work on rolling out these security capabilities, we look forward to your feedback on what’s most impactful and how we manage the transition to a more secure future.
The post Securing the open source supply chain across GitHub appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み