脆弱性管理とは？脆弱性診断との違いと脆弱性検出に使えるツールを紹介

はじめに

OSやミドルウェア、ライブラリには、新たな脆弱性が日々公表されています。 一度安全性を確認したシステムでも、その後に脆弱性が判明したり、構成変更によって影響を受ける資産が増えたりするため、公開前や年1回の検査だけではリスクの変化を追い切れません。

そこで企業に求められるのが「脆弱性管理」です。 これは、システムで利用するライブラリやミドルウェアなどの脆弱性を継続的に発見し、対応状況を管理するプロセスを指します。 この記事では、脆弱性管理と脆弱性診断の違いを整理し、Amazon Inspector v2、Vuls、Trivyを使った検出方法を含め、企業で運用を定着させる手順を解説します。

脆弱性管理とは

脆弱性管理とは、対象システムで利用するライブラリ、ミドルウェア、OSなどの脆弱性を継続的に発見し、影響と対応状況を管理するプロセスです。 検出した脆弱性を記録し、対象の資産と所有者を特定して、優先順位付け、修正、アラートの抑制といったトリアージを行います。

脆弱性スキャナを導入して検出件数を集計するだけでは、脆弱性管理は成立しません。 誰がどの資産を所有しているか、何を優先していつまでに修正するか、どの条件でアラートを抑制するかまで決める必要があります。

脆弱性診断との違い

脆弱性診断は、定めた時点と範囲でシステムを検査し、脆弱性の有無や影響を確認する検証です。 エンジニアが手動で行う脆弱性診断では、Webアプリケーションの認可不備やビジネスロジックの問題など、自動スキャンだけでは判断しにくい脆弱性を検証できます。

これに対して脆弱性管理は、検出後に優先順位付け、修正、アラートの抑制といったトリアージを繰り返す運用です。 脆弱性診断は「脆弱性管理を置き換えるもの」ではなく、管理プロセスへ脆弱性情報を供給する検出手段の一つと位置付けます。

企業で脆弱性管理を運用する手順

1. 管理対象と所有者を把握する

最初に、サーバ、端末、クラウドアカウント、コンテナ、アプリケーション、利用中のソフトウェアを台帳へ登録し、事業上の重要度と所有者を紐づけます。 検出対象から漏れた資産は脆弱性の有無を判断できず、所有者が不明な資産は修正依頼の行き先が決まりません。

クラウド環境では資産が短期間で作成、削除されるため、手作業の棚卸しだけでは実態との差が広がります。 クラウドのAPIや構成管理の情報を利用し、資産台帳を自動更新できる仕組みを検討します。

2. 複数の方法で脆弱性を検出する

OSやパッケージの既知の脆弱性は継続的なスキャンで検出し、Webアプリケーションの設計や実装に起因する問題はリリース前や大規模変更時の脆弱性診断で確認します。 一つの方法ですべてを検出できるわけではないため、インフラ、コンテナ、依存ライブラリ、Webアプリケーションなど、対象ごとに適した検出方法を割り当てます。

スキャン頻度は「月1回」のような日付だけで決めず、新しいCVEの公表、ソフトウェアの更新、資産の追加といったリスクが変化する契機も考慮します。 自動検出を基本にすると、前回の定期スキャン直後に公表された重大な脆弱性を次回まで見落とすリスクを軽減し、未対応の期間を短縮できます。

3. 事業への影響を踏まえて優先順位を付ける

CVSSの深刻度は優先順位を決める材料ですが、点数だけで対応順を決めると、自社で悪用されやすい項目が後回しになることがあります。 インターネットから到達できるか、実際の悪用が確認されているか、機密情報や管理者権限へ到達できるか、該当資産がどの業務を支えているかを併せて評価します。

同じCVEでも、外部公開された本番サーバと隔離された検証環境では想定される被害が異なります。 脆弱性の技術的な深刻度に資産の重要度と露出状況を重ね、対応理由を記録します。

4. 担当者と期限を決めて修正する

優先度ごとに対応期限を定め、各項目を資産の所有部門または開発チームへ割り当てます。 担当者はパッチ適用、バージョン更新、設定変更などから対応方法を選び、たとえばCriticalは24時間以内に一次判断を行うなど、組織の体制に合わせて期限を設定します。

セキュリティ部門だけに修正責任を集めても、システムへの変更権限や業務停止の判断権限がなければ対応は進みません。 セキュリティ部門は評価基準と全体状況を管理し、資産所有者が修正を実施する役割分担にします。

5. 対応しないアラートを抑制する

誤検知であることを確認した場合や、緩和策によって影響を許容すると判断した場合は、該当するアラートを抑制します。 単に一覧から消すのではなく、対象、抑制理由、想定する影響、承認者、有効期限を記録します。

抑制条件を製品全体やCVE全体に広げると、対応すべき別の資産のアラートまで見えなくなる可能性があります。 資産や検出条件を限定し、有効期限を迎えた抑制ルールは継続の可否を判断します。

6. 運用を見直す

月次レビューでは、重大な脆弱性の未対応件数、期限内対応率、平均修正時間、スキャン対象になっている資産の割合、有効期限が切れた抑制ルールの件数を確認します。 件数の増減だけで担当者を評価せず、資産追加や検出範囲の拡大による増加と、対応の遅延による増加を区別します。

AWSで使えるAmazon Inspector v2

Amazon Inspectorは、AWSワークロードを自動検出し、ソフトウェアの脆弱性と意図しないネットワーク露出を継続的に評価する脆弱性管理サービスです。 一般にAmazon Inspector v2と呼ばれる現在のサービスは、Amazon EC2インスタンス、Amazon ECRのコンテナイメージ、AWS Lambda関数を対象にします。

対象リソースの変更や新しいCVEの公表に応じて再評価し、問題を検出すると影響を受けるリソースや修正方法を含むFindingを作成します。 EC2ではインターネットから到達できる経路の有無などを考慮したAmazon Inspector risk scoreも利用できるため、CVSS基本値だけを使う場合よりAWS環境の実態を優先順位へ反映しやすくなります。

複数のAWSアカウントを使う企業では、AWS Organizationsの委任管理者アカウントから検出結果とスキャン状況を集約できます。 Amazon EventBridgeやAWS Security Hub CSPMと連携すれば、重大なFindingの通知やチケット作成など、既存の対応フローへ組み込めます。

ただし、Amazon Inspectorを有効にすれば修正まで自動で完了するわけではありません。 Findingの担当者、対応期限、抑制ルールの承認方法を別途定める必要があり、Webアプリケーション固有の認可やビジネスロジックは脆弱性診断で補います。

サーバの脆弱性を検出するVuls

Vulsは、LinuxとFreeBSDを主な対象とするオープンソースの脆弱性スキャナです。 NVD、JVN、OVALなどの脆弱性情報と対象サーバのパッケージ情報を照合し、影響を受ける既知の脆弱性を検出します。

リモートスキャンでは中央のVulsサーバからSSHで対象へ接続するため、各サーバへの専用エージェント導入を避けられます。 中央サーバからSSH接続させたくない構成では、対象側で情報を収集するローカルスキャンも選択できます。

Vulsは自社環境に合わせて構成や連携を設計でき、クラウドとオンプレミスのLinuxサーバを共通の仕組みで確認したい場合に適しています。 一方で、Vuls本体と脆弱性データベースの更新、認証情報の保護、定期実行、結果の保管、通知、障害対応は利用組織が設計して運用します。

OSSであることは「運用コストが発生しない」という意味ではありません。 対象OSの対応状況と必要なスキャン方式を確認し、保守に使える人員を含めて採用を判断します。

コンテナや依存ライブラリを検査するTrivy

Trivyは、Aqua Securityが開発するオープンソースのセキュリティスキャナです。 コンテナイメージ、ファイルシステム、Gitリポジトリ、仮想マシンイメージ、Kubernetesを対象に、OSパッケージや利用中のソフトウェア依存関係に含まれる既知の脆弱性を検出できます。

Trivyは脆弱性だけでなく、Infrastructure as Codeの設定不備、シークレット、ソフトウェアライセンスも検査できます。 ただし、検査対象と検出種別を広げるほど確認すべき結果も増えるため、脆弱性管理へ導入する際は、どのリポジトリやイメージにどの検査を適用するかを先に定めます。

コマンドラインで実行でき、GitHub Actionsなどの継続的インテグレーションへ組み込めるため、コンテナイメージや依存ライブラリをリリース前に確認したい開発チームに適しています。 ビルド時の検査では基準を超える問題を早期に検出し、本番環境の定期スキャンではリリース後に公表されたCVEを追跡するなど、実行段階ごとの役割を分けます。

Trivyも検出後の修正担当者やアラートの抑制を管理する仕組みそのものではありません。 脆弱性データベースとTrivy本体の更新、結果の集約、重複排除、対応チケットへの連携は利用組織が運用します。

管理対象に応じた使い分け

Amazon Inspector v2、Vuls、Trivyは、同じ用途を持つ製品の選択肢ではありません。 Amazon Inspector v2はAWSワークロードの継続評価、VulsはLinuxやFreeBSDサーバのパッケージ調査、Trivyはコンテナイメージやソフトウェア依存関係を含む開発成果物の検査に、それぞれ異なる強みがあります。

AWS中心の環境ではAmazon Inspector v2を運用の起点とし、AWS外のサーバも管理する場合はVulsで対象を補います。 コンテナやアプリケーションの依存ライブラリは、TrivyをCI/CDへ組み込み、リリース前から検出する構成が考えられます。

複数のスキャナを併用する場合は、同じ脆弱性が複数の経路から登録されることを前提に、CVE、資産、パッケージなどを使った重複排除のルールを決めます。 いずれを選んでも、Webアプリケーションの手動診断を含むすべての検査を代替するものではありません。

DevSecOpsに脆弱性管理を組み込む

脆弱性管理をリリース後の運用だけで行うと、依存ライブラリやコンテナイメージの問題を本番環境への反映後に初めて検出することがあります。 DevSecOpsでは、開発者が利用するCI/CDへスキャンを組み込み、コードの変更やビルドの段階から脆弱性を検出します。

たとえば、Trivyでコンテナイメージや依存ライブラリをリリース前に検査し、Amazon Inspector v2でAWSへ配置したワークロードを継続的に評価できます。 検出した場所が異なっても、結果は共通の管理先へ集約し、優先順位付け、修正、アラートの抑制といったトリアージへ渡します。

すべての検出結果を同じ条件でビルド停止の対象にすると、対応を急ぐ必要がない脆弱性までリリースを妨げます。 深刻度、外部からの到達可能性、対象機能の利用状況に応じて停止基準と修正期限を定め、アラートを抑制する場合は理由と有効期限を記録します。

運用を形骸化させないための役割分担

脆弱性管理では、セキュリティ部門が全体の基準と検出基盤を管理し、情報システム部門や開発チームが対象資産の修正を担います。 組織規模に応じて一人が複数の役割を兼ねても、責任の所在は分けて定義します。

定例会では全件を順番に読み上げるのではなく、期限超過、重大な新規脆弱性、有効期限が近い抑制ルール、検出対象外の資産を扱います。 判断が必要な項目に時間を使うことで、会議を報告の場ではなく対応を進める場にできます。

まとめ

脆弱性管理は、対象システムで利用するライブラリ、ミドルウェア、OSなどの脆弱性を継続的に発見し、その影響と対応状況を管理するプロセスです。 検出後は事業への影響に基づく優先順位付け、修正、アラートの抑制といったトリアージを行います。

脆弱性診断は、主にアプリケーションのコードや設計に起因する脆弱性を、特定の時点と範囲で詳しく調べる検証です。 ライブラリやミドルウェアの既知の脆弱性を継続的に扱う脆弱性管理とは対象と検出方法が異なるため、両者を組み合わせて異なる種類の脆弱性を確認します。

AWSワークロードにはAmazon Inspector v2、自社で管理するLinuxやFreeBSDのサーバにはVuls、コンテナやソフトウェア依存関係を開発工程で検査する場合はTrivyが選択肢になります。 製品やOSSの導入をゴールにせず、資産の管理者、修正担当者、アラートの抑制を承認する人まで定めることで、検出結果を実際のリスク低減へつなげられます。

脆弱性管理の体制づくりにお困りの場合

自社だけで検出結果の評価や修正状況の管理を継続することが難しい場合は、弊社のセキュリティチーム代行サービスをご検討ください。 資産と役割の整理、運用ルールの作成、脆弱性の優先順位付け、対応状況のレビューまで、外部のセキュリティチームとして支援します。