サプライチェーンセキュリティの空白地帯 信頼できる”依存性”の未来を考える @Product Security Square #4 | GMO Flatt Security 2026年6月4日 @rung 

自己紹介 ● 専門 ○ 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 

今日伝えたいこと ここ最近、厳しい話も多い ● メインテーマ ○ 「まだ答えがない」状況だからこそポジティブにやっていこう ● 扱うこと ○ CI/CD・サプライチェーンセキュリティの現在地を、少し広い視点から見る ● 扱わないこと ○ 個別の対策 (設定手順や特定ツールの使い方) 4 

5 1. 最近の状況の振り返り 

サプライチェーンセキュリティ？ ● ここ最近の状況（GMO Flatt Security関連） 6 GMO Flatt Securityの関連ページ 

依存性を経由した侵害の連鎖 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 依存 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 侵害される供給元: 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 ● 最終ゴールは不明 ○ 認証情報を取ってから決めてる？ ○ 特定のターゲットへの侵害 ? 

なぜ大きな問題に？ ● なぜ大きな問題になっているのか？ ○ オープンソース→オープンソースへの横展開（去年から話題。3月から加速） ■ 盗んだ secret で次のpublish権限を奪い、増殖する ○ まだ「ベストプラクティス」が完全に確立していない ■ 対策も、「一人ひとりが頑張るセキュリティ」の状態 ● Secure by default(デフォルト状態でセキュア)ではない ● 組織においては、対策ができていることの統制をするのが難しい ○ 取られる権限が非常に大きい ■ プロダクションに関わる権限をとられうる ● 開発者の端末: ○ Cookie, クラウド環境クレデンシャル, etc ● CI/CD 環境: ○ そのまま本番環境の権限相当 ○ GitHubのレポジトリを利用する権限 ○ （AI利用による）攻撃スピードの上昇 10 

依存性を狙った攻撃の特徴 ● 基本的に、標的型攻撃（特定組織だけをピンポイントで狙った攻撃）ではない ○ 特定のツール・ライブラリに依存している組織全体に影響が出る ○ 改変されたソフトウェアが一般に公開される。基本的にはマルウェアが特定の組織 だけではなく、全体にばらまかれる ● 高度な攻撃が行われている？ ○ どちらかというと、「効率的に狙える高権限の環境を見つけられた」という印象 ○ 高度な攻撃というよりは、対策が定まっていないエリアを狙った攻撃 ■ これからも更に増えるかも 11 

12 2. 生まれてきた対策 

生まれてきた対策 ● ここ5年でいろいろな対策が生み出されてきた ○ SLSA ■ 安全なソフトウェア作成の基準づくり ○ Sigstore ■ 署名 ■ 生成元の保証 ○ SBOM ■ 依存性記載の標準化 ○ CI/CDパイプラインでのOIDC認証 ■ 長期鍵から一時鍵(Keylessとも)への変更 ○ 依存性アップデートのCooldown期間の導入 ■ ソフトウェアアップデートを、公開されて○日経ってから行う 13 

（参考）SLSA 14 https://slsa.dev/ 

生まれてきた対策: 入口 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 侵害される供給元: 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 侵害される供給元: 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 3. まだ欠けているもの 

まだ欠けているもの ● 点としての対策は生まれてきたが、まだ線になっていない状態・・・ ○ どの対策も、存在はしているが徹底が難しいという状況 ○ 各レポジトリで考えないといけない対策も多すぎる ○ さらに・・・ 19 

欠けているもの: 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 侵害される供給元: 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 

絶望的？ ● 被害は続いているが、絶望する必要はない ○ そもそも・・・ ■ コンピュータやインターネットの土台は、安全を前提にせず作られた ● 平文の HTTP ○ TLS化が進んだのは過去10年(2013年のスノーデン事件以降) ● 認証もPasskeyの時代へ ○ たくさんの被害ののち、生まれてきた ○ （被害の後）証券会社がPasskey必須化に取り組むように ■ まだ直っていないものもある ● オンプレADは、いまだに標的型攻撃・レッドチームの主戦場 ○ サプライチェーンセキュリティも、単にまだ整ってない状況の一つ ■ ポジティブに考えると、これから直すべきことがたくさんあるフロンティア 23 

24 4. これからのこと 

サプライチェーンセキュリティの現状 ● いろいろなものが生まれているがまだ点が線になっていない状況 ○ Secure by defaultではない ● 色々なプレイヤーが今も色々なことを考えている 25 

GMO Flatt Security ● Takumi Guard ○ 悪性パッケージの自動ブロック ● Takumi Runner ○ CI/CD実行トレースの可視化 ● ソフトウェアサプライチェーン診断 ● ソフトウェアサプライチェーン攻撃演習 26 

GitHub（公開情報より） ● What’s coming to our GitHub Actions 2026 security roadmap ○ Actions Data StreamをS3やAzure Event Hubに流せるようになるらしい ○ 外向きの通信制限をかけられるようになるらしい 27 

今年の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 

@rungも個人的に・・・ ● cicd-sensor ○ GitHub Actions, GitLab CI/CD向けのオープンソースEDR ■ (eBPFを使ったランタイムセキュリティツール) ○ CI/CDセキュリティの専門家にレビューしてもらいつつ開発中 ○ https://github.com/cicd-sensor/cicd-sensor ■ 現在Pre-release状態。試してフィードバックをください ● なにかあっても検知できない・あとからログで事象を追えない状況は解決しなければなら ない ● 将来的には、ビルド中の通信や挙動も検証可能になると嬉しい(Build attestation) 29 

Chainguard ● The hardest fork (May 28, 2026) ○ Mythosなどの文脈: いくつか結果を見たが脅威は現実 ○ 現状のオープンソース消費モデルは対応できない ■ 新しい信頼インフラを作る: 何千ものプロジェクトをフォークし、維持し、配 布するインフラを構築するアイデア ● (パッチも含めた安全なライブラリをAIを使って構築する？) 30 

各レイヤでやれること ● 各レイヤでやれること・考えたいことがまだまだある ○ ポリシーを作る組織 (OpenSSF, NIST, 政府系機関？) ■ 基準の構築 ○ プラットフォーム企業(GitHub, GitLab, パッケージ管理組織など) ■ 仕組みの提供 ○ セキュリティベンダ(Flatt, Chainguard, etc) ■ 仕組みの提供 ● 安全なコンテナイメージの提供 ● パッケージの安全な構築 ■ 専門知識の提供 ● 訓練 ● 対策 ○ 各対策をする組織 ■ 自動化 ■ 対策のためのAI Skillの提供からでも 31 

僕らがいる場所 ● アイデアが出尽くしたような、成熟しきった状況ではない ● Cooldownもつい最近。まだ対応していないパッケージ管理ツールもある ● 誰かが問いを立てる → 対策が生まれる → 広がる → 別の誰かが次を出す ○ うまくいくか分からない。それでも始める ■ 考えることがたくさんある ● 「Cooldown対策は本質か？」 ○ 「AIにより脆弱性発見が早くなったとき、Cooldownだけではだめ で、セキュリティパッチに限ってすぐに展開する仕組みも必要で は？」 ○ → これから基準が生まれていく。 ○ 被害に寄り添う視点をもちつつ、少し離れた場所にたって、無邪気に謎解きをする 視点も持つ ■ まだまだ枯れていない興味深い領域。全員でポジティブに考えていきましょう 32 

まとめ 33 ● 攻撃の現状 ○ 依存性を経由した侵害は連鎖 ○ 直接的な狙いは認証情報の窃取。標的型ではなくバラマキ型 ● 生まれてきた対策 ○ SLSA・Sigstore・OIDC・Cooldownなど、予防の手段はこの数年で揃ってきた(入 口を防ぐ / 認証情報を守る / 出口側) ● まだ欠けているもの ○ 対策は「点」では増えたが、まだ「線」になっていない: 統制する手段も少ない ○ 特に CI/CDパイプラインは、監視・調査の手段が乏しく、「発見 → 調査 → 修正」 のライフサイクルを作れない ● これからのこと ○ プラットフォーム、ベンダ、各組織など、各レイヤで考えることが多い ○ まだ発展途上の領域で、やれることは多い。ポジティブに頑張っていきましょう 

Special Thanks 34 ● 壁打ち相手 ○ GMO Flatt Security: Takashi Yoneuchi ○ Mitsuaki (Mitch) Shiraishi