自動化された脆弱性管理の解説：ツール、プロセス、およびメリット

自動化されていると謳っている脆弱性管理プログラムのほとんどは、実際には自動化されていません。 各工程、すなわちスキャンや、場合によってはチケット作成の処理速度は向上しましたが、これらをワークフローに組み込んで、人の手を介さずに露出処理を完了させる仕組みにはなっていません。 「自動化が実行された」時点と「実際にエクスポージャーが解消された」時点との間に生じるギャップこそが、プログラムが失敗する原因となります。

この記事では、真に自動化された脆弱性管理プログラムと、単に作業のスピードを上げるだけのプログラムとの違いについて解説します。これには、ガバナンスの枠組み、ワークフローのアーキテクチャ、そして自動化が成果を上げているかどうかを示す指標などが含まれます。

自動化された脆弱性管理プログラムと標準的なプログラムとの違いとは

脆弱性管理の自動化により、人の介入を最小限に抑えながら、セキュリティ上の弱点を継続的に特定、評価、優先順位付けし、是正措置を講じます。 これにより、断続的なスキャンサイクルに代わり、リアルタイムの検知、脅威インテリジェンスを活用した機械による優先順位付け、および連携のとれたワークフローが実現されます。

それが教科書的な定義です。 実際には、「自動化」を謳うプログラムのほとんどは、期待に応えられていません。 スキャン作業は自動化されており、チケットの作成も自動化されているかもしれませんが、スキャナーの出力から脆弱性の修正完了に至るまでのプロセスには、依然として手作業の段階が残っています。これには、検出結果の詳細化、資産所有者への連絡、チーム間の調整などが含まれます。 それを「自動化」と呼ぶのは、そのツールが実際に提供している機能を過大評価することになります。

そして、そのリスクは現実のものなのです。 未解決の未処理事項は、侵害リスクを大幅に高める可能性があります。というのも、攻撃者は、組織がまだパッチを適用できていない既知の脆弱性を常套手段として悪用するからです。

標準的な の脆弱性管理プログラム と、真に自動化されたプログラムとの違いは、主に次の3点に集約されます。それは、継続的な検出（定期的なスキャンではないこと）、システム主導の優先順位付け（深刻度ラベルのみに依存しないこと）、そして検証を伴う調整された是正措置（単に「パッチを適用し、チケットをクローズする」だけではないこと）です。

ガバナンスの枠組みがないまま自動化を行うプログラムでは、以下の3つの失敗パターンが繰り返し見られます：

1. 優先順位の決定を自動化せずに発見プロセスを自動化すること： 継続的なスキャンにより、何千もの発見事項が生成されます。 優先順位の自動付けが行われないと、分析担当者が優先順位を判断するよりも早く、調査結果が山積みになってしまいます。 待ち行列は長くなり、アラート疲れが生じてきます。
2. ガバナンスのない状態での修正作業の自動化： 自動パッチ適用 は、テストされていない更新プログラムによって本番システムが障害を起こすまでは、効率的であるように思えます。 段階的な導入を行わない自動化は、 サイバーリスク といった、軽減しようとしているリスクを上回る変更リスクをもたらす可能性があります。
3. 各段階を連携させずに自動化する方法： ディスカバリーで収集したデータをスキャナーコンソールに反映させ、優先順位付けはスプレッドシートで行います。 修正依頼は、ITサービスマネジメント（ITSM）ツールに登録されます。 各段階は個別に「自動化」されていますが、段階間の引き継ぎは手動で行われます。

残されているのは、拡大し続ける の攻撃対象領域 であり、これを単一のチームが完全に把握することはできず、断片化された状態の自動化では、その縮小にはまったく寄与していません。

階層型自動化フレームワーク

脆弱性管理プログラムにおけるすべての項目が、同じリスクプロファイルを持つわけではありません。 一部の業務は、完全に自動化しても問題ありません。 その他については、人による確認が必要です。 その境界を決定する基準には、資産の重要度、変更に伴うリスク、およびデータの信頼度レベルなどが含まれます。

ディスカバリーの自動化

継続的なスキャンは、資産の検出における基本となります。 ガバナンス上の決定は、ディスカバリーを自動化するかどうかではなく、その範囲をどのように定めるかということです。 対象となる資産クラスにはどのようなものがありますか？ どのネットワークですか？ エージェントレスなターゲットには、どのような更新間隔が適切でしょうか？

の完全かつ最新の資産インベントリ（ ）は、効果的なディスカバリー自動化の前提条件となります。存在すら把握していないものをスキャンすることはできません。

ディスカバリーの自動化は、もはや必須の要件です。 もしまだ月次スキャンを実施しているようであれば、自動化された脆弱性管理への移行準備は整っていません。

優先順位付けの自動化

優先順位の自動付けには、機械が読み取れる形式の入力データが必要です。 このシステムは、少なくとも、脆弱性が 30 日以内に実環境で悪用される確率を推定する「エクスプロイト予測スコアリングシステム（EPSS）」のスコア、CISAの「既知の悪用済み脆弱性（KEV）」カタログ、および資産の重要度データを取り込みます。

共通脆弱性評価システム（CVSS）のスコアは、深刻度を判断する上で有用な基準となりますが、EPSS、KEV、および資産の重要度データを組み合わせて考慮せずに、CVSSスコアのみに依存して優先順位付けを行うと、実際の悪用可能性を反映していない優先順位リストができてしまいます。 また、多くのプラットフォームでは、NVD（National Vulnerability Database）から脆弱性の詳細情報を直接取得しており、手動での更新を行わなくてもCVEのメタデータが常に最新の状態に保たれるようになっています。 システム上、アナリストが の脅威インテリジェンス（）を用いて調査結果を手動で補完しなければならない場合、それはボトルネックとなります。 自動化された優先順位付けの最大の目的は、アナリストがすべての発見事項を個別に精査することなく、重要な脆弱性を特定することにあります。

リスクベースの脆弱性管理（、以下、RVMと略称されることが多い）では、各入力要素がどのように組み合わされてリスクスコアが算出されるかが説明されています。 自動化の観点から、問題は次の通りです。システムは、手動による介入なしに、データソースを自動的に取り込み、優先順位付けのロジックを適用することができるでしょうか？

修復作業の自動化

脆弱性の修正 は変更に伴うリスクをもたらすため、ガバナンスが極めて重要となります。

の自動修復機能（ ）は処理速度を向上させることができますが、自動化の範囲設定が不適切だと、サービス停止を引き起こしたり、本番システムの安定性を損なったりする恐れがあります。 重要なのは、自動化が適切である場面と、人の承認が必要な場面を明確に定義することです。 実際には、その境界線は、資産の重要度、パッチの信頼性、および障害が発生した場合の影響の大きさによって決定されます。

• 信頼性の高いパッチを用いて、重要度の低い資産を完全に自動化します
• 本番システム、インターネットに公開されている資産、または信頼度スコアが低いパッチについては、承認を必要とします
• の段階的リング型デプロイメント（ ）を活用して、ロールアウトを段階的に実施し、問題が重要なシステムに到達する前に検出してください。

ロールバック機能は、いかなるレベルの自動化においても必須の要件です。 パッチによってシステムの不安定化が生じた場合、システムはその変更を自動的に元に戻すか、または定義されたメンテナンス時間帯内に手動での対応をトリガーする必要があります。

検証の自動化

多くのプログラムでは、検証をライフサイクルの最終段階における単なるチェック項目として扱っています。 これは、是正措置が有効だったかどうかを確認するための、独自の自動化機能です。

この枠組みは固定されたものではありません。 自動化への信頼が高まり、誤検知率が低下するにつれて、タスクは「ヒューマン・イン・ザ・ループ」から完全自動化へと移行していくことができます。

発見、優先順位付け、および是正措置の関連性

この段階的な枠組みでは、各段階で何を自動化するかが定義されていますが、個々の段階内でのガバナンスだけでは、段階間の問題は解決されません。

自動化された脆弱性管理では、引き継ぎの段階で問題が生じることがよくあります。 各段階は個別に効率的に実行できますが、段階間でデータにコンテキストが引き継がれないと、ワークフローが機能しなくなります。 これは、資産の所有権、ネットワークのセグメンテーション、システムの依存関係がチームごとに大きく異なるような、複雑なIT環境において特に当てはまります。

最も重要な連携は、ワークフローの2つの重要なポイントで行われます。

発見から優先順位付けまで

スキャナーは所見を検出します。 優先順位付けエンジンがそれらを処理します。 重要なのは、2つのシステムの間をやり取りされるものです。

どのような不具合が発生するか：

• ビジネス上の文脈を含まない、スキャンしたままの出力データ
• 優先順位付けに先立ち、所見を手作業で精査すること
• 資産の重要度、所有権、およびエクスポージャーに関するデータが欠落しています

スキャン結果が生の出力（CVE ID、深刻度スコア、影響を受けるホスト）として届いた場合、優先順位付けエンジンには、実際のリスクを評価するために必要な情報が不足してしまいます。 資産の重要度、業務機能、ネットワーク上の位置、および補完的統制は、いずれも優先順位の決定に影響を与えます。 その状況で手動による情報補完が必要になると、ボトルネックが生じます。 その違いは、その文脈が結果に自動的に付随するのか、それとも手動で追加しなければならないのかという点に尽きます。

ディスカバリの出力にデフォルトでアセットのコンテキストが含まれている場合、ワークフローは正常に完了します。 スキャナーは、資産の重要度レベル、ビジネス上の役割、およびネットワークへの露出状況を特定または照会し、そのコンテキストは検出結果とともに優先順位付けエンジンへと渡されます。

効果的な方法：

• アセットのコンテキストは、各検索結果ごとに引き継がれます
• 重要度、業務機能、およびネットワークへの露出は自動的に含まれます
• リスクスコアリングには、是正措置が考慮されています

ネットワークのセグメンテーション、WAFルール、エンドポイント検知の適用範囲といった補完的な対策は、悪用可能性を明らかに制限している場合、実効リスクスコアを低減させるべきです。 これらの制御を無視する優先順位付けエンジンは、すでに部分的に緩和されている検出結果を過度にエスカレーションしてしまいます。

是正措置の優先順位付け

優先順位が付けられた調査結果は、是正措置の課題となります。 チケットにCVE IDと深刻度ラベルしか記載されていない場合、対応チームは必要な情報を得られず、適切な対応ができません。 チケットにアクションに必要な背景情報が欠けていると、プロセスが滞ってしまいます。

どのような不具合が発生するか：

• 深刻度スコアとCVE IDのみが含まれるチケット
• SLAの期限の未遵守および所有者情報について
• 是正措置に関する指針や優先順位の判断基準がありません

効果的なワークフローへの移行は、チケットに、直ちに対応できるだけの十分な背景情報が含まれているかどうかにかかっています。

効果的な方法：

• チケットには、資産所有者、SLAの期限、およびリスクレベルが含まれます
• 作成時に是正措置に関する指針が添付されています
• EPSSやKEVといった脅威シグナルは、実行段階まで引き継がれます

チケットが作成時に必要な情報がすべて追加されていれば、接続は正常に機能します。 資産の所有権データによってルーティングが決定されます。 リスクレベルによって緊急度が決まります。 是正措置に関する指針は、曖昧さを解消します。 チケットは作成された時点で処理可能となります。

EPSSやKEVデータフローなどの脅威シグナル（ ）は、ワークフロー全体を通じて維持される必要があります。 脆弱性が「現在悪用されている」とフラグ付けされた場合、その指定は是正タスクにも引き継がれるため、チームには単に「重大な深刻度」ではなく、「現在悪用されている」と表示されます。

IT／SecOpsの連携層

自動化は、IT部門とセキュリティ部門の間の組織的な境界（ ）でしばしば行き詰まります。そこでは、セキュリティチームが問題の発見と優先順位付けを担当し、IT運用部門が是正措置の実行を担当しています。 もし両者間の引き継ぎがスプレッドシートやメールであるならば、自動化によって調整上の問題は解決されていないことになります。

所有権の境界

明確な責任分担モデルにより、各段階において誰が責任を負うかが明確になります。 セキュリティ部門は、検出設定、優先順位付けのロジック、およびリスク階層の定義を管轄しています。 IT運用部門は、是正措置の実施、変更管理、および展開スケジュールの策定を担当しています。 両者とも、検証およびSLAの遵守について責任を分担しています。

明確な責任の所在が定まっていないと、調査結果は、どちらのチームも自分たちの責任とは考えていない状態で、積み上がってしまいます。 警備担当者は、「特定しました」と述べています。 IT部門は、「それが緊急だとは知りませんでした」と述べています。 この脆弱性は依然として未修正のままです。

ITSMの統合

ServiceNowの脆弱性対応「 」（または同等のITSM統合機能）は、資産のコンテキストに基づいて担当者を割り当て、ワークフローのルーティングを自動化します。 優先順位が付けられた調査結果に基づいてチケットが作成されると、ITSM連携機能により、資産の所有権データに基づいて適切なチームにチケットが振り分けられます。各チケットには、SLAの期限、リスクレベル、および是正措置の指針が含まれます。 これにより、優先順位付けと実行の間の連携のギャップが解消されます。 チームが事後にリスクを解釈するのではなく、このシステムは作成されたその時点で実行可能なタスクを生成します。

より成熟した環境では、脆弱性の検出結果は、セキュリティ情報イベント管理（SIEM）システムにも取り込まれ、進行中の脅威の検知との相関分析に活用されます。 脅威イベントログにも記録される脆弱性については、通常のキューで待機することなく、自動的にエスカレーションされます。

セキュリティ・オーケストレーション、自動化、および対応（SOAR）プラットフォームは、 の自動対応プレイブック（ ）により、この機能をさらに拡張します。これにより、相関付けられたアラートから直接是正措置をトリガーすることができ、人的な介入を必要とせずに、検知から対応までの時間を短縮できます。

資産の重要度に応じたSLAレベル

すべての脆弱性について、同じ是正措置のスケジュールが適用されるわけではありません。 SLAの階層は、資産の重要度を反映しています：

• インターネットに公開されている本番環境リソース： 24時間対応の復旧SLA
• 社内生産システム： 72時間SLA
• 開発およびステージング環境： 、7日間のSLA

ティアが違反された場合、自動エスカレーションがトリガーされます。 インターネットに公開されている資産について、是正措置が講じられないまま 24 時間を超えた場合、システムは当該資産の所有者の上司およびセキュリティチームにエスカレーションを行います。

PCI DSSや などの類似したコンプライアンスフレームワーク の対象となる組織では、社内のSLAレベルよりも優先される、外部から義務付けられた是正措置の期間が設けられている場合があります。 これらは、自動エスカレーションロジックに明示的に組み込む必要があります。

説明責任のギャップ

ほとんどのプログラムでは答えられていない疑問があります。自動化ツール がパッチを適用した際、エンドポイントが問題の解決を確認しなかった場合、その例外の責任は誰にあるのでしょうか？

もし答えが「場合によります」というものであれば、ガバナンス上の課題が存在します。

未解決の例外は、まさにランサムウェアの運営者やその他の脅威アクターが積極的にスキャンし、悪用しようとする脆弱性そのものです。 例外の所有権を明示的に定義してください。 通常、IT運用部門がデプロイの失敗（パッチがインストールされなかったなど）の責任を負います。 セキュリティ部門は、検証の失敗（パッチが適用されたにもかかわらず脆弱性が残っている場合）について責任を負います。

検証と例外処理

「展開が確認されました」は、「エクスポージャーが閉じられました」とは異なります。

パッチの適用が正常に完了しても、サービスが再起動されなかったり、設定が更新されなかったり、あるいは修正内容がエンドポイントに存在する亜種に対応していなかったりする場合、その脆弱性が依然として悪用される可能性があります。

どの検証が何を確かめるのか

検証の自動化により、是正措置によってリスクが解消されたことが確認され、単に何らかの措置が講じられたというだけではないことが明らかになります。 これには、パッチの適用後に自動で再スキャンを行い、スキャン結果に当該の脆弱性が表示されなくなったことを確認することに加え、パッチが適用され、有効になっていることを確認するためのエンドポイントの状態検証も含まれます。 設定に基づく修正の場合、検証により、意図した状態の変更が反映されたことが確認されます。

検証に失敗した場合

是正措置を講じても問題が解決しない場合、ワークフローは自動的に再開始されなければなりません。 検出結果は、以前の是正措置が失敗したことを示すフラグが付いた状態で、優先順位付けキューに再登録されます。 違いは、障害がワークフローの一部として処理されるのか、それとも手動でのフォローアップに委ねられるのかという点にあります。

設定や互換性に関連する不具合や問題が繰り返し発生する場合は、人による調査が必要となります。 検証では成功と報告されているにもかかわらず、曝露が継続している「偽陰性」は、検出がより困難です。 定期的な全面的な再スキャンと、高価値資産に対する重点的なチェックを組み合わせることで、このリスクを軽減することができます。

検証としての継続的なモニタリング

継続的な監視（ ）は、独立したライフサイクル段階ではなく、検証レイヤーが継続的に果たす機能です。 以前に検証済みの資産で新たに脆弱性が発見された場合、その資産は自動的にワークフローに再登録されます。

「デプロイ完了」と「エクスポージャー解決」の違いこそが、成熟した自動化と単なるチェックボックス式の自動化を分けるものです。

重要な指標

アクティビティ指標（実行されたスキャン、作成されたチケット、適用されたパッチ）は、プログラムが活発に稼働していることを示すものであり、それが機能しているかどうかを示すものではありません。 自動化によって実際にリスクが低減されているかどうかを測定するには、別の指標が必要です。

以下の4つの自動化に特化した指標は、貴社のプログラムが実際の成果を上げているかどうかを明らかにするのに役立ちます：

1. 自動化の適用率： この指標は、手動による介入なしに、自動化されたワークフロー（検出から是正まで）によって完全に処理された脆弱性の検出件数の割合を測定するものです。 60％を下回る場合は、通常、ツールへの投資を行っているにもかかわらず、そのプログラムが依然として手作業に大きく依存していることを示していますが、適切な目標値は組織の資産構成やリスク許容度によって異なります。
2. 自動修復の成功率： この指標は、検証レイヤーによって初回試行で完了と確認された自動修復アクションの割合を測定するものです。 85％未満の場合は、ガバナンス上の課題があることを示しています。 パッチが誤ったアセットクラスに展開されたり、エンドポイントの状態の問題により展開に失敗したりする可能性があります。
3. 自動ワークフローにおける誤検知率： この指標は、自動優先順位付けによってエスカレーションされたものの、実際には悪用不可能であったか、すでに緩和措置が講じられていたことが判明した検出結果の割合を測定するものです。 15%を超える場合は、優先順位設定の調整が必要です。
4. ティア別の自動解決： この指標は、一般にMTTRとして追跡されており、SLAティアごとに区分して、問題の発見から検証済みの解決に至るまでの完全な自動処理サイクル時間を測定するものです。 インターネットに公開されている本番環境のアセットが 24 時間を超えると、優先順位付けと是正措置の間にボトルネックが生じます。

自動化の適用範囲が広いにもかかわらず成功率が低い場合（ ）は、自動化の導入が不十分であることを示しており、一方で、適用範囲が狭いにもかかわらず成功率が高い場合（）は、 、スケーラビリティに欠けるものの効果的な手動プロセスが存在することを示しています。

しかし、どちらの結果も、多くの場合、同じ根本的な問題、すなわち連携が取れていないワークフローや断片化したデータを指し示しています。

スキャン、優先順位付け、是正措置、および検証が、それぞれ別々のツールとデータセットで行われる場合、チームは脆弱性の解消よりも、システム間の情報移動に多くの時間を費やすことになります。 セキュリティ部門が脆弱性を特定したにもかかわらず、IT運用部門が同様の緊急性や責任感を持っていない場合、連携上の問題はさらに深刻化します。 各チームは、それぞれ異なる状況に基づいて作業を進めています。

多くの自動化戦略がここで行き詰まってしまいます： 自動化された脆弱性管理は、各段階が最新のデータに基づいて処理を行い、その成果を次の段階に引き継ぐ場合にのみ機能します。そのためには、ワークフロー全体における連携のギャップを解消する、共有されたリアルタイムのデータが不可欠となります。

Taniumが、ライフサイクル全体にわたる自律的な脆弱性管理をどのようにサポートするか

の「Tanium Autonomous IT Platform」（ ）は、脆弱性対応プロセスを単一のプラットフォーム上で一元管理し、各段階でエンドポイントデータをリアルタイムで共有できるように設計されています。 これにより、ITチームとセキュリティチームは、同じ正確なデータセットに基づいて作業を行うことが可能となり、通常は問題の是正を遅らせる原因となる連携上のボトルネックを解消するのに役立ちます。

Taniumが、脆弱性管理ライフサイクルの主要な段階をどのように自動化・効率化するかを以下にご紹介します：

• 継続的かつリアルタイムな脆弱性検出： Tanium Exposure Management は、すべてのエンドポイントおよびインターネットに接続された資産を対象に、脆弱性やコンプライアンス上の不備をスキャンし、コンテンツは定期的に更新されます。 これにより、是正措置が開始される頃にはデータが数日あるいは数週間前のものになっている可能性があるという状況下でチームが作業を余儀なくされていた、定期的なスキャンサイクルに代わるものとなります。
• 管理された段階的な修復： 段階的かつリングベースの展開では、まず少数のエンドポイントから開始し、各段階が成功基準を満たすにつれて規模を拡大していきます。 Taniumのコンフィデンススコアは、チームが、自動化しても安全な低リスクのパッチと、人的な確認が必要な高リスクの変更とを区別するのに役立ちます。
• クローズドループ検証： 修正作業完了後、プラットフォームはパッチの状態を確認し、更新に失敗したシステムを特定します。 これにより、「展開を試みた」と「脆弱性が修正されたことが確認された」とを区別しています。 検証に合格しなかった調査結果は自動的に優先順位付けのキューに戻されるため、見落とされることはありません。

リカバリー・センターズ・オブ・アメリカは、Taniumを活用して、これまで検出されていなかった 2,200 台のエンドポイントにまたがる400,000 件の脆弱性を発見し、その後、2週間強でその件数を80％削減しました。 また、同組織は、年間売上高に占めるITコストの割合を 10％から 3％に引き下げました。 「」の事例研究をご覧ください。

「Taniumがなければ、エンドポイントやワークステーション、サーバーへのパッチ適用に、はるかに多くの時間を費やさなければならなかったでしょう。」 そうすれば、日々発生してくる他の業務に集中する時間は、間違いなくなくなってしまいます。”

リカバリー・センターズ・オブ・アメリカ ネットワークエンジニア クリス・マトゥーラ氏

従来の脆弱性管理から自律的なエクスポージャー管理への移行は、単なる技術的なアップグレードにとどまりません。 ガバナンスの枠組み、所有権モデル、および検証の体制によって、自動化が成果をもたらすのか、それとも単に作業のスピードを上げるだけなのかが決まります。

Taniumの統合プラットフォームアプローチは、共有されたエンドポイントデータに基づいて、検出、優先順位付け、是正措置、検証を連携させることでこの課題に対処しており、これにより各段階間でワークフローがシームレスに移行し、自動化によって一連のプロセスを完結させることができます。

自動化された脆弱性管理に関するよくある質問

自動化された脆弱性管理は、複雑かつ急速に変化する分野であるため、プログラムを常に最新の状態に保ち、適切に管理し続けることは困難です。 以下に、企業のチームから寄せられる、自動化された脆弱性管理プログラムおよびそれを支えるツールに関するよくある質問をいくつかご紹介します。

脆弱性管理の 5 のステップとはどのようなものですか？

による徹底的な脆弱性評価 が、これらの各段階の基盤となっており、発見された脆弱性が単にリスト化されるだけでなく、実際のリスクについて分析されることを保証しています。 5つの主要な段階は、発見（脆弱性を特定するための継続的なスキャン）、評価（発見された脆弱性の深刻度と悪用可能性の分析）、優先順位付け（脅威インテリジェンスと資産の重要度を用いてリスク別に脆弱性をランク付けすること）、是正措置（パッチの適用や設定の変更）、および検証（単にパッチが適用されたことを確認するのではなく、脆弱性が解消されたことを確認すること）です。

ASVスキャンと侵入テストの違いは何ですか？

認定スキャンベンダー（ASV）によるスキャンとは、コンプライアンスに重点を置いた自動化された脆弱性スキャンであり、外部から潜在的な弱点を特定するものです。一方、ペネトレーションテストでは、セキュリティの専門家が手動で脆弱性の悪用を試み、実際のリスクや影響を判断します。

自動化された脆弱性スキャンには、どのようなツールが使用されますか？

脆弱性スキャンツール「 」は、主に2つのカテゴリーに分類されます。1つは、各エンドポイントにソフトウェアを展開して継続的な監視を行うエージェント型プラットフォーム、もう1つは、スケジュールに従ってリモートでシステムをスキャンするエージェントレス型スキャナーです。 どちらを選択するかは、スキャン頻度の要件、ネットワークアーキテクチャ、およびスキャンツールが修復および検証のワークフローと直接連携しているかどうかに依存します。

セキュリティプログラムには、どのような 4 種類の脆弱性があるのでしょうか？

脆弱性の主な4つのカテゴリーは、ネットワークの脆弱性（公開されているサービス、脆弱なプロトコル）、アプリケーションの脆弱性（ソフトウェアの欠陥、不安全なコード）、設定の脆弱性（不適切な設定、デフォルトの認証情報）、および人的な脆弱性（ソーシャルエンジニアリングの標的、不十分なトレーニング）ですが、自動化された脆弱性管理プログラムは主に最初の3つに焦点を当てています。

脆弱性管理の自動化には、個別のツールだけでは不十分です。 ライフサイクルの各段階を連携させることで、洞察から解決へと、アクションがシームレスに進行するようになります。

から、無料のカスタマイズされたデモをご予約ください。Tanium が、統合されたデータ、連携されたワークフロー、継続的な検証を通じて、脆弱性管理をどのように自動化するのかをご確認いただけます。