CCEとは？セキュリティ設定の共通ID｜形式・最新リスト5.20251209とSCAPでの調べ方

CCE（Common Configuration Enumeration）は、OSやアプリケーションのセキュリティ設定項目1つずつに振る共通のIDです。たとえばWindows XPの「パスワードの最小文字数」は CCE-2981-9、Red Hat Enterprise Linux 8の「パスワードの最長有効期間」は CCE-80647-1 で、監査ツールやガイドラインが違っても同じ番号で同じ設定を指せます。リストは今もNISTが更新しており、2026年10月29日時点の最新は2025年12月9日の5.20251209です。ただしRHEL 9やWindows 11のグループはこの一覧に無く、引き方を知らないと「CCEが見つからない」で止まります。この記事では、IDの形式と検査数字の確かめ方、最新リストの中身、RHEL 9以降のCCEを調べる手順を、NISTのデータとSCAPの仕様書で確認しながら説明します。

まとめ：CCEの要点

• 何か：セキュリティ設定項目に振る共通ID。脆弱性に番号を振るCVEの「設定版」にあたり、SCAP 1.4でもCPE・CVEと並ぶ識別スキームの1つ。
• 形式：CCE-番号-検査数字。番号に意味は無く、末尾1桁はLuhnアルゴリズムの検査数字。最新リストの17,486件はすべてLuhnで正しい。
• 現状：仕様はバージョン5のまま。リストはMITREからNISTのNational Checklist Program（NCP）へ移り、最新は5.20251209（2025年12月9日）。直近2回の追加はmacOS・iOS・visionOSだけ。
• RHEL 9以降：NCPの一覧はRHEL 8まで。RHEL 9・10のCCEはComplianceAsCodeの rule.yml やSCAPデータストリームで引く。同じ設定でも製品ごとに番号が違う。
• XCCDFでの書き方：SCAP 1.4仕様の system 属性は http://cce.mitre.org、ComplianceAsCodeの実装は https://ncp.nist.gov/cce。検索や集計では両方を拾う。

以下、定義から順に具体例で見ていきます。

CCEの定義：設定項目ごとに振られる共通ID

NCPのFAQは、CCEを「設定ガイダンスの記述と設定コントロールに一意のエントリを割り当て、別々の領域にある設定上の問題をすばやく正確に突き合わせる」ための仕組みと説明しています。同じ「パスワードは14文字以上」という要件でも、CISベンチマーク、DISAのSTIG、自社の監査スクリプトでは呼び名も項目番号もばらばらです。そこにCCEを1つ付けておけば、どのツールの結果とどのガイドの推奨値が同じ設定の話なのかを番号で照合できます。

CCEは「推奨値」を持ちません。決めるのは「どの設定項目か」だけで、値はガイドごとに違ってよいという設計です。IPAの共通セキュリティ設定一覧CCE概説は、CCE-2981-9（最小パスワード長）の推奨値をFDCCが12文字以上、DISAが14文字以上、Microsoftが8文字以上と並べています。番号が同じでも、守るべき値は採用するガイドで決まります。

実際のエントリは、NISTが配布するExcelで次のように並んでいます。

出典はNCPのCCEページから落とせる全プラットフォーム統合版（cce-COMBINED-5.20251209.xlsx）です。macOSとiOSの行は2列目に audit_acls_files_configure のようなルールIDを持ち、確認用のシェルコマンドまで載っています。2010年前後のWindows系の行が文章で設定を説明しているのと比べると、同じCCEでも中身の作りが年代で違います。

CCE-IDの形式とLuhn検査数字の確かめ方

CCE-IDは CCE-2715-1 のように「CCE」「番号」「検査数字」の3つをハイフンでつなぎます。NCPのFAQによれば、番号はランダムで意味を持たず、末尾の1桁はLuhnチェックディジットアルゴリズムで作った検査数字です。番号の桁数も固定ではなく、最新リストには2桁から5桁まで混在しています。古い解説に残る「CCE-XXXX-XXXX」という4桁ずつの表記は誤りです。

検査数字は、番号と検査数字をつないだ数字列を右から数え、偶数番目の桁を2倍（9を超えたら9を引く）して全桁を足し、10で割り切れれば正しい、という計算です。クレジットカード番号の検査と同じ方式なので、入力ミスや転記ミスをIDを引く前にはじけます。

import re

def is_valid_cce(cce_id: str) -> bool:
    m = re.fullmatch(r"CCE-(\d+)-(\d)", cce_id.strip())
    if not m:
        return False
    digits = m.group(1) + m.group(2)
    total = 0
    for i, ch in enumerate(reversed(digits)):
        n = int(ch)
        if i % 2 == 1:
            n *= 2
            if n > 9:
                n -= 9
        total += n
    return total % 10 == 0

for x in ["CCE-2981-9", "CCE-83606-4", "CCE-83606-3", "CCE-2981"]:
    print(x, is_valid_cce(x))

Python 3.9.6と3.14で実行すると、出力は次のとおりです。この関数が確かめるのは形式と検査数字だけで、そのIDが発行済みかどうかや、どのリストに載っているかまでは分かりません。

CCE-2981-9 True
CCE-83606-4 True
CCE-83606-3 False
CCE-2981 False

同じ関数を5.20251209の統合ファイルにある全17,563行に当てたところ、Luhnで不正になるIDは0件でした。手元の資料やスキャン結果でFalseが出たら、リストの誤りではなく転記の誤りを疑ってください。

CCEリストの現状：仕様はv5のまま、NISTが更新を継続

MITREからNISTへの移管と版番号の読み方

CCEはMITREが立ち上げた標準ですが、MITREのCCEサイトは、利用条件のページで2013年2月に維持と開発をNISTへ移し、CCE関連資料の著作権もNISTに譲渡したと告知したうえで、更新しないアーカイブになっています。現在の公式リストはNCPが配布しています。

版番号は「5.」の後ろが公開日です。5.20251209なら仕様バージョン5の2025年12月9日版で、識別子の仕様そのものは5から変わっていません。NCPのChangeLogをたどると、更新には7年半の空白があります。

2013年の版はMITRE時代の最後の一括更新で、2018年の@ITの解説も「最新は5.20130214」と書いています。「CCEは更新が止まった」という説明が今も残るのはこのためですが、2020年以降に5回更新されています。

最新5.20251209の収録内容

統合ファイル（2,329KB）の全54シートで、先頭列がCCE-IDになっている行を数えると17,563行、同じIDを1つにまとめると17,486件でした。2013年版の12,163件から5,000件あまり増えています。主なグループの件数と、NCPに載っている個別ファイルの最終更新日は次のとおりです。

Windows 10・11、Windows Server 2016以降、RHEL 9、Ubuntuのグループはありません。2025年の2回の更新で増えたのはAppleの製品だけで、macOSとiOSの行はmacOS Security Compliance ProjectのルールIDと同じ名前を持っています。同プロジェクトのルール定義（audit_acls_files_configure.yaml）には、NCPの一覧にまだ無いmacOS 27向けの CCE-96951-9 がすでに書かれています。リストは「全製品を網羅する辞書」ではなく、NISTにCCEの発行を求めたプロジェクトの分だけ伸びる台帳だと考えたほうが実態に合います。

RHEL 9以降のCCEを調べる手順

NCPのExcelによるCCE検索（RHEL 8・macOS・iOSなど）

一覧にある製品なら、NCPのCCEページの「DOWNLOADS (MS Excel format)」から製品別か統合版のファイルを落とし、Excelの検索でCCE-IDか設定名を引きます。統合版は製品ごとにシートが分かれており、列の並びもシートごとに違います。RHEL 8のシートは「CCE ID v5／CCE Title／USGCB Setting／Technical Mechanism」、macOS Tahoeのシートは「CCE／Rule ID／Title／Discussion／Mechanism／Check」です。

ComplianceAsCodeのrule.ymlによる製品別CCE検索

RHEL 9・10やSUSEの新しい版のCCEは、Red HatやSUSEのセキュリティプロファイルの元になっているComplianceAsCodeのルール定義に書かれています。パスワードの最長有効期間を決めるルール accounts_maximum_age_login_defs の rule.yml には、製品ごとに別のCCEが並びます。ComplianceAsCodeの開発者ガイドも、製品と製品バージョンが違えば別のCCEを使わなければならないと定めています。

identifiers:
    cce@rhel8: CCE-80647-1
    cce@rhel9: CCE-83606-4
    cce@rhel10: CCE-87961-9
    cce@sle12: CCE-83050-5
    cce@sle15: CCE-85570-0

3つのRHELの番号はどれもLuhnで正しいIDですが、NCPの統合ファイルに載っているのはRHEL 8の CCE-80647-1 だけでした。RHEL 9の CCE-83606-4 と10の CCE-87961-9 は、NCPのExcelをいくら探しても出てきません。ComplianceAsCodeは製品ごとの未使用番号の在庫（shared/references/cce-redhat-avail.txt、2026年10月時点で2,286件）を持ち、utils/fix_rules.py の add-cce で新しいルールに割り当てています。

SCAPデータストリームからのCCE一覧抽出

手元で使っているSCAPコンテンツから直接引けば、使用中の版に対応するCCEを確認できます。RHELなら scap-security-guide パッケージ、それ以外はComplianceAsCodeのリリースに入っている ssg-rhel9-ds.xml などのデータストリームを読み、XCCDFのルールとCCEを対応付けます。次のコードを extract_cce.py として保存し、python3 extract_cce.py ssg-rhel9-ds.xml で実行します。

import sys
import xml.etree.ElementTree as ET

XCCDF = "{http://checklists.nist.gov/xccdf/1.2}"
CCE_SYSTEMS = {"https://ncp.nist.gov/cce", "http://cce.mitre.org"}

tree = ET.parse(sys.argv[1])
for rule in tree.iter(XCCDF + "Rule"):
    for ident in rule.findall(XCCDF + "ident"):
        if ident.get("system") in CCE_SYSTEMS:
            title = " ".join((rule.findtext(XCCDF + "title") or "").split())
            print(ident.text, rule.get("id").split("_rule_")[-1], title, sep="\t")

ComplianceAsCode v0.1.82（2026年9月1日公開）の ssg-rhel9-ds.xml に当てると、1,540ルールのうち1,129ルールがCCEを持っていました。該当行は次のように出ます。

CCE-83606-4	accounts_maximum_age_login_defs	Set Password Maximum Age
CCE-90800-4	sshd_disable_root_login	Disable SSH Root Login

残りの411ルールにはCCEがありません。CCEのある結果だけを集計すると、この411ルールのうち実際に評価対象となったルールの結果が集計から漏れます。CCEの無いルールは、ルールID（xccdf_org.ssgproject.content_rule_ で始まるID）で数えてください。

XCCDFのCCE識別に使うsystem URI：仕様と実装の違い

SCAPの技術仕様であるNIST SP 800-126 Rev. 4（SCAP 1.4、2026年6月公開）は、設定の準拠を確かめるルールの <xccdf:ident> に、system="http://cce.mitre.org" を指定するよう定めています（Table 17）。脚注では、MITREの名前が残っているのは歴史的な命名規則のためだと断っています。

一方、ComplianceAsCodeが生成するデータストリームは system="https://ncp.nist.gov/cce" です。上の ssg-rhel9-ds.xml では1,129件すべてがこちらでした。このデータストリーム自身が宣言しているのはSCAP 1.3ですが、SCAP 1.3のSP 800-126 Rev. 3も同じ表で http://cce.mitre.org を指定しています。仕様の規定と、実際に配布されているコンテンツで、同じCCEを指すURIが2種類あるわけです。

<!-- SP 800-126r4 Table 17 の例 -->
<xccdf:ident system="http://cce.mitre.org">CCE-3867-0</xccdf:ident>

<!-- ComplianceAsCode v0.1.82 ssg-rhel9-ds.xml -->
<xccdf-1.2:ident system="https://ncp.nist.gov/cce">CCE-83606-4</xccdf-1.2:ident>

自前のスクリプトやSIEMの取り込み設定で system を片方だけに絞ると、もう片方のコンテンツのCCEが0件になります。照合はURIを両方受け付けるか、値が CCE- で始まるかで判定するのが安全です。上のPythonのコードで CCE_SYSTEMS に2つ入れているのはこのためです。

同じ仕様書の3.6節は、該当する公式CCEがあればSCAPコンテンツはそれを使わなければならず（SHALL）、無ければ発行を求めるべき（SHOULD）としています。依頼先は [email protected] です。またXCCDFのidentは参考情報ではなく「記述された意味と完全に一致する」という宣言だと明記されています。似た設定に近いCCEを流用するのは、仕様上も避けるべき使い方です。

SCAPでのCCEの役割：CVE・CPE・OVAL・XCCDFとの違い

SP 800-126 Rev. 4は、SCAP 1.4の識別スキームをCPE 2.3、CCE 5、CVEの3つと定めています。CCEは「何を設定するか」に名前を付ける役で、検査の手順や結果の採点は別の仕様が受け持ちます。

XCCDFのルールが「この設定はCCE-83606-4です」と宣言し、そのルールが呼ぶOVAL定義が実際に /etc/login.defs を読む、という分担です。CVEとの違いは対象で、CVEは製品の欠陥、CCEは管理者が選ぶ設定を指します。どちらの番号も対策後に消えるものではなく、設定の合否はCCEではなく採用したガイドの要件で決まります。各仕様の詳細はSCAPの全体像とSCAP 1.4の変更点、XCCDFのファイル構造、OVALの仕組みで扱っています。CVEとCWEの区別はCVEとCWEの違いを参照してください。

CCEを照合キーにしないほうがよい場面

CCEは便利ですが、次の3つの場面では主キーに据えると集計が崩れます。

• OSのバージョンをまたぐ比較：RHEL 8から9へ移った前後で「同じ設定が直ったか」を見るとき、CCEは CCE-80647-1 から CCE-83606-4 に変わります。比較はComplianceAsCodeのルールID（accounts_maximum_age_login_defs）で行います。
• Windows 10・11やWindows Serverの新しい版の監査：NCPの一覧にグループが無く、番号の裏をNISTのリストで取れません。CIS-CAT Proのレポートの参照欄にCCEが載ることはありますが、管理表の主キーはCISベンチマークの項目番号やDISA STIGの番号にします。STIGが要件の対応付けに使うのはCCI（Control Correlation Identifier）という別の番号体系で、CCEとは別物です。
• 古いグループの記述を値の根拠にするとき：2012年以前の行は、説明文の質が揃っていません。Windows XPの CCE-2981-9（最小パスワード長）の行は、パラメータ欄が「(1) number of days」になっています。CCEは項目の特定に使い、値は採用したガイドの最新版で確かめます。

CCEに対応付けられたSP 800-53の管理策をNCPのフィードから取る方法もありますが、配布されている「CCE to SP 800-53」のマッピングは2015年12月2日付のBeta版のままです。設定の監査をまとめて見直すなら、CCEが付いたルールとそうでないルールを分けて棚卸しするところから始めると漏れが出ません。設定ミスをクラウド全体で継続的に拾う仕組みはCSPMの検出の仕組みで、外部からの診断で設定の不備を洗い出したい場合は当社の脆弱性診断・セキュリティ診断でも対応しています。

よくある質問

「CCE」は何の略ですか？

Common Configuration Enumerationの略で、IPAは「共通セキュリティ設定一覧」と訳しています。セキュリティ分野以外にも同じ略語は多いため、検索するときは「CCE SCAP」や「CCE-ID」と組み合わせると目的の情報にたどり着きやすくなります。

CCEは今も更新されていますか？

更新されています。MITREのサイトはアーカイブですが、NISTのNCPが2020年以降に5回リストを更新し、最新は2025年12月9日の5.20251209です。変わっていないのは識別子の仕様（バージョン5）のほうです。

CCEとCVEの違いは何ですか？

CVEは製品の脆弱性（欠陥）に、CCEは管理者が設定するセキュリティ項目に番号を振ります。CVEが指す脆弱性には修正や緩和策で対処し、CCEが指す設定項目は採用したガイドの要件に照らして評価します。どちらもSCAP 1.4の識別スキームです。

CCE-IDの末尾の数字は何ですか？

Luhnアルゴリズムで計算した検査数字です。番号と検査数字をつないだ数字列が検査を通らなければ、そのIDは転記ミスなどで壊れています。前の数字（番号）はランダムで、設定の種類や製品を表しません。

RHEL 9のCCEはどこで調べられますか？

NCPのExcelにはRHEL 9のグループが無いため、ComplianceAsCodeの各ルールの rule.yml（cce@rhel9 の行）か、scap-security-guide に入っている ssg-rhel9-ds.xml の xccdf-1.2:ident 要素で調べます。

関連記事

• SCAPとは？セキュリティ設定共通化手順とSCAP 1.4の変更点【2026年版】
• XCCDFとは？SCAP・OVALとの違いとファイル構造・使い方を解説
• OVALとは？脆弱性を標準化して評価するセキュリティ言語の仕組みと現状
• CVE（共通脆弱性識別子）とは？番号の読み方・CVSS/CWE/NVDとの違いと調べ方
• CPEとは？セキュリティ識別子・ネットワーク機器・CPEクレジットの違いと使い分け