サプライチェーンセキュリティの空白地帯 - 信頼できる”依存性”の未来を考える

相次ぐ依存性侵害インシデントを背景に、ソフトウェアサプライチェーンの信頼をどのように構築していくべきかを考察する。Sigstoreによる署名やOIDC認証、Cooldownといった対策が生まれてきた一方、CI/CDパイプラインや開発者端末といったビルド実行環境の保護はなお発展途上にある。本セッションでは、利用者・提供者双方の視点から現在の死角を整理し、目の前の個別対策にとどまらず、ポリシー策定・プラットフォーム・セキュリティベンダなど各レイヤーで何ができるかを探る。「まだ答えがない」フロンティアだからこそ、悲観せず前を向いて取り組んでいこうという視点を共有する。

登壇者が取り組んでいるプロジェクト:
cicd-sensor: https://github.com/cicd-sensor/cicd-sensor

Transcript

1. サプライチェーンセキュリティの空白地帯 信頼できる”依存性”の未来を考える @Product Security Square #4 | GMO Flatt Security 2026年6月4日 @rung
2. 自己紹介 • 専門 ◦ CI/CD・プロダクト開発環境のセキュリティ対策 ◦ セキュリティ周りの自動化・監視基盤構築 ◦ セキュリティ監視 ▪ ブルー側に立ちつつ、状況に応じて攻撃シミュレー ションも • 過去の関連発表など ◦ (2021年) CI/CD の攻撃手法マトリクスを公開: ▪ threat-matrix-cicd ◦ (2022-2024年) セキュリティ・キャンプで開発環境 ・CI/CD周りのセキュリティを講義: ▪ 開発環境のセキュリティおよびCI/CDパイプラインの セキュア化 - Speaker Deck ◦ (2025年) ランタイムのセキュリティ強化についてのブログ ▪ Our step-by-step guide to evaluating runtime security tools • 詳細 ◦ https://www.suezawa.net @rung /in/suezawa 2
3. 注意事項 • お願い ◦ 会社の中の人としての発表ではなく、個人としての発表です ◦ 発表内容はすべて個人としての意見です • 今日の主な対象 ◦ セキュリティに興味のあるソフトウェアエンジニア ◦ 特にサプライチェーン周りのことに興味があるセキュリティエンジニア • サプライチェーンセキュリティ ▪ この発表では、主に「ソフトウェア依存性の侵害」くらいの意味で使います 3
4. 今日伝えたいこと ここ最近、厳しい話も多い • メインテーマ ◦ 「まだ答えがない」状況だからこそポジティブにやっていこう • 扱うこと ◦ CI/CD・サプライチェーンセキュリティの現在地を、少し広い視点から見る • 扱わないこと ◦ 個別の対策 (設定手順や特定ツールの使い方) 4
5. 5 1. 最近の状況の振り返り
6. サプライチェーンセキュリティ？ • ここ最近の状況（GMO Flatt Security関連） 6 GMO Flatt Securityの関連ページ
7. 依存性を経由した侵害の連鎖 7 侵害される供給元: OSSライブラリ 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル (npm / PyPI / registry など) 次に影響を受ける供給元/組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル 本番環境, etc ある供給元の被害 → 次の供給元/組織の被害
8. 依存性を経由した侵害の連鎖 8 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 Credential(認証情報) 開発者端末 開発 Build / Release 💎 Credential(認証情報) 配布チャネル (npm / PyPI / registry など) 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 Credential(認証情報) 開発者端末 開発 Build / Release 💎 Credential(認証情報) 配布チャネル (npm / PyPI / registry など) 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 Credential(認証情報) 開発者端末 開発 Build / Release 💎 Credential(認証情報) 配布チャネル (npm / PyPI / registry など) 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 Credential(認証情報) 開発者端末 開発 Build / Release 💎 Credential(認証情報) 配布チャネル (npm / PyPI / registry など) 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 Credential(認証情報) 開発者端末 開発 Build / Release 💎 Credential(認証情報) 配布チャネル (npm / PyPI / registry など) 一つの依存性の侵害が • 次の依存性の侵害につながる • 世界中が影響を受ける
9. 依存性を経由した侵害の連鎖 9 侵害される供給元: OSS パッケージや組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル (npm / PyPI / registry など) 次に影響を受ける供給元/組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル 本番環境, etc • 依存性侵害 • マルウェア • ソーシャルエンジニアリング • 依存性侵害 • 外部からのPR経由(pull_request_target, etc) • アカウント乗っ取り 攻撃において主に狙っているもの • 認証情報の窃取がメイン: 宝探し ◦ GitHub, Cloud, SSH, AI, Cookie, etc • 最終ゴールは不明 ◦ 認証情報を取ってから決めてる？ ◦ 特定のターゲットへの侵害 ?
10. なぜ大きな問題に？ • なぜ大きな問題になっているのか？ ◦ オープンソース→オープンソースへの横展開（去年から話題。3月から加速） ▪ 盗んだ secret で次のpublish権限を奪い、増殖する ◦ まだ「ベストプラクティス」が完全に確立していない ▪ 対策も、「一人ひとりが頑張るセキュリティ」の状態 • Secure by default(デフォルト状態でセキュア)ではない • 組織においては、対策ができていることの統制をするのが難しい ◦ 取られる権限が非常に大きい ▪ プロダクションに関わる権限をとられうる • 開発者の端末: ◦ Cookie, クラウド環境クレデンシャル, etc • CI/CD 環境: ◦ そのまま本番環境の権限相当 ◦ GitHubのレポジトリを利用する権限 ◦ （AI利用による）攻撃スピードの上昇 10
11. 依存性を狙った攻撃の特徴 • 基本的に、標的型攻撃（特定組織だけをピンポイントで狙った攻撃）ではない ◦ 特定のツール・ライブラリに依存している組織全体に影響が出る ◦ 改変されたソフトウェアが一般に公開される。基本的にはマルウェアが特定の組織 だけではなく、全体にばらまかれる • 高度な攻撃が行われている？ ◦ どちらかというと、「効率的に狙える高権限の環境を見つけられた」という印象 ◦ 高度な攻撃というよりは、対策が定まっていないエリアを狙った攻撃 ▪ これからも更に増えるかも 11
12. 12 2. 生まれてきた対策
13. 生まれてきた対策 • ここ5年でいろいろな対策が生み出されてきた ◦ SLSA ▪ 安全なソフトウェア作成の基準づくり ◦ Sigstore ▪ 署名 ▪ 生成元の保証 ◦ SBOM ▪ 依存性記載の標準化 ◦ CI/CDパイプラインでのOIDC認証 ▪ 長期鍵から一時鍵(Keylessとも)への変更 ◦ 依存性アップデートのCooldown期間の導入 ▪ ソフトウェアアップデートを、公開されて◦日経ってから行う 13
14. （参考）SLSA 14 https://slsa.dev/
15. 生まれてきた対策: 入口 15 侵害される供給元: OSS パッケージや組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル (npm / PyPI / registry など) 次に影響を受ける供給元/組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル 本番環境, etc • • 入口を防ぐ ◦ 依存の安全性： ▪ 依存の固定: Hash値での固定 ▪ 署名検証（Sigstore） ▪ Cooldown(時間を防御に) ▪ Takumi Guard、Chainguard Images など、信頼度の高い方法での依存性の 取得 ◦ 外部からの攻撃 ▪ レビューの必須化、テストとビルド・ デプロイの分離 ▪ 最小権限 ◦ 端末 ▪ EDR，パスキー、公開はCI経由のみに ・・
16. 生まれてきた対策: 認証情報 16 侵害される供給元: OSS パッケージや組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル (npm / PyPI / registry など) 次に影響を受ける供給元/組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル 本番環境, etc • • 認証情報を守る ◦ 長期鍵を捨てる（CI/CD環境ではOIDC、 ローカルでも期限付きに・・） ◦ 権限の最小化
17. 生まれてきた対策: 出口 17 侵害される供給元: OSS パッケージや組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル (npm / PyPI / registry など) 次に影響を受ける供給元/組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル 本番環境, etc 出口側 • 署名必須 • Immutable release(不変的リ リース） • 生成元の付与をして検証可能に • 配布チャネル側での公開後の侵害 検知
18. 18 3. まだ欠けているもの
19. まだ欠けているもの • 点としての対策は生まれてきたが、まだ線になっていない状態・・・ ◦ どの対策も、存在はしているが徹底が難しいという状況 ◦ 各レポジトリで考えないといけない対策も多すぎる ◦ さらに・・・ 19
20. 欠けているもの: CI/CDパイプラインのエリア 20 侵害される供給元: OSS パッケージや組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル (npm / PyPI / registry など) 次に影響を受ける供給元/組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル 本番環境, etc • 高権限の認証情報が置かれがちなエリア ◦ アプリケーションのビルド・デプロイ ◦ Infrastructure as Code(Terraformなど） • 基本的な”セキュリティ対策”が欠けている ◦ 不正な動きを監視する方法がない ◦ 可視性やログがなく、事後的な調査もでき ない ◦ ネットワークのレイヤでの制御も難しい ▪ → 「不正を発見して、調査して、直 す」ライフサイクルを作れない • 設定を統制するのが難しい • 生成元がCI/CDパイプラインでも安全かわからな い ◦ CI/CDパイプライン上で攻撃コードを埋め込 めばいいだけ
21. 欠けているもの: 開発者端末のエリア 21 侵害される供給元: OSS パッケージや組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル (npm / PyPI / registry など) 次に影響を受ける供給元/組織 依存 CI/CD pipeline (GitHub / GitLab) Build / Release 💎 認証情報 開発者端末 開発 Build / Release 💎 認証情報 配布チャネル 本番環境, etc • 開発者端末も宝の山 ◦ ブラウザのCookie, Password ◦ クラウド権限 ◦ SSH ◦ AI系のトークン • EDRなど、長年対策が積み重ねられてきたエリア ではある ◦ ただ、急に依存しているライブラリが発火す ると？ ◦ OSSは個人開発も多い
22. 結局のところ・・・ • 大きな被害が続いている 22
23. 絶望的？ • 被害は続いているが、絶望する必要はない ◦ そもそも・・・ ▪ コンピュータやインターネットの土台は、安全を前提にせず作られた • 平文の HTTP ◦ TLS化が進んだのは過去10年(2013年のスノーデン事件以降) • 認証もPasskeyの時代へ ◦ たくさんの被害ののち、生まれてきた ◦ （被害の後）証券会社がPasskey必須化に取り組むように ▪ まだ直っていないものもある • オンプレADは、いまだに標的型攻撃・レッドチームの主戦場 ◦ サプライチェーンセキュリティも、単にまだ整ってない状況の一つ ▪ ポジティブに考えると、これから直すべきことがたくさんあるフロンティア 23
24. 24 4. これからのこと
25. サプライチェーンセキュリティの現状 • いろいろなものが生まれているがまだ点が線になっていない状況 ◦ Secure by defaultではない • 色々なプレイヤーが今も色々なことを考えている 25
26. GMO Flatt Security • Takumi Guard ◦ 悪性パッケージの自動ブロック • Takumi Runner ◦ CI/CD実行トレースの可視化 • ソフトウェアサプライチェーン診断 • ソフトウェアサプライチェーン攻撃演習 26
27. GitHub（公開情報より） • What’s coming to our GitHub Actions 2026 security roadmap ◦ Actions Data StreamをS3やAzure Event Hubに流せるようになるらしい ◦ 外向きの通信制限をかけられるようになるらしい 27
28. 今年の8月のBlackHatでの発表予定 • GitHub Can Tell You're Being Hacked. You're Just Not Listening: Building EDR for GitHub from Its Own Event Stream ◦ https://blackhat.com/us-26/briefings/schedule/#github-can-tell-youre-being -hacked-youre-just-not-listening-building-edr-for-github-from-its-own-even t-stream-53981 ◦ Event Streamをもとに検知を行うアイデア 28
29. @rungも個人的に・・・ • cicd-sensor ◦ GitHub Actions, GitLab CI/CD向けのオープンソースEDR ▪ (eBPFを使ったランタイムセキュリティツール) ◦ CI/CDセキュリティの専門家にレビューしてもらいつつ開発中 ◦ https://github.com/cicd-sensor/cicd-sensor ▪ 現在Pre-release状態。試してフィードバックをください • なにかあっても検知できない・あとからログで事象を追えない状況は解決しなければなら ない • 将来的には、ビルド中の通信や挙動も検証可能になると嬉しい(Build attestation) 29
30. Chainguard • The hardest fork (May 28, 2026) ◦ Mythosなどの文脈: いくつか結果を見たが脅威は現実 ◦ 現状のオープンソース消費モデルは対応できない ▪ 新しい信頼インフラを作る: 何千ものプロジェクトをフォークし、維持し、配 布するインフラを構築するアイデア • (パッチも含めた安全なライブラリをAIを使って構築する？) 30
31. 各レイヤでやれること • 各レイヤでやれること・考えたいことがまだまだある ◦ ポリシーを作る組織 (OpenSSF, NIST, 政府系機関？) ▪ 基準の構築 ◦ プラットフォーム企業(GitHub, GitLab, パッケージ管理組織など) ▪ 仕組みの提供 ◦ セキュリティベンダ(Flatt, Chainguard, etc) ▪ 仕組みの提供 • 安全なコンテナイメージの提供 • パッケージの安全な構築 ▪ 専門知識の提供 • 訓練 • 対策 ◦ 各対策をする組織 ▪ 自動化 ▪ 対策のためのAI Skillの提供からでも 31
32. 僕らがいる場所 • アイデアが出尽くしたような、成熟しきった状況ではない • Cooldownもつい最近。まだ対応していないパッケージ管理ツールもある • 誰かが問いを立てる → 対策が生まれる → 広がる → 別の誰かが次を出す ◦ うまくいくか分からない。それでも始める ▪ 考えることがたくさんある • 「Cooldown対策は本質か？」 ◦ 「AIにより脆弱性発見が早くなったとき、Cooldownだけではだめ で、セキュリティパッチに限ってすぐに展開する仕組みも必要で は？」 ◦ → これから基準が生まれていく。 ◦ 被害に寄り添う視点をもちつつ、少し離れた場所にたって、無邪気に謎解きをする 視点も持つ ▪ まだまだ枯れていない興味深い領域。全員でポジティブに考えていきましょう 32
33. まとめ 33 • 攻撃の現状 ◦ 依存性を経由した侵害は連鎖 ◦ 直接的な狙いは認証情報の窃取。標的型ではなくバラマキ型 • 生まれてきた対策 ◦ SLSA・Sigstore・OIDC・Cooldownなど、予防の手段はこの数年で揃ってきた(入 口を防ぐ / 認証情報を守る / 出口側) • まだ欠けているもの ◦ 対策は「点」では増えたが、まだ「線」になっていない: 統制する手段も少ない ◦ 特に CI/CDパイプラインは、監視・調査の手段が乏しく、「発見 → 調査 → 修正」 のライフサイクルを作れない • これからのこと ◦ プラットフォーム、ベンダ、各組織など、各レイヤで考えることが多い ◦ まだ発展途上の領域で、やれることは多い。ポジティブに頑張っていきましょう
34. Special Thanks 34 • 壁打ち相手 ◦ GMO Flatt Security: Takashi Yoneuchi ◦ Mitsuaki (Mitch) Shiraishi