OVALとは？脆弱性検査言語の仕組みとoscapでの評価手順・最新5.12.3【2026年】

OVAL（Open Vulnerability and Assessment Language、読み方は「オーバル」）は、脆弱性・パッチ適用・設定の状態を「どのパッケージが、どの版より古ければ該当か」といった判定条件として、製品に依存しないXMLで書くための言語です。英単語のoval（楕円）とは関係なく、IT・セキュリティの文脈ではこの検査言語を指します。OVAL自体はスキャンを実行しません。Ubuntu や Red Hat が配布するOVAL定義を、OpenSCAP（oscap）などの評価エンジンに読ませて初めて「このサーバーに未適用の修正があるか」が分かります。この記事では、定義ファイルの実物、Ubuntu 24.04 で oscap を動かした結果、コンテナで評価するときの誤判定、仕様と実装の版のズレまでを順に扱います。

まとめ：OVALの要点

• OVALは判定条件を書く言語で、検査はOpenSCAPなどの評価エンジンが行う。定義のXMLを持っているだけでは何も起きない。
• 定義はdefinition（何を判定するか）→test（どう比べるか）→object（何を集めるか）→state（どの値なら該当か）の4層。
• Ubuntuは security-metadata.canonical.com/oval/ でリリースごとの定義を随時更新して配布しており、oscap oval eval 1行で評価できる。
• Ubuntuのカーネル定義は実行中のカーネルを uname で調べるため、コンテナで評価するとホストのカーネルが判定され、ホストが修正版より古ければ「該当」と出る。コンテナの結果ではカーネル項目を分けて読む。
• 仕様は5.12.3（2026年6月）が最新で、SCAP 1.4に対応する。一方、oscapは1.3.9がOVAL 5.11.1、1.4.5が5.11.3までの対応で、配布データも5.11.1（Ubuntu）や5.10（Red Hat）で書かれている。
• Red HatはOVAL v2を保守モードにし、RHEL 10以降には配布しない。RHEL 10の脆弱性判定はCSAF／VEXを使う。

OVALの役割：判定条件の共通化とツールからの分離

脆弱性スキャナは、どれも内部に「このCVEはどのパッケージのどの版で直ったか」という判定条件を持っています。条件がツールごとの独自形式だと、同じ判定を製品の数だけ書き直すことになり、ツールを替えると結果も変わります。OVALはこの判定条件を共通のXMLスキーマで表し、配布元（OSベンダーなど）が一度書けば、どの対応ツールでも同じ結果になるようにします。

OVALはIPAの概説によると、MITREが仕様策定を主導し、2002年10月のSANS Network Security 2002で発表されました。定義には用途を示すclassがあり、共通スキーマでは vulnerability（脆弱性がある）、patch（修正を入れるべき）、compliance（方針に適合している）、inventory（ソフトウェアが入っている）、miscellaneous の5種類で、それぞれ括弧内の状態のときにtrueになると定義されています。実際の配布データはclassを絞っていて、2026年10月28日版のUbuntu 24.04向けUSN OVALは1,568定義のうち1,567件がpatch、1件がinventory（「Ubuntu 24.04がインストールされているか」）でした。

OVAL定義ファイルの構造：definition・test・object・stateの関係

OVALでやり取りするXMLは3種類あります。配布元が用意するのはDefinitionsだけで、残り2つは評価エンジンが作ります。

Definitionsの中身を、Ubuntu 24.04向けUSN OVALの「USN-8954-1 — zlib vulnerability」で見ます（2026年10月28日版から抜粋した説明用の断片です。CVE参照・説明文・一部の属性（「…」の箇所）とobject本体は省略しており、このままでは評価できません）。

<definition id="oval:com.ubuntu.noble:def:895410000000" class="patch" version="1">
  <metadata>
    <title>USN-8954-1 -- zlib vulnerability</title>
    <reference source="USN" ref_id="USN-8954-1" ... />
  </metadata>
  <criteria>
    <extend_definition definition_ref="oval:com.ubuntu.noble:def:100"
      comment="Ubuntu 24.04 LTS (noble) is installed" />
    <criterion test_ref="oval:com.ubuntu.noble:tst:895410000000"
      comment="zlib source package in noble, is affected and has been fixed ..." />
  </criteria>
</definition>

<linux-def:dpkginfo_test id="oval:com.ubuntu.noble:tst:895410000000" check="at least one" ...>
  <linux-def:object object_ref="oval:com.ubuntu.noble:obj:870610000000" />
  <linux-def:state state_ref="oval:com.ubuntu.noble:ste:895410000000" />
</linux-def:dpkginfo_test>

<linux-def:dpkginfo_state id="oval:com.ubuntu.noble:ste:895410000000" ...>
  <linux-def:evr datatype="debian_evr_string" operation="less than">1:1.3.dfsg-3.1ubuntu2.3</linux-def:evr>
</linux-def:dpkginfo_state>

読み方は下から上です。stateは「版が 1:1.3.dfsg-3.1ubuntu2.3 より小さい」という値の条件、objectは「zlib由来のバイナリパッケージ（zlib1g など）」という集める対象、testは「objectで集めた版のうち少なくとも1つがstateを満たすか」という比較の仕方です。definitionはそれを criteria でまとめ、「Ubuntu 24.04であり、かつ zlib が修正版より古い」ならtrue（未修正）を返します。

この分け方の利点は部品の使い回しです。zlibのobjectは別のUSNの定義からも参照でき、Ubuntu 24.04かどうかの判定（def:100）は、1,567件のpatch定義のうちLivepatch向けの通知（LSN）19件を除く1,548件が extend_definition で共有しています。dpkginfo_test の比較は debian_evr_string（エポック・版・リビジョンを分けて比べる型）で行われるので、文字列としての大小比較とは結果が違う点も押さえておくと、結果の検算で迷いません。

oscapによるOVALの評価：UbuntuとRHELの配布データ

手元で動かす場合、評価エンジンは OpenSCAP のコマンド oscap が標準です。Ubuntu 24.04 と Fedora 44 では、どちらも openscap-scanner パッケージで入ります。

UbuntuのUSN OVAL取得とoscap oval evalによる評価手順

Canonical はUbuntu OVAL dataとして、サポート中の全リリース向けに2系統の定義を配っています。USN OVAL は公開済みのセキュリティ通知（USN）から作られ、未適用の修正を調べる用途です。CVE OVAL はCVEごとのトリアージ結果から作られ、修正がまだ出ていないものも含めて脆弱性の有無を調べる用途です。公式手順は次の3行で、事前に wget・bzip2・lsb-release・openscap-scanner の各パッケージが要ります（最小構成のコンテナでは未導入です）。

wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml

CVE OVALは同じ場所の com.ubuntu.<コードネーム>.cve.oval.xml.bz2、公式クラウドイメージのマニフェストを評価するときは oci.com.ubuntu.<コードネーム>.usn.oval.xml.bz2 を使います。2026年10月29日時点で noble（24.04）のUSN版は圧縮1.25MB・展開後36.4MB、CVE版は圧縮11.0MBで、どちらも2026年10月28〜29日（UTC）に更新されたものでした。lsb_release が無い最小構成のコンテナでは、/etc/os-release の VERSION_CODENAME からコードネームを取ります。

RHELのOVAL v2提供範囲とRHEL 10でのCSAF／VEX移行

Red Hat は https://security.access.redhat.com/data/oval/v2/ でRHEL 5〜9向けのOVAL v2を配っており、RHEL 9用は RHEL9/rhel-9.oval.xml.bz2 です（2026年10月29日版で2,222定義、すべてpatch、schema_versionは5.10）。ただしRed HatのOVAL v2告知は、2024年7月にVEXファイルを一般提供したことを受けてOVAL v2を保守モードに移し、「新機能は追加せず重大な不具合修正のみ」「RHEL 10以降には公開しない」「RHEL 8・9の保守終了とともにアーカイブする」と明記しています。RHEL 10.0のリリースノートも、CVE OVALv2フィードを提供せずCSAF・VEXで代替すると記載しており、配布ディレクトリにもRHEL10はありません。RHEL 10を含む環境の脆弱性判定をOVALで組むのは避け、Red HatのCSAF／VEXデータに対応したスキャナを選ぶのが正解です。VEXの位置づけはSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説で扱っています。

評価結果の読み方：6種類の結果とclassごとのtrueの意味

oscap oval eval は定義ごとに Definition <id>: true のような行を標準出力に出し、--results を付けるとOVAL Results のXML、--report を付けるとHTMLレポートを書き出します。OVAL Resultsのスキーマが定める結果は true・false・unknown・error・not evaluated・not applicable の6種類です。unknown と error は情報を集められなかった・評価に失敗したという意味なので、false と同じ「問題なし」に数えてはいけません。patch・vulnerabilityの定義では true が「未修正・該当あり」で、良い結果ではありません。反対に compliance の定義は true が「基準に適合」、inventory の定義（Ubuntuの def:100 など）は true が「インストールされている」で、どちらも問題を意味しません。結果を集計するときは true の件数ではなく、classごとに分けて数えてください。

2026年10月29日に ubuntu:24.04 イメージ（24.04.5）へ openscap-scanner 1.3.9 だけを入れて評価した結果は次のとおりです。検証環境はmacOS上のColima（x86_64のVM、ホストカーネル 6.8.0-117-generic）で、定義は同日取得の2026年10月28日版、コマンドは oscap oval eval --results results.xml --report report.html com.ubuntu.noble.usn.oval.xml です。評価に約40秒かかり、results.xml は39MB、report.html は7.5MBになりました（時間とサイズはこの環境での参考値です）。

どちらの回も unknown・error は0件で、結果はすべて true か false でした。zlib（USN-8954-1）とXZ Utils（USN-8945-1）は、upgrade でパッケージが修正版になり false に変わりました。残ったカーネル9件がなぜ消えないのかは、次の章の落とし穴です。

コンテナ評価でのホストカーネルの検出と結果の切り分け

Ubuntu のカーネル向けUSN定義（例：USN-8917-1 — Linux kernel vulnerabilities）は、パッケージの版ではなく unix-def:uname_test で「いま動いているカーネル」を調べ、その版を修正版（linux なら 6.8.0-147.147）と比べます。コンテナはホストのカーネルを共有するので、uname が返すのはホスト側の値です。ホストのカーネルが定義の対象（linux・linux-aws などの種類）に当たり、かつ修正版より古いときに true になります。上の実測ではホストが 6.8.0-117-generic（linux系統）で修正版より古かったため、コンテナ内の apt-get upgrade では直しようがない9件が true のまま残りました。

判断は単純です。コンテナイメージを評価した結果のうち、カーネル定義の true はイメージの問題として扱わず除外します。カーネルの状態はホスト（またはVM）側で別に評価します。逆にホストで評価するときは、新しいカーネルを入れても再起動するまで true が消えないのが正しい挙動で、「アップデートしたのに残る」と問い合わせる前に uname -r を確かめてください。

OVALとSCAP・CVE・XCCDFの役割分担

OVALはNISTのSCAP（Security Content Automation Protocol）を構成する言語の一つで、SCAPの中では「マシンの状態を自動で判定する」部分を受け持ちます。CVEやCVSSは識別子と深刻度で、判定ロジックを持ちません。OVAL定義の metadata にCVE番号やCVSSベクタが入っているのは、判定結果を識別子に結び付けるためです。

設定監査（CIS Benchmark や DISA STIG への準拠確認）では、XCCDFのプロファイルが各ルールの判定をOVAL定義に委ね、oscap xccdf eval がまとめて実行します。脆弱性・パッチの確認だけならXCCDFは不要で、この記事のように oscap oval eval で足ります。SCAP全体の構成と1.4の変更点はSCAPとは？セキュリティ設定共通化手順とSCAP 1.4の変更点【2026年版】、XCCDFとOVALの連携はXCCDFとは？SCAP・OVALとの違いとファイル構造・使い方を解説、設定項目のIDはCCEとは？セキュリティ設定の共通ID｜形式・最新リスト5.20251209とSCAPでの調べ方、識別体系はCVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説とCVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説で整理しています。

OVALの最新バージョンと運営体制：仕様5.12.3と実装5.11系のズレ

MITREの oval.mitre.org には「Archive」状態であることと、OVALがNIWC Atlantic（米海軍情報戦センター大西洋）へ移ったことが掲示されており、言語仕様はGitHubのOVAL-Community/OVALでOVAL Boardが管理しています。MITREは定義集を2015年7月31日まで運営し、同年9月からはCISが言語と定義集の管理主体を引き継ぎました。5.11.2（2016年）はCISがOVAL Communityと協力して公開した版です。定義集はCISのOVAL Repositoryに移りました。ただしそのWebサイトは廃止扱いで、GitHubのリポジトリも2026年10月時点でアーカイブ（読み取り専用・最終更新2023年6月）になっています。新しい定義を探すなら、OSベンダーの配布データが本命になります。

仕様の版は次の順で出ています。日付はGitHubのリリース日です。

SCAP 1.4の仕様書NIST SP 800-126 Rev.4は2026年6月8日にFinalとして公開され、附属文書SP 800-126Ar4がOVAL 5.12.xを承認し、スキーマの参照先を5.12.3としています。SCAP 1.3（SP 800-126 Rev.3）の対応版は5.11系で、附属文書が5.11.2を承認済みの更新として載せています。

6.0は非推奨のテスト140種を削って5.x向けのコンテンツと互換性がなくなった版で、公式READMEは「6.0系の開発はSCAP 3.0についてのNISTとの協議待ちで保留、安定したSCAP開発には5.12.xを使う」と案内しています。仕様として準拠先を選ぶなら5.12系ですが、実際に評価できるかは次に述べる評価エンジンの対応版で決まります。

注意したいのは、仕様の最新と実際に動く版が一致しない点です。手元で確かめると、Ubuntu 24.04 の oscap 1.3.9 は oscap --version の対応版が「OVAL Version: 5.11.1」、Fedora 44 の oscap 1.4.5 は「5.11.3」でした。OpenSCAPのソースでは1.4.3（2025年11月）で対応版を5.11.3へ上げたのが最後で、2026年10月22日公開の最新1.4.6までリリースノートに5.12対応の記載はなく、main ブランチの OVAL_SUPPORTED も “5.11.3” のままです。配布データも、Ubuntu は schema_version 5.11.1、Red Hat は 5.10 で書かれています。SCAP 1.4が5.12系を求めていても、OpenSCAPの対応はまだ5.11系にとどまっています。5.12で追加・変更された要素を使って定義を自作すると、現行のoscapでは評価できないおそれがあります。自作する定義は、使う評価エンジンの oscap --version が示す版に合わせて書いてください。

OVALを自分で扱うべき場面・扱わなくてよい場面

サーバーの未適用パッチを洗い出したいだけなら、OVALを直接触る必要はありません。OSSスキャナのVulsも、かつてはgoval-dictionaryでOSベンダーのOVALを取り込んで判定していましたが、2026年5月の告知では最新版v0.39.1がgoval-dictionaryに依存しなくなったと説明されています。スキャナを使うなら、判定データの形式は製品側に任せれば足ります。運用の比較はFutureVulsとは？SSVCの優先度判定と料金・スキャナ導入とAPI連携の手順が参考になります。

直接扱う価値があるのは次の場面です。

• エージェントを入れられない閉域のUbuntu・RHEL 8／9を、配布データとoscapだけで点検したい。
• スキャナが「該当」と出した根拠を、定義のstate（どの版未満か）までさかのぼって確かめたい。
• 社内独自の設定基準を、XCCDFとOVALで機械判定できる形にしたい。

逆に、RHEL 10 を含む環境や、コンテナイメージの継続的な検査を新しく組むなら、OVALを土台に選ぶのは避けた方が安全です。前者は配布データが無く、後者はカーネル判定の扱いを自前で補う必要があります。どこまで自動化し、どこを人の診断で補うかの線引きに迷う場合は、脆弱性診断・セキュリティ診断のような外部診断と組み合わせる選択肢もあります。

よくある質問

OVALの読み方と意味は？

「オーバル」と読みます。Open Vulnerability and Assessment Language の頭字語で、脆弱性やパッチ・設定の状態を判定する条件を書くためのXMLベースの言語です。英単語のoval（楕円）とは無関係です。

OVALとSCAPの違いは何ですか？

SCAPは脆弱性・設定管理の標準を束ねた枠組みで、OVALはその中で状態判定を担う言語です。SCAP 1.3はOVAL 5.11系（5.11.2まで承認）を、2026年6月に確定したSCAP 1.4は5.12.x（参照先は5.12.3）を構成言語としています。

OVALで脆弱性スキャンはできますか？

OVAL定義だけではできません。OpenSCAPの oscap oval eval などの評価エンジンに定義を読ませると、定義ごとに true・false・unknown・error などの結果が返ります。patch・vulnerabilityの定義では true が「該当あり」ですが、compliance の定義では true が「基準に適合」で、意味がclassで変わります。

OVALの最新バージョンはどれですか？

2026年10月時点の最新は5.12.3（2026年6月6日公開）です。6.0も公開されていますが開発が保留されており、公式は5.12系の利用を案内しています。ただし評価エンジンのoscapは5.11系までの対応です。

OVAL定義ファイルはどこで入手できますか？

UbuntuはCanonicalの security-metadata.canonical.com/oval/、RHEL 5〜9はRed Hatの security.access.redhat.com/data/oval/v2/、Debianは www.debian.org/security/oval/、SUSEは security-data.suse.com/oval/ で配布されています。CISのOVALRepoはアーカイブ済みで更新されていません。

関連記事

• SCAPとは？セキュリティ設定共通化手順とSCAP 1.4の変更点【2026年版】
• XCCDFとは？SCAP・OVALとの違いとファイル構造・使い方を解説
• CVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説
• CVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説