---
title: "XCCDFとは？OVALとの違い・ファイル構造とoscapで評価する手順【XCCDF 1.2】"
url: "https://www.issoh.co.jp/tech/details/5141/"
published: 2025-02-03
updated: 2026-10-29
categories: ["セキュリティ"]
publisher: "株式会社一創"
---
# XCCDFとは？OVALとの違い・ファイル構造とoscapで評価する手順【XCCDF 1.2】
XCCDF（Extensible Configuration Checklist Description Format）は、OSやミドルウェアに求めるセキュリティ設定を、ツールで読めるチェックリストとしてXMLで書くための仕様です。CIS BenchmarkやDISA STIGをOpenSCAPで自動点検できるのは、SCAP Security GuideがこれらをXCCDFのProfileとして収録しているからです。この記事では、XCCDFの定義と現行版、OVALとの役割分担、ファイルの構造を押さえたうえで、自作の最小XCCDFとSCAP Security Guideのプロファイルを実際に`oscap`で評価した結果を載せます。
## まとめ：XCCDFの要点
- **正体**：セキュリティ設定のチェックリスト（ベンチマーク）を書くXML形式。現行版は**XCCDF 1.2**（NISTIR 7275 Rev.4・2011年9月）で、ISO/IEC 18180:2013として国際規格にもなっています。
- **OVALとの違い**：XCCDFは「どのルールを選び、どう採点・報告するか」を書き、ルールの合否を実際に調べる検査はOVALなどの検査システムに任せます（SSGは人が答える質問票のOCILも参照します）。XCCDF単体では合否を出せません。
- **構造**：`Benchmark`の下に`Profile`（ルールの選択と値の上書き）、`Group`、`Rule`（点検項目）、`Value`（閾値などの変数）が並びます。
- **実行**：`oscap xccdf eval --profile …`で評価します。失敗が1件でもあると終了コードは2なので、CIで合否を拾えます。
- **実務の基本**：自作より、SCAP Security Guide（SSG）のプロファイルを使い、組織ごとの差分はテーラリングファイルで上書きします。この記事のAlmaLinux 9コンテナでCISのLevel 1（Server）を評価すると、295件中220件が対象外（notapplicable）になりました。
## XCCDFの定義と現行版：1.2がNISTIR 7275 Rev.4とISO/IEC 18180
XCCDFは、対象システムに適用するセキュリティ設定ルールの集まりを構造化して書く仕様です。仕様書の要旨には、情報交換・文書生成・組織や状況に合わせたテーラリング・自動の準拠テスト・採点を支えることが目的として挙がっており、点検結果を記録するデータモデルも同じ仕様に含まれます（[NIST CSRC：NISTIR 7275 Rev.4 Update 1](https://csrc.nist.gov/pubs/ir/7275/r4/upd1/final)）。「パスワードの有効期限は60日以下」のような要件を、表計算のメモではなく同じ書式のXMLで持つので、同じチェックリストを別の組織・別のツールでそのまま使えます。
版の流れは、NISTの[XCCDF仕様ページ](https://csrc.nist.gov/projects/security-content-automation-protocol/scap-specifications/xccdf)に1.0から1.2までの仕様書とスキーマが並んでいます。
| 版 | 仕様書 | 公開 |
| ----- | --------------------- | ------------------------ |
| 1.0 | NISTIR 7188（NSA・NIST） | 2005年1月 |
| 1.1.4 | NISTIR 7275 Rev.3 | 2008年1月 |
| 1.2 | NISTIR 7275 Rev.4 | 2011年9月30日（更新版2012年3月1日） |
| 1.2 | ISO/IEC 18180:2013 | 2013年6月10日 |
1.2のあとに新しい版は出ていません。2026年6月8日に正式版となったSCAP 1.4（[NIST SP 800-126 Rev.4](https://csrc.nist.gov/pubs/sp/800/126/r4/final)）も、構成仕様としてXCCDF 1.2を指定しています。日本語の解説記事には1.1の名前空間（`http://checklists.nist.gov/xccdf/1.1`）のサンプルが残っていますが、いまのSSGが配布するコンテンツは1.2の名前空間（末尾が`/1.2`）です。OpenSCAPは旧版のコンテンツも読めるので、1.1のサンプルを1.1のまま評価することはできます。仕様書の付録Aは、1.1.4から1.2へ移すときに名前空間とIDの両方を書き換えるよう求めています。名前空間だけを1.2に変えて旧版のIDを残すと、次の章で説明するIDの書式で弾かれます。
## XCCDFとSCAP・OVALの役割分担
### SCAPの中でのXCCDFの位置づけ：チェックリスト層
SCAP（Security Content Automation Protocol）は、脆弱性管理と設定管理を自動化するためにNISTがまとめた規格群です。XCCDFはその中で「チェックリストの記述と採点・報告」を受け持ちます。ルールの合否判定はOVAL、対象製品の識別はCPE、設定項目の共通IDはCCEが担い、XCCDFのRuleはこれらを参照して束ねます。SCAP全体の構成と1.4での変更点は[SCAPとセキュリティ設定共通化手順の解説](/tech/details/5125/)に、識別子は[CCEの形式とSCAPでの調べ方](/tech/details/5090/)と[CPEの解説](/tech/details/5088/)にまとめています。
### XCCDFとOVALの違い：チェックリストの定義と状態の検査
XCCDFのRuleは「空のパスワードを禁止する」「有効期限を60日以下にする」と宣言し、`check`要素で検査の中身を外部のOVAL定義に任せます。OVALは「`/etc/login.defs`の`PASS_MAX_DAYS`行を正規表現で取り出し、数値を比べる」といった、システムの状態の読み方そのものを書きます。
| 観点 | XCCDF | OVAL |
| ----- | ---------------------------- | -------------------------------- |
| 書くこと | ルールの選択・閾値・採点・報告 | 状態の取得方法と比較条件 |
| 主な要素 | Benchmark・Profile・Rule・Value | definition・test・object・state |
| 単体で合否 | 出せない | 出せる |
| 結果の形 | TestResult・ARF・スコア | definitionごとのtrue・false・unknown等 |
両者は値の受け渡しでもつながります。XCCDFの`Value`に置いた閾値を`check-export`でOVALの`external_variable`へ渡すので、OVAL定義を書き換えずにProfileごとに閾値を変えられます。OVALの書き方と`oscap oval eval`での単体評価は[OVALの仕組みとoscapでの評価手順](/tech/details/5123/)で扱っています。
## XCCDFファイルの構造：Benchmark・Profile・Rule・Value
主な要素は次のとおりです。Profile・Rule・Value・Group・TestResultは`Benchmark`の中で使い、Tailoringは別文書のルート要素です。TestResultは評価ツールが書き込み、Tailoringは手書きでもツールでも作れます。
- **Profile**：どのRuleを有効にするか（`select`）と、Valueをどの値にするか（`refine-value`）の組。「CIS Level 1（Server）」「DISA STIG」などが1つずつProfileになります。
- **Rule**：個々の点検項目。重み（`weight`）と深刻度（`severity`）、検査の参照先（`check`）、修復手順（`fix`）を持ちます。
- **Value**：Ruleが参照する変数。`selector`付きで複数の候補値を持たせ、Profileから選びます。
- **Group**：RuleとValueの入れ物。Groupに付けた`platform`の条件は、配下のRuleにも効きます（後述のコンテナの落とし穴の原因）。
- **TestResult**：評価結果。Ruleごとの`rule-result`とスコアが入ります。
- **Tailoring**：Benchmark本体とは別のファイルで、既存のProfileを継承した派生Profileを定義します。
### XCCDF 1.2のIDは「xccdf\_名前空間\_種別\_名前」
1.2の仕様書（6.2.3節）は、Benchmark・Profile・Group・Rule・Value・TestResult・Tailoringの7要素のIDに`xccdf_<逆ドメイン名>_<種別>_<名前>`の書式を求めています。SSGのRuleが`xccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs`という長いIDなのはこのためです。
これは努力目標ではなく、スキーマで強制されます。後述の最小例でProfileのIDだけを1.1風の`test_profile`に変えて`oscap xccdf validate`にかけると、`The value 'test_profile' is not accepted by the pattern 'xccdf_[^_]+_profile_.+'`というエラーで終了コード2になりました。自作するときは、自社ドメインを逆順にした名前空間（下の例では`jp.co.issoh`）を先に決めます。
## 最小XCCDF 1.2の作成とoscapによる評価・修復
ここからは、AlmaLinux 9のコンテナにディストリビューション標準のopenscap-scanner 1.3.14を入れて実行した結果です（2026年10月29日）。`oscap --version`は対応仕様を「XCCDF Version: 1.2」「OVAL Version: 5.11.1」「SCAP Version: 1.3」と表示しました。上流の最新は[OpenSCAP 1.4.6（2026年10月22日）](https://github.com/OpenSCAP/openscap/releases/tag/1.4.6)ですが、RHEL 9系のパッケージは1.3系です。この記事で使うオプションは1.4.6のmanページにも同じ名前で載っています。
### XCCDF 1.2とOVALの2ファイル
次の2つのXMLを`demo-xccdf.xml`と`demo-oval.xml`として同じディレクトリに保存し、そのディレクトリでコマンドを実行します。修復はroot権限で行います。掲載した結果は、修復前の`PASS_MAX_DAYS`が`99999`（AlmaLinux 9の初期値）だった環境のものです。
Ruleは2本だけです。1本目は`/etc/login.defs`の`PASS_MAX_DAYS`が上限以下かをOVALで調べ、上限はValueから渡します。既定は365日で、厳格プロファイルでは`refine-value`で60日に切り替えます。2本目は人が確かめる運用ルールで、`check`を持たせていません。
```
draft
XCCDF 1.2 最小デモ
1.0
厳格プロファイル
PASS_MAX_DAYSの上限
365
60
パスワードの有効期限を上限日数以下にする
sed -i -E 's/^[[:space:]]*PASS_MAX_DAYS.*/PASS_MAX_DAYS /' /etc/login.defs
管理者アカウントの棚卸しを年1回行う
```
OVAL側は、正規表現で数値を取り出し、XCCDFから受け取った上限と「以下」で比べるだけです。
```
5.11.1
2026-10-29T00:00:00
PASS_MAX_DAYSlogin.defsの値を上限と比べる
/etc/login.defs
^\s*PASS_MAX_DAYS\s+(\d+)\s*$
1
```
`oscap xccdf validate demo-xccdf.xml`は終了コード0で通りましたが、「Benchmarkにdescriptionが無い」「platformの指定が無いので全プラットフォームに適用される」など4件の警告を出しました。警告は合否に影響しません。社内で配るファイルなら`platform`だけは付けておくと、対象外のOSで誤ってfailを出さずに済みます。
### 評価結果：fail・notcheckedとスコア0、終了コード2
```
# プロファイルを指定せずに評価（Ruleはselected="false"なので何も評価されない）
$ oscap xccdf eval demo-xccdf.xml
--- Starting Evaluation ---
$ echo $?
0
# 厳格プロファイルで評価し、結果XMLとHTMLレポートを出す
$ oscap xccdf eval --profile xccdf_jp.co.issoh_profile_strict \
--results res1.xml --report rep1.html demo-xccdf.xml
--- Starting Evaluation ---
Title パスワードの有効期限を上限日数以下にする
Rule xccdf_jp.co.issoh_rule_pass_max_days
Result fail
Title 管理者アカウントの棚卸しを年1回行う
Rule xccdf_jp.co.issoh_rule_manual_review
Result notchecked
$ echo $?
2
$ grep -o ']*>[^<]*' res1.xml
0.000000
```
プロファイルを指定しない実行は1件も評価せず、終了コード0で終わりました。Ruleを`selected="false"`で書いたためで、AlmaLinux 9向けSSGのデータストリームも1,540件のRuleがすべて同じ書き方です。厳格プロファイルでは、`check`を持たない運用ルールがnotcheckedとして採点から外れ、残ったfail 1件だけで0点になりました。failがあるときの終了コードは2です。manページは「すべてのRuleがpassなら0、評価中のエラーは1、failかunknownが1件でもあれば2」と定めています。
### `generate fix`による修復スクリプトの生成と`--remediate`による適用
Ruleに`fix`要素を書いておくと、OpenSCAPが修復スクリプトを組み立てます。`fix`の中の`sub`要素はValueの値に置き換わるので、厳格プロファイルでは60が埋め込まれました。
```
# 評価結果から、失敗したルールだけの修復スクリプトを作る
$ oscap xccdf generate fix --fix-type bash --result-id "" res1.xml
（ヘッダー部分は省略）
###############################################################################
# BEGIN fix (1 / 1) for 'xccdf_jp.co.issoh_rule_pass_max_days'
###############################################################################
(>&2 echo "Remediating rule 1/1: 'xccdf_jp.co.issoh_rule_pass_max_days'"); (
sed -i -E 's/^[[:space:]]*PASS_MAX_DAYS.*/PASS_MAX_DAYS 60/' /etc/login.defs
) # END fix for 'xccdf_jp.co.issoh_rule_pass_max_days'
# 評価と修復を1回で行う
$ oscap xccdf eval --remediate --profile xccdf_jp.co.issoh_profile_strict \
--results res2.xml demo-xccdf.xml
（評価結果は上と同じfail・notchecked）
--- Starting Remediation ---
Title パスワードの有効期限を上限日数以下にする
Rule xccdf_jp.co.issoh_rule_pass_max_days
Result fixed
$ echo $?
0
$ grep '^PASS_MAX_DAYS' /etc/login.defs
PASS_MAX_DAYS 60
$ grep -o ']*>[^<]*' res2.xml
100.000000
```
修復後の結果はfixedで、スコアは100になりました。ただし変えたのは`/etc/login.defs`の`PASS_MAX_DAYS`で、これは新しく作るアカウントに適用される既定値です。既存アカウントの有効期限は変わらず、棚卸しのRuleもnotcheckedのままです。`--remediate`を付けた実行は、修復に成功すれば終了コード0で返ります。本番サーバーでいきなり`--remediate`を使うのは避け、まず`generate fix`でスクリプトを出してレビューするのが安全です。`--fix-type`は`bash`・`ansible`・`puppet`・`kubernetes`・`bootc`などから選べます。AlmaLinux 9向けSSGでは、1,540件のRuleのうち1,315件がシェル、1,294件がAnsibleの`fix`を持っていました。Playbookとして構成管理に組み込む場合は[Ansibleの使い方入門](/tech/details/18473/)の手順と組み合わせます。
## 評価結果の読み方：rule-resultの値と採点
`TestResult`には、Ruleごとに次の9種類のいずれかが入ります（仕様書の表26）。採点の扱いは[NISTIR 7275 Rev.4（2012年3月更新版）](https://csrc.nist.gov/files/pubs/ir/7275/r4/upd1/final/docs/nistir-7275r4%5Fupdated-march-2012%5Fclean.pdf)の7.3.2節によります。
| 結果値 | 意味 | 既定の採点 |
| ------------- | --------------- | ----------- |
| pass | Ruleの条件をすべて満たした | 得点 |
| fixed | failだったが修復された | 得点（passと同じ） |
| fail | 条件を満たしていない | 失点 |
| error | 評価を完了できなかった | 失点 |
| unknown | 結果を解釈できなかった | 失点 |
| notapplicable | この対象には当てはまらない | 除外 |
| notchecked | checkが無い・未対応の検査 | 除外 |
| notselected | Profileで選ばれていない | 除外 |
| informational | 監査向けの情報のみ | 除外 |
見落としやすいのはerrorとunknownです。仕様の採点手順は、notapplicable・notchecked・informational・notselectedの4つだけを分母から外し、ほかは分母に数えます。点になるのはpass（とfixed）だけなので、仕様書が例に挙げるとおり権限不足で検査が止まったRuleはerrorになり、failと同じく点数を下げます。`sudo`を付けずに評価して点数が低く出たら、まず結果値の内訳を見ます。
採点モデルは4つあります。`urn:xccdf:scoring:default`はGroupの階層ごとに重み付きで正規化し、根のBenchmarkで最終点を出します（ツールは対応必須）。`flat`はpassしたRuleの重みの合計を、対象Ruleの重みの合計を満点として出します。`flat-unweighted`は0以外の重みを1としてflatと同じ計算をするので、実質はpassの件数です。重み0のRuleは採点に寄与しません。`absolute`はflatの得点が満点と等しければ1、それ以外は0で、除外される結果や重み0のRuleは妨げになりません。4つのモデルとも、fixedはpassとして数えます。この記事の点数はいずれもdefaultモデルの値です。defaultは同じGroup内の兄弟要素どうしで正規化するので、重みが小さいRuleでも、Group内で唯一の採点対象なら点数を大きく動かします。重みの数字だけで影響を判断せず、合否はfail・error・unknownの中身で決めます。
## SCAP Security Guideのプロファイルで監査する手順
実際の監査では、XCCDFを自作する場面はまれです。[ComplianceAsCode](https://github.com/ComplianceAsCode/content)が作っているSCAP Security Guide（SSG）が、XCCDF・OVAL・OCIL・CPEを1つにまとめたデータストリーム（`ssg-*-ds.xml`）をディストリビューションごとに配布しています。
### プロファイルIDの選び方：cisはLevel 2
```
# AlmaLinux 9 の場合（RHEL 9 はパッケージ名が同じで、ファイルは ssg-rhel9-ds.xml）
$ sudo dnf install -y openscap-scanner openscap-utils scap-security-guide
$ DS=/usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml
# データストリームに入っているプロファイルIDを確かめる
$ oscap info $DS
# CIS Level 1 - Server で評価する
$ sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
--results-arf arf.xml --report report.html $DS
```
AlmaLinux 9向けのscap-security-guide 0.1.82（上流の[ComplianceAsCode content 0.1.82](https://github.com/ComplianceAsCode/content/releases/tag/v0.1.82)は2026年9月1日公開）では、`oscap info`がANSSI、BSI、CIS、HIPAA、PCI DSS v4.0.1、DISA STIGなど20のプロファイルを表示しました。紛らわしいのはCISです。`content_profile_cis`のタイトルは`CIS AlmaLinux OS 9 Benchmark for Level 2 - Server`で、Level 1（Server）は`content_profile_cis_server_l1`です。「CISプロファイル」のつもりで`cis`を指定するとLevel 2の厳しいルールまで評価されるので、どちらのレベルに合わせるのかを先に決めてIDを選びます。
### テーラリングファイルによる閾値の変更
SSGのデータストリームを直接編集すると、パッケージ更新のたびに上書きされます。組織の基準がCISと少しだけ違うなら、XCCDF 1.2のTailoringで派生プロファイルを作ります。openscap-utilsに入っている`autotailor`なら1行で生成できます。
```
# CIS L1を土台に、パスワード有効期限の値だけ60日に変えた派生プロファイルを作る
$ autotailor -v var_accounts_maximum_age_login_defs=60 \
-p cis_l1_pass60 -o tailoring.xml $DS cis_server_l1
$ cat tailoring.xml
1
60
# 派生プロファイルで評価する（SSG本体は書き換えない）
$ sudo oscap xccdf eval --tailoring-file tailoring.xml \
--profile xccdf_org.ssgproject.content_profile_cis_l1_pass60 \
--results-arf arf.xml --report report.html $DS
```
生成されたファイルは`extends`で元のプロファイルを継承し、`set-value`で変数だけを上書きしています。ルールを外すときは`-u`、足すときは`-s`にRule IDを渡します。[SCAP Workbench](https://github.com/OpenSCAP/scap-workbench)のGUIでも同じテーラリングファイルを作れます。
### コンテナの内側から評価すると295件中220件が対象外
同じAlmaLinux 9コンテナの中で`cis_server_l1`を評価したところ、36秒で終わり、結果はpass 70件、fail 5件、notapplicable 220件、スコアは87.85でした。8割近くのRuleが対象外です。
原因はGroupのplatformです。たとえばパスワード有効期限のRule（`accounts_maximum_age_login_defs`）は、親Group「password\_expiration」に`system_with_kernel`というplatformが付いています。カーネルパッケージを持たないコンテナはこの条件を満たさないため、`/etc/login.defs`が`99999`のままでもfailにならず、notapplicableになりました。テーラリングで上限を60日にしても結果は同じです。
このコンテナ評価の87点を、ホストやサーバー全体の準拠度として報告してはいけません。点数を出すときは、対象環境・プロファイルと、295件中220件が対象外だった事実を併記します。ホストやVMの監査は対象のOS上で行い、コンテナイメージを調べたいなら、`oscap-podman`のようにイメージを外側から検査するツールを使います。
### XCCDFを自作する判断基準
自作が見合うのは、CISやSTIGに無い社内独自の基準（業務アプリの設定ファイル、社内ツールの導入有無など）を、複数のサーバーに同じ形式で配って点検したい場合です。OSの一般的な堅牢化だけが目的なら自作はしません。SSGのプロファイルを当て、差分はテーラリングで吸収した方が、OVALの保守まで抱えずに済みます。設定監査の結果を踏まえた脆弱性の洗い出しまで外部に任せる場合は、[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)の範囲として相談できます。
## よくある質問
### XCCDFとOVALの違いは何ですか？
XCCDFはチェックリストの形式で、どのRuleを選ぶか、閾値をいくつにするか、結果をどう採点・報告するかを書きます。OVALはシステムの状態を実際に調べる検査言語で、ファイルの中身やパッケージの有無を調べ、true・falseのほか、unknown・error・not evaluated・not applicableを返します。XCCDFのRuleが`check`要素でOVAL定義を参照し、閾値は`check-export`でOVALに渡します。XCCDF単体では合否を出せません。
### XCCDFファイルの例はどこで見られますか？
RHEL系なら`scap-security-guide`パッケージを入れると`/usr/share/xml/scap/ssg/content/`にデータストリームが入り、実運用の何千件ものRuleを読めます。仕組みを確かめるだけなら、この記事の最小例のようにRule 1本とOVAL定義1本から始め、`oscap xccdf validate`でスキーマ検証してから評価すると、どこで間違えたかが分かります。
### XCCDFの最新バージョンは？
XCCDF 1.2です。NISTIR 7275 Rev.4（2011年9月30日公開、2012年3月1日に更新版）で、ISO/IEC 18180:2013にもなっています。その後の版は無く、2026年6月に正式版となったSCAP 1.4（NIST SP 800-126 Rev.4）もXCCDF 1.2を指定しています。更新が続いているのは実装側で、2026年10月時点の最新はOpenSCAP 1.4.6、SSG 0.1.82です。
### oscap xccdf evalの終了コードは？
すべてのRuleがpassなら0、評価中のエラーは1、failかunknownが1件でもあれば2です。CIでは2を「不適合または判定不能」、1を「処理エラー」として通知を分け、2のときは結果XMLでfailとunknownの内訳を確かめます。`--profile`を省略するとBenchmarkの選択状態のまま評価されるので、全Ruleが`selected="false"`のSSGでは何も評価されずに0が返ります（AlmaLinux 9向けのデータストリームで評価件数0・終了コード0を確認）。
### CIS BenchmarkやDISA STIGとの関係は？
CIS BenchmarkやDISA STIGは設定基準そのもので、XCCDFはそれを機械で読める形にする入れ物です。SSGはCISとSTIGをXCCDFのProfileとして収録しており、AlmaLinux 9向けにはCIS Level 1・Level 2（ServerとWorkstation）とSTIG、STIG with GUIがあります。CIS純正の[CIS-CAT Pro Assessor](https://ciscat-assessor.docs.cisecurity.org/en/latest/About/)もXCCDFとOVALで評価し、DoD Platform Oneの手順ではOpenSCAPのXCCDF結果ファイルをSTIG Viewerに読み込んで確認します。
## 関連記事
- [SCAPとは？セキュリティ設定共通化手順とSCAP 1.4の変更点【2026年版】](/tech/details/5125/)
- [OVALとは？脆弱性検査言語の仕組みとoscapでの評価手順・最新5.12.3【2026年】](/tech/details/5123/)
- [CCEとは？セキュリティ設定の共通ID｜形式・最新リスト5.20251209とSCAPでの調べ方](/tech/details/5090/)
- [CPEとは？セキュリティ識別子・ネットワーク機器・CPEクレジットの違いと使い分け](/tech/details/5088/)
- [CVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説](/tech/details/5094/)
---
出典: [XCCDFとは？OVALとの違い・ファイル構造とoscapで評価する手順【XCCDF 1.2】]()（株式会社一創）