脆弱性を見つける方法

by Canonical on 13 June 2025

脆弱性の評価を行う方法

情報セキュリティの世界は専門用語だらけです。脆弱性関連の用語を見たことがある方ならご存じでしょう。さらに厄介なのは、複数の用語が同じ意味に使用されたり、コンピューター以外の分野で使用される用語が混じっていたりすることです。これは、脆弱性の評価について学びたいと考えている人にとって混乱の元です。ですからこのブログ記事では、Ubuntu環境の脆弱性評価について掘り下げる前に、用語の意味を解説します。

脆弱性とは

脆弱性とは、攻撃者による悪用やユーザーのミスによって損害を引き起こす可能性のあるすべての欠陥です。リスク管理において脆弱性は、脅威の可能性を高める、または攻撃が成功したときの損失を増やす、あるいはその両方によって、リスクを増大させます。

サイバーセキュリティの世界では、脆弱性は一般に以下の2つに分類されます。

• 何らかの害を引き起こすシステム（ほとんどはソフトウェアコード）のロジックにおける欠陥
• 同様にセキュリティ全体を弱体化させるシステムの設定ミスや誤用

この区別に明確な根拠はありませんが、サイバーセキュリティの分野ではよく使われるので覚えておきましょう。この区別をベースにして、この後の考察を進めます。

わかりやすいよう、よく知られた脆弱性の例を2つ挙げます。

• Log4Shell – 人気の高いApache Log4jソフトウェアフレームワークの重大な欠陥。この欠陥を含むアプリケーションは、特定の状況で、攻撃者が制御するコードを通じたリモート攻撃を受けます。
• インターネットへの内部サービスの漏洩 – 前述の「設定ミス」に分類される一般的なケース。特定の製品というよりは、設定ミスのあるすべてのシステムに害を及ぼします。

脆弱性を取り巻く状況

脆弱性の評価とは、特定の時点でシステム内で見つかった脆弱性を識別して報告するプロセスです。通常、このプロセスは高度に自動化されており、脆弱性スキャナーと呼ばれるサービスやソフトウェアアプリケーションを使用して高い頻度で実行されます。脆弱性の評価は組織の広範な脆弱性管理戦略における中心的な要素ですが、定期的なリスク評価の一環として行われる場合もあります。

多くの場合、政府の規制や業界標準は脆弱性の評価を義務付けています。たとえば、大手の決済カード企業によって採用されているPCI DSS標準の一定のコンプライアンスレベルでは、オンライン決済を行う業者に、ASV（Approved Scanning Vendors）を使用した脆弱性の評価を要求します。

規制コンプライアンスの要件がなくても、脆弱性スキャンを行うに越したことはありません。結局のところ、脆弱性はリスクを増大させるものであり、どんな脆弱性が存在するかを把握することはセキュリティ体制にとって極めて重要だからです。率直に言えば、スキャンが義務ではないからといって、脅威にさらされていることはおすすめしません。

準備

定期的でも単発でも、脆弱性評価の最初の手順は以下のとおりです。

1. スキャンするシステムを特定して分類します。これらのシステムは多くの場合「アセット」と呼ばれ、スキャンのターゲットとなります。結果を解釈し、必要な修復作業の優先度を決めるには、ターゲットの機能と重要度を判断することが重要となります。
2. どのような脆弱性を評価の対象とするかを明確にします。公に知られている脆弱性で、インストールされているソフトウェアに影響を与えるものをすべて対象とするのか、設定ミスや古いソフトウェアなど、攻撃者がインターネット上で特定できる問題に限定するのかなどを決定しましょう。
3. 最初の2つの手順で定義した目的に基づいてスキャナーを選択します。ベンダーのソリューションごとにアプローチが異なります。特定した要件にすべてのソリューションが適しているとは限りません。

スキャンの実行

この手順は最も簡単です。前述のように、多くの場合は自動化されています。スキャナーは主に2つに分類されます。

• ネットワークスキャナーは、インターネットまたはプライベートネットワークを介してターゲットにアクセスし、一連のテストを実行します。以下の2種類のアプローチがあります。
  • 非認証スキャンは、攻撃者と同様に、外部から判断できるもののみに基づいた結果を生成します。スキャナーにはシステムにアクセスするための認証情報がないので、インストールされているすべてのソフトウェアとそのバージョンを正確に特定できないという欠点があります。
  • 一方、認証ネットワークスキャンは、ターゲットへのアクセス権限を利用して正確な情報を得ます。この場合、より包括的な結果が得られますが、攻撃者から見えるものを明らかにすることはできません。

いずれの場合も、ファイアウォールや侵入防止システム（IPS）などのネットワーク構成要素が、それぞれの目的でスキャンを中断したり、アラートを発したりする場合があります。

• ホストスキャナーは、ターゲットシステム上で直接実行され、データ（インストールされているソフトウェアのバージョンなど）を収集する本格的なアプリケーションまたはシンエージェントです。多くのホストスキャナーはオペレーティングシステムへの特権アクセスを持ち、ソフトウェアの既知の脆弱性をすべてリストアップするには、ネットワークスキャナーより有利です。欠点は、前述のIPSなどのセキュリティ制御の緩和が考慮されないことです。稼働中のシステムを利用する代わりに、ターゲットのオフラインディスクやルートファイルシステムに対してホストスキャナーを実行すれば、同様の最終結果を得られます。

脆弱性の評価の対象範囲によって、スキャナーの種類と採用されるアプローチが決まります。どのスキャナーを選択しても誤検出や検出漏れの可能性があることは覚えておいてください。誤検出とは、報告されているが実際には存在しない脆弱性です。検出漏れは、存在しているがスキャナーが見落としている脆弱性です。

スキャンが完了（数秒から数時間かかる場合があります）すると、レポートが生成されます。このレポートには、ターゲットに関するデータに加えて、CVE IDが割り当てられているかどうかや、CVSSスコア、詳細な説明、修復や緩和のために取り得る対策など、特定された脆弱性に関する情報が含まれています。

結果の解釈

スキャンによるテストは完璧ではありません。特に、既知のソフトウェアやハードウェアの欠陥（CVE識別子が割り当てられているものなど）に関しては、スキャナーが脆弱性を直接判定することはほとんどありません。スキャナーはインストールされているアプリケーションのバージョンなどの間接的な手がかりに依存します。

このため、最新のアップストリームソフトウェアバージョンにアップグレードせずに脆弱性が修正された場合、オープンソースで問題が起きます。Ubuntuでは、互換性と安定した動作を維持するため、修正はバックポートされてLTSリリースの安定したセキュリティ更新に反映されます。したがって、パッケージのバージョンはアップストリームのOSSプロジェクトと異なります。修正プログラムは、他の安定版リリースのLinuxディストリビューションと同じように、Ubuntuエコシステムに固有のバージョンを受け取ります。多くのスキャナーはこのことを正しく考慮しますが、認証なしのネットワークスキャンなど、完全な情報を取得できない場合もあります（Linuxディストリビューションの名前さえ非表示の場合もある）。

誤検知の可能性があるとは言っても、すべての脆弱性が同じではありません。悪用が難しい脆弱性もあります。同様に、攻撃が成功した場合の被害も多様であり、システムの機密性、完全性、可用性（CIAトライアド）のどれが損なわれる場合もあります。共通脆弱性評価システム（CVSS）やUbuntu CVE優先度などのスコアリングスキームが、結果の評価を標準化するために役立ちます。

最も重要なのは、より広いターゲットのコンテキストで本当に明らかである脆弱性を把握することです。ここでは、ターゲットアセットを分類することが重要です。既存の補完的なセキュリティ制御によって悪用の可能性が大幅に減少するケースや、脆弱性が特定の構成に適用されないケースもあります。要するに、影響を受けるシステムの特性を考慮し、パーソナライズされた環境内での解決を優先して解釈を行う必要があります。

次の段階

ターゲットと適切なスキャナーの特定、スキャンの完了、結果の解釈、問題の優先度付けを終え、レポートが完成しました。これで脆弱性の評価は正式に終了です。しかし、セキュリティに関する作業はここで終わりではありません。脆弱性の管理プロセスは幅広く、連続的です。リスク管理でよく言われるのは、リスクは削減（軽減）、回避、移転、容認して良いが、決して無視すべきではないということです。脆弱性はリスク増大の原因であり、脆弱性に対処することで、良好なセキュリティ状態を維持できます。

ソフトウェア製品の既知の脆弱性についてはセキュリティ更新が最善の対策です。速やかなパッチ適用を推奨します。ハードウェアの脆弱性は、通常、ベンダーのファームウェアまたはマイクロコードの更新によって軽減できます。設定ミスは、把握して直接修正する必要があります。前の手順で優先度付けは、論理的順序を守るのに役立ちます。

ポイントは、脆弱性を避けることはできず、製品になってから発見されることも想定内であり、備えが重要だということです。備えは、成熟したセキュリティプロセスと、まだ発見されていない脆弱性をアプリケーション隔離などのセキュリティ機能を通じて軽減する多層防御アプローチの両方の形を取ります。

Ubuntuの役割

Canonicalでは、徹底的かつ効果的な脆弱性の評価を行うための適切なツールをUbuntuのユーザーが自由に使えるようにすることに取り組んでいます。Ubuntuには、デプロイメントのセキュリティ体制を改善するために、次の3つのアプローチがあります。

• 透明性と可視性 – オープンソースは、ユーザーが情報に基づいて選択するために必要なすべての情報をパブリックドメインに置くというオープンポリシーを促進しています。Ubuntuセキュリティチームのプロセスは、すべてのユーザーが利用できるドキュメントに記載されています。同様に、Canonicalは、Ubuntuパッケージに影響を及ぼすすべての既知の脆弱性のデータフィードをオープン標準形式（OVAL、OSV、VEX）で公開しています。これは、前述のように、バックポートされたパッチを通じて脆弱性を修正するUbuntu固有のパッケージバージョンを知るために特に役立ちます。実際に、多くの場合、スキャナーは正確な結果を生成するためにこれらのデータフィードを使用します。
• リアクティブ – ソフトウェアパッケージに対してセキュリティ更新が提供されます。Ubuntu Proでは最長12年間の長期サポートが提供されます（5台のデバイスで無料で利用できます）。Ubuntuセキュリティ通知の形の通知によって、利用可能な修正に関する情報が提供されます。標準インストールの場合はデフォルトで全自動アップグレードが有効になっているため、タイムリーにパッチが自動でロールアウトされます。
• プロアクティブ – 数多くのセキュリティ機能によって緩和策が提供されます。デフォルトのインストールで利用できます。改良に応じて、新しい機能が定期的に追加されます。たとえば、AppArmorはLinuxカーネルレベルで強制アクセス制御（MAC）機能を実行するアプリケーション隔離テクノロジーであり、SELinuxと同様に、攻撃の影響を受ける範囲を大幅に減少できます。

Ubuntuセキュリティリサーチアライアンスプログラム

2024年末に向けて、CanonicalはUbuntuセキュリティリサーチアライアンスプログラムの導入を発表しました。このイニシアチブの目的は、この記事で紹介している脆弱性スキャナーが可能な限り少ない誤検知や検出漏れで、正確な修復のアドバイスを提供できるようにすることです。このスキャンベンダーとの無償のパートナーシップによって、Ubuntuユーザーが攻撃者の一歩先を行けるように支援します。Ubuntuセキュリティリサーチアライアンスプログラムの詳細は、発表をご覧ください。当社は、業界のパートナーと協力してオープンソース環境をすべてのユーザーにとってより安全な場所にできることを嬉しく思います。

参考資料

• Canonicalからオープンソースセキュリティを入手
• 脆弱性管理とは
• jp.ubuntu.com/pro