ServiceNowで発覚した『認証なしAPI』設定ミス｜脆弱性ではなく設定の見落としが情報露出を招いた理由

結論から言う。今回ServiceNowで起きたのは、ソフトウェアの「脆弱性」ではなく「設定」の見落としだ。 業務システムの一部APIエンドポイントが、認証を要求しない状態(requires_authenticationが無効)になっており、条件が揃えば外部から特定のテーブル情報に到達できる状態だったことが、2026年6月9日に報じられた。CVE番号は付与されておらず、ServiceNow自身も「評価中」としている。パッチを当てれば終わる話ではなく、「自社のAPI公開設定を誰が・いつ・どう点検しているか」という運用面の問い直しが必要になる事案だ。

何が起きたか

• ServiceNowのREST APIエンドポインの一部で、認証を要求しない設定になっている状態が確認された。ServiceNowは2026年6月5日にセキュリティ更新を適用し、該当設定を無効化(認証必須化)した。
• 影響が疑われる不審なアクセスは、更新適用以前の数日間に観測されたと報じられている。
• アクセス可能だった情報の種類は正式には開示されていないが、一般にServiceNowインスタンスにはITヘルプデスクのチケット内容や従業員関連の記録、資産管理情報などが保存される。特定のプラットフォームリリースを使用し、なおかつ該当の設定変更を行っていた顧客が対象とされる。
• 重要な経緯として、ServiceNowは2026年4月22日に非公開のバグバウンティ報告としてこの脆弱な設定を把握していたが、パッチ適用は6月5日までかかった。この間の6月上旬、顧客インスタンスを狙ったとみられる活動が確認されたことが、更新適用のきっかけになったと報じられている。
• 加えて、ServiceNowは調査の結果、観測された挙動は「セキュリティ研究者またはバグバウンティ提出に関連した、顧客主導の調査活動」である可能性が高いと6月10日付で説明を更新している。悪意ある大規模な情報窃取が確定した事案ではない点には注意が必要だ。

一次報道としてBleepingComputerを参照した。ServiceNow公式のトラストポータル等での詳細開示内容は今後更新される可能性があるため、自社が対象顧客に該当するか懸念がある場合は、ServiceNowからの公式通知・トラストポータルを直接確認することを推奨する。

なぜ「脆弱性ではなく設定ミス」が厄介なのか

CVEが付与されるような脆弱性であれば、ベンダーのパッチを適用すれば対応が完了する。しかし今回のように「顧客側の設定・カスタマイズの組み合わせによって意図せず認証が外れる」というパターンは、ベンダーのパッチ配布だけでは解決しない。SaaSやノーコードプラットフォームは、標準機能に加えて顧客ごとにAPI連携やカスタムスクリプトを追加できる設計になっていることが多く、その追加設定こそが盲点になりやすい。

これはServiceNowに限った話ではない。Salesforceのカスタムオブジェクト共有設定、kintoneのAPIトークン権限、Microsoft 365のPower Automate連携など、「標準では安全でも、カスタム設定次第で意図せず公開範囲が広がる」構造を持つSaaSは多い。自社で使っているSaaSに同種の設定項目がないか、一度棚卸しする価値がある。

自社に関係あるか確認すべきポイント

• ServiceNowを利用している場合、対象プラットフォームリリース・設定変更の有無に該当するか、ベンダーからの通知やトラストポータルの情報を確認したか
• ServiceNow以外でも、Salesforce・kintone・Microsoft 365等でカスタムAPI連携やスクリプト拡張を行っている場合、認証設定を「意図的に緩めた」箇所が残っていないか
• 過去にPoCやテスト目的で一時的に認証を緩めた設定を、恒久設定に戻し忘れていないか
• 自社のSaaS環境で、誰がAPI・連携設定の変更権限を持ち、変更履歴がどこまで追跡できるか

誰が読むべき記事か

• ServiceNow・Salesforce・kintone等のSaaSを業務システムとして利用し、カスタムAPI連携や外部連携を行っている情報システム担当者
• SaaS導入・カスタマイズをベンダーやパートナーに委託しており、設定変更の中身を自社で把握しきれていない経営者・DX推進担当者
• 「脆弱性診断はしているが、SaaSの設定監査までは手が回っていない」企業の担当者

実務判断のポイント

この記事は、経営者、CIO、情シス、セキュリティ担当、開発責任者向けです。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。

GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。ServiceNowで発覚した『認証なしAPI』設定ミス｜脆弱性ではなく設定の見落としが情報露出を招いた理由に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。

放置した場合と整備した場合の違い

導入・改善前のチェックリスト

• 対象業務、対象部門、対象データを明文化しているか
• 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
• 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
• 例外処理、承認、差し戻し、監査証跡まで確認しているか
• 社内で判断できる範囲と外部支援が必要な範囲を分けているか
• 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
• 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
• 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
• セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
• 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
• 経営判断に必要な資料を1枚で説明できる状態にしているか
• 次の90日で検証する範囲と、やらない範囲を明確にしているか

GXOの見解

セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。

GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。

自社だけで整理が難しい場合、GXOは脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる。最初から大規模な発注を前提にせず、現状整理や診断から必要な範囲を確認できます。

実行までの進め方

1. 現在の業務、データ、ツール、担当者を棚卸しする
2. 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
3. 初期対応、90日以内の改善、半年以上の投資を分ける
4. 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
5. 小さく検証し、効果測定後に本番化や横展開を判断する

90日で進める実装ロードマップ

部門別に確認すべき論点

経営層は、ServiceNowで発覚した『認証なしAPI』設定ミス｜脆弱性ではなく設定の見落としが情報露出を招いた理由が売上、粗利、採用、顧客維持、リスク低減のどれに効くのかを確認する必要があります。単なる効率化として扱うと、投資判断が後回しになり、現場任せの小さな改善で止まりやすくなります。

DX責任者や情シスは、既存システムとの接続、認証、権限、ログ、保守体制、外部ベンダーとの責任分界を確認します。ここを曖昧にすると、導入直後は動いても、問い合わせ増加、障害対応、改修費用で現場負荷が増えます。

業務部門は、例外処理、承認、差し戻し、手作業で補っている判断を洗い出します。表面上の手順だけを自動化しても、例外が多い業務では成果が出にくいため、現場の暗黙知を要件に変換することが重要です。

管理部門は、契約、個人情報、補助金、会計処理、監査証跡、社内規程との整合性を確認します。特に制度、法務、セキュリティ、価格が絡むテーマでは、公開情報と社内ルールの両方を確認してから進めるべきです。

KPIと効果測定の設計

効果測定では、導入の有無だけでなく、対応時間、差し戻し率、業務処理件数、障害件数、監査指摘、顧客満足度などを分けて確認します。着手前に成功条件を決め、検証後に継続投資するか判断できる形へ落とし込みます。

相談前に用意すると判断が早くなる資料

• 現在の業務フロー、担当者、月間件数、処理時間
• 利用中のSaaS、基幹システム、Excel、外部委託先の一覧
• 直近のトラブル、問い合わせ、手戻り、障害、監査指摘の記録
• 投資できる予算感、希望時期、社内の承認者
• 個人情報、機密情報、外部送信、契約条件に関する制約
• 既に検討したツール、ベンダー、見積、PoC結果
• 成功時に増やしたい売上、減らしたい工数、避けたい損失

GXOが支援する場合の進め方

GXOが支援する場合は、最初に記事テーマをそのまま提案にせず、現場の制約と経営上の目的に分解します。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応の相談を入口に、要件定義、RFP、ベンダー比較、実装、運用改善まで接続できるかを確認します。

短期的には、課題整理、現状棚卸し、優先順位付け、概算費用、実行計画をまとめます。中期的には、PoCや小規模実装を通じて、データ品質、権限、運用負荷、費用対効果を検証します。長期的には、月次レビュー、改善バックログ、追加開発、セキュリティ確認を継続し、投資を一度きりで終わらせない状態を作ります。

重要なのは、記事を読んだ直後に「問い合わせるかどうか」ではなく、「自社では何を確認すべきか」「どの段階から外部支援を入れるべきか」が明確になることです。そのため、GXOでは相談前の論点整理から支援し、必要に応じて診断、要件定義、実装、保守まで段階的に進めます。

よくある質問

Q. 自社もServiceNowを使っていますが、どう対応すればよいですか。 A. まず、該当プラットフォームリリースや設定変更の有無について、ServiceNowからの通知やトラストポータルの情報を確認してください。不明な場合はベンダーサポート窓口、または第三者による設定監査の利用も選択肢です。

Q. 今回の件は情報漏えいと断定してよいのでしょうか。 A. ServiceNowは後日、観測された挙動がセキュリティ研究者やバグバウンティ関連の調査活動である可能性が高いとの見解を示しています。悪意ある大規模流出と断定する材料は現時点では確認できておらず、本記事でも断定は避けています。自社への影響有無は公式情報で確認してください。

Q. CVE番号がつかないインシデントは軽視してよいですか。 A. いいえ。CVE番号は主にソフトウェア自体の脆弱性に付与される仕組みであり、設定ミス起因のリスクには付与されないことがあります。CVEの有無と深刻度は必ずしも一致しないため、番号の有無で軽重を判断しないことをおすすめします。

GXOに相談すべきタイミング

• 自社で利用しているSaaS・ノーコードプラットフォームのAPI・連携設定を、誰も体系的に棚卸ししたことがない場合
• ベンダーやパートナーにSaaSカスタマイズを委託しており、設定変更の中身をブラックボックスのまま運用している場合
• 過去のPoCやテストで緩めた設定が、現在も残っていないか確認したい場合
• SaaS単体の設定監査にとどまらず、業務システム全体のアクセス制御・API連携方針を見直したい場合

自社のSaaS・業務システムのAPI公開設定に不安がある場合は、委託先ベンダーのセキュリティ評価やSaaS設定監査を含めた点検を検討したい。SaaS連携やカスタムAPIの設計そのものを見直したい場合は、DX・システム開発の観点から要件を整理することもできる。まずはセキュリティの全体像から、自社に必要な対策の優先順位を確認することも可能だ。

GXOはServiceNow公式サポートや侵害有無の確定調査機関ではありません。支援できるのは、SaaS設定、API公開範囲、権限、ログ、委託先変更管理を棚卸しし、設定ミスが起きやすい箇所を潰すことです。具体的な相談はSaaS/API設定監査の相談窓口からお問い合わせください。

---

参考・出典

• BleepingComputer「ServiceNow discloses security incident exposing customer data」（2026年7月2日閲覧）
• ServiceNow Trust Center（2026年7月2日閲覧）

本記事のインシデント情報は2026年7月2日時点で確認できた報道に基づく。ServiceNow公式による続報・詳細開示が更新される可能性があるため、自社への影響が疑われる場合は公式情報を直接確認することを推奨する。

公式・一次情報（最終確認: 2026年7月12日）

• IPA 情報セキュリティ: https://www.ipa.go.jp/security/
• CISA Cybersecurity Resources: https://www.cisa.gov/topics/cybersecurity-best-practices

制度、仕様、価格、法令、脆弱性情報は改定されるため、発注・申請・対応の直前にリンク先の最新版と適用条件を再確認してください。