「OSS開発者は今何をするべきか？ソフトウェアサプライチェーン侵害対策を考える」参加レポート #oss_supplychain
2026年6月23日、GMO Flatt Security主催のイベント「OSS開発者は今何をするべきか？ソフトウェアサプライチェーン侵害対策を考える」がLayerX様のイベントスペースで開催されました。
OSS開発者は今何をするべきか？ソフトウェアサプライチェーン侵害対策を考える - connpass
2026年に入り、OSSのサプライチェーン侵害が相次いで発生しました。
このような背景を踏まえて、無料から始められる Takumi Guard を導入して悪意あるパッケージをインストール前にブロックしている企業も多いのではないかと思います。
イベントのきっかけは @yusukebe さんの次のツイートです。
セキュリティがテーマのイベントは抽象論・一般論になりがちですが、どのセッションも、具体的なアプローチまで落とし込まれており、サプライチェーン対策と日々向き合っている実務家ならではの内容でした。
コーポレートエンジニアリング室におけるサプライチェーンセキュリティへの取り組み (竹山雄也さん / LayerX)
1つ目のセッションは、会場を提供してくださったLayerX 竹山雄也さんのスポンサーセッションです。
事業部ごとにサプライチェーンへの取り組みは異なっており、今回は、所属するコーポレートエンジニアリング室としての取り組みとのことです。
他の発表がOSSを開発する立場に寄っていたのに対して、本セッションはOSSを使う側の立場からの発表です。
- ライブラリのアップデートはセキュリティ系(Dependabot)と非セキュリティ系(Renovate)でアップデート方法を分ける(Dependabotのほうがタイムリーとのこと)
- バージョンのピン止め、GitHub Actions(pinact)やコンテナイメージのハッシュ値での指定
- クールダウン期間の設定
など、OSSを使う側としての防御策が紹介されました。
どれも、プラクティスとして紹介されることが多いですが、当たり前のように導入・運用するのは難しいことです。
AIエージェント時代に、技術を絞って、少ない技術の組み合わせで多くのことを実現するというアプローチも参考にしたいです。
なお、GitHub Enterpriseを全社導入するとコストが嵩むため、GitHubのような開発体験を提供するForgejoも併用しているとのことです。
PRを取り込むのが怖くなった理由と今後 (Kyohei / pdfme)
2つ目のセッションは、PDF生成ライブラリpdfmeのメンテナ、Kyohei(@labelmake)さんによる「PRを取り込むのが怖くなった理由と今後」です。
なぜ私はPRをマージするのが怖くなったのか(登壇スライド / Google Slides)
かつての牧歌的な時代のOSS開発では、利用者からのPRは歓迎すべきものでしたが、昨今は、OSSのサプライチェーンが狙われるようになっており、PRを素直に喜べません。
AIスロップの問題もあり、広義のOSSの運用方法も変わってきています。
- PRを受け付けない(Ladybird)
- パブリックドメインを維持するために、貢献者に権利放棄してもらう(SQLite)
- PRを自分で書き直す(SQLite)
- テストケースは公開しない(SQLite)
- ソースコードは公開せず、コミュニケーションの場だけ提供する(Typora)
Kyoheiさんは「社会に還元したくてOSS開発をしている人が多い」と考えます。TanStackがインシデント発生時に爆速でPostmortemを公開したのも、OSS開発者による還元の1つです。セキュリティエンジニアではないKyoheiさんがセキュリティに興味を持ったのも、自身のOSSでセキュリティ報告を受けたことがきっかけだったとのことです。
AIで大きく変わりつつある時代に、過去に固執せず、自分に合う形でOSSを運用すれば良い、というのがKyoheiさんのメッセージです。
Kyoheiさんは自身のYouTubeチャンネルでも再演しているため、ぜひご視聴ください。
Honoでのサプライチェーン侵害対策 〜 3つのライブラリに学ぶ (yusukebe / Cloudflare)
3つ目のセッションは、Honoの作者で、CloudflareのDeveloper AdvocateでもあるYusuke Wada(@yusukebe)さんによる「Honoでのサプライチェーン侵害対策 〜 3つのライブラリに学ぶ」です。
登壇者が開発するHonoは外部依存を持たない一方で、月間ダウンロードが1億を超えるほど、数多くのライブラリやサービスから依存される側にあります。つまり、Honoが侵害されれば被害が広範囲へ連鎖します。
そのため、直近の以下の3つのインシデントから、HonoがGitHubとnpmの運用で採っている対策を紹介する構成でした。
- axios
- 原因 : ソーシャルエンジニアリングによるPC乗っ取り
- 対策 : OIDC trusted publishingでGitHub Actionsから公開など
- TanStack
- 原因 : GitHub Actionsのpull_request_targetによるキャッシュ汚染
- 対策 :
pull_request_targetを使わないなど(actions/checkout@v7など新しいバージョンは対策済み)
- Mastra
- 原因 : npmアカウント乗っ取りによる、依存関係の悪用
- 対策 : ライブラリ依存が0。コントリビュータが少なく、npm貢献者は自身のみで、自分以外のアカウントが乗っ取られるリスクは皆無
Hardening npm Publishing サプライチェーン侵害から公開フローを守る (azu)
最後のセッションはjsprimerやJSer.infoの著者で、月におよそ90個のパッケージを公開するazu(@azu_re)さんによる "Hardening npm Publishing" です。
azuさんのセッションは、npm周りを中心に、yusukebeさんの発表よりもテクニカルかつシステマティックに、境界を適切に設定し、多層の仕組みで対策するアプローチでした。
- ローカル環境: 生のcredentialをローカルに置かず、1PasswordやBitwardenのようなパスワードマネージャーで管理する
- GitHub認証: GitHubのAPI操作にはPersonal Access Token(PAT)を使うが、権限が強すぎるclassic PATの使用は極力控え、用途ごとにread-only!のfine-grained PATを発行。GitHub Appベースのghtknを使っても fine-grained PAT相当のことを実現できるが、GitHub Organizationの管理チームとの調整を伴うため、使っていない(懇親会情報)
- npm認証: npmのアクセストークンは発行せず、npmとGitHub ActionsがOIDCでトークン交換するOIDC Trusted Publishingを使う
- 公開フロー: GitHub側とnpm側の両方で操作ステップを挟み(マルチステージ)、攻撃者が片方のアカウントを侵害しただけでは公開できないようにする
セッション資料
最後に
OSSのサプライチェーン侵害対策という少しニッチなテーマのイベントでしたが、4つのセッションはどれも独自色があり、それぞれの立場から日々の実践内容を具体的に発表し、非常に濃い内容でした。
OSSを開発している人も、(AIエージェント経由で)利用している人も、日々の開発に持ち帰れるトピックが多く、参加者の皆さんも熱心にメモを取っていました。
主催のGMO Flatt Security様、会場提供のLayerX様、登壇者の皆様、ありがとうございました。
