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

Embed

Start on current slide

Slide 1

Slide 1 text

セキュリティの専門家じゃなくてもできる。「セキュリティ意識」をアップデートしてサプライチェーン攻撃への耐性を高めよう。 2026.06.09 サプライチェーン攻撃にどう向き合う？今こそ見直す、リスクとの向き合い方 Hiroki Takatsuka (@tk3fftk)

Slide 2

Slide 2 text

Hiroki Takatsuka @tk3fftk primeNumber (2022 〜 ) • TROCCO / COMETA SRE, Engineering Manager • Security Team ⽴ち上げ → 兼務メンバー • Corporate SRE ⽴ち上げ最近はFinOpsなどもヤフー株式会社 (2016 〜 2022) • CI/CD プラットフォーム Screwdriver.cd の SRE, Engineering Manager 猫はアルくんです、かわいいですね。

Slide 3

Slide 3 text

会社概要 3 株式会社primeNumber 代表取締役CEO 田邊雄樹 2015年11月約120名約34億円東京都品川区上大崎 3丁目1番1号 JR東急目黒ビル5F 会社名代表創業メンバー数累計調達額オフィス © primeNumber Inc.

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

AGENDA 6 1. なぜセキュリティ意識を高めるべきか 2. セキュリティ意識をどのように高めるか 3. すぐできる/検討するとよい対策 4. まとめ

Slide 7

Slide 7 text

7 なぜセキュリティ意識を高めるべきか

Slide 8

Slide 8 text

8 リスクってなんだろう

Slide 9

Slide 9 text

9 ● 「weblio英和辞典 (risk)」 ○ (危険・不利などを受けるかもしれない)危険，恐れ ● 「デジタル大辞泉」 ○ 危険の生じる可能性。危険度。また、結果を予測できる度合い。予想通りにいかない可能性。 ● 「熊とワルツを - リスクを愉しむプロジェクト管理」 ○ 1. 将来起こりうる出来事で、望まない結果を生むもの。 (原因) ○ 2. 望まない結果そのもの。 (結果) リスクってなんだろう〜色々な定義〜

Slide 10

Slide 10 text

10 リスクってなんだろう〜色々な定義〜 ● 「weblio英和辞典 (risk)」 ○ (危険・不利などを受けるかもしれない)危険，恐れ ● 「デジタル大辞泉」 ○ 危険の生じる可能性。危険度。また、結果を予測できる度合い。予想通りにいかない可能性。 ● 「熊とワルツを - リスクを愉しむプロジェクト管理」 ○ 1. 将来起こりうる出来事で、望まない結果を生むもの。 (原因) ○ 2. 望まない結果そのもの。 (結果) リスクとは、必ず起きるものではないらしい (実現する/しないの確率が存在する)

Slide 11

Slide 11 text

11 リスクってなんだろう〜色々な定義〜リスクとは、大小があるものらしい (危険>不利≧予想通りにいかない) ● 「weblio英和辞典 (risk)」 ○ (危険・不利などを受けるかもしれない)危険，恐れ ● 「デジタル大辞泉」 ○ 危険の生じる可能性。危険度。また、結果を予測できる度合い。予想通りにいかない可能性。 ● 「熊とワルツを - リスクを愉しむプロジェクト管理」 ○ 1. 将来起こりうる出来事で、望まない結果を生むもの。 (原因) ○ 2. 望まない結果そのもの。 (結果)

Slide 12

Slide 12 text

12 サプライチェーン攻撃のリスクが漠然と不安になる理由を考えてみる ● リスクの実現確率が読みにくいこと ○ 語弊を恐れずに言うと交通事故や通り魔に遭うような感覚に近いのでは ○ AIによる不確実性も読みにくさを加速させている ■ 動いてるものや利用しているパッケージを完全に把握できていないケースが増えてきている (そもそも依存完全把握はムズいが) ■ 非エンジニアのAI利用、vibe codingの拡大 ● リスクが実現した際の被害の大きさが読みにくいこと ○ 万が一攻撃を食らったらどこまで何が盗られるのか？ ○ 自分だけでなく自分が攻撃の踏み台として利用されるのでは？ 👉 解像度を上げるために「セキュリティ意識」を高めよう！

Slide 13

Slide 13 text

13 知識を高めるのは難しい(険しい)が、意識なら今から変えられる ● セキュリティに限らず、専門知識を高めるのは険しい道のり ○ 他に学ぶべきこと・やりたいことが大量にある世の中 ○ (とはいえ、そうも言ってられない状況な気もしつつ…) ● 攻撃手法の詳細まで踏み込めなくても「意識を高める」ことで守れる部分がある ○ ⚠ もちろん、詳細を知っていた方が間違いなくプラスではある ● 高塚自身もセキュリティの専門家ではなく意識が高いだけ ○ それでもこうやって登壇の機会をいただく程度にはやっていけている

Slide 14

Slide 14 text

セキュリティ意識を高めるとは情報収集の習慣をつけるセキュリティ動向や脆弱性情報に触れられる状態を維持するリスク管理の思考の習慣をつける収集した情報が自分たちにどう影響するかを考える習慣をつけるリスクマネジメント具体と抽象の往復自分たちの現在地を把握する「何が発生すると自分たちは困るのか？」を知っておく脅威モデリング(的な考え方) すぐやるコスト低く対応可能な対策は速やかに実施する多層防御 (的な考え方) 14

Slide 15

Slide 15 text

15 セキュリティ意識をどのように高めるか

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 普段扱っている情報(データ)を理解・意識しておく ● 本番環境(アプリケーション)のデータ ○ DBに何が入ってる？個人情報は？ ○ クレデンシャルはどこで何を管理している？ ● 開発環境のデータ ○ 弊社のソースコードって、漏れるとどこまでまずいんだっけ？ ○ 開発環境の本番のデータとか入ってないよね？ ○ GitHubに個人情報とか乗せてないよね？ ● ローカルマシンにあるデータ ○ 環境変数とか.envみたいなのって何が入っている？ ○ AWSのアクキーとかってある？

Slide 18

Slide 18 text

18 脅威モデリングの考え方を取り入れる (⚠あくまで考え方) 脅威モデリングの考え方を「自分の家をどう守るか」という例で説明してみる脅威モデリングの問い家にたとえると 01 何を守るのか？ → 大切なものはどこ？現金・通帳・思い出の品が、家のどこにあるか 02 何が起きると困る？ → 起こりうることを想像空き巣・なくし物・火事…どこから入られる？ 03 どう備えるか？ → できる備えをする鍵をかける・金庫に入れる・保険に入る 04 ちゃんとできた？ → 見落としはない？裏口や窓も大丈夫か、鍵は閉め忘れていないか

Slide 19

Slide 19 text

Slide 20

Slide 20 text

20 ● 「問題が発生する前の抽象的な概念の段階で対策を考えるプロセス」 ● リスクは発生するまで抽象的な概念にすぎない ○ 無視しても大丈夫なこともある ■ ⚠リスクを考えなかったという管理上の過失については責任を免れられない ○ 実現し、実際の問題になることで具体化する (リスク移行) ● リスク管理は大抵の人が日常で実践している ○ 保険に入る、一本早い電車に乗る、生牡蠣は食べない… リスク管理とは

Slide 21

Slide 21 text

21 ● リスク管理の活動 a. 思いつく限りのリスクを考えぬき、検討を継続すべきリスクを選別 b. リスクが実現した場合の影響の大小、リスクの実現率を検討する c. リスクが実現した場合に、何をすべきか計画しておく d. リスクが実現した場合の影響を小さくする、または実現率を低くする対策を実施する e. リスクを追跡、実現しないかどうかを監視する ● すべてのリスクに対して対策をすることは現実的ではない ● 見えないふりをして影響がないことを祈るのも違うのは明らか 👉 この2点の間のどこかにスタンスを取るリスク管理をしよう

Slide 22

Slide 22 text

22 ● 定義: リスクは抽象的なもの ● リスク軽減の対策を考えるには具体と抽象の往復が必要 ● 具体と抽象とは別軸で、想像力を働かせ視座を上げることも必要具体と抽象の往復リスク抽象サプライチェーン攻撃具体サプライチェーンリスク軽減対策具体サプライチェーン攻撃によるリスク抽象(やや具体)

Slide 23

Slide 23 text

23 例えば「axiosで侵害があった」というケースを考えてみる抽象度 axiosで侵害視座を上げる組織内に波及? 抽象化 npm侵害の構造抽象化外部モジュール導入リスク具体横展開 AIツール利用で混入率↑ 自分ができる行動は？具体 axiosに依存しているライブラリも侵害されている可能性がある社内でもaxiosを使っている axiosだけでなくnpmのエコシステム全体への波及があるのでは「検証せずに外部のモジュールを導入すること全般のリスク」とも言えるのでは具体非エンジニアもAIツールを使い開発をすることがある。エンジニアだけの問題ではなくなっているのではないか？ -> 対応を実施

Slide 24

Slide 24 text

Slide 25

Slide 25 text

25 情報源を持っておく・コミュニティに参加する勝手に宣伝 && 高塚がこのあたりから情報を得ることが多いよという話 ● コミュニティ/ Slack ○ CloudSec JP ■ 国内のクラウドセキュリティに関わるエンジニア有志によるベンダーニュートラルなコミュニティ ○ 情シスSlack ■ 約17,000名超が参加する情シスのためのSlackコミュニティ ○ Cyber-sec+ ■ サイバーセキュリティに特化したオンラインコミュニケーションスペース

Slide 26

Slide 26 text

26 情報源を持っておく・X (Twitter)/Podcast 勝手に宣伝 && 高塚がこのあたりから情報を得ることが多いよという話 ● X (Twitter) (敬称略) ○ GMO Flatt Security株式会社 (@flatt_security) ○ Socket (@SocketSecurity) ○ YONEUCHI, Takashi (@y0n3uchy) ○ yousukezan (@yousukezan) ○ Hazy (@kawada_syogo225) ○ piyokango (@piyokango) ● Podcast ○ #セキュリティのアレ

Slide 27

Slide 27 text

27 すぐできる/検討するとよい対策サプライチェーン攻撃対策の社内展開したやつの抜粋(SHA pinning必須化/min-release-age/Takumi Guard) + α

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 ⚠ 注意点 ● ここにある対策を全てやったからといって、必ず守れるわけではない ○ 多層防御的に様々な方面に様々な手段でやれることをやっておく ● 個人でやるよりは組織で、気合でやるよりは仕組みで制限すると尚良

Slide 30

Slide 30 text

30 ● 公開から一定期間経過していないパッケージのinstallを防ぐ設定 ● 悪意あるパッケージやActionが発見・削除されるまでの時間的バッファを確保する目的 ○ ⚠あくまで遅延させるだけなので、発見・削除されなければ意味はない ○ ⚠更新を遅らせるので逆に脆弱性の対応を遅らせてしまう可能性もある ● npmの設定例 ○ .npmrc で min-release-age を設定 min-release-age=7 ○ またはコマンドで設定 npm config set min-release-age=7 --location=project Dependency cooldown

Slide 31

Slide 31 text

31 GMO Flatt Securityが基本利用無料で提供しているセキュリティツール Takumi Guard (Takumi byGMO) Guard機能 - Takumi byGMO | GMO Flatt Security より

Slide 32

Slide 32 text

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) の機能

Slide 33

Slide 33 text

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系エディタの拡張棚卸し + 自動更新停止

Slide 34

Slide 34 text

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系エディタの拡張の中央管理はたいへん

Slide 35

Slide 35 text

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より

Slide 36

Slide 36 text

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 がなぜ必要か

Slide 37

Slide 37 text

37 ● GitHub Actionsで外部のActionを利用する場合、v1などのタグ指定ではなく SHA(commit hash)でバージョンを固定することを強制する設定 ● チェックボックスをクリックして有効化するだけなので入れるだけなら簡単 ○ Organization or Repository Levelで設定できる ● 利用しているActionやReusable Workflowが依存しているActionも対象 ○ Actionは「依存の依存がわからない」問題がある ■ Actionのサプライチェーンを可視化する手段は提供されていない ■ 実行時にしか弾いてくれない GitHub Actions SHA pinning enforcement

Slide 38

Slide 38 text

38 tk3fftk/check-actions-sha-pinning 利用GitHub Actionsとその依存ActionがSHA pinningされているか確認するスクリプト FYI: SHA pinning enforcement のためのヘルパースクリプト

Slide 39

Slide 39 text

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機能もロードマップにはある

Slide 40

Slide 40 text

40 Docker Hardened Image (DHI) ● Docker が提供する「最小構成・セキュア・本番向け」のコンテナイメージ ○ docker pull dhi.io/node:26-alpine みたいに使える (要 docker login) ● ほぼ既知のCVEゼロを目指して保守 ● 有償プランだとSLAやサポートが付く

Slide 41

Slide 41 text

41 まとめ

Slide 42

Slide 42 text

42 ● リスクは抽象、インシデントや軽減策は具体 ○ 具体と抽象の往復が必要 ● まとめ: 意識を上げればサプライチェーン攻撃への耐性は高められる

Slide 43

Slide 43 text

43 ● 熊とワルツを - リスクを愉しむプロジェクト管理 ● 「具体⇔抽象」トレーニング思考力が飛躍的にアップする29問 ● サプライチェーン攻撃対策の社内展開したやつの抜粋(SHA pinning 必須化/min-release-age/Takumi Guard) ● Takumi Guardと近しい機能を持っているツール ○ AikidoSec/safe-chain ○ SocketDev/sfw-free 参考資料

Slide 44

Slide 44 text

44 宣伝: TROCCO、無料トライアル + フリープランあります！

Slide 45

Slide 45 text

45 宣伝: 関西のSREコミュニティを立ち上げました！関西の方なにとぞ！SREじゃなくてもウェルカムです！！！初回は6/25にはてなさんオフィスでやるよ〜

Slide 46

Slide 46 text

46 おしまい EOP