OVALとは?脆弱性を標準化して評価するセキュリティ言語の仕組みと現状
OVAL(Open Vulnerability and Assessment Language、読み方は「オーバル」)は、システムの脆弱性やセキュリティ設定の状態を、特定の製品に依存しない共通のXML形式で記述するための言語標準です。脆弱性スキャナそのものではなく、「何を・どんな状態だったら問題か」を機械可読で表現するフォーマットにあたります。2000年代前半にMITREが立ち上げた古参の標準で、いまもSCAP対応ツールやLinuxディストリビューションのセキュリティ情報の内部で使われる一方、運用主体はMITREから移り、公式サイトはアーカイブ化されています。この記事では、OVALの仕組みとSCAPとの関係、脆弱性評価での使い方、そして見落とされがちな運用主体の移管と最新バージョンまでを整理します。
まとめ:OVALの要点
- OVALは脆弱性・設定・パッチ状態を製品非依存のXMLで記述する言語標準。単体では検査せず、記述された定義を解釈するツールが必要。
- 中核は「Definitions(検査すべき状態)」「System Characteristics(収集した実状態)」「Results(突合した結果)」の3スキーマ。
- OVALはNISTのSCAPを構成する言語の一つで、XCCDFがOVAL定義を呼び出して自動判定する。CVE・CVSS・CPEと役割分担する。
- 実務ではOpenSCAPなどの解釈エンジンと、Red HatやUbuntuが配布するベンダOVAL定義を組み合わせて使うのが一般的。
- 運用主体はMITRE→NIWC Atlanticへ移管され、旧CIS OVAL Repositoryサイトは2023年2月に閉鎖。安定版は5.12系(最新5.12.3)で、メジャー刷新の6.0は開発が一時停止中。
OVALとは何か:脆弱性を記述する共通言語
OVALが解決するのは、脆弱性や設定の「チェック内容」がツールごとにバラバラで再利用できない、という問題です。あるスキャナ用に書いたチェックが別のツールでは使えなければ、同じ判定ロジックを製品の数だけ書き直すことになります。OVALはこの判定ロジックを共通のXMLスキーマで表現し、対応ツール間で同じセキュリティコンテンツを流通させられるようにします。
対象になるのは、既知の脆弱性(該当パッチが未適用か)、セキュリティ設定(パスワードポリシーやサービス稼働状態が基準を満たすか)、パッチ適用状況、そしてインストール済みソフトウェアなどの構成情報です。いずれも「システムが特定の状態にあるかどうか」を判定する点が共通しており、OVALはこの状態判定を宣言的に記述します。注意したいのは、OVAL自体はスキャンを実行しないことです。OVALは判定の設計図であり、実際に対象を調べて答えを出すのは、次に述べる評価エンジン側の役割になります。
OVALの仕組み:3つのスキーマと評価の流れ
OVALの評価は、3種類のXMLドキュメント(スキーマ)を順に受け渡すことで進みます。役割を分けているため、定義の作成者と評価の実行者、結果の受け手が別々でも同じ形式でやり取りできます。
| スキーマ | 役割 | いつ生成されるか |
|---|---|---|
| OVAL Definitions | 検査すべきマシン状態(脆弱性・設定・パッチ)を宣言的に記述 | 事前に用意する設計図 |
| OVAL System Characteristics | 対象システムから実際に収集した構成・状態の値 | 評価エンジンが対象から収集 |
| OVAL Results | 定義と実状態を突合した合否(true/false) | 評価の出力 |
定義ファイルの内部構造
OVAL Definitionsの中身は、さらに「definition」「test」「object」「state」という要素に分かれます。objectは「調べる対象」(例:あるパッケージ)、stateは「期待する値」(例:バージョンがX以上)、testはその両者を結び付けて判定条件を作り、definitionが複数のtestを論理演算(ANDやOR)で束ねて一つの脆弱性・設定チェックにまとめます。この分解のおかげで、objectやstateを部品として使い回せるのがOVALの設計上の狙いです。評価エンジンは、この定義で指定されたobjectの実際の値をSystem Characteristicsとして集め、stateと突合してResultsを返します。
OVALとSCAPの関係:標準化フレームワークの一部
OVALは単独で使うより、NIST(米国国立標準技術研究所)が策定するSCAP(Security Content Automation Protocol)の構成要素として使われる場面が多い言語です。SCAPは脆弱性・設定管理に関わる複数の標準を束ねた枠組みで、OVALはその中で「状態判定の低レベルな記述」を担当します。SCAP 1.3(NIST SP 800-126 Rev.3)ではOVAL 5.11系が採用されており、各標準は次のように役割分担します。なお次期のSCAP 1.4は、後述するOVAL 5.12.3が整合を狙う対象になっています。
| 標準 | 役割 |
|---|---|
| XCCDF | チェックリスト・ポリシーを定義し、判定をOVALに委譲 |
| OVAL | 個々のマシン状態を自動判定する記述 |
| OCIL | 自動化できない項目の手動確認手順 |
| CPE | 製品・プラットフォームの識別名 |
| CVE / CVSS | 脆弱性の識別番号と深刻度スコア |
実際のコンプライアンス評価では、XCCDFのチェックリストが各項目の判定をOVAL定義に投げ、OVALが対象システムを調べて合否を返す、という連携になります。SCAP全体の位置づけはSCAPとは?セキュリティ設定共通化手順とSCAP 1.4の変更点【2026年版】で、脆弱性の識別体系はCVEとCWEの違いとCVSSv3のスコア計算方法で整理しています。
OVALでできること:脆弱性評価とコンプライアンス
OVALの実務での使いどころは大きく3つです。第一に脆弱性評価で、ベンダが公開するOVAL定義を使い「このCVEに該当するパッチが未適用か」を判定します。第二にセキュリティ設定のコンプライアンスチェックで、CIS BenchmarkやDISA STIGといった基準を満たしているかを定義化して確認します。第三にパッチ適用状況やソフトウェア構成の棚卸しです。
見落とされがちなのは、OVAL定義を自分で書かなくても使える点です。Red Hat(RHSAに対応するOVALデータ)、SUSE、Debian、Ubuntu(USN)、Ciscoなどが自社製品向けのOVAL定義を公開しており、利用者はそれを取り込んで評価するだけで済みます。定義を解釈して実行する側は、代表的にはOpenSCAP(oscapコマンド)などの評価エンジンが担います。逆に言えば、OVAL定義のXMLをテキストで持っているだけでは何も起きません。「oval scan」と呼ばれる自動判定を成立させるには、必ず定義を読み込んで対象を調べる解釈エンジンとセットで運用する必要があります。
OVALの現状と最新バージョン:MITREからの移管と実務判断
OVALを調べると、多くの日本語記事が「MITREが維持する標準」と説明していますが、この点は現状とずれています。OVALはMITREが米国土安全保障省(DHS)の資金で立ち上げましたが、その後の運用は段階的に移りました。コミュニティが管理する脆弱性定義集であるOVAL Repositoryは一度CIS(Center for Internet Security)へ移管され、そのCISのOVAL Repositoryサイトも2023年2月1日に閉鎖されて、以降はGitHub(CISecurity/OVALRepo)での配布に切り替わっています。言語仕様そのものの管理はNIWC(Naval Information Warfare Center)Atlanticへ移り、MITREのoval.mitre.orgは現在「Archive」状態と明記されています。
バージョンも動いています。MITRE期の最後の安定版は5.11.2でしたが、コミュニティ管理(GitHubのOVAL-Community/OVAL)に移った後は2つの系統に分かれました。互換性を保つ5.12系は2026年6月公開の5.12.3が最新で、これはNISTの次期SCAP 1.4との整合を狙った更新です。一方、名前空間をURLベースからURNベースへ変更し非推奨要素を削除したメジャー刷新の6.0(2025年1月公開)は、SCAP 3.0を巡るNISTとの協議待ちで開発が一時停止しており、公式は安定運用にはOVAL 5.12系を使うよう案内しています。したがって現時点で実務の基準にすべきは5.12系で、最新の対応版は公式リポジトリで確認するのが確実です。
実務判断としては、独自の設定監査要件がない限りOVAL定義を自作する必要はありません。多くの現場が求めるのは「自社のサーバーに既知の脆弱性が残っていないか」の確認であり、それはベンダ配布のOVAL定義とOpenSCAPの組み合わせで足ります。自前で定義を書くのは、社内独自のセキュリティ基準を機械判定したい、あるいは既存ツールが対応しない項目を検査したい、といった限られたケースに絞るのが現実的です。OVALは新しく採用が広がる技術というより、SCAP対応ツールの内側に組み込まれて動く成熟した基盤と捉えるのが、いまの立ち位置に合っています。
よくある質問
OVALの読み方は?
「オーバル」と読みます。Open Vulnerability and Assessment Language(オープン脆弱性評価言語)の頭字語です。
OVALとSCAPの違いは何ですか?
SCAPは脆弱性・設定管理の標準を束ねた枠組み全体で、OVALはその中で個々のマシン状態を自動判定する言語です。並立する別物ではなく、OVALはSCAPを構成する言語の一つという包含関係にあります。
OVALで脆弱性スキャンはできますか?
OVAL定義だけではスキャンは実行できません。OVALは判定内容の記述であり、実際に対象を調べるにはOpenSCAPなどの評価エンジンに定義を読み込ませる必要があります。
OVALの最新バージョンはどれですか?
安定運用の基準は5.12系で、最新は5.12.3(2026年6月)です。名前空間を刷新したメジャーバージョン6.0(2025年1月)もありますが、SCAP 3.0を巡る協議待ちで開発は一時停止中のため、公式は安定運用に5.12系を推奨しています。最新状況は公式リポジトリで確認してください。
OVAL定義ファイルはどこで入手できますか?
Red HatやUbuntu(USN)などのベンダが自社製品向けに公開しているほか、コミュニティの定義はGitHub(CISecurity/OVALRepo)で配布されています。多くの場合、これらを取り込めば自作は不要です。