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

by NTT docomo Business

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 4 ソフトウェア開発における脆弱性の例利用する言語ライブラリの脆弱性 • 開発するソフトウェアに脆弱な依存が含まれるコンテナ・サーバなどの実行環境の脆弱性 • ソフトウェアを動かすためのコンテナのベースイメージに脆弱性がある • ソフトウェアを動かすサーバ環境に脆弱性がある利用するコンポーネントの脆弱性 • DBなど、利用するコンポーネントに脆弱性がある

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 6 ソフトウェア開発の高度化と脆弱性ソフトウェア開発の高度化に伴い、依存関係が増加それに伴い脆弱性の影響を受ける箇所も増加。ビルドプロセスで利用するツールなども脆弱性の対象に Source Code Build Dependency Artifact Deployment 利用するパッケージの脆弱性コンテナイメージの脆弱性ビルド時に利用するツールの脆弱性利用コンポーネントの脆弱性 (DBなど)

Slide 8

Slide 8 text

© 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の侵害にも繋がり、影響範囲が拡大

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 11 脆弱性情報の入手脆弱性を発見するためには、発見された脆弱性に関する情報を収集する必要がある CVEによる脆弱性管理が広く使われているが、それ以外のエコシステムもある CVEを中心とした脆弱性情報 • CVE.org • NVD 独自のエコシステムによる脆弱性情報 • GitHub Advisory Database • JVN • 日本で使用されているソフトウェアの脆弱性情報言語パッケージやOSディストリビューションの脆弱性情報 • golang, cargo, pypi など、言語システムの脆弱性情報 • ubuntuなど、ディストリビューションの脆弱性情報

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 14 GitHub Advisory Database • 言語パッケージの脆弱性情報が充実、バージョン情報なども記載 • GitHub Actionsの脆弱性情報も含まれる • GHSAという、独自の識別子が付与されるソフトウェア開発における脆弱性対応の情報源として有用 • python, rust, golang などの脆弱性は GitHub Advisory Databaseの情報が充実 • 影響を受けるバージョン情報が含まれている

Slide 16

Slide 16 text

© 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作成ツールとの相性でうまく検知できないことも。作成ツールとスキャンツールを合わせるのが望ましい

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 17 脆弱性の対処発見した脆弱性に対して、修復などの対処を行うことになる修復 • 脆弱性が存在しないバージョンにアップデートする利用停止 • 脆弱性が存在するソフトウェアの利用を停止する • 恒久的に利用を停止したり、脆弱性が修復可能になるまで機能を停止するなど軽減策の適用 • 修復バージョンがない場合や、即座のアップデートが難しい場合は脆弱性のリスクを軽減する処置を行う • WAFなどによる攻撃の防御、設定の変更など

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 19 効率的なアップデートソフトウェア開発のプラクティスを活用することで、修復を容易にできる • パッケージマネージャによる、明示的な依存 • バージョンを明示的に更新可能 • 自動化されたテスト • バージョンを更新しても動作に影響がないか確認する • 自動化されたデプロイ • 迅速に脆弱性が修復されたソフトウェアをデプロイできるようにする効率的なCICDは、セキュリティにとっても重要なプラクティス

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 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の事例)

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 24 c 脆弱性を発見する依存ソフトウェアの脆弱性を発見する c 脆弱性に対処するソフトウェアのアップデートなど脆弱性の影響を取り除く事前・事後の対策を拡充する c 攻撃を受けづらくする脆弱性の影響を受けづらくする実装・運用の段階でリスクを低下させる c 脆弱性を優先度づけする早期に対応すべき脆弱性を決める

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 26 攻撃を受けづらくする依存関係を減らす • 不要な依存関係を発生させない。新たな依存を発生させなくて済む方法があればそちらを採用する依存関係をコントロールする • 意図しないバージョンへの依存が発生しないようにする • 気づかない間に脆弱な/侵害されたバージョンを利用していた・・という事態を防ぐ o eslint-config-prettier の事例。メンテナの資格情報が盗まれ、npmにマルウェアを含んだバージョンが公開 https://github.com/advisories/GHSA-f29h-pxvx-f335 攻撃可能性を低減する • インターネットからアクセス可能なコンポーネントを最小化する • 適切なアクセス制限を実施する • シンプルだが重要設計・開発・運用のレイヤーの観点を組み合わせた多層防御の観点が重要

Slide 28

Slide 28 text

© 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 を指定してビルド

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 29 脆弱性の優先度づけ発見される脆弱性数が増加し、悪用が高速化されている現状では脆弱性が悪用可能で、悪用のリスクが高い脆弱性を早期に対処することが重要いくつか考慮すべきポイントがある脆弱性の影響を受けるか • 脆弱性が存在していても、影響を受けない場合がある攻撃可能性がどの程度か • 脆弱性の悪用が確認されている場合などは攻撃可能性が高いと考えられる脆弱性が含まれる資産の性質 • 組織の活動に不可欠であったり、含まれる情報の機密性が高い資産の方が優先度が高い • インターネットに公開されている資産の方が一般的に優先度が高い

Slide 31

Slide 31 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 30 脆弱性の影響を受けるか脆弱性スキャナーが判断できるのは、あくまで脆弱性があるバージョンのソフトウェアが依存関係に含まれるかのみ脆弱性が存在するバージョンを利用していても、被害を受けない例が存在する • 脆弱性がある関数・機能を参照していない • 脆弱性の影響を受けるのが、特定の設定・環境の場合のみスコアは高いが、発火条件が難しく多くの場合影響を受けない脆弱性も多いので注意

Slide 32

Slide 32 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 31 脆弱性の影響を受けるかの判断脆弱性の解説ページを見て、脆弱性の発火条件を判断材料とするのが一手法 • VEXという、ソフトウェアが脆弱性の影響を受けるかなどの情報を提供するためのフォーマットも存在 rejectPublicSuffix=false を設定していると脆弱性がある https://github.com/advisories/GHSA- 72xf-g2v4-qvf3

Slide 33

Slide 33 text

© 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より提供されている

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 35 脆弱性運用のノウハウ意思決定の背景情報の保存 • 優先度づけの結果、現時点で対応しない脆弱性については意思決定の根拠を文書化しておく • 将来状況が変化し判断の見直しが必要になった場合や、担当者の変更などが発生した際なぜリスクが低いと判断したかを正確に追跡できるようにする • 脆弱性スキャンツールの除外設定に、コメントなどで背景を説明しておくと良い • Trivyなら、.trivyignore というファイルに脆弱性IDを記載するとその脆弱性を無視できる .trivyignoreファイルのコメントに、根拠などを記載しておくと背景情報の保存に役立つコミュニティの重要性 • 重要な脆弱性はXなどで発信してくれる人がおり、情報収集先として有用 • 会社slackなどで、脆弱性情報が集まるチャンネルがあると意思決定に役立つ • 影響度が大きい脆弱性は、影響を受ける対象や攻撃の発火条件などが様々な場所から発信され目まぐるしく状況が変わる • 最新の情報を皆で共有・議論をする場所があると、チームの垣根を越えたノウハウの共有がなされ全体のセキュリティの底上げになる

Slide 37

Slide 37 text

© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 36 まとめ脆弱性対応のための4要素。近年は攻撃を受けづらくすること、優先度づけすることが重要 • 攻撃を受けづらくする • 脆弱性を発見する • 脆弱性を優先度づけする • 脆弱性に対応する脆弱性の検知に使えるツール・優先度づけに使えるデータが拡充されつつある • 脆弱性スキャンツール (Dependabot, trivy) • KEV, EPSSなどのデータ脆弱性対応にはコミュニティの力が大事。情報交換できる場が組織にあるとGood