セキュリティの専門家じゃなくてもできる。「セキュリティ意識」をアップデートして サプライチェーン攻撃への耐性を高めよう。

サプライチェーン攻撃 にどう向き合う？~今こそ見直す、リスクとの向き合い方~ - connpass
https://findy.connpass.com/event/392431/

Transcript

1. セキュリティの専門家じゃなくてもできる。 「セキュリティ意識」をアップデートして サプライチェーン攻撃への耐性を高めよう。 2026.06.09 サプライチェーン攻撃にどう向き合う？ 今こそ見直す、リスクとの向き合い方 Hiroki Takatsuka (@tk3fftk)
2. Hiroki Takatsuka @tk3fftk primeNumber (2022 〜 ) • TROCCO / COMETA SRE, Engineering Manager • Security Team ⽴ち上げ → 兼務メンバー • Corporate SRE ⽴ち上げ 最近はFinOpsなども ヤフー株式会社 (2016 〜 2022) • CI/CD プラットフォーム Screwdriver.cd の SRE, Engineering Manager 猫はアルくんです、かわいいですね。
3. 会社概要 3 株式会社primeNumber 代表取締役CEO 田邊 雄樹 2015年11月 約120名 約34億円 東京都品川区上大崎 3丁目1番1号 JR東急目黒ビル5F 会社名 代表 創業 メンバー数 累計調達額 オフィス © primeNumber Inc.
5. © primeNumber Inc. 5 TROCCO/COMETAについて TROCCO:「データ統合」を軸にデータ基盤の構築や運用を支援 COMETA: AIを軸にデータの発見/理解/活用を促進するデータカタログ データをビジネスに活用するまでのステップ
6. AGENDA 6 1. なぜセキュリティ意識を高めるべきか 2. セキュリティ意識をどのように高めるか 3. すぐできる/検討するとよい対策 4. まとめ
7. 7 なぜセキュリティ意識を高めるべきか
8. 8 リスクってなんだろう
9. 9 • 「weblio英和辞典 (risk)」 ◦ (危険・不利などを受けるかもしれない)危険，恐れ • 「デジタル大辞泉」 ◦ 危険の生じる可能性。危険度。また、結果を予測できる度合い。 予想通りにいかない可能性。 • 「熊とワルツを - リスクを愉しむプロジェクト管理」 ◦ 1. 将来起こりうる出来事で、望まない結果を生むもの。 (原因) ◦ 2. 望まない結果そのもの。 (結果) リスクってなんだろう 〜色々な定義〜
10. 10 リスクってなんだろう 〜色々な定義〜 • 「weblio英和辞典 (risk)」 ◦ (危険・不利などを受けるかもしれない)危険，恐れ • 「デジタル大辞泉」 ◦ 危険の生じる可能性。危険度。また、結果を予測できる度合い。 予想通りにいかない可能性。 • 「熊とワルツを - リスクを愉しむプロジェクト管理」 ◦ 1. 将来起こりうる出来事で、望まない結果を生むもの。 (原因) ◦ 2. 望まない結果そのもの。 (結果) リスクとは、必ず起きるものではないらしい (実現する/しないの確率が存在する)
11. 11 リスクってなんだろう 〜色々な定義〜 リスクとは、大小があるものらしい (危険>不利≧予想通りにいかない) • 「weblio英和辞典 (risk)」 ◦ (危険・不利などを受けるかもしれない)危険，恐れ • 「デジタル大辞泉」 ◦ 危険の生じる可能性。危険度。また、結果を予測できる度合い。 予想通りにいかない可能性。 • 「熊とワルツを - リスクを愉しむプロジェクト管理」 ◦ 1. 将来起こりうる出来事で、望まない結果を生むもの。 (原因) ◦ 2. 望まない結果そのもの。 (結果)
12. 12 サプライチェーン攻撃のリスクが漠然と不安になる理由を考えてみる • リスクの実現確率が読みにくいこと ◦ 語弊を恐れずに言うと交通事故や通り魔に遭うような感覚に近いのでは ◦ AIによる不確実性も読みにくさを加速させている ▪ 動いてるものや利用しているパッケージを完全に把握できていないケース が増えてきている (そもそも依存完全把握はムズいが) ▪ 非エンジニアのAI利用、vibe codingの拡大 • リスクが実現した際の被害の大きさが読みにくいこと ◦ 万が一攻撃を食らったらどこまで何が盗られるのか？ ◦ 自分だけでなく自分が攻撃の踏み台として利用されるのでは？ 👉 解像度を上げるために「セキュリティ意識」を高めよう！
13. 13 知識を高めるのは難しい(険しい)が、意識なら今から変えられる • セキュリティに限らず、専門知識を高めるのは険しい道のり ◦ 他に学ぶべきこと・やりたいことが大量にある世の中 ◦ (とはいえ、そうも言ってられない状況な気もしつつ…) • 攻撃手法の詳細まで踏み込めなくても「意識を高める」ことで守れる 部分がある ◦ ⚠ もちろん、詳細を知っていた方が間違いなくプラスではある • 高塚自身もセキュリティの専門家ではなく意識が高いだけ ◦ それでもこうやって登壇の機会をいただく程度にはやっていけている
14. セキュリティ意識を高めるとは 情報収集の習慣をつける セキュリティ動向や脆弱性情報に触れ られる状態を維持する リスク管理の思考の習慣をつける 収集した情報が自分たちにどう影響す るかを考える習慣をつける リスクマネジメント 具体と抽象の往復 自分たちの現在地を把握する 「何が発生すると自分たちは困るの か？」を知っておく 脅威モデリング(的な考え方) すぐやる コスト低く対応可能な対策は速やかに 実施する 多層防御 (的な考え方) 14
15. 15 セキュリティ意識をどのように高めるか
16. セキュリティ意識を高めるとは 情報収集の習慣をつける セキュリティ動向や脆弱性情報に触れ られる状態を維持する リスク管理の思考の習慣をつける 収集した情報が自分たちにどう影響す るかを考える習慣をつける リスクマネジメント 具体と抽象の往復 自分たちの現在地を把握する 「何が発生すると自分たちは困るの か？」を知っておく 脅威モデリング(的な考え方) すぐやる コスト低く対応可能な対策は速やかに 実施する 多層防御 (的な考え方) 16
17. 17 普段扱っている情報(データ)を理解・意識しておく • 本番環境(アプリケーション)のデータ ◦ DBに何が入ってる？個人情報は？ ◦ クレデンシャルはどこで何を管理している？ • 開発環境のデータ ◦ 弊社のソースコードって、漏れるとどこまでまずいんだっけ？ ◦ 開発環境の本番のデータとか入ってないよね？ ◦ GitHubに個人情報とか乗せてないよね？ • ローカルマシンにあるデータ ◦ 環境変数とか.envみたいなのって何が入っている？ ◦ AWSのアクキーとかってある？
18. 18 脅威モデリングの考え方を取り入れる (⚠あくまで考え方) 脅威モデリングの考え方を「自分の家をどう守るか」という例で説明してみる 脅威モデリングの問い 家にたとえると 01 何を守るのか？ → 大切なものはどこ？ 現金・通帳・思い出の品が、家のどこにあるか 02 何が起きると困る？ → 起こりうることを想像 空き巣・なくし物・火事…どこから入られる？ 03 どう備えるか？ → できる備えをする 鍵をかける・金庫に入れる・保険に入る 04 ちゃんとできた？ → 見落としはない？ 裏口や窓も大丈夫か、鍵は閉め忘れていないか
19. セキュリティ意識を高めるとは 情報収集の習慣をつける セキュリティ動向や脆弱性情報に触れ られる状態を維持する リスク管理の思考の習慣をつける 収集した情報が自分たちにどう影響す るかを考える習慣をつける リスクマネジメント 具体と抽象の往復 自分たちの現在地を把握する 「何が発生すると自分たちは困るの か？」を知っておく 脅威モデリング(的な考え方) すぐやる コスト低く対応可能な対策は速やかに 実施する 多層防御 (的な考え方) 19
20. 20 • 「問題が発生する前の抽象的な概念の段階で対策を考えるプロセス」 • リスクは発生するまで抽象的な概念にすぎない ◦ 無視しても大丈夫なこともある ▪ ⚠リスクを考えなかったという管理上の過失については責任を免れられない ◦ 実現し、実際の問題になることで具体化する (リスク移行) • リスク管理は大抵の人が日常で実践している ◦ 保険に入る、一本早い電車に乗る、生牡蠣は食べない… リスク管理とは
21. 21 • リスク管理の活動 a. 思いつく限りのリスクを考えぬき、検討を継続すべきリスクを選別 b. リスクが実現した場合の影響の大小、リスクの実現率を検討する c. リスクが実現した場合に、何をすべきか計画しておく d. リスクが実現した場合の影響を小さくする、または実現率を低くする対 策を実施する e. リスクを追跡、実現しないかどうかを監視する • すべてのリスクに対して対策をすることは現実的ではない • 見えないふりをして影響がないことを祈るのも違うのは明らか 👉 この2点の間のどこかにスタンスを取る リスク管理をしよう
22. 22 • 定義: リスクは抽象的なもの • リスク軽減の対策を考えるには具体と抽象の往復が必要 • 具体と抽象とは別軸で、想像力を働かせ視座を上げることも必要 具体と抽象の往復 リスク 抽象 サプライチェーン攻撃 具体 サプライチェーン リスク軽減対策 具体 サプライチェーン攻撃 によるリスク 抽象(やや具体)
23. 23 例えば「axiosで侵害があった」というケースを考えてみる 抽 象 度 axiosで侵害 視座を上げる 組織内に波及? 抽象化 npm侵害の構造 抽象化 外部モジュール 導入リスク 具体 横展開 AIツール利用で 混入率↑ 自分ができる 行動は？ 具体 axiosに依存しているライブラリも 侵害されている可能性がある 社内でもaxiosを使っている axiosだけでなくnpmのエコシステム 全体への波及があるのでは 「検証せずに外部のモジュールを導入するこ と全般のリスク」とも言えるのでは 具体 非エンジニアもAIツールを使い 開発をすることがある。 エンジニアだけの問題ではなく なっているのではないか？ -> 対応を実施
24. セキュリティ意識を高めるとは 情報収集の習慣をつける セキュリティ動向や脆弱性情報に触れ られる状態を維持する リスク管理の思考の習慣をつける 収集した情報が自分たちにどう影響す るかを考える習慣をつける リスクマネジメント 具体と抽象の往復 自分たちの現在地を把握する 「何が発生すると自分たちは困るの か？」を知っておく 脅威モデリング(的な考え方) すぐやる コスト低く対応可能な対策は速やかに 実施する 多層防御 (的な考え方) 24
25. 25 情報源を持っておく・コミュニティに参加する 勝手に宣伝 && 高塚がこのあたりから情報を得ることが多いよという話 • コミュニティ/ Slack ◦ CloudSec JP ▪ 国内のクラウドセキュリティに関わるエンジニア有志によるベンダー ニュートラルなコミュニティ ◦ 情シスSlack ▪ 約17,000名超が参加する情シスのためのSlackコミュニティ ◦ Cyber-sec+ ▪ サイバーセキュリティに特化したオンラインコミュニケーションスペース
26. 26 情報源を持っておく・X (Twitter)/Podcast 勝手に宣伝 && 高塚がこのあたりから情報を得ることが多いよという話 • X (Twitter) (敬称略) ◦ GMO Flatt Security株式会社 (@flatt_security) ◦ Socket (@SocketSecurity) ◦ YONEUCHI, Takashi (@y0n3uchy) ◦ yousukezan (@yousukezan) ◦ Hazy (@kawada_syogo225) ◦ piyokango (@piyokango) • Podcast ◦ #セキュリティのアレ
27. 27 すぐできる/検討するとよい対策 サプライチェーン攻撃対策の社内展開したやつの抜粋(SHA pinning必須化/min-release-age/Takumi Guard) + α
28. セキュリティ意識を高めるとは 情報収集の習慣をつける セキュリティ動向や脆弱性情報に触れ られる状態を維持する リスク管理の思考の習慣をつける 収集した情報が自分たちにどう影響す るかを考える習慣をつける リスクマネジメント 具体と抽象の往復 自分たちの現在地を把握する 「何が発生すると自分たちは困るの か？」を知っておく 脅威モデリング(的な考え方) すぐやる コスト低く対応可能な対策は速やかに 実施する 多層防御 (的な考え方) 28
29. 29 ⚠ 注意点 • ここにある対策を全てやったからといって、必ず守れるわけではない ◦ 多層防御的に様々な方面に様々な手段でやれることをやっておく • 個人でやるよりは組織で、気合でやるよりは仕組みで制限すると尚良
30. 30 • 公開から一定期間経過していないパッケージのinstallを防ぐ設定 • 悪意あるパッケージやActionが発見・削除されるまでの時間的バッ ファを確保する目的 ◦ ⚠あくまで遅延させるだけなので、発見・削除されなければ意味はない ◦ ⚠更新を遅らせるので逆に脆弱性の対応を遅らせてしまう可能性もある • npmの設定例 ◦ .npmrc で min-release-age を設定 min-release-age=7 ◦ またはコマンドで設定 npm config set min-release-age=7 --location=project Dependency cooldown
31. 31 GMO Flatt Securityが基本利用無料で提供しているセキュリティツール Takumi Guard (Takumi byGMO) Guard機能 - Takumi byGMO | GMO Flatt Security より
32. 32 • ほぼ「1行足すだけ」または「1コマンド実行するだけ」で導入可能 ◦ 例: npm config set registry https://npm.flatt.tech/ • 公開アドバイザリより速くカバレッジも高いパッケージブロック機能 • npm, PyPI, RubyGems, Goに対応、Packagistやcrates.ioも対応予定 ◦ PyPIなど一部パッケージマネージャーにはcooldownあり (ここから有償機能) • Takumi Guardを通じたインストールログの確認 • MDM等の管理ツールを組み合わせた一括セットアップへの対応 ◦ (弊社では絶賛ここに取組中です🐼) Takumi Guard (Takumi by GMO) の機能
33. 33 • 「自動更新で侵害された拡張機能が入ってきちゃった」を避けたい • 例: 侵害されたVSCode拡張によりGitHub社内reposが漏洩 (2026/05) ◦ Investigation update: GitHub Enterprise Server signing key rotation - The GitHub Blog ◦ 直接の対策ではないが「あのGitHubでも」起こるリスクという見方もできる • 使ってないものは消しておこう(もう使ってなければエディタごと) ◦ 一覧は code --list-extensions --show-versions でも見れる • “cmd + ,” → “autoupdate” で検索して設定変更 VSCode系エディタの拡張棚卸し + 自動更新停止
34. 34 • minimumReleaseAge的な設定を可能にする機能は議論中 ◦ Security: minimumReleaseAge setting for mitigating supply chain attacks on extensions · Issue #316867 ◦ Visual Studio Code 1.123から2時間のdelayが入るようにはなった • 現時点でも、allowlist方式でのポリシー管理は可能 ◦ Manage extensions in enterprise environments ◦ やるかどうかは組織規模と体制次第… • autoUpdateのポリシー設定的なissueは盛り上がってなさそう… ◦ extensions.autoUpdate setting should be group policy controlled · Issue #234543 FYI: VSCode系エディタの拡張の中央管理はたいへん
35. 35 • GitHub Actionsで外部のActionを利用する場合、v1などのタグ指定では なくSHA(commit hash)でバージョンを固定する • 固定はsuzuki-shunsuke/pinactやsuzuki-shunsuke/pinact-actionが便利 ◦ AIにやらせると間違ったSHAや古いのを持ってくるので個人的には非推奨 GitHub Actions SHA pinning GitHub - suzuki-shunsuke/pinact-action READMEより
36. 36 • GitHub Actionが侵害されるケースもある ◦ New GitHub Action supply chain attack: reviewdog/action-setup (2025/03) ◦ Popular GitHub Action tj-actions/changed-files is compromised (2025/03) ◦ 直接利用しているActionが侵害されていなくても、Actionが依存するActionが… • サプライチェーン攻撃とは別で「なにもしてないのに壊れました」 を避けるためにも固定しておくほうがよい👌 GitHub Actions SHA pinning がなぜ必要か
37. 37 • GitHub Actionsで外部のActionを利用する場合、v1などのタグ指定ではなく SHA(commit hash)でバージョンを固定することを強制する設定 • チェックボックスをクリックして有効化するだけなので入れるだけなら簡単 ◦ Organization or Repository Levelで設定できる • 利用しているActionやReusable Workflowが依存しているActionも対象 ◦ Actionは「依存の依存がわからない」問題がある ▪ Actionのサプライチェーンを可視化する手段は提供されていない ▪ 実行時にしか弾いてくれない GitHub Actions SHA pinning enforcement
38. 38 tk3fftk/check-actions-sha-pinning 利用GitHub Actionsとその依存ActionがSHA pinningされているか確認するスクリプト FYI: SHA pinning enforcement のためのヘルパースクリプト
39. 39 What's coming to our GitHub Actions 2026 security roadmap - The GitHub Blog > Think of it as Go’s go.mod + go.sum, but for your workflow with complete reproducibility and auditability. FYI: workflow-level dependency locking機能もロードマップにはある
40. 40 Docker Hardened Image (DHI) • Docker が提供する「最小構成・セキュア・本番向け」のコンテナイメージ ◦ docker pull dhi.io/node:26-alpine みたいに使える (要 docker login) • ほぼ既知のCVEゼロを目指して保守 • 有償プランだとSLAやサポートが付く
41. 41 まとめ
42. 42 • リスクは抽象、インシデントや軽減策は具体 ◦ 具体と抽象の往復が必要 • まとめ: 意識を上げればサプライチェーン攻撃への耐性は高められる
43. 43 • 熊とワルツを - リスクを愉しむプロジェクト管理 • 「具体⇔抽象」トレーニング 思考力が飛躍的にアップする29問 • サプライチェーン攻撃対策の社内展開したやつの抜粋(SHA pinning 必須化/min-release-age/Takumi Guard) • Takumi Guardと近しい機能を持っているツール ◦ AikidoSec/safe-chain ◦ SocketDev/sfw-free 参考資料
44. 44 宣伝: TROCCO、無料トライアル + フリープランあります！
45. 45 宣伝: 関西のSREコミュニティを立ち上げました！ 関西の方なにとぞ！SREじゃなくてもウェルカムです！！！ 初回は6/25にはてなさんオフィスでやるよ〜
46. 46 おしまい EOP