セキュリティ評価サービス（SRS）とは？2026年最新動向とサプライチェーンリスク管理での使い方|セキュリティ対策Lab

投稿日時: 2025年04月03日更新日時: 2026年08月02日

セキュリティ評価サービス（Security Rating Services：SRS）は、企業や取引先のセキュリティ状態を外部から観測し、スコアやランクで可視化するサービスです。以前は、公開サーバーの設定不備や脆弱性の有無を点数化するツールという見方が中心でしたが、2026年時点では少し意味合いが変わってきました。

背景にあるのは、サードパーティ経由の侵害、クラウド・SaaS連携、ソフトウェアサプライチェーン、外部公開資産の増加です。自社の境界だけを固めても、委託先、SaaS、ファイル転送製品、MSP、開発委託先、グループ会社のどこかが侵害されれば、情報漏えいや業務停止につながります。

ネットワークやサーバーを見てきた立場からすると、SRSの価値は点数そのものではなく、外から見える危険な状態を早く見つけるところにあります。放置されたサブドメイン、古いVPN機器、設定が甘いメール認証、意図せず公開された管理画面は、社内台帳よりも外部スキャンの方が先に気づくことがあります。一方で、SRSだけで委託先の安全性を判断するのは危険です。内部統制、アクセス権管理、ログ監視、バックアップ、インシデント対応体制までは、外からの観測だけでは分かりません。

本記事では、セキュリティ評価サービス（SRS）とは？概要や種類、事例を解説の内容を、2026年時点の海外レポート、国内のSCS評価制度、サプライチェーンリスク管理の観点を加えてリライトします。

セキュリティ評価サービス（SRS）とは？2026年最新動向とサプライチェーンリスク管理での使い方のサマリー

SRSは、企業の外部公開資産やセキュリティ設定を外部から観測し、スコアやランクで評価するサービスです。
2026年時点では、サードパーティ侵害やサプライチェーンリスクの増加により、取引先管理やグループ会社管理での利用が広がっています。
Verizonの2026年DBIRでは、第三者が関与する侵害が全体の48％を占めるとされ、委託先管理の重要性が一段と高まっています。
Black Kiteの2026年レポートでは、1件のベンダー侵害が平均5.28社の下流組織に波及したとされ、特定ベンダーへの依存が集中リスクになっています。
国内ではIPAがSCS評価制度を公開しており、SRSとあわせて、自己申告、第三者評価、外部観測をどう組み合わせるかが実務上の論点になります。
SRSのスコアは便利ですが、単独で取引可否を決めるものではありません。質問票、監査、契約、ログ・証跡、インシデント対応体制の確認と組み合わせる必要があります。

整理表

項目	2026年時点の見方	情報システム部門が確認すべき点
SRSの位置づけ	外部公開資産を継続的に観測し、セキュリティ状態をスコア化する仕組み	自社・グループ会社・重要委託先の外部露出を継続監視できるか
主な用途	サードパーティリスク管理、取引先評価、M&A、サイバー保険、経営報告	スコアの悪化を誰が確認し、どの期限で直すか
評価対象	ドメイン、IP、メール認証、TLS、公開サービス、脆弱性、漏えい認証情報など	自社所有でない資産が誤って紐づいていないか
最新動向	脆弱性悪用、サードパーティ侵害、AI利用、委託先集中リスクが重視されている	CVE、KEV、DMARC、漏えい認証情報を優先度付けに入れるか
国内制度との関係	SCS評価制度は制度上の対策可視化、SRSは外部観測型の継続監視	SCS、ISMS、SOC 2、SRSを混同せず、用途を分ける
注意点	スコアは外から見える一部の状態に過ぎない	スコアだけで合否判定せず、質問票や契約条項と併用する

セキュリティ評価サービスSRSとは

SRSは、企業のインターネット上に公開されている資産や設定を外部から観測し、セキュリティ状態を数値やランクで示すサービスです。代表的な評価対象には、公開中のWebサーバー、メール認証設定、TLS証明書、DNS、公開ポート、脆弱性のあるサービス、マルウェア感染の痕跡、ボットネット通信、漏えいした認証情報などがあります。

一般的な脆弱性診断と違うのは、攻撃者が外から見ている景色に近い形で、継続的に観測する点です。脆弱性診断は特定システムを対象に、許可された範囲で深く調査します。一方のSRSは、会社全体や取引先全体の外部露出を広く見ます。深さよりも、範囲と継続性に強みがあります。

たとえば、自社が把握していない古いサブドメインに検証用サーバーが残っている、海外拠点のVPN装置だけパッチが遅れている、グループ会社のメール認証が未設定でなりすましリスクがある、といった状態は、SRSで見つかりやすい典型例です。現場では、台帳上は廃止済みのはずのサーバーがDNSだけ残っていた、という話も珍しくありません。

ただし、SRSは万能ではありません。社内ネットワークの分離、特権IDの運用、EDRの検知品質、バックアップからの復旧手順、委託先の再委託管理までは、外部観測だけでは分かりません。SRSのスコアが高いから安全、低いから危険と単純に決めるのではなく、外部から見えるリスクの早期発見ツールとして扱うのが現実的です。

2026年にSRSの重要性が高まっている理由

SRSが注目される理由は、サイバー攻撃の入口が自社の境界だけではなくなったためです。Verizonの2026年DBIRでは、脆弱性悪用が侵害の入口として31％を占め、19年のDBIRで初めて盗まれた認証情報を上回ったと説明されています。同じレポートでは、第三者が関与する侵害が全体の48％に達し、前年比で60％増えたとされています。

この数字は、SRSの使い方にも直結します。取引先の公開VPN、ファイル転送製品、リモートアクセス機器、メール設定、クラウド公開設定の不備は、攻撃者にとって分かりやすい入口です。自社のEDRやSOCを強化していても、委託先の1社が侵害されれば、認証情報、APIキー、顧客データ、業務データが連鎖的に流出することがあります。

SecurityScorecardのGlobal Third Party Breach Reportでは、2024年の侵害の35.5％がサードパーティアクセスに関連し、ランサムウェア攻撃の41.4％にも第三者アクセスが関与したとされています。とくにファイル転送ソフトウェアの脆弱性が悪用された事例は、多数の組織に一斉に影響するため、単社の問題では済みません。

Black Kiteの2026年Third-Party Breach Reportも、同じ方向を示しています。同レポートでは、2025年の検証済み136件の第三者侵害を分析し、1件のベンダー侵害が平均5.28社の下流組織に波及したとしています。さらに、侵害が検知されてから公表されるまで平均117日の遅れがあるとされ、委託元企業が実態を把握できない空白期間の長さが問題になります。

ここでSRSが役立つのは、取引先からの報告を待つだけではなく、自社側でも外部から継続的に変化を見られる点です。もちろん、SRSが侵害を直接検知するわけではありません。それでも、重要委託先の外部公開サービスに重大な脆弱性が見えた、メール認証が急に崩れた、認証情報流出のシグナルが出た、といった変化は、問い合わせや追加確認のきっかけになります。

国内事例を見ても、2026年6月サイバー攻撃の被害事例まとめで触れているように、GitHub、Salesforce、SaaS連携、委託先を起点とした被害は継続的に確認されています。サプライチェーンリスクとは？インシデント事例から見る危険なポイントと対策を解説で整理した通り、サプライチェーンリスクは契約先の数ではなく、業務影響とデータ流通の深さで見る必要があります。

SRSで見えるものと見えないもの

SRSで見えるものは、外から観測できるセキュリティ上の弱点です。代表例は、古いTLS設定、期限切れ証明書、SPF・DKIM・DMARCの不備、危険な公開ポート、既知脆弱性のあるソフトウェア、ボットネット通信、マルウェア感染の痕跡、漏えい認証情報、DNS設定の問題などです。

2026年のBitSightのレーティングアルゴリズム更新では、従来のPatching Cadenceに代わり、Critical Vulnerability Managementが重視されるようになりました。重大な脆弱性をどれだけ早く管理するか、DMARCを含むメールセキュリティをどう評価に反映するかなど、実際の攻撃動向に近い評価へ寄せている点は注目できます。

この流れは、SRS全体の方向性を表しています。単に設定ミスの数を数えるだけでなく、攻撃で悪用されやすい脆弱性、認証情報流出、メールなりすまし、ランサムウェアにつながりやすい外部露出を優先して見る方向です。CISAのKnown Exploited Vulnerabilitiesのように、実際の悪用が確認されている脆弱性を優先する考え方とも相性があります。

一方で、SRSで見えないものも多くあります。たとえば、特権IDがどのように承認されているか、MFAが全管理者に強制されているか、EDRアラートを誰が何分以内に見るか、バックアップが暗号化被害から分離されているか、委託先の再委託先まで監査しているか、といった情報は、通常の外部観測では分かりません。

さらに、SRSには資産帰属の誤りもあります。昔使っていたIPレンジ、CDN、ホスティング、M&Aで取得したドメイン、外部委託先の開発環境が、誤って自社スコアに入ることがあります。逆に、本当に自社が管理すべき資産が評価範囲から漏れることもあります。

そのため、SRS導入時に最初にやるべきことは、点数を見て一喜一憂することではありません。自社のドメイン、IP、クラウドアカウント、ブランド名、グループ会社、重要サービスを棚卸しし、評価対象が正しいか確認することです。ここを飛ばすと、スコア改善が実態改善ではなく、資産の付け替え作業になってしまいます。

SRSの主な種類

SRSにはいくつかのタイプがあります。完全に分かれるわけではなく、最近は複数の機能をまとめて提供するサービスが増えています。

種類	主な目的	代表的な利用シーン	注意点
外部レーティング型	外部公開資産のセキュリティ状態をスコア化	自社・取引先・グループ会社の継続監視	内部統制や運用実態は見えにくい
サードパーティリスク管理型	委託先のリスクを台帳・質問票・スコアで管理	調達、契約更新、重要委託先レビュー	質問票が形骸化しやすい
攻撃対象領域管理型	未把握資産や公開サービスを発見	シャドーIT、クラウド公開、M&A後の棚卸し	発見後の修正運用がないと効果が薄い
サイバーリスク定量化型	侵害時の財務影響を見積もる	経営報告、保険、投資判断	前提条件によって結果が大きく変わる
国内制度・認証連携型	制度や認証と組み合わせて対策水準を示す	SCS評価制度、ISMS、取引先説明	SRSの点数と制度上の評価は同じではない

BitSight、SecurityScorecard、UpGuard、Black Kiteなどは、外部観測型のセキュリティレーティングやサードパーティリスク管理の文脈でよく名前が挙がるサービスです。国内では、Secure SketCH、Assured、セキュリティチェックシート管理、ASM系サービス、ISMS・Pマーク運用支援などと組み合わせて使われる場面があります。

ここで注意したいのは、SRSという言葉がかなり広く使われる点です。製品比較表では同じSRSに見えても、実際には外部スコアリング、質問票管理、クラウドサービス審査、脆弱性管理、ASM、リスク定量化が混在しています。導入時には、何を評価したいのかを先に決める必要があります。

セキュリティチェックシートとは？目的や構成、評価項目の考え方を解説で解説したように、SaaSやクラウドサービスの審査では、質問票と証跡確認が今も重要です。SRSはこの業務を置き換えるものではなく、質問票では拾いにくい外部変化を補うものと考える方が現場に合っています。

国内のSCS評価制度とSRSは何が違うのか

2026年に国内で重要になっているのが、IPAのサプライチェーン強化に向けたセキュリティ対策評価制度、いわゆるSCS評価制度です。IPAは、ビジネス・ITサービスサプライチェーンにおける委託先へのサイバー攻撃、サービス提供途絶、機密情報の漏えい、改ざん、委託先を踏み台にした不正侵入などのリスクに対し、サプライチェーン全体の対策水準向上を目的として制度を説明しています。

このSCS評価制度とSRSは、名前や目的が似て見えますが、同じものではありません。

SCS評価制度は、企業が満たすべき対策を段階的に示し、取引契約などで委託元が委託先に適切な段階を提示し、実施状況を確認することを想定した制度です。2026年4月にはIPAが要求事項・評価基準を公開しており、国内の取引先管理では今後参照される場面が増えると見られます。

一方のSRSは、外部公開資産や脅威シグナルを継続的に観測する商用サービスです。制度上のマークや認証ではなく、外から見えるリスクを点数やアラートで示します。

実務では、この2つを対立させる必要はありません。SCS評価制度で求められる対策水準、ISMSやSOC 2で確認する管理策、SRSで得られる外部観測の結果を組み合わせる方が自然です。たとえば、重要委託先にSCSの該当段階やISMS認証を確認しつつ、SRSで公開VPNやメール認証、漏えい認証情報の変化を継続監視する、という使い方です。

ただし、セキュリティ対策評価制度(SCS評価)とは？概要と求められる事を解説でも触れているように、制度を取っていないから直ちに取引不可、今すぐ取得しないと入札除外、といった雑な運用は避けるべきです。SRSでも同じで、スコアが一定点以下だから即取引停止という運用は、誤判定や説明責任の問題を生みます。

SRSを導入する企業が最初に決めるべきこと

SRSを導入する前に決めるべきことは、どのサービスを買うかではなく、何の判断に使うかです。自社の外部露出を減らしたいのか、グループ会社を横並びで見たいのか、重要委託先のリスクを可視化したいのか、経営会議で使う指標がほしいのかで、必要な機能は変わります。

自社管理を目的にするなら、外部資産の棚卸し、ASM、脆弱性管理との連携が重要です。スコアよりも、誰の持ち物か分からない資産をなくすこと、期限切れ証明書や古い公開サービスを短期間で潰すことが成果になります。

取引先管理を目的にするなら、ベンダー台帳、契約情報、重要度分類、データ取扱い、再委託、質問票、証跡管理との連携が必要です。外部スコアだけを見ても、委託先がどのデータを持っているのか、どの業務を止める可能性があるのかは分かりません。

経営報告を目的にするなら、点数の上下だけではなく、重大リスクの件数、改善に要した日数、重要委託先のカバー率、SLA違反、未対応のKEV、漏えい認証情報の件数など、行動につながる指標に変換する必要があります。

SRSの運用でよく失敗するのは、点数を担当者の成績表にしてしまうことです。点数が悪い部門を責める運用にすると、資産の登録を避ける、評価対象から外す、危険な例外を隠す、といった逆方向の動きが出ます。SRSは責任追及の道具ではなく、直すべき場所を見つける道具として使う方がうまく回ります。

取引先評価でSRSを使う場合の注意点

取引先評価でSRSを使う場合、最も重要なのはスコアの使い方です。SRSのスコアを契約審査の一要素にすることは有効ですが、それだけで合否を決めるのは避けるべきです。

米国商工会議所が公表しているSecurity Ratingsの公正性に関する原則では、透明性、品質と正確性、異議申し立てや修正のプロセス、適切な利用と開示が重要だとされています。SRSは、公開情報や商用データ、独自アルゴリズムを組み合わせて評価するため、データの古さ、誤った資産紐づけ、評価ロジックの変更によって結果が変わることがあります。

取引先にスコア改善を求める場合は、次のような運用が現実的です。

運用項目	望ましい対応
評価対象の確認	対象ドメイン、IP、ブランド、グループ会社の範囲を取引先と確認する
是正要求	点数ではなく、具体的なリスク項目と期限を示す
異議申し立て	取引先が誤った資産紐づけや修正済み事項を説明できる窓口を用意する
契約条項	重大脆弱性、漏えい、侵害疑い、再委託の通知義務を明文化する
定期確認	年1回の質問票だけでなく、重要委託先は継続監視する
例外承認	事業上必要な例外はリスク受容者、期限、補完策を記録する

SRSを導入すると、調達部門や法務部門から、何点以上なら契約してよいのかと聞かれることがあります。ここは慎重に答えるべきです。取引先の重要度、扱うデータ、接続方式、代替可能性、再委託の有無によって許容リスクは変わります。

たとえば、社内報の配信だけを委託する業者と、顧客データをAPI連携するSaaSでは、同じスコアでも意味が違います。前者なら改善計画を求めながら契約できる場合がありますが、後者ならMFA、暗号化、ログ提供、インシデント通知、データ削除、再委託管理まで確認する必要があります。

SRSで見るべき具体的な評価項目

SRSの評価項目はサービスごとに異なりますが、情報システム部門が実務で優先したい項目はある程度共通しています。

評価項目	リスク	優先度の考え方
既知悪用脆弱性	VPN、ファイル転送、Webサーバーなどの侵害入口になる	KEV掲載、公開悪用、インターネット露出があるものを最優先
リモートアクセス機器	認証情報窃取や初期侵入に使われやすい	管理画面公開、古いバージョン、MFA未適用を確認
メール認証	なりすまし、請求書詐欺、フィッシングに悪用される	SPF、DKIM、DMARCを段階的に整備
漏えい認証情報	パスワード再利用や不正ログインにつながる	重要アカウント、管理者、委託先アカウントを優先
公開ストレージ	機密情報や設定ファイルが露出する	クラウド公開設定、匿名アクセス、古いバックアップを確認
TLS・証明書	古い暗号や期限切れが信頼性を下げる	顧客向けサービス、API、決済関連を優先
不審通信・感染痕跡	社内端末やサーバーの感染疑い	EDR、プロキシ、DNSログと突合する

実務上は、スコアに大きく効く項目だけを追うのではなく、攻撃者にとって使いやすい項目から潰すことが大切です。特に、公開VPN、ファイル転送、リモートデスクトップ、管理画面、古いCMS、漏えい認証情報は、点数よりも先に確認した方がよい領域です。

SRSは外から見える結果を示すため、社内の修正チームはインフラ、クラウド、メール、ID管理、SOC、開発、委託先管理にまたがります。担当不明のままアラートだけ増えると誰も直さなくなります。運用開始時に、評価項目ごとの担当部門と期限を決めておくべきです。

SRSのスコアを改善するための実務ステップ

SRSのスコア改善は、表面的な点数上げではなく、外部から見える攻撃面の削減として進めるべきです。順番は次の通りです。

ステップ	内容	成果物
1	評価対象資産を確認する	ドメイン、IP、クラウド、グループ会社の一覧
2	誤紐づけを修正する	ベンダーへの修正依頼、除外理由の記録
3	重大リスクから対応する	KEV、外部公開、漏えい認証情報、メール認証の是正
4	担当者と期限を決める	リスク別のオーナー、SLA、エスカレーション
5	再発防止に入れる	変更管理、資産登録、ドメイン管理、クラウド公開レビュー
6	経営向けに翻訳する	重大リスク件数、平均修正日数、重要委託先カバー率

この中で地味に効くのが、ドメインと証明書の管理です。古いキャンペーンサイト、買収前のブランドサイト、検証用サブドメイン、退職者が作ったクラウド環境などは、台帳から漏れがちです。攻撃者は、こうした忘れ物をよく見ています。

メール認証も軽視できません。BitSightが2026年のレーティング更新でDMARCを評価に反映したように、メールなりすまし対策は外部からも分かりやすい防御状態です。SPF、DKIM、DMARCを整備し、最終的にはDMARCのポリシーをnoneからquarantine、rejectへ進める計画を持つべきです。

脆弱性対応では、CVSSの高低だけでなく、実際に悪用されているか、インターネットに露出しているか、重要システムに接続されているかを組み合わせます。脆弱性のニュースで日々出てくるCVEをすべて同じ重さで扱うと、現場は疲弊します。SRS、CISA KEV、EPSS、自社の露出状況を組み合わせて、直す順番を決める方が現実的です。

経営層にSRSを説明する際のポイント

経営層にSRSを説明する場合、技術項目の羅列ではなく、取引継続、顧客信頼、保険、監査、M&A、サプライチェーンの観点で伝える必要があります。

SRSのスコアは、経営会議で見せやすい指標です。ただし、点数だけを見せると、なぜ上がったのか、なぜ下がったのか、何をすればよいのかが分からなくなります。経営向けには、次のような形に変換すると使いやすくなります。

経営向け指標	意味
重要外部資産の棚卸し率	自社が外からどう見えているかを把握できているか
重大脆弱性の平均修正日数	攻撃可能な状態をどれだけ短くできているか
重要委託先の監視カバー率	自社に影響する取引先をどれだけ継続監視できているか
漏えい認証情報の対応率	不正ログインの入口を放置していないか
メール認証の整備率	なりすましやビジネスメール詐欺の土台を減らせているか
例外リスクの期限超過件数	リスク受容が放置に変わっていないか

Black Kiteのレポートが示すような集中リスクは、経営層に伝えやすいテーマです。クラウド、ID基盤、決済、ファイル転送、開発基盤、顧客管理SaaSなど、特定のベンダーに依存している領域は、1社の障害や侵害が複数部門に波及します。SRSは、その依存先の外部状態を監視する入口にはなりますが、代替策、バックアップ、契約、通知義務、データ分離まで含めて見なければ不十分です。

情報システム部門への示唆

情報システム部門がSRSを使うなら、最初から完璧なサードパーティリスク管理を作ろうとするより、自社と重要委託先の外部公開資産を正しく把握するところから始めるべきです。公開資産の棚卸し、担当部門の特定、重大リスクの是正期限、例外承認のルールがなければ、SRSはアラートを増やすだけのツールになります。

取引先管理では、重要度分類が欠かせません。全取引先を同じ粒度で見るのではなく、顧客情報を扱う、社内ネットワークに接続する、特権IDを持つ、業務停止時の影響が大きい、再委託が多い、といった条件で優先順位をつける必要があります。SRSのスコアは、その優先順位を補強する材料として使うべきです。

SRSで低いスコアが出た取引先に対しては、点数だけを突きつけるのではなく、具体的なリスク項目、確認したい証跡、希望する対応期限を示します。たとえば、公開VPNの重大脆弱性、DMARC未設定、漏えい認証情報、期限切れ証明書など、相手が直せる単位に分解することが大切です。

自社側では、SRSの結果を脆弱性管理、ASM、メールセキュリティ、ID管理、EDR/SIEM、契約管理に接続する必要があります。とくに、CISA KEVに掲載された脆弱性、インターネット公開された管理画面、漏えい認証情報は、通常の月次レビューでは遅い場合があります。重大リスクだけは、日次または週次で確認する運用が現実的です。

最後に、SRSは信用を作る道具にもなります。取引先からセキュリティチェックシートを受け取った時、自社のスコア、改善履歴、SCS評価制度への対応方針、ISMSやSOC 2の状況、脆弱性対応のSLAを整理しておけば、回答の説得力が増します。スコアをよく見せることが目的ではなく、外から見えるリスクを継続的に直していることを説明できる状態にすることが重要です。