ServiceNow SNUG 2025YEP ServiceNow の責任のある開示プログラムとは

Transcript

1. ServiceNowの脆弱性を 発見したらどうする？ 責任のある開示プログラムとは？ よこはま みお （@mio_yokohama）
2. 自己紹介 ServiceNow歴：Kingston(2019)～ 好きなライセンス：ITOM, SecOps X：@mio_yokohama よこはま みお 第013795号 2025年度
3. 撮影禁止のお願い •スライド右上、左下に「撮影禁止」 と表示のあるスライドは、写真撮影、 SNSへの投稿をご遠慮ください。 •それ以外のスライドは写真撮影、 SNS投稿大歓迎です！ ぜひシェアしてください！ 撮影禁止 撮影禁止
4. もしServiceNowで脆弱性を 見つけたらどうしますか？
5. 実際に脆弱性を報告した話 ある機能の検証中、私はセキュリティ上の懸念のある動作に遭遇しました。 ServiceNowへ報告した結果、脆弱性として特定され、CVE-2025-3648 として公開されました。 CVE-2025-3648 特定条件下のACL設定において、Range Queryを用いて 本来アクセスできないデータを推論できてしまう脆弱性
6. 「あれ…？このACL、 効いてない？」 ある機能の検証中、意図しない挙動に遭遇しました。
7. 状況：本来見えないはずのデータ ユーザー “Alice”には”readable_role” のみを付与。 “unreadable_column”の読み取りには ”itil”ロールが必要なACLを設定。 この設定では、Aliceは”unreadable_column”の値を 閲覧・推測できないはずです。 撮影禁止 撮影禁止
8. 発見：フィルタークエリによるデータ推論の成功 ACLの有無を問わず、データを推論できてしまう可能性がありました。 しかし、特定のフィルター（read_column=foo^unreadable_column=foobar）を使うと… 撮影禁止 撮影禁止 本来アクセスできないはずの”unreadable_column”の値が ”foobar”であると推測できてしまった。
9. 脆弱性かもしれない･･･ でも、どうすれば？ • これは本当に報告すべき問題なのか？ • 正しい報告窓口はどこ？ • どのような情報を提供すればよい？ • 安全な検証方法は？ 当時の私は報告の方法が分からず、多くの時間を費やしました…
10. CVD (Coordinated Vulnerability Disclosure) 発見者による脆弱性の無秩序な公開を防ぎ、悪意のある攻撃者が脆弱性を 悪用する前に、脆弱性を修正してユーザーを保護する一連のプロセスのこと。 • CVDの考え方を踏まえたServiceNow公式 の脆弱性対応の枠組み。 • 脆弱性の安全な検証と報告、開示のルールが 定められている。 • リサーチャーは法的なリスクを負わずに調査 ができ、ServiceNowは製品をより堅牢にで きるWin-Winの関係。 ServiceNowの「責任のある開示プログラム」 発見 報告 修正 開示
11. ServiceNowが所有するドメインや製品 の「技術的な脆弱性」 •*.servicenow.com •*.service-now.com •.lightstep.com 対象となるもの（In Scope） 対象外となるもの（Out of Scope） •物理的なアクセスが必要な脆弱性 •パートナーサイトやインスタンス固有の問題（設 定ミスなど） 自動スキャンツールで検出した脆弱性は必ず手動で再検証してください。 未検証の脆弱性レポートはServiceNowは評価しません。 責任のある開示プログラム：報告のスコープ
12. 善意の調査であっても、手法を誤れば攻撃とみなされる可能性があります。 以下の原則に従ってください。 •迅速な報告：セキュリティ上の懸念を発見したら、速やかに報告する。 •詳細な再現手順の提供：PoC（概念実証）を含め、十分な情報を提供する。 •誠実な行動：プライバシー侵害やサービス中断を避ける努力を払う。 テストは必ず自身が所有もしくは権限のあるインスタンスのみで行う。 •報酬の対象外：プログラムに費やした時間や貢献に対して金銭的な報酬を要求しない。 •情報の秘匿化：脆弱性開示後に情報を公開する場合は、顧客・個人情報を削除する。 重要：ServiceNowは不正な診断スキャンやインフラストラクチャ に対する積極的なテストを厳しく禁止しています。 責任のある開示プログラム：遵守すべきガイドライン ガイドライン
13. 脆弱性発見から開示までの5ステップ Step 1: 発見と事前検証 Step 2: レポートの送信 Step 3: トリアージと評価 Step 4: CVE採番と修正 Step 5: 開示(Disclosure)
14. Step 1-2：発見者がすること（検証と報告） １ 事前検証 ２ レポート送信 報告先は立場によって異なる。 検証： 最新のPDIや非本番環境で 事象が再現可能か検証する。 PoC作成： 明確な再現手順、スクリーンショット、 動画などを準備する。 顧客/パートナー Now Supportの ”Security Finding Submission” 研究者/その他 disclosure@servicenow.com または HackerOne
15. 実際に私が送ったレポート（再現） Summary 脆弱性の概要を簡潔に Impact どのような影響があるか Environment 再現環境の詳細（ビルド名など） Steps to Reproduce ServiceNow PSIRTが事象 を再現できる手順 Proof 証拠となるスクリーンショット
16. Step 3-5：PSIRTがすること（評価、修正、開示） ３ トリアージと評価 ４ CVE採番と修正 • ServiceNow PSIRTがPoCを元に再現確認。 • CVSSスコア等を用いて深刻度を評価。 ５ 開示（Disclosure） • 脆弱性が認定されるとCVE番号が割り当て*られる。 ※ServiceNowはCNA（CVE採番機関）のため、自社製品の脆弱性に自らCVEを発行可能。 • 開発チームが修正パッチを開発 • 公式ナレッジベースKBにて脆弱性の詳細を回 避策（Security Advisory）が公開される。
17. 貢献の成果：クレジットへの掲載 修正の準備が整うと、Security Advisoryが公開 されます。 報告者の貢献が認められた場合、アドバイザリ内に 「Finder」として名前が掲載されることがあります。 ・Mio Yokohama finder
18. あなたの発見が、ServiceNowをより強くする どんなに優れたプロダクトでも、脆弱性が全くないということはありません。 だからこそ、私たちユーザーコミュニティによる「発見」と「報告」のサイクルが重要です。 私たちが発見した脆弱性を適切なプロセスで報告することは、製品への批判ではありません。 ServiceNow AI プラットフォームをより信頼性の高いもの変革する、前向きな行動です。