ServiceNowの脆弱性を発見したらどうする？「責任のある開示プログラム」とは

本記事は【Qiita ServiceNow アドベントカレンダー2025】の11日目です。

記載内容は 2025年12月時点の ServiceNow の公開情報 と、筆者が実際に脆弱性報告に関わった経験に基づいています。脆弱性を発見した場合は、必ず最新の ServiceNow 公式情報を参照して行動してください。

はじめに

ServiceNow の導入や開発に関わっていると、検証の過程で意図しない挙動や不具合に遭遇することは珍しくありません。多くは設定ミスや単純なバグですが、もしそれがセキュリティ上の問題、つまり脆弱性だった場合、どのように対処すべきかご存知ですか？

CVE-2025-3648 の発見と報告

私は以前、ある機能の検証中にセキュリティ上懸念のある動作に遭遇しました。ServiceNow へ報告した結果、この問題は脆弱性として特定され、CVE-2025-3648 として公開されました。

日々業務で関わっているServiceNowのセキュリティに貢献できたことは、ServiceNowエンジニアとしてこの上ない喜びです。この脆弱性の発見における私の貢献を認めてくださったことに、深く感謝しています。

CVE-2025-3648
特定条件下の ACL（アクセス制御リスト）設定において、認証の有無を問わずユーザーが Range Query を用いて本来アクセスできないデータを推論できてしまう可能性がある脆弱性。これに対応するため、ServiceNow は Query ACLs、Security Data Filters、Deny-Unless ACLs などの新たなアクセス制御機能を導入し、2025年5月には ACL 強化のための追加セキュリティアップデートを提供した。

しかし、脆弱性を発見した当初の私は報告の方法が分からず、正しい窓口や安全な報告方法を調べるために多くの時間を費やしました。
この経験に基づいて、本記事では当時の私と同じように迷うことがないよう、ServiceNow に脆弱性を報告するための適切な方法とルールを共有したいと思います。

1. 責任のある開示（Responsible Disclosure）とは

「責任のある開示」とは、脆弱性を発見したセキュリティ研究者や開発者が、まずベンダーに直接報告し、情報が公開される前にベンダーが問題を修正する時間を確保する取り組みです。

CVD（Coordinated Vulnerability Disclosure）の原則

発見者とベンダーが協力して進める一連のプロセスは、近年ではCVD（Coordinated Vulnerability Disclosure：協調的な脆弱性公開）と定義されています。
その目的は、発見者による脆弱性の無秩序な公開を防ぎ、悪意のある攻撃者が脆弱性を悪用する前に、脆弱性を修正してユーザーを保護することです。

▼ Coordinated Vulnerability Disclosure (CVD) Program

ServiceNowはこの理念を体現しており、顧客、開発者、研究者が安全に脆弱性を報告できるよう、責任のある開示プログラムを設けています。

このプログラムは Now Support ケースのような通常の製品サポートとは異なり、安全な報告ルートを通じて脆弱性の早期発見と修正を促進し、発見者に対して公正かつ透明なプロセスを提供することを目的としています。

2. 範囲および禁止行為

報告にはいくつかのルールが存在します。善意の調査であっても、手法を誤れば攻撃と見なされる可能性があるため、以下のルールを遵守する必要があります。

✅ 対象となるもの（スコープ内）

ServiceNow が所有するドメインや製品における「技術的な脆弱性」が対象です。
例えば以下のドメインが対象です。

*.servicenow.com
*.service-now.com
*.lightstep.com

❌ 対象外となるもの（スコープ外）

以下の脆弱性や行為は、報告の対象外、または禁止されています。

• 対象外の脆弱性
  • 物理的アクセスが必要な脆弱性
  • パートナーサイト、顧客インスタンス固有（設定起因など）の脆弱性
• 禁止されている行為
  • 自動化ツール・スキャンによる積極的な攻撃的調査
  • 顧客・従業員に対するソーシャルエンジニアリング・フィッシング
  • DoS攻撃・サービス停止につながる操作
  • 費やした時間や貢献に対する金銭的な報酬の要求

重要: ServiceNow では、不正な診断スキャンやインフラストラクチャに対する積極的なテストを厳しく禁止しています。

⚠️ 従うべきガイドライン

報告する際は、次の原則に従う必要があります。

• 迅速な報告
  セキュリティ上の懸念を発見した場合は、速やかに報告を行うこと。

• 詳細な再現手順の提供
  報告時は概念実証（PoC）を含む、脆弱性を再現するために十分な詳細情報を提供すること。

• 誠実な行動
  プライバシー侵害、データ破壊、サービス中断を回避するためにあらゆる努力を払うこと。
  テストは、自身が所有するインスタンス、または許可されたアカウントでのみ行うこと。

• 情報の秘匿化
  脆弱性開示後に情報を公開する場合は、顧客・個人情報を削除すること。

• 報酬の対象外
  責任のある開示プログラムに費やした時間や貢献に対して金銭的な報酬を要求しないこと。

自動スキャンの結果は、提出する前に必ず手動で再検証してください。未検証のレポートは評価されません。

顧客侵入テスト (CPT) を実施する場合は、事前に申請して承認を受ける必要があります。（KB1048209）

3. どこに報告するか？

報告窓口は大きく分けて2つ存在します。
あなたがどの立場で脆弱性を発見・報告するかによって、利用すべき窓口が異なります。

🔹 Security Finding Submission

• 立場： Now Support のアクセス権を持つ顧客/パートナー
• 報告先： Now Support の Security Finding Submission フォーム

🔹 Responsible Disclosure（責任のある開示）

• 立場： セキュリティ研究者、サポート契約のない開発者/テスター
• 報告先： [e-mail] または HackerOne

4. 脆弱性を見つけたらどうする？

では、実際に脆弱性を発見した場合はどのように対応すれば良いのでしょうか？
脆弱性を発見した場合、以下の手順で報告を進めます。

• Step 1: 発見と事前検証
• Step 2: レポートの送信
• Step 3: トリアージと評価
• Step 4: CVE採番と修正
• Step 5: 開示（Disclosure）

Step 1: 発見と事前検証

まず、事象が再現可能であり、本当に脆弱性であるかどうかを確認します。

可能な限り、最新の PDI や非本番環境で検証します。
ServiceNow PSIRT が事象を確認できるよう、明確な再現手順（PoC）を作成します。
スクリーンショットや動画などのエビデンスもこの段階で準備します。

公式ではReproNow*での記録が推奨されていますが、記事執筆時点でReproNowはメンテナンスされておらず、事実上の開発停止状態にあり現在利用できません。他のキャプチャツールや動画、テキスト等でPoCを作成してください。
※ReproNow: 脆弱性のPoCを記録するためのOSSのキャプチャーツール

Step 2: レポートの送信

適切な窓口（セクション 3 で説明）を通じてレポートを送信します。
記述は英語が基本で、事実を正確に伝えることが重要です。

• 顧客の場合: Now Support でSFレコードを作成
• 顧客ではない場合: [e-mail] へのメール、または HackerOne で報告

レポートのテンプレート

Title:
[脆弱性のタイトル]

Summary:
[どこに脆弱性があり、悪用されると何が起きるかを簡潔な文章で]

Asset:
[対象URL、リソースの場所など]

Severity:(任意)

• Weakness: [脆弱性の種類 (CWE)]
• CVSS: [CVSSベクトル文字列]

Impact:
[脆弱性が悪用された場合の影響を文章で]

Steps to Reproduce:
[再現手順]
1.
2.
3.

Proof / References:
[証跡: スクリーンショット、HTTPログ、PoCコードなどを添付]

単に「バグがある」ではなく、「それによって何が起き、なぜ修正が必要なのか」が説明できる状態を目指します。

Step 3: トリアージと評価

報告が受理されると、ServiceNow PSIRT が内容を確認します

• 再現確認: 提供されたPoCをもとに、ServiceNow側で事象を再現します。

• 影響度評価: CVSS（共通脆弱性評価システム）スコアなどを用いて、脆弱性の深刻度を決定します。

この段階で、追加の情報提供を求められる場合があります。報告者と ServiceNow PSIRT との間でコミュニケーションを取りながら、正確な評価を行います。

Step 4: CVE採番と修正

• CVE採番: 脆弱性が認定されるとCVE番号が割り当てられます。
• 修正: 開発チームが修正パッチ（Hotfix）を開発します。

ServiceNow は CNA（CVE 採番機関）のため、自社製品の脆弱性に対して自ら CVE を発行することが可能です。これにより、外部機関の調整を待つことなく、迅速に処理されます。

Step 5: 開示（Disclosure）

修正の公開準備が整ったあとに情報が開示されます。

• Security Advisory: 公式ナレッジベース（KB）にて脆弱性の詳細と回避策が公開されます。

• クレジットの掲載: 報告者の貢献が認められた場合、アドバイザリ内に「Finder」として名前が記載されることがあります。

Tips：最新のCVE情報を入手するには

プラットフォームのセキュリティを維持するためには、脆弱性情報の継続的なモニタリングが不可欠です。

ServiceNow は、セキュリティ アドバイザリ ランディング ページで脆弱性情報を公開します。このページを購読することを強くお勧めします。新しいアドバイザリが追加されると通知が届きます。脆弱性への迅速な対応が求められるセキュリティ担当者やプラットフォームオーナーにとって非常に重要です。

ServiceNow CVE セキュリティアドバイザリ一覧：KB1226057

おわりに：プラットフォームセキュリティへの貢献

ServiceNow は急速に進化しています。しかし、どんなに優れたプロダクトであっても、脆弱性が全くないということはありません。だからこそ、ユーザーコミュニティによる「発見」と「報告」のサイクルが重要です。

私はこの経験を通して、ServiceNowが発見者を尊重し、報告を安全に処理する「責任のある開示」プログラムを提供していることを学びました。私たちが発見した脆弱性を適切なプロセスで報告することは、製品への批判ではなく、ServiceNow AI プラットフォームをより信頼性の高いものに変革する前向きな行動です。

この記事が、今後皆様が脆弱性を見つけた際の役に立てば幸いです。

それでは、素晴らしいホリデーシーズンと新年をお過ごしください。