自社DBライブ  | 
市場データ取得中...
直近7日 CVE 件数
…
自社DB (NVD)
🔴 緊急 (CVSS 9.0+)
…
Critical
🟠 重要 (CVSS 7.0–8.9)
…
High
🟡 警告 (CVSS 4.0–6.9)
…
Medium

🔍 脆弱性検索

提供: MyJVN API（IPA／JPCERT）
取得中…

🚨 CISA KEV — 実際に攻撃に悪用されている脆弱性

CISAカタログへ →

米国CISAが管理する「Known Exploited Vulnerabilities」カタログ。 実際に攻撃で悪用されたことが確認されている脆弱性のみが収録されているため、 最優先で対処すべき脆弱性の参考になります。

登録済み総数
…
All time
🦠 ランサムウェア悪用
…
Known Ransomware
直近7日に追加
…
最新
取得中…

📦 ソフトウェアカテゴリ

自社DB (endoflife.date)
🌐Webサーバー
🗄️データベース
⌨️言語
🔧フレームワーク
📝CMS
📨ミドルウェア
🖥️仮想化
⚙️DevOps
🔐暗号化

🌐 Webサーバー — サポート期限情報

自社DBライブ

各製品のチェックボックスで期限切れバージョンの表示／非表示を切り替えられます。

取得中…

⚠ OSサポート期限アラート（90日以内）

自社DB (endoflife.date)

管理対象OSのうち、直近90日以内に期限切れとなったものと 今後90日以内に期限が来るものを一覧表示します。

取得中…

📋 OS一覧

自社DB (endoflife.date)

サポート対象の全OSを一覧表示します。期限切れは行が薄く表示されます。

取得中…
🚧
改定予定 — 前提の切り分けが不足しています
自らサービスを公開したので技術的に確認したいという自発的な診断と、 監査や取引先要求によって実施が求められる受動的な診断では、 目的・範囲の決め方・必要な成果物が別物です。前者は範囲も深さも自分で決められますが、 後者は監査人や取引先が範囲を決めます。 現状の記載はこの2つを明確に分けておらず、証跡目的の側に寄っています。 この軸を前提に置いて整理し直す改定を予定しています。

🧭 脆弱性診断を受けたい方へ — 事業者の選び方

本サイトは特定の事業者を推薦しません

「脆弱性診断を受けたい」と思ったとき、多くの解説は IPA の情報セキュリティサービス基準適合サービスリスト を案内して終わります。しかしそのリストは「誰に頼めるか」の出口であって、 「何を、どこまで、どう頼むか」を決める部分は空白です。 発注側がここを決められないから、見積を並べても比較にならない。このページはその前段を扱います。

このページの立ち位置。 特定の事業者名を挙げて「おすすめ」を示すことはしません。個別企業の得意分野に関する評価は 公開された一次情報で裏付けられず、時間とともに実態から乖離するためです。 代わりに、読者が自分で見分けられるようになるための判断軸と、 公開情報で検証できる確認事項を提供します。 最終的な事業者の絞り込みには、ページ末尾の公的リストをご利用ください。

① まず、自分が何を買おうとしているのかを決める

ここが決まらないと価格は比較できない

「脆弱性診断」という同じ言葉で呼ばれていても、発注の動機によって実際に買っているものが違います。 価格差の大部分はここから生まれます。安いから手抜き、高いから丁寧、という単純な話ではありません。

あなたの状況実際に買っているもの価値の源はどこにあるか
カード情報を扱う
（PCI DSS）		 制度上有効な資格 認定そのもの。四半期の外部スキャンは ASV 認定事業者でなければ要件を満たせません。技術力が高くても認定がなければ無効です（詳細は②）
上場企業の監査対応・
取引先への提出		 監査人と取引先に通る証跡 報告書の様式と、発行元の説明力。監査人や調達部門が認知している発行元であること自体に実務価値があります。この場合、発注側の購入動機として診断の深さが二次的になっていることがあり、そこを自覚しておくと判断を誤りません
チェックシートを
埋めたい		 「実施した」という事実 単価。目的が明確なら合理的な選択です。ただし「診断を受けた」と「安全である」は別物なので、経営判断の材料としては使えません
実際に危ないところを
見つけたい		 発見された脆弱性 担当する診断員の技量。会社の看板ではなく個人のスキルに依存します。だからこそ「誰が担当するか」を契約前に確認する意味があります
攻撃されたらどうなるかを
知りたい（ペネトレ）		 攻撃シナリオの検証結果 シナリオ設計力。脆弱性の列挙ではなく「侵入から目的達成まで到達できるか」を見るため、目的（何が守られていれば合格か）の定義が成果を左右します
「監査対応だから大手」は手抜きではありません。 監査人・調達部門が認知している発行元であることには実際の業務価値があります。 ただしその選択をしたとき、自社の購入動機が主に証跡であって発見の網羅性ではないという自覚があるかどうかで、 あとから「診断を受けたのに侵害された」という事故の受け止め方が変わります。 これは事業者の役務の質の話ではなく、発注側が何を発注したかの話です。

② 制度が事業者を指定するのか、自由に選べるのか

ここを間違えると発注が無駄になる

「制度対応のために診断を受ける」場合、まず確認すべきは制度が診断の実施者を指定しているかどうかです。 指定がある場合、認定を持たない事業者に頼んでも制度上は無効になります。 逆に指定がない制度は大半で、そこでは自由に選べます。実際に一次情報を確認すると、 事業者が指定されているのは例外的なケースだけでした。

制度診断実施者の
指定		内容
PCI DSS
要件 11.3.2		 ASV 必須 四半期ごとの外部脆弱性スキャンだけは ASV（Approved Scanning Vendor）認定事業者が必須。 規格本文が実施者を名指しで指定している、ほぼ唯一の例です。ASV はスキャン製品ごとに PCI SSC の承認を受ける仕組みなので、認定一覧が「会社名／製品名」の併記になっています
PCI DSS
11.3.1 / 11.3.1.3 / 11.3.2.1 / 11.4		 自由 内部スキャン・重大変更後のスキャン・ペネトレーションテストは ASV も QSA も不要。 11.3.1.3 / 11.3.2.1 / 11.4.3 / 11.4.5 には not required to be a QSA or ASV と明記されています。 四半期の内部スキャン（11.3.1）についても「内部脆弱性スキャンの実施に QSA や ASV を用いることは要求されない」と注記されています。 実施者に関する要求は「有資格の担当者」と「診断対象からの組織的独立性」で、自社要員でも可（ただし対象システムを運用している当人は不可）。 なお 11.4.3 には方法論への準拠・12か月ごと・重大変更後といった実施者以外の要件も併せて定められています
SCS評価制度 ★4
2027年3月頃 運用開始予定		 実質指定 ★4 の「技術検証」を行う事業者は、経産省の情報セキュリティサービス基準適合サービスリスト（脆弱性診断サービス）の登録要件を満たすことが求められます。技術検証責任者は同リストの技術責任者を想定。適合リストが初めて実質的なゲートになる制度です
SOC 2 指定なし 診断実施者の要件は一切ありません。そもそも規準本文が診断を要求していません（③参照）
ISO/IEC 27001（ISMS） 指定なし 診断実施者の要件はありません。審査員側にも脆弱性診断の実施能力は制度上要求されていません（ISO/IEC 27006-1:2024）
プライバシーマーク 指定なし そもそも脆弱性診断が要求事項に含まれていません
NIST CSF / SP 800-171 指定なし SP 800-171A は評価を「柔軟」とし、第三者評価でも政府が主管する評価でも可としています。評価者の資格要件はありません
FISC 安全対策基準 指定なし 認定制度ではありません。ただし金融庁ガイドラインは TLPT について、大手金融機関等が参照すべき「対応が望ましい事項」として 「テスターの資格や経歴の確認等のバックグラウンドチェックを含む」業者選定を挙げています — 認定に頼らず発注側が確認する、という設計です
ISMAP 確認できず 監査を行うのは ISMAP 登録監査機関（8機関）ですが、脆弱性診断の実施者要件は公開範囲では見つかりませんでした（すべての詳細管理策は JIS 規格の購入を条件とする限定配布のため未確認）
PCI DSS の非対称は実務で最も誤解されています。 同じ「外部スキャン」でも、四半期の定期スキャン（11.3.2）は ASV 必須、 重大変更後のスキャン（11.3.2.1）は ASV 不要です。後者は CVSS 4.0 以上の解消が判定線として明記されています。 「PCI DSS なら全部 ASV に頼まないといけない」という思い込みで、 本来自由に選べる内部スキャンやペネトレーションテストまで選択肢を狭めているケースがあります。
そもそも「準拠が必要か」を決めるのは PCI SSC ではありません。 PCI SSC は「準拠および準拠の検証を求めるかどうかは、カードブランドやアクワイアラなど コンプライアンスプログラムを運営する組織の裁量による」と明記しています。 加盟店レベルの判定と、SAQ（自己問診）で足りるか ROC（QSA審査）が必要かは、契約先のアクワイアラに確認する事項です。

出典: PCI SSC — PCI DSS / QSA・ASV の定義、 ASV 公式一覧、 QSA 公式一覧、 PCI DSS v4.0.1 公開（現行版は v4.0.1 のみ）、 IPA — SCS評価制度

QSA / ASV の一覧は PCI SSC の公式リストで確認してください。 国内向けに JCDSC（日本カード情報セキュリティ協議会） の一覧もありますが、同ページ自身が「当協議会会員のみ掲載しています」と明記しており、 網羅的ではありません。JCDSC は特定の事務所や電話回線を持たず、会員企業のボランティアで運営されている民間の任意団体で、 認定の現況についても PCI SSC 側での確認を案内しています。

③ 事業者のタイプを見分ける

実名ではなく類型で整理する

国内の診断事業者はおおまかに4つの類型に分かれます。 どれが優れているかではなく、①で決めた「買っているもの」とタイプが合っているかが問題です。 1社が複数の類型にまたがることもあります。

A. 認定必須型
PCI SSC の QSA / ASV 認定を持つ事業者
強み
制度上有効な成果物を出せる。他に代替手段がない領域を持つ
向いている
PCI DSS の四半期外部スキャン、ROC 作成
向いていない
PCI DSS の枠外の診断。認定は「制度要件を満たす」ことの証明で、診断の深さの証明ではありません
確認すること
PCI SSC 公式リストに現在も掲載されているか。ASV は製品名まで一致しているか
B. 大手SI・監査対応型
総合ITベンダー、大手コンサル系、独立系専業大手
強み
報告書の様式が監査提出・社内稟議に耐える。要件定義から一括で引き受けられる。監査人や調達部門の認知度が高い
向いている
監査対応、官公庁・金融案件、社内に推進体制がなく丸投げしたい場合
向いていない
予算が限られる場合。また実作業が再委託されることがあり、その場合看板と実作業者が別になります
確認すること
再委託の有無と再委託先。実際に手を動かす担当者の経歴。過去の類似案件の業種
C. 低価格・ツール主体型
SaaS型スキャンサービス、定額診断サービス
強み
安く速い。継続的・高頻度に回せる。既知脆弱性と設定不備の検出はツールが得意な領域で、実際に有効です
向いている
定期的な健全性確認、リリースごとの回帰確認、予算内で「まず状況を知る」段階
向いていない
認可制御の不備、業務ロジックの悪用、権限昇格などツールが原理的に検出できない類。これらは実被害に直結しやすい種類でもあります
確認すること
手動検査の工数が含まれるか。検出結果に対する誤検知の精査を誰がやるか。ログイン後の画面を診断できるか
D. 高難度・攻撃者視点型
ペネトレーションテスト・レッドチーム専業
強み
シナリオ設計と侵入経路の連鎖の検証。脆弱性の列挙ではなく「目的達成に到達できるか」を示せる
向いている
通常の診断を回し切って指摘が枯れてきた組織。攻撃を受けた前提での耐性を経営に示したい場合
向いていない
網羅的な脆弱性一覧が欲しい場合。ペネトレは網羅性を目的としていないので、監査提出用の一覧としては噛み合いません。基礎的な対策が未整備な段階でも費用対効果が悪い
確認すること
ゴール（何に到達したら成功とするか）を誰が定義するか。担当者の実績。ペネトレと脆弱性診断を混同した提案になっていないか
D は「上位互換」ではありません。 ペネトレーションテストと脆弱性診断は目的が違います。ペネトレは深さを取るために網羅性を捨てる手法なので、 「一番良いものを頼もう」という理由でペネトレを選ぶと、監査に出せる一覧が出てこないという食い違いが起きます。 逆に、脆弱性診断を何年も回して指摘が設定不備ばかりになってきた組織にとっては、 脆弱性診断の追加発注はほぼ情報を生みません。

④ 資格の読み方 — 資格はフロアであってランキングではない

「あれば安心」ではなく「無いなら理由を聞く」

提案書に並ぶ資格名は、診断の実力を保証するものではありません。 有資格者は国内に数千〜数万人規模で存在し（情報処理安全確保支援士の登録者は2026年4月1日時点で26,453名）、 資格の有無で腕を序列化することはできません。 ただしまったく無い場合に理由を尋ねる材料にはなります。読み方は次の通りです。

系統代表的な資格何を示していて、何を示していないか
監査・管理系 CISA、CISM、CISSP、情報処理安全確保支援士（登録セキスペ）、公認情報セキュリティ監査人、ISO 27001 主任審査員 統制の設計・評価、マネジメント、監査手続の知識を示します。手を動かして脆弱性を見つける能力の証明ではありません。 報告書を経営や監査人に説明する場面では有効。実際、SCS評価制度の「セキュリティ専門家」に求められる資格はこの6つであり、制度が想定している役割が管理・確認側であることが分かります （資格に加えて力量の維持、制度が定める研修の受講、事務局への登録が必要です。詳細要件は公表待ちです）
実技系 OSCP、OSEP、OSWE、OSWA、CEH、GIAC 系（GPEN / GWAPT 等） 実際に手を動かして侵入・攻撃を成立させた実績を示します。報告書の品質や、経営への説明力は保証しません。 ペネトレーションテストを発注するなら見るべきはこちら側
経営・業務系 中小企業診断士 セキュリティ資格ではありません。経営課題の整理と、経営者の言葉で話せることを示します。 「何から手をつけるべきか分からない」段階の中小企業にとっては、技術資格より役に立つ場面があります。 一方、診断の技術的な深さとは無関係です
重要 — IPA 適合サービスリストの技術責任者要件は、資格が無くても満たせます。 経産省「情報セキュリティサービス基準」第4.1版の脆弱性診断サービスの技術要件は、 次のいずれか1つを満たす技術責任者を業務に従事させることです。
（ア）例示に定める資格又は同等のものを有する
（イ）専門家コミュニティにおける講師・リーダー経験、又は高等教育機関における講師経験
（ウ）過去3年間に合計5件以上の診断実績（契約件数。包括的な契約の場合は1年間分で1件とみなす。診断方法は問わない）
（エ）例示に定める研修を修了している
つまり（ウ）だけでも技術要件を満たせます。「診断方法は問わない」と明記されているため、 資格の保有は必須ではありません。「適合リストに載っている＝有資格者が診断する」ではないという点が要点です。

ここから「だから適合リストは事業者の絞り込みには使えない」と考えるかどうかは本サイトの見方です。 基準には技術要件のほかに、サービス仕様の明示・品質管理者の割当・品質管理マニュアルの整備といった 品質管理要件も定められており、掲載されていること自体には意味があります（⑥参照）。

出典: 経産省 情報セキュリティサービス基準 第4.1版（PDF）、 同 審査登録制度、 IPA SCS評価制度（セキュリティ専門家の要件）
※ 資格の列挙は基準本体とは別の文書「技術及び品質の確保に資する取組の例示」に示されています。 その最新版の原文は本サイトで取得できていないため、上記の資格名は制度解説として一般的に知られている範囲を記載しています。 発注判断に用いる場合は例示の原文をご確認ください。

⑤ 提案書を受け取ったら聞くこと

見積を比較可能にするための質問

診断の見積は、1ドメイン単価・1画面単価・1リクエスト単価・人日単価が事業者ごとにバラバラで、 同じ対象なのに桁が違って見えることがあります。次の質問に答えてもらえば、比較できる形に揃います。 答えを渋る項目があること自体が情報です。

  • 1. 見積の単位は何ですか。その単位はどう数えていますか ◯ 「画面数。1画面＝1URLではなく、入力を伴う機能単位で数えます」など定義が返ってくる
    ✕ 「一式」で内訳が出てこない 単位の定義が揃わないと他社比較は不可能です。ここを揃えるだけで比較できるようになります
  • 2. ツールによる検査と、人が手で行う検査の比率・工数はどれくらいですか ◯ 工数の内訳が示され、手動で見る観点（認可、権限昇格、業務ロジック等）が具体的に挙がる
    ✕ 「独自ツールと専門家の組み合わせ」で終わる 価格差の最大要因です。ツール主体が悪いのではなく、そう認識して買っているかが問題です
  • 3. 実際に診断を担当するのは誰ですか。再委託はありますか ◯ 担当者の経験年数・実績領域が示される。再委託がある場合は先を明示する
    ✕ 「弊社の認定資格保有者が対応します」だけ 診断の質は個人に依存します。会社の看板と実作業者が別なことは珍しくありません
  • 4. 報告書に再現手順は付きますか。サンプルを見せてもらえますか ◯ 過去案件のマスキング版サンプルが出てくる
    ✕ 「機密なので出せない」（マスキング版すら出ない） 報告書は成果物そのものです。再現手順がないと修正の検証ができません
  • 5. 指摘のリスク評価は何を根拠にしていますか。CVSS だけですか ◯ CVSS に加えて、対象システムでの実際の影響・悪用条件を評価する旨の説明がある
    ✕ CVSS スコアの一覧しか出てこない CVSS は汎用の深刻度指標で、その環境での実リスクとは別物です
  • 6. 修正後の再テストは費用に含まれますか。範囲と回数は ◯ 含まれる／含まれないが明記され、範囲（指摘箇所のみか周辺も見るか）まで定義されている
    ✕ 契約書に記載がなく「都度相談」 再テストが有償だと、修正を確認しないまま完了扱いになりがちです
  • 7. 診断で得た情報の取り扱い・保存期間・削除はどうなりますか ◯ 保存期間と削除手続が契約に定義されている
    ✕ NDA だけで、成果物・生データの扱いに触れていない 診断結果は攻撃者にとって最も価値の高い情報です
  • 8. 診断対象がクラウド・SaaS の場合、事業者側の許諾は必要ですか ◯ 対象環境ごとに必要な手続を把握している
    ✕ 発注側に丸投げされる、または不要と断言される 環境によっては事前申請や禁止事項があります。無断実施は契約違反になりえます
公開情報で裏が取れる確認事項。 主観的な評判に頼らず、次は自分で確認できます — PCI SSC の QSA / ASV 公式リストへの現在の掲載、 IPA 適合サービスリストのどの区分に載っているか（ペネトレーションテストのオプション有無まで確認可）、 官公庁調達の落札実績（政府の調達ポータルで公開されています）、 脆弱性の発見・報告実績やカンファレンス登壇、CVE 採番機関（CNA）かどうか、公開された料金表の有無。
実装予定。数十社規模の事業者について、上記の検証可能な客観指標だけを並べた一覧表を準備中です。 主観的な評価は掲載しません。

⑥ IPA のリストは何を保証していて、何を保証していないのか

「役に立たない」と感じる理由には制度上の根拠があります

情報セキュリティサービス基準適合サービスリスト は、脆弱性診断の発注先を探す入口としてよく案内されます。 ただし制度の仕様を確認すると、絞り込みには使えない構造になっていることが分かります。 リストを否定するためではなく、正しい用途を理解して使うために整理します。

序列が付かない
基準にランクや段階評価が存在しません。脆弱性診断サービスは約180件（うちペネトレーションテストのオプション付きが約50件）が すべて同じ「適合」表示です。絞り込むための情報が制度側から供給されない — これが「役に立たない」と感じる正体です
診断員のスキルは対象外
基準が求めるのは技術責任者を業務に従事させ、要件を満たす者ごとの人数を明らかにすることです。 実際に案件を担当する診断員の資格・経験は審査対象ではありません。しかもリストPDFの掲載項目に 人数欄も資格欄もありません
IPA は検証していない
審査・判定を行うのは JASA（日本セキュリティ監査協会）で、IPA は 「この審査・判定に IPA は何ら関与しておりません」「サービス基準適合性の再確認・検証等を行っておりません」と明記しています。 JASA 自身も「本制度はサービスの品質を保証するものではありません」と明記
継続確認はごく一部
2025年度のサーベイランス（登録内容の評価。2025年9〜12月に実施）の対象は11サービスでした（登録件数は2026年6月時点で約400件）。 そのうち6件に改善要求が出ており、内容には「技術責任者が業務を離れたのに変更申請が未提出」 「新たに着任した3名のうち2名の保有資格が例示に定める資格ではなかった」が含まれます。 登録情報が実態と乖離しうることが、制度運営者自身の記録で確認できます
未掲載＝低品質ではない
登録料は年18万円（ペネトレーションテストを含む場合27万円）＋審査料4万円／サービス（いずれも税別）。 費用が参入障壁になるため、技術力の高い小規模事業者や個人事業主が費用面で載らない構造があります。 リストに無いことは品質の否定ではありません
価格情報がない
掲載項目にサービス料金の欄はありません。相見積もりの前段としては機能しません
粒度が事業者次第
登録はサービス単位です。「Webアプリ診断」「プラットフォーム診断」「スマホアプリ診断」を 3件に分けて登録する事業者と、「脆弱性診断サービス」1件にまとめる事業者が混在します。 件数は実力や規模を表しません
情報が最大3か月遅れる
台帳登録は年4回（3月・6月・9月・12月の各下旬）、リストPDFの更新も同頻度。登録の有効期間は2年です
では何に使えるのか。 「最低限の体制と品質管理プロセスを、費用を払って第三者に確認させた」ことの確認には使えます。 つまり候補を絞り込むための入口ではなく、候補が既にあるときの一次スクリーニングです。 ①〜④でタイプと確認事項を決めたあとに参照するのが正しい順序で、 リストを起点にすると約180件から手がかりなく選ぶことになります。
中小企業向けサイバーセキュリティ対策支援者リストは用途が違います。 こちらは個人単位のリスト（2026年8月時点で143名）で、 指導テーマは「規程整備／情報管理・リスク分析／クラウド安全利用／インシデント対応／従業員教育」の5区分。 脆弱性診断・ペネトレーションテストのテーマが存在しません。 掲載対象は国家資格「情報処理安全確保支援士」の保有者に限られますが、 掲載内容そのものには第三者審査がなく自己申告で、IPA は「何らの責任を負うものではありません」と明記、 制度自体も「試行公開」段階と位置づけられています。 マネジメント面の相談相手を探すリストであり、技術診断の発注先リストではありません。
制度側も限界を認識しています。 経済産業省は2026年6月5日に公表した検討会の中間とりまとめで、 新制度「サイバーセキュリティ・サービス認定制度」を 「現行の登録制度に新たな要件を付加するのではなく、現行の登録制度の二階部分として上乗せする形で、 国の行政機関等が運営することを想定」して整備する方針を示しました。制度開始は2027年度中を目指すとされています。 同とりまとめは現行制度について、事業者の「適切な運営体制」に関する要件が 「反社会的勢力等への関与がないことのみ」である点を課題として挙げており、 新制度では ISMS 認証の取得や SCS評価制度★4以上の取得を要件とする案が示されています。

出典: IPA 情報セキュリティサービス基準適合サービスリスト、 IPA 中小企業向けサイバーセキュリティ対策支援者リスト、 JASA 情報セキュリティサービス審査登録制度、 JASA 登録料・審査料、 経産省 サイバーセキュリティ・サービス事業者の信頼性強化に向けた検討会 中間とりまとめ

⑦ 発注する前に、自分で潰しておけること

無料で分かることに診断費用を使わない

診断報告書に並ぶ指摘のうち、かなりの割合は発注前に自分で確認できる種類です。 公開ポート、TLS の設定、サポート切れのバージョン、既知の CVE。 これらを先に潰しておくと、診断の工数をツールでは見つけられない領域（認可制御、業務ロジック、権限昇格）に寄せられます。 同じ予算で得られる情報量が変わります。

STEP 1
公開状態を確認
意図せず開いているポート、外部から見える機器を把握する。診断で「発見」される前に自分で知っておく
STEP 2
TLS 設定を確認
古いプロトコルや弱い暗号スイートは定番の指摘。設定変更だけで解消するものが多い
STEP 3
サポート期限を確認
EOL に達したバージョンは、それ自体が指摘事項。個別の CVE を待たずに判断できる
STEP 4
既知 CVE を確認
使用中のソフトウェアに既知の脆弱性がないか。特に実際に悪用が確認されているもの（KEV）
STEP 5
診断範囲を決める
上を潰した上で、残る不確実性がどこかを言語化する。これが RFP の中身になる
本サイトの「プラットフォーム診断対象チェック」タブで STEP 1・2 を、 「構成チェック (SBOM)」タブで STEP 3・4 を、ブラウザ内で確認できます（入力内容はサーバへ送信しません）。 「OSサポート期限」タブと「KEV (悪用中)」タブも同じ用途に使えます。
ただし、これは診断の代わりにはなりません。 自己確認で分かるのは既知の脆弱性と設定不備までで、 認可制御の不備・業務ロジックの悪用・複数の弱点を連鎖させた侵入経路は見つかりません。 「指摘が0件」は安全の保証ではないという点は、診断を受けた場合も同じです。

⑧ 事業者を探すための公的リスト

①〜⑦を踏まえた上で参照してください
リスト運営用途と注意点
情報セキュリティサービス基準
適合サービスリスト		 JP IPA
審査は JASA		 脆弱性診断サービスの一次スクリーニング。序列は付かず、担当診断員のスキルと価格は対象外。⑥参照
ASV 公式一覧
QSA 公式一覧		 INT PCI SSC PCI DSS 対応ではこちらが一次情報。ASV は製品単位で承認されるため、会社名だけでなく製品名まで確認が必要
JCDSC 国内 QSA・ASV 一覧 JP JCDSC 国内事業者を探す補助。「当協議会会員のみ掲載」と明記されており網羅的ではありません。認定の現況は PCI SSC 側で確認
ISMAP 登録監査機関リスト JP ISMAP 政府調達向けクラウドサービスの監査機関（8機関）。脆弱性診断の発注先リストではありません
ISMS 認証機関リスト JP ISMS-AC ISO/IEC 27001 の認証機関（27機関）。組織が自由に選べます。診断事業者のリストではありません
中小企業向けサイバーセキュリティ
対策支援者リスト		 JP IPA 個人単位・自己申告・審査なし。指導テーマに脆弱性診断が含まれません。マネジメント支援の相談相手を探す用途
本ページの記載は公開されている一次情報に基づく整理であり、特定の事業者・サービスの推奨や品質保証を意図するものではありません。 制度の要件は改定されます。発注の判断に用いる場合は、リンク先の原文で最新の内容をご確認ください。
🚧
改定予定 — 監査実務の変化を反映できていません
本ページは「制度文書が何を要求しているか」の整理にとどまっており、 運用実務が向かっている先を扱っていません。 年1回や四半期ごとに証跡を揃えるスナップショット型の確認から、 パッチ適用状況やガイドラインへの対応状況を常時可視化して継続的に確認できる状態へ、 という方向を踏まえた改定を予定しています。 制度が求める頻度（例: PCI DSS の四半期スキャン）は下限であって目標ではない という整理を加える予定です。

🏅 認証・監査制度の比較 — ISMS / SOC 2 / Pマーク / NIST / PCI DSS

脆弱性診断の観点から整理する

「取引先から SOC 2 レポートを求められた」「ISMS と Pマークはどう違うのか」「NIST 準拠と言われたが認証があるのか」。 これらは同じ土俵にある選択肢ではありません。認証・保証報告書・フレームワーク・登録制度が混ざっています。 このページは、まず種別の違いを整理し、そのうえで 各制度が脆弱性診断を実際にどこまで要求しているのかを一次情報で確認します。 後者は実務での思い込みと最もズレている部分です。

① そもそも種別が違う

「どれが一番いいか」という問いが成立しない理由
第三者認証
認定を受けた機関が審査し、認証書を付与する。有効期間と更新審査がある
  • ISO/IEC 27001（ISMS） — ISMS-AC 認定の認証機関27機関から自由に選べる
  • プライバシーマーク — JIPDEC と指定審査機関。ただし申請先は原則として業種・所在地で割り当てられる
保証報告書
監査人が意見を表明した報告書。認証書ではなく、合否でもない
  • SOC 1 / SOC 2 / SOC 3 — 発行できるのはライセンスを持つ会計事務所のみ。日本では JICPA の保証業務実務指針3702 に基づき監査法人が発行
  • 意見は4類型（無限定 Unmodified ／ 限定付 Qualified ／ 不適正 Adverse ／ 意見不表明 Disclaimer）。「合格」という概念がありません
フレームワーク（参照モデル）
やるべきことの地図。第三者が証明する仕組みが存在しない
  • NIST CSF 2.0 — NIST 自身が「認証も推奨も提供せず、適合性評価プログラムを開発する予定もない」と明言
  • NIST SP 800-53 / SP 800-171 — 管理策のカタログ・技術基準
  • FISC 安全対策基準 — 業界の自主基準。FISC 自身「適合性評価認定制度のようなものもありません」（現行は第14版・2026年3月）
登録・審査を伴う制度
特定の目的（調達要件など）のために、審査を経て名簿に載せる
  • PCI DSS — 準拠の検証義務を課すのはカードブランドとアクワイアラ（PCI SSC ではない）
  • ISMAP — 政府調達向け。登録監査機関8機関による監査
  • CMMC — 米国防衛調達。2026年7月13日から Phase II が停止中
  • SCS評価制度 — 2027年3月頃 運用開始予定
「SOC 2 認証を取得した」は誤りです。 SOC 2 は examination（検証）であり、成果物は service auditor の意見が付いた保証報告書です。 AICPA & CIMA が発行する Journal of Accountancy（2026年2月）の記事は、 「compliance ── SOC 2 の検証では決して使われない用語」と括弧書きで断じています。 国内の大手監査法人4社の SOC 2 サービス紹介ページは、いずれも「保証報告書」「保証業務」と表記しています。 一方、事業者側のプレスリリースでは「認証」表記が混在しています。
◯ 推奨 SOC 2 報告書を受領した／SOC 2 検証を受けた
✕ 誤用 SOC 2 認証を取得した／SOC 2 certified／SOC 2 compliant
「無限定意見（unmodified opinion）＝例外ゼロ」でもありません。 AICPA 自身が「これは例外が無かったことを必ずしも意味せず、 指摘された例外があったとしてもそれが意見に否定的な影響を与えなかったことのみを意味する」と明記しています。 報告書を受け取る側は、意見の種類だけでなく本文の例外事項（exceptions）を読む必要があります。

② 誰が認証・報告書を出せるのか

発注先を間違えないための一覧
制度発行できる主体補足
SOC 2 ライセンスを持つ会計事務所（CPA firm）のみ。日本では JICPA の保証業務実務指針3702 に基づく監査法人・公認会計士 AICPA が公開する利用者向けチェックリスト（冒頭に「例示目的のみ」と付記されたもので、専門基準そのものではありません）に「Only a licensed CPA firm can issue a valid SOC 2 report」と明記。 SI企業やセキュリティ事業者は SOC 2 報告書を発行できません。 それらの企業が担うのは準備支援と、監査人に証拠として提出する脆弱性診断報告書です。ここは混同されやすい点です
SOC 2
（日本の枠組み）		 JICPA 保証業務実務指針3702 に基づく監査法人 「情報セキュリティ等に関する受託業務の Trust に係る内部統制の保証報告書に関する実務指針」。 評価規準として AICPA の Trust Services Criteria を名指ししています。 国内の大手監査法人4社すべてが提供中。日本で SOC 2 が広まっていないのは制度が無いからではなく、需要側の事情です。 なお JICPA と CPA Canada のライセンス契約は2020年12月末で終了しており、 2021年以降に Trust サービス業務を行う監査法人は個別に対応が必要とされています
ISO/IEC 27001
（ISMS）		 ISMS-AC の認定を受けた認証機関（27機関） 組織が認証機関を自由に選べます。なお認定機関は ISMS-AC だけではなく JAB 認定の範囲も少数存在しますが、 実務上は ISMS-AC 認定が事実上の標準です
プライバシーマーク JIPDEC（付与機関）と指定審査機関 申請先は原則として業種または本社所在地で決まり、申請者が自由に選べません（一部の県や業界団体の会員には選択肢があります）。 また JIPDEC 自身も審査を実施します。ISMS のような「認定機関と認証機関の分離」という 国際的な適合性評価の原則が適用されていない構造です
PCI DSS QSA（審査・ROC 作成）／ASV（外部脆弱性スキャン）／ISA（自組織内の内部審査） いずれも PCI SSC の認定。QSA と ASV は役割が完全に別です。 なお加盟店レベルの判定と SAQ／ROC の区分を決めるのは PCI SSC ではなくカードブランドとアクワイアラです
NIST CSF /
SP 800-171		 存在しません NIST の FAQ に「NIST does not offer certifications or endorsements of CSF-related products, implementations, or services, and there are no plans to develop a conformity assessment program.」と明記。 CSF 2.0 の本文には certif という語が一度も登場しません。 NIST 自身も「NIST は要求事項の実装状況や準拠状況を特定・追跡しない」と明言しています。 「NIST 認証」は存在しません
FISC 安全対策基準 存在しません FISC が金融庁のスタディ・グループに提出した資料（2014年12月）に「“自主基準”であるため強制力はありません。また、 第三者あるいは FISC による『適合性評価認定制度』のようなものもありません」と明記されており、 現在も FISC・金融庁のいずれにも認証制度の記載は見当たりません。 現行は第14版（2026年3月）。金融庁のガイドラインが参考資料として参照する業界共通の拠り所という位置づけです
ISMAP ISMAP 登録監査機関（8機関） 2025年12月以降で3機関増え、2026年6月には監査法人以外が初めて登録されました。 ISMAP-LIU は管理策基準の外部監査の範囲が縮小される点が最大の違いです（ガバナンス基準・マネジメント基準の外部監査は毎年必要で、加えて全管理策の内部監査を3年に一度実施することが求められます）
CMMC Level 2 には自己評価とC3PAO による認証評価の2経路がある／Level 3 = DCMA DIBCAC 🔴 2026年7月13日から Phase II が停止中。現在指定できるのは Level 1（自己評価）と Level 2（自己評価）のみ。 停止期間中は SP 800-171 Rev.2 が適用されます。DFARS 252.204-7012 の要求自体は有効です
SCS評価制度
2027年3月頃予定		 ★3 = 登録されたセキュリティ専門家が自己評価を確認／★4 = 指定された評価機関＋技術検証事業者 ★1・★2 は SCS評価制度ではなく SECURITY ACTION の枠組みです（誤解の多い点）。 評価機関の公表は2026年12月頃、専門家は2027年1月以降の予定。 経産省は「制度開始時点において★を取得している企業は存在しません」と明記しています
SOC 2 が海外展開で効く理由。 北米の企業との取引、特にクラウド・SaaS・データ処理系のサービスでは SOC 2 の type 2 報告書の提出を求められることが増えています。 ISO/IEC 27001 を持っていても別途求められるのは、両者が別のものを見ているからです — ISMS は「組織のマネジメントシステムが機能しているか」、 SOC 2 は「特定のサービスの統制が、一定期間にわたって有効に運用されていたか」。 後者は委託先を評価する側の関心に直接答える形になっています。

※ 現行の AICPA 文書での正式表記は小文字の type 1 / type 2 です。 「Type I / Type II」というローマ数字表記は、旧 SAS No. 70 時代の呼称が慣習として残ったものです。

③ 各制度は脆弱性診断をどこまで要求しているのか

一次情報で確認すると、実務の思い込みと大きくズレます

「ISO 27001 だから脆弱性診断が必要」「SOC 2 だからペネトレーションテストが必須」。 実務ではよく聞きますが、規格・規準の本文を確認すると、そう書いてある制度はごく一部です。 要求の強さには4段階あり、混同すると「制度が求めているから」という理由で 実際には裁量のある部分を固定してしまいます。

レベル1
規格本文で明示的に義務
PCI DSS — 要件11で明確に義務化。内部スキャン四半期（11.3.1）、外部スキャン四半期（11.3.2、ASV必須）、 重大変更後のスキャン（11.3.1.3 / 11.3.2.1）、ペネトレーションテスト（11.4）。 11.3.2.1 は CVSS 4.0 以上の解消を判定線として明記
NIST SP 800-171 — Rev.2 の 3.11.2 / 3.11.3、Rev.3 の 03.11.02。 米国防衛調達では DoD が Rev.3 適用に備えた具体値を示しています： スキャンは月次以上、high（critical を含む）は30日・moderate は90日・low は180日以内に修正。 ただし契約上の最低要件は現在も Rev.2 です
SCS評価制度 ★4 — 「技術検証」として制度に組み込み。インターネット公開機器（例：VPN装置、ルータ）を対象に ポートスキャンと既知脆弱性の検査を実施し、CVSS 7.0 以上の有無が確認事項として例示されています （技術検証ガイド（仮称）の作成時点イメージとして示されたもので、完成後の文書とは異なる可能性があると注記されています）。 直近の脆弱性検査の実施結果を証跡として提出することで検証の代替とみなすことも検討されています
レベル2
規準の「着眼点」に登場
SOC 2 — Trust Services Criteria の規準（criteria）本文には、「脆弱性スキャン」も「ペネトレーションテスト」も登場しません （CC7.1 の規準本文には「新たに導入された脆弱性」「新たに発見された脆弱性」という語自体は含まれます）。 両方とも points of focus（着眼点）にのみ出てきます。 脆弱性スキャンは CC7.1 の着眼点、ペネトレーションテストは CC4.1 の着眼点で、 しかも後者は「含みうる（may include）」8項目の列挙の1つです。 そして AICPA は「規準の利用にあたって、各着眼点が対応されているかを評価することは要求されない」と明記しています
レベル3
手引での「例示」にとどまる
ISO/IEC 27001 — 規格本文（箇条4〜10の要求事項）に脆弱性診断の要求はありません。 附属書A の 8.8「技術的ぜい弱性の管理」が求めているのは 「情報を入手し、さらされている状況を評価し、適切な措置をとる」というレベルです。 脆弱性スキャンやペネトレーションテストは ISO/IEC 27002 の実施の手引で「脆弱性を特定する手段」として挙げられています （8.29 の手引にも登場します）。手引は要求事項ではなく、実装の指針という位置づけです。 8.29「開発及び受入れにおけるセキュリティテスト」も、テストプロセスの定義・実施を求める要求です
レベル4
要求が存在しない
プライバシーマーク — 審査基準（全2ページの枠文書）が実質的な要求事項を構築・運用指針に委ねる入れ子構造になっており、その指針の目次に技術試験の項目が存在しません。 適正管理の下位は「正確性の確保／安全管理措置／従業者の監督／委託先の監督」の4項目のみで、 ISO 27002 の 8.8 に相当する項目がありません。JIS Q 15001:2023 でも技術的な管理策は参考の附属書に置かれています
NIST CSF 2.0 — ID.RA-01「資産の脆弱性は特定・検証・記録される」等はありますが、 頻度・手法・実施者の資格は一切書かれていません。そもそも認証制度ではありません
FISC（※要求の有無は確認できていません） — 基準本文が有償のため本サイトでは未確認です。「要求がない」ことを確認したわけではありません。 ただし実質的な要求は金融庁ガイドライン側に明文化されており、そちらは具体的です（下記）
では、なぜ実務では「必須」になっているのか。 監査実務上の期待値と相場観です。制度の強制ではありません。 この区別は実務上の意味があります — 制度が強制していない領域は、範囲・深度・頻度を自分で設計できるということです。 「SOC 2 だからペネトレーションテストを毎年」と決め打つ前に、 自社のリスクに照らして何を検証すべきかを決め、それを監査人と合意する余地があります。 逆に PCI DSS のように規格が具体的に指定している領域では、その余地はありません。
金融機関向けは例外的に具体的です。 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」は 脆弱性診断・ペネトレーションテストについて、 外部直接接続機器（VPN機器等）を対象範囲に含めること、 外部公開ウェブサイトはプラットフォーム診断とウェブアプリケーション診断の両方を実施すること、 モバイルアプリの診断、リスクの高い構成では内部機器も対象とすること等を挙げています。 さらに TLPT については、大手金融機関及び主要な清算・振替機関等が参照すべき「対応が望ましい事項」として 「必要な経験及びスキルを持つ業者を選定すること （テスターの資格や経歴の確認等のバックグラウンドチェックを含む）」と示されており、 認定制度に頼らず発注側が確認する設計になっています。 なお前段の対象範囲に関する記載は【基本的な対応事項】に置かれており、外部公開 API も明示的に含まれます。
審査員側にも診断能力は要求されていません。 ISO/IEC 27006-1:2024 が ISMS 審査員に求めているのは「IT と情報セキュリティの実務経験」と規格・管理策の知識で、 附属書A の管理策に関する知識すら審査チーム全体で満たせばよいとされています 個々の審査員が情報セキュリティの全領域の経験を持つことは求められていません。 脆弱性診断の実施能力、スキャナの操作能力、コードレビュー能力を要求する条項は、 公開されている範囲では確認できません（同規格は有償で、本サイトは全文を確認していません）。 力量に関する要求は 7.1.2 / 7.1.3（審査チームの力量）と 7.2.2（審査員の知識・経験）に置かれています。 つまり認証審査は、技術的な検証ではなくマネジメントシステムの検証です。

④ リスクベースか、ベースラインか — 実務で最も差が出る構造

「ISMS を持っているのに差分が出る」の正体

制度の設計思想には2種類あります。この違いが、 「ISMS を取得済みなのに、別の制度で改めて指摘される」という状況を生みます。

リスクベース型
組織がリスクを評価し、必要な管理策を自分で決める
  • ISO/IEC 27001 — 6.1.3 でリスク対応に必要な管理策を決定し、附属書Aと比較して見落としがないことを検証する構造。 適用宣言書（SoA）で管理策の除外を正当化できます。附属書A は「可能な管理策の一覧」という位置づけです
  • SOC 2 — 経営者が統制を設計し、監査人がその妥当性を判断。着眼点の充足は要求されない
  • NIST CSF — 目標プロファイルを組織が設定する
ベースライン型
定められた項目を全部実施しているかを見る
  • SCS評価制度 — 経産省が「効果の高い管理策を抽出するベースラインアプローチ」と明言。 要求事項数は★3 が26件、★4 が43件で、合格基準は原則としてすべての評価基準への適合 （評価基準は要求事項の下位にあり、要求事項1本に複数の評価基準が対応します）。 取得範囲も「インターネットに接続している自社IT基盤」として制度側が指定します
  • プライバシーマーク — 指針は残留リスクを一定認めつつ、《留意事項》で 「個人情報の不適切な取扱いに関するリスクについては、法令遵守の観点から全て対応する必要があるため、 残留リスクとすることは認められない」としています（原文は「個人情報の不適切な取扱い（不正な取得・利用など）に関するリスク」）。適用除外が構造的に想定されていません
  • PCI DSS — 要件が具体的な数値・頻度で指定されます
実務上の落とし穴。 ISMS でリスク評価の結果として適用除外にしていた項目は、 ベースライン型の制度ではそのまま差分として出てきます。 「ISMS を持っているから SCS も大丈夫」とは言えません。 経産省・IPA も両制度を「相互補完的」と位置づけており、上下関係ではありません。
本サイトによる整理（公式な包含関係ではありません）。 層として捉えると理解しやすくなります — 制度・証跡（対外的な説明。SCS評価制度、ISMS、SOC 2）→ 組織の管理策（何をやるか。CIS Controls など）→ 機器の設定値（どう設定するか。CIS Benchmark など）。 ただし SCS評価制度の要求事項は経営ガイドラインや ISO 27001 の系譜で作られており、 CIS Controls を土台にした公式な包含関係ではありません。 あくまで理解のための整理として扱ってください。

⑤ 目的から逆算する

「どれが一番いいか」ではなく「何を説明したいか」
説明したい相手・目的噛み合う制度理由と注意点
米国企業との取引
（SaaS・クラウド・データ処理）		 SOC 2 type 2 委託先評価の実務で定着しており、ISO/IEC 27001 を持っていても別途求められることがあります。 報告書は一般公開向けではないため、NDA を結んで個別提供する運用になります。 一般公開したい場合は SOC 3（テスト手続とその結果について SOC 2 と同レベルの詳細を提供しない版）という選択肢があります
国内の大企業・官公庁との取引 ISO/IEC 27001（ISMS） 調達要件として指定されるケースが多く、認知度が高い。認証書という形で示せます。 適用範囲を組織が決められるため、範囲の記載を確認されることがあります
一般消費者・個人情報を
多く扱う業務		 プライバシーマーク 国内での認知度が高く、対象が個人情報に限定されるため取得の負荷は相対的に軽い。 個人情報以外の機密情報やシステムのセキュリティはスコープ外です。 「Pマークがあるから情報セキュリティは大丈夫」という誤解を生みやすい点に注意
カード情報を扱う PCI DSS 選択の余地は小さく、実務上は必須。まず契約先のアクワイアラに、自社のレベルと 検証方法（SAQ か ROC か）を確認してください。現行版は v4.0.1 のみです
政府情報システムへの
クラウドサービス提供		 ISMAP / ISMAP-LIU 登録監査機関による外部監査が必要。ISMAP-LIU は対象が限定的なサービス向けで、 管理策基準の外部監査の範囲が縮小されるのが最大の違いです（内部監査は代替ではなく追加要求です）
米国防衛調達の
サプライチェーン		 NIST SP 800-171
／CMMC		 DFARS 252.204-7012 は保護対象防衛情報を扱う下請や、運用上重要な支援を行う下請に、当事者名の変更以外は無改変で承継されるため、 日本企業にも降りてきます。Rev.3 が最新の NIST 基準ですが、契約上は Rev.2 に固定されている二重構造に注意 （固定の根拠は 7012 本文ではなく DoD の Class Deviation 2024-O0013）。 CMMC は Phase II が停止中です
日本の防衛調達 防衛産業
サイバーセキュリティ基準		 防衛省が「米国国防省が契約企業に義務付けている基準（NIST SP 800-171）と同水準の管理策を採用」と説明。 「保護すべき情報を取り扱う」全ての防衛関連企業（下請負を含む）が対象。基準は改正され2025年7月1日から適用されています
金融機関 FISC 安全対策基準
＋金融庁ガイドライン		 FISC は自主基準で認証制度がありません。実務上の要求は金融庁ガイドライン側に明文化されており、 脆弱性診断・TLPT について具体的な記載があります（③参照）
自組織の対策整備
（対外証明は後回し）		 NIST CSF 2.0
／CIS Controls		 認証費用をかけずに現状把握と改善計画を作れます。 ただし対外的に証明する手段がありません。「NIST CSF に準拠しています」は自己申告であり、 第三者が証明しているわけではない点は正確に伝える必要があります
サプライチェーンの
一員としての証明（国内）		 SCS評価制度
2027年3月頃予定		 ★1・★2 は SECURITY ACTION の枠組み。★3・★4 が SCS評価制度の対象です。 要求事項・評価基準は2026年3月27日に公表済み（要求事項数は★3 = 26件、★4 = 43件。今後の定期的な見直しが想定されています）。 有効期間は★3 が1年、★4 が3年。★3 を取得していなくても★4 を取得できます。 申請方法・解説書は2026年10月頃、評価機関の公表は2026年12月頃の予定。 経産省が「不適切な勧誘」への注意喚起を出しています
本サイトの一貫した立場 — 認証を持つことと、実際に守れていることは別です。 どの制度も、取得や報告書の受領はある時点における一定水準の充足を示すものであって、 侵害されないことを保証しません（SCS評価制度の制度構築方針にも同旨の注記があります）。 認証は手段であって目的ではない、というのは一般論としてよく言われますが、 制度の中身を確認するとその理由がはっきりします — ③で見たように、多くの制度は脆弱性診断の深度も頻度も指定していません。 つまり形式的に満たすことは可能で、実際のリスクを下げるかどうかは運用側の設計次第です。

⑥ 一次情報

記載内容は下記で確認できます
制度一次情報
SOC 2 AICPA — SOC Suite of Services、 SOC 2 Report Review Checklist （PDF 直リンク）、 Trust Services Criteria（2022年改訂着眼点版）、 JICPA 保証業務実務指針3702（PDF）、 JICPA Trust サービス
ISO/IEC 27001 ISMS-AC — ISMS適合性評価制度、 認証機関一覧、 経産省 情報セキュリティ管理基準（令和7年改正版・PDF）、 JIS Q 27002:2024 プレビュー（目次のみ）
プライバシーマーク JIPDEC — 制度の仕組み、 申請先（業種・所在地で決まる）、 構築・運用指針 JIS Q 15001:2023準拠版（PDF）
PCI DSS PCI SSC — PCI DSS、 v4.0.1 が唯一の有効版である旨、 認定事業者一覧の入口
NIST NIST CSF 2.0（CSWP 29・PDF）、 NIST Cybersecurity Framework、 SP 800-171 Rev.3、 SP 1318 CUI 中小企業向け解説（NIST は準拠状況を追跡しない旨・PDF）
CMMC 米国防省 CIO — CMMC（サイト表記は Department of War CIO）、 32 CFR Part 170、 DFARS 252.204-7012（eCFR）
FISC / 金融庁 FISC、 金融庁 金融分野におけるサイバーセキュリティに関するガイドライン（PDF・2025年7月一部改正）
ISMAP ISMAP ポータル、 登録監査機関リスト、 クラウドサービスリスト
SCS評価制度 経産省 SCS評価制度、 IPA 制度の詳細、 IPA よくある質問、 不適切な勧誘への注意喚起
防衛省 防衛装備庁 サイバーセキュリティ
本ページは公開されている一次情報に基づく整理です。 規格・制度の要求事項は改定されます。特に SCS評価制度は運用開始前、CMMC は Phase II 停止中で、 いずれも今後変更されます。判断に用いる場合はリンク先の原文で最新の内容をご確認ください。 なお ISO 規格および FISC 安全対策基準の本文は有償のため、本サイトは公開されている告示・プレビュー・ 認証機関の解説を基に記載しています。

🇯🇵 日本

経済産業省・金融庁・NISC 等
名称発行元概要対象
サイバーセキュリティ基本法
2014年制定		 JP NISC 日本のサイバーセキュリティ施策の基本方針を定めた法律 全組織
金融庁 サイバーセキュリティガイドライン
2023年改訂		 JP 金融庁 金融機関向けサイバーセキュリティ対策の指針 金融機関
中小企業向けサイバーセキュリティ対策の極意 JP 経産省 中小企業が実践すべき最低限のセキュリティ対策 中小企業
SECURITY ACTION
自己宣言制度		 JP IPA 中小企業がセキュリティ対策に取り組むことを自己宣言する制度（★1・★2）。SCS評価制度の★1・★2 はこの延長線上に位置づけられている 中小企業
サイバーセキュリティ経営ガイドライン
Ver3.0 (2023)		 JP 経産省・IPA 経営者が認識すべき3原則と、担当幹部に指示すべき重要10項目 全組織（経営層）
情報セキュリティ10大脅威 JP IPA 毎年発行。組織・個人向けの主要脅威ランキング 全組織
個人情報保護法
2022年改正		 JP 個人情報保護委員会 個人情報の取扱いに関する規制。漏洩報告義務等を含む 全組織

🌐 国際標準・フレームワーク

ISO / NIST / CIS 等
名称発行元概要対象
ISO/IEC 27001 INT ISO/IEC 情報セキュリティマネジメントシステム（ISMS）の国際規格 全組織
NIST Cybersecurity Framework (CSF)
v2.0 (2024)		 US NIST 識別・防御・検知・対応・復旧の5機能からなるフレームワーク 全組織
NIST SP 800-53 US NIST 連邦情報システム向けセキュリティ・プライバシー管理策カタログ 政府・大企業
CIS Controls
v8.1 (2024)		 US CIS 優先度付きで実装可能な18の重要セキュリティ管理策（153 Safeguards）。組織規模・リスクに応じて IG1／IG2／IG3 の3段階で適用範囲を選べる。
※組織の管理策のカタログであり、機器の設定値を定める CIS Benchmark とは別物。Benchmark は Controls の「4: 資産とソフトウェアの安全な設定」を実現する手段にあたる		 全組織
OWASP Top 10
2021		 INT OWASP Webアプリケーションの最重要脆弱性トップ10 開発者・Web系

🏦 業界標準・規制

PCI DSS / GDPR / HIPAA 等
名称発行元概要対象
PCI DSS
v4.0.1（v4.0は2024年末失効）		 INT PCI SSC クレジットカード情報を扱う事業者向けセキュリティ基準 決済・小売
GDPR EU EU EU一般データ保護規則。EU市民の個人データ保護法。EU域外にも適用あり EU関連事業者
NIS2指令
2024年施行		 EU EU EUネットワーク・情報セキュリティ指令の改訂版。重要インフラ対象 EU重要インフラ
HIPAA US 米国HHS 医療情報のプライバシー・セキュリティ規則 医療機関・米国
CISA 重要インフラ向けガイダンス US CISA 重要インフラ事業者向けサイバーセキュリティ推奨事項 重要インフラ

🌏 アジア・その他主要国

中国・インド・シンガポール 等
名称発行元概要対象
Cyber Essentials (SG) SG CSA Singapore シンガポール企業向け基本サイバーセキュリティ認証制度 シンガポール企業
CERT-In ガイドライン IN CERT-In インド政府のサイバーセキュリティインシデント報告義務等 インド事業者

🏅 第三者監査・認証制度

ISMS / プライバシー / クラウド / 製品評価
名称発行元概要主な対象
ISMS認証（ISO/IEC 27001） INT ISO/IEC / JIPDEC 情報セキュリティマネジメントシステムの第三者認証。日本ではJIPDECが認定機関 全組織
プライバシーマーク（Pマーク） JP JIPDEC 個人情報の適切な取扱いを認定する日本独自の認証制度（JIS Q 15001準拠） 日本企業
ISO/IEC 27701（プライバシー情報管理） INT ISO/IEC ISO 27001の拡張規格。GDPR等のプライバシー規制への対応にも活用 全組織
SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）
2026年度末〜 申請受付開始予定		 JP 経産省・IPA 企業のセキュリティ対応力を★1〜★5で段階評価し、企業間取引での可視化を図る新制度。★1・★2 は SECURITY ACTION の延長線上（自己宣言）、★3 は専門家確認付きの自己評価、★4 はより広い要求事項＋第三者評価機関による評価。★5 は開始時期未定。★3・★4 の申請受付は2026年度末（2027年1〜3月）頃を予定。
※制度構築中のため要求事項は変更の可能性あり。IPAの詳細情報で最新を確認のこと		 全組織（特にサプライチェーン参加企業）
ISMAP（政府情報システムのためのセキュリティ評価制度） JP 内閣府・総務省・経産省 日本政府調達向けクラウドサービスのセキュリティ評価制度。登録サービス一覧あり クラウド事業者
CSA STAR認証 INT CSA クラウドサービス固有のセキュリティ管理策（CCM）に基づく第三者認証 クラウド事業者
SOC 2 Type II US AICPA セキュリティ・可用性・機密性等を第三者監査で評価。SaaS・クラウド事業者の信頼証明として標準化 SaaS・クラウド事業者
FedRAMP US 米国GSA 米国連邦政府向けクラウドサービスのセキュリティ評価・認可プログラム 米国政府調達向けクラウド
CC認証（コモンクライテリア / ISO 15408） INT CCRA加盟国 セキュリティ製品（FW・VPN・OS等）の機能・信頼性を評価する国際標準認証 セキュリティ製品ベンダー
JISEC（ITセキュリティ評価及び認証制度） JP IPA 日本のCC認証実施機関。日本市場向けセキュリティ製品の評価認証を担当 セキュリティ製品ベンダー
Cyber Essentials (UK) UK NCSC 英国政府が推進する基本的サイバーセキュリティ認証。英国政府調達の要件になる場合あり 英国企業・政府調達

🔍 脆弱性情報・調査サイト

CVE検索・脅威インテリジェンス
🛡️
NVD (NIST)
nvd.nist.gov
米国国立脆弱性データベース。CVSSスコア・CWE付きで網羅的に収録
無料CVE検索
🇯🇵
JVN iPedia
jvndb.jvn.jp
IPA/JPCERTが運営する日本語脆弱性データベース
無料日本語
🚨
CISA KEV
cisa.gov
実際に攻撃に悪用されている脆弱性カタログ
無料悪用中CVE
🌐
Shodan
shodan.io
インターネットに公開されているデバイスを検索できるサーチエンジン
無料枠ありOSINT
📡
GreyNoise
viz.greynoise.io
インターネットスキャン・ノイズIPの可視化
無料枠あり脅威IP

🔧 Webアプリ診断ツール（OSS）

オープンソース・無償ツール
⚡
OWASP ZAP
zaproxy.org
OWASPが開発するWebアプリケーションセキュリティ診断ツール
無料OSSWebアプリ
🕷️
Nikto
github.com/sullo/nikto
Webサーバーの既知の脆弱性・設定ミスを高速スキャン
無料OSSWebサーバー
🗄️
SQLMap
sqlmap.org
SQLインジェクション脆弱性の自動検出ツール
無料OSSSQLi
✂️
XSStrike
github.com/s0md3v/XSStrike
XSSペイロード生成・脆弱性検出ツール。WAFバイパス機能付き
無料OSSXSS

🌐 ネットワーク診断ツール

ポートスキャン・SSL診断
📡
Nmap
nmap.org
ポートスキャン・OS検出・サービス探索。ネットワーク診断の定番
無料OSSネットワーク
🔒
SSL Labs
ssllabs.com/ssltest
SSL/TLS設定の詳細評価。グレード（A〜F）で一目把握
無料SSL/TLS
📋
Security Headers
securityheaders.com
HTTPセキュリティヘッダーの設定状況をスキャン・評価
無料HTTPヘッダー
💣
Metasploit
metasploit.com
ペネトレーションテストフレームワーク
無料枠ありOSSPenTest
🗺️
DNSDumpster
dnsdumpster.com
ドメインのDNSレコード・サブドメインを可視化するOSINTツール
無料OSINT

💻 コード・依存関係解析ツール

SAST・SCA・シークレット検出
📦
OWASP Dependency-Check
owasp.org
ライブラリの既知脆弱性を検出するSCAツール
無料OSSSCA
🔬
SonarQube
sonarqube.org
静的コード解析ツール。セキュリティホットスポット・バグを検出
無料枠ありOSSSAST
🐷
TruffleHog
github.com/trufflesecurity
GitリポジトリにAPIキー・シークレットが混入していないか検出
無料OSSシークレット検出

🔎 オンライン調査・分析サイト

マルウェア解析・IP調査・フィッシング確認
🦠
VirusTotal
virustotal.com
ファイル・URL・IPを70以上のエンジンでスキャン
無料マルウェア解析
🏃
ANY.RUN
any.run
インタラクティブなマルウェアサンドボックス
無料枠ありサンドボックス
🔗
urlscan.io
urlscan.io
URLの安全性スキャン。スクリーンショット・外部通信を可視化
無料URL調査
🚫
AbuseIPDB
abuseipdb.com
不審なIPアドレスの報告・照会サービス
無料枠ありIP調査
📧
Have I Been Pwned
haveibeenpwned.com
メールアドレスがデータ漏洩に含まれているか確認
無料漏洩確認
🔭
Hybrid Analysis
hybrid-analysis.com
無料マルウェアサンドボックス。CrowdStrike提供
無料マルウェア解析

📊 日次脆弱性ダイジェスト

毎日 11:00 更新 · AI 解析

直近の脆弱性・ソフトウェア更新情報を集計し、Claude Code CLI が優先度ランクを付けて解析した日次レポートです。

📄 本日のレポートを開く 🗂️ 過去分の一覧
レポートの内容:
・★★★ 要対応 CVE（自社主要ソフトの重大脆弱性）
・★★ 参考 CVE（業界動向として押さえるべきもの）
・主要ソフトウェアの新バージョン一覧（関連 CVE 件数付き）
・全体トレンドサマリ

📰 情報漏洩・インシデント情報

自動収集 · 毎日 07:00 更新

日本国内で公開されている情報漏洩・不正アクセス事案を集約して掲載。 組織種別 (上場/大学/自治体等) と原因種別でフィルタ可能。

総件数 (直近1年)
-
公表日 組織種別 企業名 原因 漏洩件数 概要
読み込み中...

各エントリの分類は自動判定のため誤りが含まれる可能性があります。詳細は各種公開情報を確認してください。

🔔 脆弱性ニュース

Security NEXT / ScanNetSecurity / piyolog 自動収集

製品・ソフトウェアの脆弱性報告記事 (CVE、ゼロデイ、パッチ情報等)。 企業事案は「インシデント情報」タブへ。

総件数 (直近1年)
-
公表日 組織種別 組織名 原因 件数 概要
読み込み中...

脆弱性ニュース記事から自動判定した情報です。詳細は必ず一次情報を確認してください。

🔑 Base64 エンコード / デコード

▼ 結果

🔗 URL エンコード / デコード

▼ 結果

📄 HTML エスケープ / アンエスケープ

▼ 結果

🔒 パスワード生成

長さ:文字

📖 指摘事項解説

プラットフォーム診断の報告書でよく見かける指摘事項について、実際のリスクを踏まえて解説します。

⚠️ ご利用にあたって（このページの「リスク」表記について・事前にお読みください）
クリックで開閉 ▼
📊 リスクの目安（本ページでの相対的な整理）
中リスク
📡 非暗号化プロトコルの利用
前提条件なしで通信内容がそのまま読める
低リスク（暗号関連）
🔓🔑🧮 脆弱な暗号プロトコル／暗号スイート／DHパラメータ
MITMや大規模な事前計算など前提条件が必要
情報
📂 ディレクトリリスティング
直接的な被害ではなく偵察情報として悪用されうる
※ 診断報告書上のリスク表記（Critical/High/Medium/Low等）と必ずしも一致しません。攻撃成立に必要な前提条件の少なさを軸にした、このページ内での相対的な整理です。
📂 ディレクトリリスティング 情報
クリックで開閉 ▼
🔓 脆弱な暗号プロトコルの利用 低リスク
クリックで開閉 ▼
🔑 脆弱な暗号スイートの利用 低リスク
クリックで開閉 ▼
🧮 脆弱なDHパラメータの利用 低リスク
クリックで開閉 ▼
📡 非暗号化プロトコルの利用 中リスク
クリックで開閉 ▼
🏷️ バージョン情報の検出 情報
クリックで開閉 ▼
🐛 既知の脆弱性が存在するソフトウェアの利用 中リスク
クリックで開閉 ▼
⏳ サポートの終了したソフトウェアの利用 中リスク
クリックで開閉 ▼
🖥️ サポートの終了したOSの利用 高リスク
クリックで開閉 ▼

🛰️ プラットフォーム診断対象チェック

指定された IP/FQDN が CDN/WAF や PaaS のエッジになっていないか、 オリジンサーバーが別経路で露出していないかを公開情報（DNS / CT log / WHOIS / ASN）から 二重チェックします。診断対象の事前確認に。

⚠ ご利用にあたって
判定はあくまで公開情報シグネチャに基づく参考情報です。診断対象の最終判断は実施者の責任で行ってください。
📋 診断対象の選び方（参考ガイド）
クラウド／オンプレ環境で「どこを診断対象にすべきか」を考える際の一般的な視点
クリックで開閉 ▼
🌐 IPアドレス／FQDNの選び方（参考ガイド）
同じ診断対象でも、IPを指定した場合とFQDNを指定した場合では結果が異なることがあります
クリックで開閉 ▼
🤖 判断に迷ったら（AIに相談する）
上記の考え方を自分の環境に当てはめるのが難しい場合は、AIに聞いてみるのも一つの方法です
クリックで開閉 ▼

※ 本ツールは情報提供を目的としており、調査対象への攻撃を意図したものではありません。 自身が管理するドメイン、または合法的に調査権限のあるドメインのみを対象としてください。 レート制限: 1分5回 / 1時間50回。

スキャン対象イメージ
…
Dockerコンテナ
🔴 CRITICAL
…
緊急対応
🟠 HIGH
…
要対応
問題のあるイメージ
…
5件中

🛡️ 自サーバー脆弱性スキャン結果

最終スキャン: -
本サイトを運用しているDockerコンテナ群を Trivy で定期スキャンし、HIGH/CRITICAL の既知CVE（修正版があるもの）を表示しています。
スキャン頻度: 毎月1回 / 修正可能なものに限定表示 / ドッグフーディング目的で公開
取得中…

📋 設定コンプライアンス（CIS Benchmark Level 1）

最終スキャン: -
本サーバー（Ubuntu 24.04）のOS設定を OpenSCAP + ComplianceAsCode の CIS Benchmark Level 1 (Server) プロファイルで評価し、FAIL項目を NIST SP 800-53 のファミリー別に集計して表示しています。
Level 1 は「利便性への影響を抑えつつ実装できる基本的な設定基準」、Level 2 は「利便性への影響を許容してより深い多層防御を取る基準」で、業種別の区分ではありません。一般公開のWebサーバーには Level 1 が適切と判断しています。
個別の設定項目・具体的な失敗内容は非公開です（集計値のみ公開、攻撃対象情報の露出を避けるため）。スキャン頻度: 毎月1回
対応率
…%
…
CIS Benchmark は認証制度ではなく推奨設定のカタログです。実務上は「全項目 PASS」ではなく 「未達項目に理由と承認があること（例外管理）」が求められるため、承認済み例外を対応済みとして算入しています。
他組織との比較値は公表されていないため、業界平均等との対比は掲載していません。
評価件数
…
チェック対象
✅ PASS
…
合格
📋 承認済み例外
…
意図的に非準拠
⚠️ 未対応
…
判断・対応が未了

📋 承認済み例外の一覧

技術的・運用的な制約により意図的に非準拠としている項目です。個別のルール名は公開せず、分類と理由のみ掲載しています。
取得中…

⚠️ 未対応項目の内訳（NIST SP 800-53 ファミリー別）

取得中…
参考: FAIL 合計 … 件（うち承認済み例外 … 件） / NIST 参照が無くファミリー分類できなかった未対応 … 件 / OVALチェックが無く評価されなかった項目 … 件
実装検討中 — アクセス元情報
IPアドレスは第3・第4オクテットをマスク済み（例: 203.0.xxx.xxx）です。EU圏は 赤文字。

⚠ 攻撃疑いIP

直近 時間 / 閾値 件以上
取得中…

アクセスログ（直近100件）

取得中…
🔒
入力データの取り扱い — 入力した製品名・バージョンはリクエスト処理中のみ扱い、DB・アクセスログに保存しません。 ブラウザにも保持しないため、リロードすると結果は消えます。
SBOMファイルの受け取りは行いません。SBOM品質チェック（②）は、ファイルをサーバへ送らずブラウザ内だけで処理します。

製品を選んでバージョンを入力

準備するものはありません
ℹ 製品リストは「OSサポート期限」「ソフトウェア」タブと同じ 94 製品。バージョンは英数・ドット・ハイフン・プラス・コロンのみ（最大64文字）。
ℹ 判定は NVD の CPE 情報（影響バージョン範囲）と CISA KEV の突合で行います。影響バージョンが未登録のCVEは「要確認」として安全側に表示します。
🖥
この機能はサーバを使いません。選んだSBOMファイルはブラウザ内のJavaScriptだけで解析し、採点結果を表示します。 ネットワークへは何も出ません（開発者ツールの Network タブで確認できます）。
そのため、取引先から受領したSBOMや自社の未公開SBOMでも安全に採点できます。 JSON形式のみ対応です（XML/RDF形式は XXE 等のリスクがあるため意図的に非対応。JSONへ変換してからお使いください）。

SBOMの品質を採点する

🖥 ブラウザ内で処理 — 送信しません
📋
SBOMファイルを選択（送信されません）

または JSON をそのまま下のテキストエリアに貼り付け
CycloneDX 1.2–1.7 (JSON) SPDX 2.2 / 2.3 (JSON) SPDX 3.x (JSON-LD) は未対応 XML / RDF は非対応
未入力
実装予定 — 依存リストで一括チェック
pip freeze / npm ls / dpkg-query などの出力をそのまま貼り付けて、 数十〜数百件のライブラリを一括で脆弱性突合する機能です。
現状の脆弱性DBは「①の94製品」を対象に構築されているため、任意の pypi / npm パッケージを突合するには 外部の脆弱性DB（osv.dev）への問い合わせが必要になります。ここには 「貼り付けた依存構成を第三者APIへ送ることになる」という設計上の判断が必要なため、方針決定後に実装します。
当面は ①「製品を選んでチェック」をご利用ください。貼り付ける一覧の取り方は ④ にまとめています。

そもそもSBOMは必要か

SBOM（Software Bill of Materials＝ソフトウェア部品表）は、 「どのライブラリのどのバージョンを使っているか」を機械可読な形で列挙した部品リストです。食品の原材料表示に相当します。

ただし脆弱性を調べたいだけならSBOMは要りません。 必要なのは「パッケージ名 ＋ バージョン」の対応表だけで、それは既にあるコマンド1つで取れます。 SBOMが本当に必要になるのは、取引先へ提出を求められたときと、 ハッシュ値付きで成果物の同一性を証明する必要があるときです。
本サイトがSBOMファイルをアップロードさせない理由: SBOMのXML/RDF形式は XXE（外部エンティティ参照）、圧縮形式は zip bomb、 巨大JSONはパース時DoS の入口になります。加えて、SBOMは他社の内部構成そのものであり、 サーバに保管すること自体が情報資産の集約リスクになります。 このため、脆弱性突合は「製品名＋バージョンのみ受領・非永続」、SBOM採点は「ブラウザ内完結」に分離しています。

使っているライブラリ一覧の取り方

環境コマンド
Python
$ pip freeze
Node.js
$ npm ls --all --parseable # または package-lock.json を見る
Debian / Ubuntu
$ dpkg-query -W -f='${Package}=${Version}\n'
RHEL / Rocky
$ rpm -qa --qf '%{NAME}=%{VERSION}-%{RELEASE}\n'
Go
$ go list -m all
Java / Maven
$ mvn dependency:list -DoutputFile=deps.txt
コンテナイメージ
$ trivy image --list-all-pkgs --format table myapp:latest

SBOMを作る必要が出たとき

取引先から提出を求められた場合の最短手順です。いずれも無償のOSSツールで、数分で生成できます。
# コンテナイメージから（最も簡単・ハッシュ値付き） $ syft myapp:latest -o cyclonedx-json > sbom.json # ソースコードのリポジトリから（推移依存まで辿る） $ cdxgen -o sbom.json /path/to/repo # SPDX形式を要求された場合 $ syft myapp:latest -o spdx-json > sbom.spdx.json

生成したら 「② SBOM品質チェック」 に通して、CISA最小要素を満たしているか確認してから提出するのが安全です。

フォーマットの違い

フォーマット推進特徴 / 使いどころ
CycloneDXOWASP
(ECMA-424)		 セキュリティ用途向けの設計。脆弱性・VEX・暗号(CBOM)・AIモデル(ML-BOM)も同一形式で扱える。 Trivy / Syft / cdxgen の既定出力。最新は 1.7（1.x系の最終リリース、1.4〜1.6と後方互換）。
SPDXLinux Foundation
(ISO/IEC 5962)		 もとはライセンスコンプライアンス用途。ISO標準なので調達・契約書で指定されやすい。 2.2 / 2.3 が実運用の主流、3.0 で構造を刷新。
Excel / PDF— 規格ではないが、実務では提出物としてこれを求められることも多い。上記から変換して作る。

迷ったら: CycloneDX で作り、SPDXを要求されたら変換して渡す。 脆弱性管理が目的なら CycloneDX、調達要件に「ISO標準」と書かれていたら SPDX。

関連リソース

ドキュメント発行概要
2026 Minimum Elements for a SBOM CISA / NSA / FBI ほか
2026-07-29		 2021年のNTIA版を置き換える最小要素の最新版。本サイトの品質チェック（②）の判定基準。
ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0 経済産業省
2024-08-29		 国内向けの実務手引。脆弱性管理プロセス、SBOM対応モデル、取引モデルを収録。
CycloneDX 仕様 (ECMA-424) OWASP 1.7 が 1.x系の最終リリース。1.4〜1.6 と後方互換。
SPDX 仕様 (2.3 / 3.0) Linux Foundation ISO/IEC 5962:2021 として国際標準化されたのは 2.2。
脆弱性情報サイト v0.6
脆弱性・サポート期限情報は以下のデータソースから取得しています:
MyJVN API（IPA／JPCERT） · NVD（NIST） · CISA KEV カタログ · endoflife.date
※ 日本語の脆弱性情報はIPA／JPCERTが運営する MyJVN API より取得しています。
本サイトの情報は各データソースの内容を集約したものであり、独自に生成・改変したものではありません。
脆弱性対応の実務にあたっては、各公式サイトの一次情報をあわせてご確認ください。