増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理 / Confronting the Rise of Vulnerabilities: Sustainable Management Through Proactive Measures and Prioritization

2025年7月24日のNIKKEI Tech Talkで発表した「増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理」の講演資料です。
講演詳細についてはこちらをご覧ください。 https://nikkei.connpass.com/event/357482/

Transcript

1. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理 2025年7月24日 NTTドコモビジネス株式会社 志村正樹
2. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 1 自己紹介 NTTドコモビジネス イノベーションセンターテクノロジー部門 志村正樹 (@mshim03) 業務内容 : ​ • 脅威インテリジェンスの分析・活用業務 • SBOM関連のソフトウェア開発 • 社内の技術検証NWのセキュリティ運用 • 部署のセキュリティマネジメント業務
3. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 2 本日のテーマ ソフトウェア開発における 脆弱性とその対応
4. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 3 脆弱性とは • ソフトウェアに存在するセキュリティ上の弱点のこと • バグ、構成ミスなどを含む • 本日は、依存先のソフトウェアなどで発見・公表される既知脆弱性にフォーカスを当てる • いわゆる「脆弱性がある依存関係」 • CVE (共通脆弱性識別子) などが付与され、情報が公開されるもの
5. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 4 ソフトウェア開発における脆弱性の例 利用する言語ライブラリの脆弱性 • 開発するソフトウェアに脆弱な依存が含まれる コンテナ・サーバなどの実行環境の脆弱性 • ソフトウェアを動かすためのコンテナのベースイメージに脆弱性がある • ソフトウェアを動かすサーバ環境に脆弱性がある 利用するコンポーネントの脆弱性 • DBなど、利用するコンポーネントに脆弱性がある
6. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 5 ソフトウェア開発の高度化と脆弱性 ソフトウェア開発の高度化に伴い、依存関係が増加 それに伴い脆弱性の影響を受ける箇所も増加。ビルドプロセスで利用するツールなども脆弱性の対象に Source Code Build Dependency Artifact Deployment
7. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 6 ソフトウェア開発の高度化と脆弱性 ソフトウェア開発の高度化に伴い、依存関係が増加 それに伴い脆弱性の影響を受ける箇所も増加。ビルドプロセスで利用するツールなども脆弱性の対象に Source Code Build Dependency Artifact Deployment 利用するパッケージの脆弱性 コンテナイメージの脆弱性 ビルド時に利用する ツールの脆弱性 利用コンポーネントの 脆弱性 (DBなど)
8. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 7 ビルドプロセスの脆弱性の例 GitHub Actionsなど、CICDで利用される外部ツールを狙った攻撃も増加しており、 これらの脆弱性も検知・対処する必要がある https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog- action-setup#which-actions-should-security-teams-take-17 GitHub Actions の reviewdog の脆弱性の例 (CVE-2025-30154) • reviewコメントを自動でコメントするGitHub Actionsである review dogが一時侵害され、 シークレット情報が一部漏洩する状態になっていた • tj-actions/changed-files という 別のGitHub Actionsの侵害にも繋がり、影響範囲が拡大
9. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 8 脆弱性対応の基本 ソフトウェアやCICDプロセスの脆弱性に対応するためには、脆弱性の検知と対処が必要 c 脆弱性を検知する 依存ソフトウェアの脆弱性を発見する c 脆弱性に対処する ソフトウェアのアップデートなど 脆弱性の影響を取り除く
10. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 9 c 脆弱性を検知する 依存ソフトウェアの脆弱性を発見する
11. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 10 脆弱性を検知する 脆弱な依存関係を発見するための要素は大きく分けて二つ 脆弱性情報の入手 脆弱性があるソフトウェア・バージョンの 情報を入手する 脆弱性のスキャン 脆弱性が存在するか調査する スキャンツールが数多くある
12. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 11 脆弱性情報の入手 脆弱性を発見するためには、発見された脆弱性に関する情報を収集する必要がある CVEによる脆弱性管理が広く使われているが、それ以外のエコシステムもある CVEを中心とした脆弱性情報 • CVE.org • NVD 独自のエコシステムによる脆弱性情報 • GitHub Advisory Database • JVN • 日本で使用されているソフトウェアの脆弱性情報 言語パッケージやOSディストリビューションの脆弱性情報 • golang, cargo, pypi など、言語システムの脆弱性情報 • ubuntuなど、ディストリビューションの脆弱性情報
13. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 12 cve.org MITRE社が提供する、CVEの情報を展開するサイト https://www.cve.org/ APIによる情報取得も可能 https://cveawg.mitre.org/api/cve/CVE-2023-26136
14. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 13 NVD NISTが提供する脆弱性データベース • 脆弱性の重要度を表すCVSSスコアなど、有用な情報が追加されている
15. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 14 GitHub Advisory Database • 言語パッケージの脆弱性情報が充実、バージョン情報なども記載 • GitHub Actionsの脆弱性情報も含まれる • GHSAという、独自の識別子が付与される ソフトウェア開発における脆弱性対応の情報源として有用 • python, rust, golang などの脆弱性は GitHub Advisory Databaseの情報が充実 • 影響を受けるバージョン情報が含まれている
16. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 15 脆弱性のスキャン 脆弱性情報をもとに、依存ソフトウェアの脆弱性を発見するためのツール・手法が数多くある コードベースのスキャン • GitHub Dependabot による脆弱性通知、アップデート (GitHub Actionsの脆弱性も一部対応) • Trivyなどのスキャンツールによる依存関係の脆弱性検知 (パッケージマネージャーのファイルを解析) コンテナイメージのスキャン • Trivyなどのスキャンツールでコンテナイメージをスキャンして検知 • コンテナレジストリの脆弱性スキャン機能を使い、保存したイメージの脆弱性検知 • クラウドベンダーのコンテナレジストリはスキャン機能が基本存在。HarborなどのOSSにもスキャン機能がある サーバのスキャン • Trivy,Grype, Vulsなどのツールや、有償の資産管理ツールなどで検知 SBOMファイルのスキャン • SBOM (ソフトウェア部品表）による脆弱性検知。コードなどにアクセスできなくても脆弱性検知可能 • TrivyはSBOMの作成と、SBOMによる脆弱性スキャンに対応 • SBOM作成ツールとの相性でうまく検知できないことも。作成ツールとスキャンツールを合わせるのが望ましい
17. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 16 c 脆弱性に対処する ソフトウェアのアップデートなど 脆弱性の影響を取り除く
18. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 17 脆弱性の対処 発見した脆弱性に対して、修復などの対処を行うことになる 修復 • 脆弱性が存在しないバージョンにアップデートする 利用停止 • 脆弱性が存在するソフトウェアの利用を停止する • 恒久的に利用を停止したり、脆弱性が修復可能になるまで機能を停止するなど 軽減策の適用 • 修復バージョンがない場合や、即座のアップデートが難しい場合は脆弱性のリスクを軽減する処置を行う • WAFなどによる攻撃の防御、設定の変更など
19. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 18 アップデートの方法 手動でのアップデート • パッケージマネージャーでの更新 • 使用するコンテナイメージを更新 • サーバの依存関係の更新 アップデートをツールで自動化する • Dependabot Security update • Renovate
20. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 19 効率的なアップデート ソフトウェア開発のプラクティスを活用することで、修復を容易にできる • パッケージマネージャによる、明示的な依存 • バージョンを明示的に更新可能 • 自動化されたテスト • バージョンを更新しても動作に影響がないか確認する • 自動化されたデプロイ • 迅速に脆弱性が修復されたソフトウェアをデプロイできるようにする 効率的なCICDは、セキュリティにとっても重要なプラクティス
21. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 20 脆弱性対応の基本 (おさらい) この二点を押さえれば問題ない？ c 脆弱性を発見する 依存ソフトウェアの脆弱性を発見する c 脆弱性に対処する ソフトウェアのアップデートなど 脆弱性の影響を取り除く
22. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 21 脆弱性対応の基本 (おさらい) 現実的にはこれだけでは難しい c 脆弱性を発見する 依存ソフトウェアの脆弱性を発見する c 脆弱性に対処する ソフトウェアのアップデートなど 脆弱性の影響を取り除く
23. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 22 なぜ発見と対処だけではダメなのか？ c 発見・報告される脆弱性数が 急増している c 実際に悪用される脆弱性は 脆弱性数に対してわずか c 脆弱性の発覚から悪用までが 高速化 • 2024のCVE数は4,0000件を突破 (2023は29,006件) • 2025のCVE数はすでに2,5000件を突破 • 悪用される脆弱性は、全体の6%程度という報告も • VPN製品など、攻撃者にとって有用な脆弱性は 公表から2日後には攻撃が開始 (paloaltoの事例)
24. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 23 c 脆弱性を発見する 依存ソフトウェアの脆弱性を発見する c 脆弱性に対処する ソフトウェアのアップデートなど 脆弱性の影響を取り除く なぜ発見と対処だけではダメなのか？ 脆弱性の増加、高速化に対応するためには これだけでは不十分
25. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 24 c 脆弱性を発見する 依存ソフトウェアの脆弱性を発見する c 脆弱性に対処する ソフトウェアのアップデートなど 脆弱性の影響を取り除く 事前・事後の対策を拡充する c 攻撃を受けづらくする 脆弱性の影響を受けづらくする 実装・運用の段階でリスクを低下させる c 脆弱性を優先度づけする 早期に対応すべき脆弱性を決める
26. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 25 c 攻撃を受けづらくする 脆弱性の影響を受けづらくする 実装・運用の段階でリスクを低下させる
27. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 26 攻撃を受けづらくする 依存関係を減らす • 不要な依存関係を発生させない。新たな依存を発生させなくて済む方法があればそちらを採用する 依存関係をコントロールする • 意図しないバージョンへの依存が発生しないようにする • 気づかない間に脆弱な/侵害されたバージョンを利用していた・・という事態を防ぐ o eslint-config-prettier の事例。メンテナの資格情報が盗まれ、npmにマルウェアを含んだバージョンが公開 https://github.com/advisories/GHSA-f29h-pxvx-f335 攻撃可能性を低減する • インターネットからアクセス可能なコンポーネントを最小化する • 適切なアクセス制限を実施する • シンプルだが重要 設計・開発・運用のレイヤーの観点を組み合わせた多層防御の観点が重要
28. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 27 イミュータブルによる依存関係のコントロール ソフトウェア開発におけるイミュータブルとは、「不変である」ことを表す • 一度作成・デプロイしたサーバーやコンテナ、アーティファクトを変更せず、変更する場合は再デプロイする • アーティファクトのバージョンを固定し、再ビルドや再デプロイ時に内容が変わらないようにする イミュータブルな例 イミュータブルでない例 c v パッケージマネージャーで バージョンを固定しGit管理 c GitHub Actionsで Commit HashによるAction指定 参考 https://docs.github.com/en/actions/how-tos/security-for-github- actions/security-guides/security-hardening-for-github-actions c コンテナのベースイメージを 明示的にバージョンを指定してビルド c v pythonのrequirements.txtなどで バージョンを指定しないで開発 c GitHub Actionsで タグを利用してActionsのバージョン指定 (mainタグなど) c v コンテナのベースイメージを latest を指定してビルド
29. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 28 c 脆弱性を優先度づけする 早期に対応すべき脆弱性を決める
30. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 29 脆弱性の優先度づけ 発見される脆弱性数が増加し、悪用が高速化されている現状では 脆弱性が悪用可能で、悪用のリスクが高い脆弱性を早期に対処することが重要 いくつか考慮すべきポイントがある 脆弱性の影響を受けるか • 脆弱性が存在していても、影響を受けない場合がある 攻撃可能性がどの程度か • 脆弱性の悪用が確認されている場合などは攻撃可能性が高いと考えられる 脆弱性が含まれる資産の性質 • 組織の活動に不可欠であったり、含まれる情報の機密性が高い資産の方が優先度が高い • インターネットに公開されている資産の方が一般的に優先度が高い
31. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 30 脆弱性の影響を受けるか 脆弱性スキャナーが判断できるのは、あくまで脆弱性があるバージョンのソフトウェアが 依存関係に含まれるかのみ 脆弱性が存在するバージョンを利用していても、被害を受けない例が存在する • 脆弱性がある関数・機能を参照していない • 脆弱性の影響を受けるのが、特定の設定・環境の場合のみ スコアは高いが、発火条件が難しく多くの場合影響を受けない脆弱性も多いので注意
32. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 31 脆弱性の影響を受けるかの判断 脆弱性の解説ページを見て、脆弱性の発火条件を判断材料とするのが一手法 • VEXという、ソフトウェアが脆弱性の影響を受けるかなどの情報を提供するためのフォーマットも存在 rejectPublicSuffix=false を設定していると脆弱性がある https://github.com/advisories/GHSA- 72xf-g2v4-qvf3
33. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 32 攻撃可能性がどの程度か 攻撃されるリスクが高い脆弱性を優先して対処する必要がある いくつかの参考となる指標が存在する KEV (Known Exploited Vulnerabilities) • すでに悪用が確認されている脆弱性を集めたカタログ • CISAが発行する CISA KEVが有名 • https://www.cisa.gov/known-exploited-vulnerabilities-catalog EPSS • FIRSTが算出する、脆弱性が今後30日以内に悪用される確率を示したスコア • 脆弱性情報をもとに、機械学習でスコアを計算している • https://www.first.org/epss/ SSVC、および関連データ • SSVCは脆弱性対応の優先順位づけを行うための方法論 • https://certcc.github.io/SSVC/ • SSVCの判断に使われる、脆弱性の悪用状況などのデータがCISAより提供されている
34. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 33 各種スコアの取得 KEVスコア・SSVC関連データは cve.org からデータ取得可能 (API経由でも可) CISA-ADPというフィールドで 以下データが提供 • KEV • SSVC データ
35. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 34 各種スコアの取得 EPSSはFIRSTの公式サイトよりcsvデータを取得するか、APIで取得する CVEデータ https://www.first.org/epss/data_stats APIページ https://www.first.org/epss/api
36. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 35 脆弱性運用のノウハウ 意思決定の背景情報の保存 • 優先度づけの結果、現時点で対応しない脆弱性については意思決定の根拠を文書化しておく • 将来状況が変化し判断の見直しが必要になった場合や、担当者の変更などが発生した際 なぜリスクが低いと判断したかを正確に追跡できるようにする • 脆弱性スキャンツールの除外設定に、コメントなどで背景を説明しておくと良い • Trivyなら、.trivyignore というファイルに脆弱性IDを記載するとその脆弱性を無視できる .trivyignoreファイルのコメントに、根拠などを記載しておくと背景情報の保存に役立つ コミュニティの重要性 • 重要な脆弱性はXなどで発信してくれる人がおり、情報収集先として有用 • 会社slackなどで、脆弱性情報が集まるチャンネルがあると意思決定に役立つ • 影響度が大きい脆弱性は、影響を受ける対象や攻撃の発火条件などが様々な場所から発信され 目まぐるしく状況が変わる • 最新の情報を皆で共有・議論をする場所があると、チームの垣根を越えたノウハウの共有がなされ 全体のセキュリティの底上げになる
37. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 36 まとめ 脆弱性対応のための4要素。近年は攻撃を受けづらくすること、優先度づけすることが重要 • 攻撃を受けづらくする • 脆弱性を発見する • 脆弱性を優先度づけする • 脆弱性に対応する 脆弱性の検知に使えるツール・優先度づけに使えるデータが拡充されつつある • 脆弱性スキャンツール (Dependabot, trivy) • KEV, EPSSなどのデータ 脆弱性対応にはコミュニティの力が大事。情報交換できる場が組織にあるとGood