--- title: "CCEとは？セキュリティ設定の共通ID｜形式・最新リスト5.20251209とSCAPでの調べ方" url: "https://www.issoh.co.jp/tech/details/5090/" published: 2025-01-30 updated: 2026-10-29 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 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概説](https://www.ipa.go.jp/security/vuln/scap/cce.html)は、`CCE-2981-9`（最小パスワード長）の推奨値をFDCCが12文字以上、DISAが14文字以上、Microsoftが8文字以上と並べています。番号が同じでも、守るべき値は採用するガイドで決まります。 実際のエントリは、NISTが配布するExcelで次のように並んでいます。 | CCE-ID | プラットフォーム | 設定項目 | | ----------- | ----------- | ----------------------------- | | CCE-2981-9 | Windows XP | minimum password length | | CCE-80647-1 | RHEL 8 | Set Password Maximum Age | | CCE-95101-2 | macOS Tahoe | audit\_acls\_files\_configure | | CCE-95422-2 | iOS 26 | icloud\_backup\_disabled | 出典は[NCPのCCEページ](https://ncp.nist.gov/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チェックディジットアルゴリズム](https://ncp.nist.gov/faq/cce)で作った検査数字です。番号の桁数も固定ではなく、最新リストには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サイト](https://cce.mitre.org/)は、[利用条件のページ](https://cce.mitre.org/termsofuse.html)で2013年2月に維持と開発をNISTへ移し、CCE関連資料の著作権もNISTに譲渡したと告知したうえで、更新しないアーカイブになっています。現在の公式リストはNCPが配布しています。 版番号は「5.」の後ろが公開日です。5.20251209なら仕様バージョン5の2025年12月9日版で、識別子の仕様そのものは5から変わっていません。NCPの[ChangeLog](https://csrc.nist.gov/CSRC/media/Projects/national-vulnerability-database/documents/CCE/ChangeLog-5.20251209.txt)をたどると、更新には7年半の空白があります。 | 版 | 公開日 | 追加された主なグループ | | ---------- | ---------- | --------------------------------------------------- | | 5.20130214 | 2013-02-14 | 合計12,163件・32グループ | | 5.20201021 | 2020-10-21 | RHEL 6/7/8、OpenShift 3、VMware、macOS Catalina | | 5.20210407 | 2021-04-07 | macOS Big Sur | | 5.20220713 | 2022-07-13 | SUSE Linux Enterprise Server 15、macOS Monterey | | 5.20250915 | 2025-09-15 | macOS Sequoia/Sonoma/Ventura、iOS 16〜18、visionOS 2.0 | | 5.20251209 | 2025-12-09 | macOS Tahoe、iOS 26、visionOS 26 | 2013年の版はMITRE時代の最後の一括更新で、2018年の[@ITの解説](https://atmarkit.itmedia.co.jp/ait/articles/1809/05/news014%5F2.html)も「最新は5.20130214」と書いています。「CCEは更新が止まった」という説明が今も残るのはこのためですが、2020年以降に5回更新されています。 ### 最新5.20251209の収録内容 統合ファイル（2,329KB）の全54シートで、先頭列がCCE-IDになっている行を数えると17,563行、同じIDを1つにまとめると17,486件でした。2013年版の12,163件から5,000件あまり増えています。主なグループの件数と、NCPに載っている個別ファイルの最終更新日は次のとおりです。 | 系統 | グループ（行数） | 最終更新 | | ------- | -------------------------------------------- | ------------ | | Apple | macOS Tahoe（325）、iOS 26（132）、visionOS 26（45） | 2025-12-09 | | Red Hat | RHEL 6（572）、RHEL 7（868）、RHEL 8（701） | 2020-10-21 | | SUSE | SLES 15 DISA STIG（233）、SLES 15 PCI-DSS（110） | 2022-07-13 | | Windows | Windows 7（612）、Windows Server 2008 R2（1,130） | 2012-05-21以前 | | Office | Office 2010（2,020）、Office 2007（476） | 2013-02-14 | Windows 10・11、Windows Server 2016以降、RHEL 9、Ubuntuのグループはありません。2025年の2回の更新で増えたのはAppleの製品だけで、macOSとiOSの行は[macOS Security Compliance Project](https://github.com/usnistgov/macos%5Fsecurity)のルール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ページ](https://ncp.nist.gov/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](https://github.com/ComplianceAsCode/content)のルール定義に書かれています。パスワードの最長有効期間を決めるルール `accounts_maximum_age_login_defs` の `rule.yml` には、製品ごとに別のCCEが並びます。ComplianceAsCodeの[開発者ガイド](https://complianceascode.readthedocs.io/en/latest/manual/developer/06%5Fcontributing%5Fwith%5Fcontent.html)も、製品と製品バージョンが違えば別の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のリリース](https://github.com/ComplianceAsCode/content/releases)に入っている `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](https://csrc.nist.gov/pubs/sp/800/126/r4/final)（SCAP 1.4、2026年6月公開）は、設定の準拠を確かめるルールの `` に、`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](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-126r3.pdf)も同じ表で `http://cce.mitre.org` を指定しています。仕様の規定と、実際に配布されているコンテンツで、同じCCEを指すURIが2種類あるわけです。 ``` CCE-3867-0 CCE-83606-4 ``` 自前のスクリプトやSIEMの取り込み設定で `system` を片方だけに絞ると、もう片方のコンテンツのCCEが0件になります。照合はURIを両方受け付けるか、値が `CCE-` で始まるかで判定するのが安全です。上のPythonのコードで `CCE_SYSTEMS` に2つ入れているのはこのためです。 同じ仕様書の3.6節は、該当する公式CCEがあればSCAPコンテンツはそれを使わなければならず（SHALL）、無ければ発行を求めるべき（SHOULD）としています。依頼先は `cce@nist.gov` です。また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は「何を設定するか」に名前を付ける役で、検査の手順や結果の採点は別の仕様が受け持ちます。 | 仕様 | 何を表すか | 例 | | ----- | ----------- | --------------------------------------------------------- | | CCE | セキュリティ設定項目 | CCE-83606-4 | | CVE | 個別の脆弱性 | CVE-2021-44228 | | CPE | 製品・プラットフォーム | cpe:2.3:o:redhat:enterprise\_linux:9:\*:\*:\*:\*:\*:\*:\* | | OVAL | 状態を検査するロジック | oval:ssg-accounts\_maximum\_age\_login\_defs:def:1 | | XCCDF | チェックリストと結果 | Rule・Profile | | CVSS | 脆弱性の深刻度 | 基本値 0.0〜10.0 | XCCDFのルールが「この設定はCCE-83606-4です」と宣言し、そのルールが呼ぶOVAL定義が実際に `/etc/login.defs` を読む、という分担です。CVEとの違いは対象で、CVEは製品の欠陥、CCEは管理者が選ぶ設定を指します。どちらの番号も対策後に消えるものではなく、設定の合否はCCEではなく採用したガイドの要件で決まります。各仕様の詳細は[SCAPの全体像とSCAP 1.4の変更点](/tech/details/5125/)、[XCCDFのファイル構造](/tech/details/5141/)、[OVALの仕組み](/tech/details/5123/)で扱っています。CVEとCWEの区別は[CVEとCWEの違い](/tech/details/5119/)を参照してください。 ## 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のレポート](https://ciscat-assessor.docs.cisecurity.org/en/latest/ReportHTML/)の参照欄にCCEが載ることはありますが、管理表の主キーはCISベンチマークの項目番号やDISA STIGの番号にします。STIGが要件の対応付けに使うのは[CCI（Control Correlation Identifier）](https://www.cyber.mil/stigs/cci/)という別の番号体系で、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の検出の仕組み](/tech/details/16228/)で、外部からの診断で設定の不備を洗い出したい場合は当社の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でも対応しています。 ## よくある質問 ### 「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年版】](/tech/details/5125/) - [XCCDFとは？SCAP・OVALとの違いとファイル構造・使い方を解説](/tech/details/5141/) - [OVALとは？脆弱性を標準化して評価するセキュリティ言語の仕組みと現状](/tech/details/5123/) - [CVE（共通脆弱性識別子）とは？番号の読み方・CVSS/CWE/NVDとの違いと調べ方](/tech/details/5092/) - [CPEとは？セキュリティ識別子・ネットワーク機器・CPEクレジットの違いと使い分け](/tech/details/5088/) --- 出典: [CCEとは？セキュリティ設定の共通ID｜形式・最新リスト5.20251209とSCAPでの調べ方]()（株式会社一創）