--- title: "脆弱性対応の自動化｜情報収集・優先順位付け・修正・検証で任せる範囲と人が残す判断" url: "https://www.issoh.co.jp/column/details/2372/" published: 2024-06-07 updated: 2026-10-26 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 脆弱性対応の自動化｜情報収集・優先順位付け・修正・検証で任せる範囲と人が残す判断 脆弱性対応は、情報を集める、資産と照らす、優先順位をつける、直す、悪用できるかを確かめる、という工程に分かれ、使う仕組みも自動化できる深さも工程ごとに違います。この記事では、CISAのKEVとBOD 26-04、FIRSTのEPSS、経済産業省のASM導入ガイダンスなどの一次情報をもとに、機械に任せられる範囲と人の判断が残る部分を工程別に整理します。 ## まとめ 資産台帳が整っている組織で自動化の効果が出やすいのは、優先順位付けです。CISAが2026年6月10日に出したBOD 26-04は、対応の緊急度を「資産の露出」「KEV掲載の有無」「攻撃の自動化可能性」「技術的影響」の4変数で決めると定めており、このうち資産の露出以外の3つはCISAがCVEごとに公開しています。KEVとEPSSを加えれば、CVSSの点数順より悪用の事実と見込みに沿った順番を機械で出せます。 修正は、依存ライブラリの更新ならDependabotなどが修正版への更新プルリクエストを自動で作れますが、マージの判断とテストは残ります。悪用できるかの検証は、防御が効くかをBASが、侵入経路が通るかを自動ペネトレーションテストが担い、Gartnerはこの2つとレッドチーミングをAEVという1つの市場区分にまとめました。どの工程でも、資産台帳が不正確なら自動化の結果は外れます。最初に整えるのは台帳です。 ## 脆弱性対応の工程と自動化できる範囲 | 工程 | 主な仕組み | 自動化の度合い | 人が残る判断 | | -------- | ----------------- | ------- | ----------- | | 情報収集 | KEV・NVD・JVNのフィード | 高 | 自社製品への該当判定 | | 資産把握 | ASM・SBOM・資産管理ツール | 高 | 管理部署の特定 | | 検出 | スキャナ・SCA・SAST | 高 | 誤検知の判定 | | 優先順位付け | KEV・EPSS・SSVC | 中〜高 | 業務影響の加味 | | 修正 | 自動PR・AIの修正案・パッチ配信 | 中 | マージと停止時間の判断 | | 検証（防御） | BAS | 高 | シナリオ選定 | | 検証（経路） | 自動ペネトレーションテスト | 中 | 業務影響の事前評価 | | 検証（業務仕様） | 手動ペネトレーションテスト | 低 | 仕様に基づく攻撃設計 | ※度合いは、ツール単体で結論まで出せるかどうかで3段階に分けた本記事の整理で、公的な分類ではありません。 自動化が届きにくいのは、仕様や業務フローの理解を前提にする検証です。権限昇格につながる画面遷移の抜け、決済フローの金額改ざん、多要素認証の回避手順は、何が正しい動作かをツールに教えなければ判定できません。設計書を読ませて業務ロジックを試験する製品も出ていますが、渡す仕様の選定と結果の妥当性の確認は人に残ります。診断の種類や費用相場を先に押さえたい場合は[脆弱性診断の種類・費用相場と外注時の判断基準](/column/details/13101/)を参照してください。 ## 脆弱性情報収集の自動化と取得元の選定 ### KEV・NVD・JVNのフィードと取得方法 情報源は、悪用の事実を示すものと、脆弱性そのものを網羅するものに分かれます。前者の代表がCISAの[Known Exploited Vulnerabilities（KEV）カタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)です。JSONフィードで配布されており、2026年10月23日版（catalogVersion 2026.10.23）の掲載は1,756件、うち2026年に追加された分が272件、ランサムウェアでの利用が確認済み（knownRansomwareCampaignUse=Known）のものが361件でした。 網羅側はNISTのNVDと、日本のJVNです。NVDはCVE API 2.0で取得できますが、前提が変わりました。[NISTの告知（2026年4月15日）](https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth)によると、CVEの登録件数が2020年から2025年に263％増えたため、影響製品のリストや深刻度スコアを付け足す分析（エンリッチメント）は、KEV掲載のCVE、米連邦政府で使われるソフトウェア、大統領令14028の重要ソフトウェアに絞られ、それ以外は「Lowest Priority」に回されています。NVDのCPE（製品識別子）だけで自社製品と突き合わせる仕組みは分析されないCVEを取りこぼすため、CVEを登録した採番機関（CNA）の記載やベンダーのアドバイザリを読む経路も要ります。CVEとNVDの関係は[CVEの仕組みとNVDとの違い](/tech/details/5092/)で解説しています。 JVNには注意点があります。JPCERT/CCは2026年10月22日に[JVN iPediaとMyJVNの一時停止](https://jvn.jp/nav/info2026102281.html)を告知し、再開時期は未定としています。MyJVN APIとJVNDBRSSのデータフィードも止まっているため、MyJVN APIだけに頼って国内製品の脆弱性を拾っていた仕組みは、この間何も取得できていません。JVN本体（jvn.jp）とそのRSSは引き続き更新されています。情報収集を自動化するなら、取得元を1系統にせず、取得の成否と、取得したデータの最終更新日時が止まっていないかを監視しておくべきです。 ### SBOMによる照合の自動化と残る修正作業 集めた脆弱性情報が自社に関係するかは、使っている製品とバージョンの一覧と突き合わせて初めて分かります。ソフトウェアの部品表であるSBOMがあれば、この照合をOSVなどのデータベースへの問い合わせで機械化できます。ただし、照合が自動になっても対応が楽になるとは限りません。IPA産業サイバーセキュリティセンターの中核人材育成プログラムがまとめた[SBOM導入・運用の手引き（2024年12月）](https://www.ipa.go.jp/jinzai/ics/core%5Fhuman%5Fresource/final%5Fproject/2024/sbn8o10000001y6j-att/sbn8o10000001zcl.pdf)は、「SBOMで脆弱性検知ができれば、パッチ適用などの脆弱性対応が容易になる」を誤解例に挙げ、他システムへの影響調査やパッチ適用後の動作テストが必要なため、検知の工数は減っても対応に必要な作業は変わらないと書いています。自動化の投資は、検知の速さと修正の速さを分けて見積もる必要があります。AWS環境でSBOMを出力する手順は[Amazon InspectorでSBOMを出力する手順](/tech/details/4322/)で扱っています。 ## 脆弱性スキャンのCI/CD連携と定期実行 検出の自動化は、どの層を見るかで道具が分かれます。アプリケーションのソースコードはSASTのGitHub Code Scanning（CodeQL）など、依存ライブラリはSCAのDependabot alertsやTrivy、コンテナイメージやクラウド上のホストはAmazon Inspectorなどのスキャナが担います。プルリクエストのたびに走らせる検出と、新しい脆弱性が公表されたときに既存の資産を洗い直す定期スキャンは別物で、前者だけでは本番環境で動いている古いイメージを見落とします。Code Scanningの設定手順と対応言語は[GitHub Code Scanningの設定手順・対応言語](/tech/details/5210/)で扱っています。 スキャン結果をそのまま担当者へ流すと件数に埋もれるため、次の章の優先順位付けを通してから通知する設計にします。 ## KEV・EPSS・SSVCによる優先順位付けの自動化 ### KEVとEPSSの役割分担 KEVは「すでに悪用された」という事実の一覧で、[FIRSTのEPSS](https://www.first.org/epss/)は公開済みのCVEが今後30日以内に実際に悪用される確率を機械学習で推定した値です。EPSSは公開済みのCVEについて0〜1の確率とパーセンタイルを毎日公開しており、APIとCSVで無償取得できます。現行モデルは2026年6月15日に配信が始まったEPSS v5です。両者は代わりになりません。KEVは掲載まで時間がかかることがあり、EPSSは悪用が確認済みかどうかを答えません。KEV掲載を最優先にし、残りをEPSSで並べ、そのうえで資産の重要度を加味する順番が基本形です。 CVSSの基本値（Base）は深刻度の指標で、それだけでリスクを判断するものではないとCVSSの利用ガイド自身が書いています。CVSS 9.0以上から順に潰す運用は、悪用されていない高得点の脆弱性に工数を取られ、悪用中の中得点を後回しにします。 ### BOD 26-04の4変数と機械で取得できる3変数 CISAの[BOD 26-04「Prioritizing Security Updates Based on Risk」](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk)は2026年6月10日に出された米連邦民間行政機関（FCEB）向けの拘束的運用指令で、KEVを根拠にしていたBOD 22-01と、インターネットに面したシステムの修正期限を定めたBOD 19-02を置き換えました。修正の緊急度は次の4変数で決まります。 - Asset Exposure：脆弱な資産が公開されているか - KEV Status：KEVに掲載されているか - Exploit Automation：攻撃の全手順を自動化できるか - Technical Impact：悪用後に資産を部分的に制御されるか、完全に制御されるか 自動化の観点で重要なのは、CISAがこのうちKEV Status、Exploit Automation、Technical Impactの3つをVulnrichmentプログラムなどを通じてCVEごとに公開している点です。CVEレコードのCISA ADPコンテナに、KEV掲載時の追加日と、SSVCの値（悪用状況のExploitation／Automatable／Technical Impact）が入っており、APIで引けます。SSVCのExploitationはnone・poc・activeといった悪用状況の判定で、KEV掲載の有無とは別の項目です。残るAsset Exposureは、自社の資産台帳やASMの結果、ネットワーク設定から判断するしかありません。日本企業に適用義務はありませんが、変数の組み立ては民間でもそのまま使えます。 ### KEV・EPSS・SSVCを突き合わせるPythonの例 KEVのJSONフィード、EPSSのAPI、CVEレコードのVulnrichment（CISA-ADPの値だけ）を引いて、CVEごとに並べる少数件向けのスクリプトです。標準ライブラリだけで動きます。EPSSに値がないCVEは0ではなく「n/a」と表示し、CVEレコードが存在しない（404）とき以外のHTTPエラーは握りつぶさずに止めます。 ``` import json, sys, urllib.error, urllib.request KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" EPSS_URL = "https://api.first.org/data/v1/epss?cve=" CVE_URL = "https://cveawg.mitre.org/api/cve/" def get(url): req = urllib.request.Request(url, headers={"User-Agent": "triage-sample"}) with urllib.request.urlopen(req, timeout=30) as r: return json.load(r) def ssvc(cve): try: record = get(CVE_URL + cve) except urllib.error.HTTPError as e: if e.code == 404: return {} raise for adp in record["containers"].get("adp", []): if adp["providerMetadata"].get("shortName") != "CISA-ADP": continue for m in adp.get("metrics", []): o = m.get("other", {}) if o.get("type") == "ssvc": return {k: v for d in o["content"]["options"] for k, v in d.items()} return {} cves = sys.argv[1:] kev = {v["cveID"] for v in get(KEV_URL)["vulnerabilities"]} epss = {d["cve"]: float(d["epss"]) for d in get(EPSS_URL + ",".join(cves))["data"]} for cve in cves: s = ssvc(cve) print(cve, "KEV" if cve in kev else "-", f"EPSS={epss[cve]:.3f}" if cve in epss else "EPSS=n/a", s.get("Exploitation", "?"), s.get("Automatable", "?"), s.get("Technical Impact", "?")) ``` 存在しない番号（CVE-2099-0001）を含む4件を渡したときの出力例です（2026年10月26日時点のデータ・Python 3.9.6）。EPSSは小数第3位に丸めて表示するため、0.99999も1.000と出ます。 ``` $ python3 triage.py CVE-2024-3400 CVE-2025-40775 CVE-2021-44228 CVE-2099-0001 CVE-2024-3400 KEV EPSS=1.000 active yes total CVE-2025-40775 - EPSS=0.153 none yes partial CVE-2021-44228 KEV EPSS=1.000 active yes total CVE-2099-0001 - EPSS=n/a ? ? ? ``` PAN-OSのCVE-2024-3400とLog4ShellのCVE-2021-44228はKEV掲載・悪用中・自動化可能・完全制御で、公開資産にあれば最優先です。BINDのCVE-2025-40775はCVSS v3.1で7.5（High）のDNSサーバー停止（DoS）で、悪用は確認されていません。点数順より順番を下げる根拠にはなりますが、外部向けDNSを自前で運用しているなら停止の影響が大きいため、資産の重要度を確かめてから下げます。実運用では資産台帳の「公開しているか」「どの業務を止めるか」を結合し、数百件を渡すなら、EPSS APIのcveパラメータの上限（2,000文字）と、1回の応答が既定で100件までである点に合わせて、分割とページング（limit・offset）を足します。VPN機器の版とKEVの照合手順は[VPN機器の版確認コマンドとKEV照合スクリプト](/tech/details/18740/)、CVSSと実際の優先度が食い違った事例は[デジタル庁GSSの不正アクセスとVPN脆弱性の優先順位](/tech/details/18091/)で扱っています。 ## 依存関係の自動PRとAIの修正案による修正の自動化 ### Dependabotの自動プルリクエストと自動トリアージ 依存ライブラリの脆弱性は、修正のプルリクエスト作成まで自動化できます。[Dependabot security updates](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-security-updates)を有効にすると、Dependabot alertが出たときに、依存関係グラフを壊さずに上げられるかを確かめたうえで、修正を含む最小のバージョンへ更新するプルリクエストを自動で作ります。npm以外のエコシステムでは、親の依存も上げなければ直らない間接依存は更新できないなど、すべてのアラートがPRになるわけではありません。 件数を減らす仕組みが自動トリアージのルールです。プリセットの「Dismiss low impact issues for development-scoped dependencies」は、開発時だけ使うnpm依存の特定の低影響な脆弱性を通知前に自動で却下し、公開リポジトリでは既定で有効です。重大度やCWEで条件を書くカスタムルールは、組織所有の非公開リポジトリではGitHub Code Securityのライセンスが要ります。dependabot.ymlの書き方とRenovateとの違いは[Dependabotの料金とdependabot.ymlの書き方](/tech/details/6796/)を参照してください。 自動マージまで任せてよいのは、テストが十分にあり、パッチ版の更新に限る場合です。メジャーバージョンをまたぐ更新や、テストの薄いリポジトリで自動マージを有効にすると、互換性のない変更がテストをすり抜けて本番障害につながるおそれがあります。 ### AIによる修正案のレビューとテスト 自社コードの脆弱性には、AIが修正案を作る仕組みが広がっています。Copilot AutofixはCode Scanningのアラートに修正コードを提案し、GoogleのCodeMenderやAWS Continuumは修正の作成からプルリクエストまでをエージェントで進めます。出てくるのはレビュー前の差分で、業務仕様を壊していないかのテストとレビューは省けません。詳細は[GitHub Copilot Autofixの対応言語と料金](/tech/details/5213/)と[CodeMenderの仕組みとCI連携](/tech/details/16373/)で扱っています。 ## ASMによる外部攻撃面の発見と評価 ### 経済産業省ガイダンスによるASMの定義と3段階 ASM（Attack Surface Management）には日本の公的な定義があります。経済産業省が令和5年5月29日に初版を公表した[ASM導入ガイダンス](https://www.meti.go.jp/policy/netsecurity/wg1/ASMguidance.pdf)は、ASMを「組織の外部（インターネット）からアクセス可能なIT資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス」と定義しています。同書には「本書ではASMとEASMを同じ意味として取り扱う」という一文があります。一方、英国NCSCの[EASM製品の選定ガイド](https://www.ncsc.gov.uk/guidance/external-attack-surface-management-buyers-guide)はEASMをASMの一部（subset）と位置づけており、範囲の取り方は文書や製品によって違います。本記事は経済産業省の整理に従います。製品を比べるときは、各社が「攻撃面」をどこまでと定義しているかを確かめてください。 プロセスは3段階です。ドメイン名やDNS検索からIPアドレス・ホスト名の一覧を得る「攻撃面の発見」、OS・ソフトウェア・バージョン・開放ポートを通常のアクセスの範囲で集める「攻撃面の情報収集」、それを既知の脆弱性情報と突合する「攻撃面のリスク評価」です。把握していない資産や設定ミスで公開された社内システムを見つけるのが主な役割で、BOD 26-04のAsset Exposureを埋めるデータ源にもなります。評価後の対応は同書のプロセスに含まれず、組織の判断として残ります。 ### ASMと脆弱性診断の違い：確度と影響 ASMを脆弱性診断の代わりにすると危険です。ガイダンスは、ASMは外部から確認できる情報しか使わないため「脆弱性が存在する可能性の検知にとどまる」と注意しています。バージョン情報と既知の脆弱性を突き合わせているだけで、実際に悪用できるかは確かめていません。 脆弱性診断は対象へ攻撃を模したパケットを送って応答を評価するため特定の確度が高い一方、セキュリティ監視装置のアラート発報や対象の動作への支障を招く場合がある、と同書は整理しています。ASMは影響が小さく確度が低い、診断は確度が高いが影響がある、という関係です。ASMで洗い出した資産のうち重要なものに診断をかける順序が現実的です。 ## BASと自動ペネトレーションテストによる悪用可能性の検証 ### BASによる防御コントロールの有効性評価 BAS（Breach and Attack Simulation）は、実際の攻撃手法を安全な形で自社環境に対して実行し、EDR・WAF・SIEMなどが検知・防御できたかを測る仕組みです。シナリオの土台は[MITRE ATT&CK](https://attack.mitre.org/resources/versions/)で、2026年10月13日にv20.0が公開されました。測るのは攻撃が成功したかではなく、個々の攻撃挙動や複数段階のシナリオに対して防御製品が検知・遮断できたかです。EDRの除外設定が広すぎるといった、脆弱性の件数では見えない対策の穴を数字で示せます。 ### 自動ペネトレーションテストによる攻撃経路の実証 Automated Security Validation（ASV）や自動ペネトレーションテストと呼ばれる製品は、見つけた弱点を実際に突いてつなぎ、初期侵入から目的達成までの経路が通るかを確かめます。BASが防御製品の検知・遮断を測るのに対し、こちらは攻撃者が目的に届くかに重点があります（両方の機能を持つ製品もあります）。たとえば単体では低リスクと判定された設定ミスが連鎖して管理者権限に届く、といった経路の発見に向きます。経路が成立しなかった脆弱性も、検証した範囲と前提を記録しておけば、優先度を見直す材料になります。なお、Nessusは既知の脆弱性を検出するスキャナで、攻撃を連鎖させる製品ではありません。 大規模言語モデルに攻撃の手順を判断させるエージェントも出ています。オープンソースのPentAGIや、AWS Continuum（旧AWS Security Agent）のペネトレーションテスト機能が例で、詳細は[PentAGIの導入手順とDocker権限設計](/tech/details/11016/)と[AWS Security Agentのペネトレーションテストの料金と実行手順](/tech/details/10822/)で解説しています。後者は設計書や脅威モデルを読み込み、OWASP Top 10に加えてアプリ固有の業務ロジックの欠陥も試験すると[AWSのベストプラクティスガイド](https://aws.github.io/aws-security-services-best-practices/guides/security-agent/)で説明しています。それでも、どの仕様を渡し、どこまで試せば十分かを決めるのは人です。 ### GartnerのAEV統合とCTEMでの位置 GartnerはBAS、自動ペネトレーションテスト、レッドチーミングをAdversarial Exposure Validation（AEV）という1つの市場区分にまとめました。AEVのMarket Guideは2026年3月24日に最新版が公表されています。統合されたのは市場区分で、BASと自動ペネトレーションテストの検証の重点が違う点は変わりません。AEVを名乗る製品でも防御の検証と経路の実証のどちらに強いかは偏るため、どちらの問いに答える製品かで選びます。オープンソースではOpenBASがOpenAEVへ改称しており、[OpenAEVの導入手順](/tech/details/11392/)で扱っています。 CTEM（Continuous Threat Exposure Management）の5段階に当てはめると、ASMはDiscovery、KEVやEPSSによる並べ替えはPrioritization、BASと自動ペネトレーションテストはValidationを担います。範囲設定（Scoping）と修正の動員（Mobilization）は組織が決めるもので、製品だけでは回りません。詳しくは[CTEMの5つの段階と脆弱性管理との違い](/tech/details/13277/)を参照してください。 ## 自動化の導入順序と見送るべき条件 ### 資産台帳・修正体制・検知基盤による導入順序 判断材料は、資産台帳の正確さ、修正の体制、検知基盤の有無の3つです。 - 公開資産の一覧を即答できない、グループ会社や海外拠点の資産を把握していない場合は、ASMと資産台帳から始める - 台帳はあるが毎月の検出件数をさばけていない場合は、KEVとEPSSによる優先順位付けを先に自動化する - 依存ライブラリの更新が滞っている開発チームは、Dependabotなどの自動PRとテストの整備を進める - EDRやWAFを導入済みだが設定が導入時のままで、検知実績を確かめていない場合は、BASを優先する ASM導入ガイダンスは、机上の検討が難しい場合は少額で実行できる範囲のPoC（概念実証）が有用だとし、調査対象の範囲や、発見した資産の管理者が分からなかったときの扱いを事前に決めておくよう求めています。管理者不明の資産が見つかったときの調査担当・対応期限・エスカレーション先を決めていないと、発見結果が放置されやすくなります。社外の診断と組み合わせて体制を作る場合は、issohの[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)でも相談を受けています。 ### 自動化を見送る条件と先に整える前提 次の条件に当てはまる工程は、ツールを入れる前に前提を整えるべきです。 - 直す体制がない：優先順位付けや検証は「直すものが多すぎて順番がつかない」問題を解くもので、「直す人手がない」問題は解きません。パッチ適用に数か月かかる組織では、未対応の一覧が増えるだけです。 - 結果を観測できない：BASは防御・検知・対応の結果を記録できて初めて評価になります。検知や遮断のログを集める仕組みがなければ、何が効かなかったのかを切り分けられません。 - テストのない自動マージ：自動PRを自動マージまでつなぐと、互換性のない更新がそのまま本番に入ります。 - KEVだけを待つ：KEVは悪用が確認されてから載る一覧で、CISA自身も掲載まで遅れることがあるとしています。公開資産にある脆弱性はKEV掲載を待たずにEPSSと露出で判断します。 ## よくある質問 ### BASとは何の略ですか？ セキュリティ分野のBASはBreach and Attack Simulation（侵害・攻撃シミュレーション）の略で、実際の攻撃手法を安全な形で実行し、自社の防御が機能するかを継続的に確かめる技術を指します。建物の設備を制御するビルオートメーションシステム（Building Automation System）もBASと略されるため、検索時は正式名称を添えると混ざりません。 ### ASMと脆弱性管理の違いは何ですか？ ASMは外部から到達できるIT資産を見つけ、既知の脆弱性がありそうかを継続的に評価する工程です。脆弱性管理は、見つかった脆弱性に優先順位をつけて修正し、直ったかを確かめるまでを含む運用全体を指します。ASMは脆弱性管理の入口にあたる資産の発見と評価を担い、修正の判断までは含みません。 ### ASVとは何の略ですか？ この記事ではAutomated Security Validation（自動化されたセキュリティ検証）の略として使っています。PCI DSSの文脈でASVと書かれている場合はApproved Scanning Vendor（PCI SSCが認定したスキャニングベンダー）を指し、別のものです。 ### 自動ペネトレーションテストはどのくらいの頻度で実施すべきですか？ 準拠する基準があればそれに従います。PCI DSS v4.xは要件11.4.2（内部）と11.4.3（外部）で、少なくとも12か月ごとと重大な変更の後のペネトレーションテストを求めています。どちらもv3.2.1から引き継いだ既存要件で、2025年3月31日に発効した将来日付要件ではありません。自動ツールはリリースのたびの検証を足せますが、年次テストには範囲と手法の要件があり、継続実行だけで置き換えられるとは限りません。 ### SaaSやクラウド上のシステムにペネトレーションテストを実行できますか？ 事業者のポリシーの範囲内でだけ可能です。[AWSのPenetration Testingポリシー](https://aws.amazon.com/security/penetration-testing/)は、EC2やRDS、Lambda、Amazon Bedrock AgentCoreなどの許可サービスなら事前承認なしでテストできるとする一方、C2を含むテストは事前承認制とし、DoSやフラッディング、S3バケットやサブドメインのテイクオーバーを禁止事項に挙げています（DDoSのシミュレーションは別のDDoSシミュレーションテストのポリシーに従います）。AWSのサービス自体への診断も認められていません。SaaSは利用者が診断できないことが多く、認証設定と権限の点検、第三者監査報告書の確認が中心です。 ## 関連記事 - [ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](/column/details/13440/) - [CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説](/tech/details/13277/) - [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](/column/details/13101/) - [Dependabotとは｜料金は無料・dependabot.ymlの書き方とRenovateとの違い【2026年10月】](/tech/details/6796/) - [OpenAEVとは？OpenBASからの改称・CE/EEの違いとDocker導入手順【2026年10月】](/tech/details/11392/) --- 出典: [脆弱性対応の自動化｜情報収集・優先順位付け・修正・検証で任せる範囲と人が残す判断]()（株式会社一創）