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）。「パスワードの有効期限は60日以下」のような要件を、表計算のメモではなく同じ書式のXMLで持つので、同じチェックリストを別の組織・別のツールでそのまま使えます。

版の流れは、NISTのXCCDF仕様ページに1.0から1.2までの仕様書とスキーマが並んでいます。

1.2のあとに新しい版は出ていません。2026年6月8日に正式版となったSCAP 1.4（NIST SP 800-126 Rev.4）も、構成仕様として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とセキュリティ設定共通化手順の解説に、識別子はCCEの形式とSCAPでの調べ方とCPEの解説にまとめています。

XCCDFとOVALの違い：チェックリストの定義と状態の検査

XCCDFのRuleは「空のパスワードを禁止する」「有効期限を60日以下にする」と宣言し、check要素で検査の中身を外部のOVAL定義に任せます。OVALは「/etc/login.defsのPASS_MAX_DAYS行を正規表現で取り出し、数値を比べる」といった、システムの状態の読み方そのものを書きます。

両者は値の受け渡しでもつながります。XCCDFのValueに置いた閾値をcheck-exportでOVALのexternal_variableへ渡すので、OVAL定義を書き換えずにProfileごとに閾値を変えられます。OVALの書き方とoscap oval evalでの単体評価はOVALの仕組みとoscapでの評価手順で扱っています。

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日）ですが、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を持たせていません。

<?xml version="1.0" encoding="UTF-8"?>
<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2" id="xccdf_jp.co.issoh_benchmark_demo" resolved="1" xml:lang="ja">
  <status>draft</status>
  <title>XCCDF 1.2 最小デモ</title>
  <version>1.0</version>
  <Profile id="xccdf_jp.co.issoh_profile_strict">
    <title>厳格プロファイル</title>
    <select idref="xccdf_jp.co.issoh_rule_pass_max_days" selected="true"/>
    <select idref="xccdf_jp.co.issoh_rule_manual_review" selected="true"/>
    <refine-value idref="xccdf_jp.co.issoh_value_pass_max_days" selector="60"/>
  </Profile>
  <Value id="xccdf_jp.co.issoh_value_pass_max_days" type="number">
    <title>PASS_MAX_DAYSの上限</title>
    <value>365</value>
    <value selector="60">60</value>
  </Value>
  <Rule id="xccdf_jp.co.issoh_rule_pass_max_days" selected="false" severity="medium" weight="10.0">
    <title>パスワードの有効期限を上限日数以下にする</title>
    <fix system="urn:xccdf:fix:script:sh">sed -i -E 's/^[[:space:]]*PASS_MAX_DAYS.*/PASS_MAX_DAYS <sub idref="xccdf_jp.co.issoh_value_pass_max_days" use="value"/>/' /etc/login.defs</fix>
    <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
      <check-export export-name="oval:jp.co.issoh:var:1" value-id="xccdf_jp.co.issoh_value_pass_max_days"/>
      <check-content-ref href="demo-oval.xml" name="oval:jp.co.issoh:def:1"/>
    </check>
  </Rule>
  <Rule id="xccdf_jp.co.issoh_rule_manual_review" selected="false" severity="low" weight="1.0">
    <title>管理者アカウントの棚卸しを年1回行う</title>
  </Rule>
</Benchmark>

OVAL側は、正規表現で数値を取り出し、XCCDFから受け取った上限と「以下」で比べるだけです。

<?xml version="1.0" encoding="UTF-8"?>
<oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" xmlns:ind="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent">
  <generator>
    <oval:schema_version>5.11.1</oval:schema_version>
    <oval:timestamp>2026-10-29T00:00:00</oval:timestamp>
  </generator>
  <definitions>
    <definition id="oval:jp.co.issoh:def:1" version="1" class="compliance">
      <metadata><title>PASS_MAX_DAYS</title><description>login.defsの値を上限と比べる</description></metadata>
      <criteria><criterion test_ref="oval:jp.co.issoh:tst:1"/></criteria>
    </definition>
  </definitions>
  <tests>
    <ind:textfilecontent54_test id="oval:jp.co.issoh:tst:1" version="1" check="all" check_existence="at_least_one_exists" comment="PASS_MAX_DAYS">
      <ind:object object_ref="oval:jp.co.issoh:obj:1"/>
      <ind:state state_ref="oval:jp.co.issoh:ste:1"/>
    </ind:textfilecontent54_test>
  </tests>
  <objects>
    <ind:textfilecontent54_object id="oval:jp.co.issoh:obj:1" version="1">
      <ind:filepath>/etc/login.defs</ind:filepath>
      <ind:pattern operation="pattern match">^\s*PASS_MAX_DAYS\s+(\d+)\s*$</ind:pattern>
      <ind:instance datatype="int">1</ind:instance>
    </ind:textfilecontent54_object>
  </objects>
  <states>
    <ind:textfilecontent54_state id="oval:jp.co.issoh:ste:1" version="1">
      <ind:subexpression datatype="int" operation="less than or equal" var_ref="oval:jp.co.issoh:var:1"/>
    </ind:textfilecontent54_state>
  </states>
  <variables>
    <external_variable id="oval:jp.co.issoh:var:1" version="1" datatype="int" comment="XCCDFのValueから受け取る"/>
  </variables>
</oval_definitions>

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 '<score[^>]*>[^<]*</score>' res1.xml
<score system="urn:xccdf:scoring:default" maximum="100.000000">0.000000</score>

プロファイルを指定しない実行は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 '<score[^>]*>[^<]*</score>' res2.xml
<score system="urn:xccdf:scoring:default" maximum="100.000000">100.000000</score>

修復後の結果は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の使い方入門の手順と組み合わせます。

評価結果の読み方：rule-resultの値と採点

TestResultには、Ruleごとに次の9種類のいずれかが入ります（仕様書の表26）。採点の扱いはNISTIR 7275 Rev.4（2012年3月更新版）の7.3.2節によります。

見落としやすいのは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が作っている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は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
<?xml version="1.0" ?>
<xccdf-1.2:Tailoring xmlns:xccdf-1.2="http://checklists.nist.gov/xccdf/1.2" id="xccdf_auto_tailoring_default">
	<xccdf-1.2:benchmark href="file:///usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml"/>
	<xccdf-1.2:version time="2026-10-29T13:33:02.568251">1</xccdf-1.2:version>
	<xccdf-1.2:Profile id="xccdf_org.ssgproject.content_profile_cis_l1_pass60" extends="xccdf_org.ssgproject.content_profile_cis_server_l1">
		<xccdf-1.2:title override="false"/>
		<xccdf-1.2:set-value idref="xccdf_org.ssgproject.content_value_var_accounts_maximum_age_login_defs">60</xccdf-1.2:set-value>
	</xccdf-1.2:Profile>
</xccdf-1.2:Tailoring>

# 派生プロファイルで評価する（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の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の保守まで抱えずに済みます。設定監査の結果を踏まえた脆弱性の洗い出しまで外部に任せる場合は、脆弱性診断・セキュリティ診断の範囲として相談できます。

よくある質問

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もXCCDFとOVALで評価し、DoD Platform Oneの手順ではOpenSCAPのXCCDF結果ファイルをSTIG Viewerに読み込んで確認します。

関連記事

• SCAPとは？セキュリティ設定共通化手順とSCAP 1.4の変更点【2026年版】
• OVALとは？脆弱性検査言語の仕組みとoscapでの評価手順・最新5.12.3【2026年】
• CCEとは？セキュリティ設定の共通ID｜形式・最新リスト5.20251209とSCAPでの調べ方
• CPEとは？セキュリティ識別子・ネットワーク機器・CPEクレジットの違いと使い分け
• CVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説