SCAP（Security Content Automation Protocol）の現行版は、2026年6月に確定したSCAP 1.4です。日本語の解説はIPA「セキュリティ設定共通化手順」のページ（最終更新2015年7月22日）を起点にしたものが多く、そこではSCAPを6つの仕様の集合として説明しています。11年分の差があり、構成仕様の顔ぶれもバージョンの扱いも今は違います。SCAP 1.4を基準に、構成仕様・1.3からの変更点・OpenSCAPでの実行手順を整理します。
まとめ
- SCAPは「設定チェック項目」「検査ロジック」「識別子」「深刻度スコア」を別々の仕様として標準化し、1本のデータストリームに束ねて自動評価できるようにした枠組み。
- 現行版はSCAP 1.4。NIST SP 800-126r4と附属書SP 800-126Ar4として2026年6月に確定した。日本語の主要解説はほぼSCAP 1.3以前が前提で、仕様の記述と食い違う。
- 仕様書のChange Logは変更を5項目挙げるが、実務に効くのは3点。SWID要件の削除、CVSSのバージョン優先規則（v4.0 > v3.1 > v3.0 > v2.0）の明文化、SCAP 1.0／1.1との後方互換要件の削除。
- 実装側はまだ1.4に追いついていない。OpenSCAPの最新版1.4.4が対応を宣言しているのはSCAP 1.3で、OpenSCAPが扱えるOVALも5.11.3止まり（OVAL仕様側は5.12.3）。仕様書どおりのコンテンツをそのまま流すと読めない可能性がある。
- Linux／UNIX系サーバの設定監査を継続的に回す用途では有効。Windows中心の環境では、OpenSCAPのWindows対応が事実上止まっているため別手段を選ぶ。
まずIPAの6仕様と現行の構成がどうズレたのか、一覧から確認します。
SCAPの定義と、設定監査を属人化させないための標準化
SCAPは単体のツールでも製品でもなく、複数の仕様を組み合わせた枠組みです。NIST SP 800-126r4はSCAPを「ソフトウェアの欠陥情報とセキュリティ設定情報を、機械にも人にも伝わる形式と用語で標準化した仕様の集合」と定義しています。標準化の対象は4つです。何をチェックすべきかを書いたチェックリスト、それをどう判定するかの検査ロジック、製品や設定項目や脆弱性を指す識別子、問題の深刻度を表すスコア。従来はこの4つがツールごとに独自形式で、あるスキャナ向けに書いた設定基準を別のスキャナで使い回せませんでした。SCAPはそれぞれに別の仕様を割り当て、1本のXMLデータストリームに束ねて配布できるようにしています。
実務上の効果は、監査基準の再利用と証跡の機械可読化です。DISA STIGやCIS Benchmarkの内容をSCAPコンテンツとして配布すれば、対応スキャナならベンダーを問わず同じ判定結果になり、結果もARF形式で他システムへ渡せます。設定監査がスクリプトと担当者の記憶に依存する状態から抜け出すための土台、という位置づけです。
SCAP 1.4の構成仕様：5カテゴリと各仕様のバージョン
SP 800-126r4はSCAP 1.4を「5つのカテゴリ・12の構成仕様から成る」と説明しています。ただし、その直後に並ぶ実際の列挙は11件です。
| カテゴリ | 仕様 | SCAP 1.4での版 | 役割 |
|---|---|---|---|
| 言語 | XCCDF | 1.2 | チェックリスト記述と結果報告 |
| 言語 | OVAL | 5.12 | システム状態の検査ロジック |
| 言語 | OCIL | 2.0 | 人への質問形式の検査 |
| レポート形式 | ARF | 1.1 | 結果の転送形式 |
| レポート形式 | Asset Identification | 1.1 | 資産の一意識別 |
| 識別スキーム | CPE | 2.3 | OS・アプリの名前付けと辞書 |
| 識別スキーム | CCE | 5 | 設定項目の名前付けと辞書 |
| 識別スキーム | CVE | 版番号なし | 脆弱性の名前付けと辞書 |
| 測定・スコアリング | CVSS | v4.0 / v3.1 | 脆弱性の深刻度評価 |
| 測定・スコアリング | CCSS | 1.0 | 設定不備の深刻度評価 |
| 完全性 | TMSAD | 1.0 | コンテンツと結果への電子署名 |
数が合わないのは、後述するSWID要件の削除が反映されていないためです。SCAP 1.3の仕様書（SP 800-126r3）も「12仕様」と書いており、そちらはSWIDを含めて実数が12でした。1.4でSWIDを外したあとも地の文の数字が据え置かれています。CVSSをv3.1とv4.0の2件と数えれば12になりますが、いずれにせよ数字ではなく列挙のほうを正として読むべき箇所です。
もうひとつ、日本語の解説で頻出する誤りがCWE（共通脆弱性タイプ一覧）をSCAPの構成仕様に数えるものです。SP 800-126r3にもr4にも、構成仕様の一覧にCWEはありません。r4本文でCWEが出てくるのはNVDが提供するデータの説明箇所だけです。
この一覧で押さえておきたいのは、CVEやCVSSがSCAPの「一部」だという点です。CVE識別子はXCCDFのルールから参照され、そのCVSSスコアがXCCDFの結果に埋め込まれます。CVE・CVSSそのものの読み方は脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説、スコア計算式と評価基準はCVSSv3とは？スコアの計算方法と3つの評価基準・v3.1との違いを解説で扱っています。コンテンツを書くときの中心になる2言語については、Benchmark／Profile／Ruleの構造をXCCDFとは？SCAP・OVALとの違いとファイル構造・使い方を解説、definition／test／object／stateの関係をOVALとは？脆弱性を標準化して評価するセキュリティ言語の仕組みと現状で個別に解説しています。
SCAP 1.3から1.4への変更点：SWID要件削除とCVSSバージョン規則の明文化
SP 800-126r4のChange Log（Revision 4 Release 1, 2026年6月）が挙げる変更は5項目です。SCAP 1.3への参照をすべて1.4へ更新、SCAP 1.1および1.0の後方互換要件の削除、電子署名要件の改定、SWID要件の削除、OVALの「core」「platform」スキーマ版への参照の削除。このうち既存の解説記事と食い違うのが、SWIDとCVSSの扱いです。
SWID要件の削除とソフトウェア資産管理側への切り離し
SCAP 1.3ではSWIDタグ（ソフトウェア識別タグ）が構成仕様に含まれ、SP 800-126r3は「Software Identification (SWID) Tags 2015 revision」としてCPEと並ぶ識別手段に挙げていました。SCAP 1.4ではSWID要件が削除され、構成仕様一覧からも姿を消しています。識別スキームとして残るのはCPE 2.3・CCE 5・CVEの3つです。
SWID自体が廃止されたわけではありません。実体はISO/IEC 19770-2という独立した国際規格であり、NISTもIR 8060「Guidelines for the Creation of Interoperable Software Identification (SWID) Tags」（2016年4月22日確定）でタグ作成の指針を出しています。SCAPスキャナの適合要件からは外れましたが、資産管理やSBOMの文脈でタグを参照する運用はそのまま続けられます。「SCAPの識別スキーマはCPE・SWID・CCE・CVEの4つ」と書かれた記事は、SCAP 1.3までの説明として読んでください。
CVSS v4.0優先とレガシー版の適用期限
SCAP 1.3の「CVSS v3」という表記はv3.0とv3.1のどちらを指すのか曖昧でした。SP 800-126r4はこれを解消し、§3.8で4つの版を2階層に整理しています。
現行版はv4.0が推奨（r4の公開日以降のコンテンツは、権威ある情報源からv4.0のベクタが得られるなら参照すべき）、v3.1が最低ライン（v4.0のデータが無い脆弱性では適合製品がv3.1を受け入れなければならない）。レガシー版のv3.0とv2.0は適用範囲に日付の線が引かれ、v3.0はNVDが全CVEにv3.1ガイダンスを適用した2019年9月10日より前に公開された脆弱性のみ、v2.0はNVDが新規v2.0ベクタの生成を停止した2022年7月13日より前のみです。
版の判定方法も規定されました。適合製品はベクタ文字列の接頭辞（CVSS:4.0/、CVSS:3.1/、CVSS:3.0/）から版を識別しなければならず、別の版のラベルを黙って付け替えてはなりません。接頭辞が無いベクタはv2.0として扱います。同じ脆弱性に複数の版のベクタがある場合の優先順位は v4.0 > v3.1 > v3.0 > v2.0 です。
この規定に直接抵触するのが、v2.0スコアをv3系の値に読み替えて保持するような既存の変換処理です。自社でSCAPコンテンツを生成しているなら、スコアを出力する箇所で版・ベクタ文字列・出典の3点を記録するよう実装を変えておくべきです。仕様上の強度はSHOULD（推奨）ですが、後から出典をたどれなくなる実装が多いため、必須運用として扱ったほうが安全です。
電子署名要件の改定：署名が覆う対象の限定
改定の中身は、1つの署名が何を保証するのかの限定です。SP 800-126r4 §3.10.3は、各<ds:Signature>が「ソースデータストリームコレクションのルート要素」か「単一のデータストリーム」のちょうど一方だけを対象とすることを求めています（SHALL）。後者の場合は、参照する各ローカル構成要素への同一文書参照を並べるか、署名内に<ds:Manifest>を置いて構成要素ごとの参照を持たせます（外部の構成要素は省略可）。コレクション全体に1つ署名を打って済ませていた運用は、データストリーム単位で配布し直す際に署名構造の作り替えが要ります。
後方互換の打ち切りとOVAL 5.12系への移行
SCAP 1.4はSCAP 1.1および1.0との後方互換要件を持ちません。10年以上前のデータストリームを読める必要がなくなったぶん実装は軽くなりますが、古いコンテンツを保持している組織は変換または再作成が必要です。
OVALは5.12.xが承認されました。附属書SP 800-126Ar4は、スキーマの配布場所としてGitHubのOVAL-Community/OVALリポジトリのv5.12.3（2026年6月6日リリース）を指しています。OVALのスキーマ配布がNISTのサイトではなくコミュニティのGitHubリポジトリを正としている点は、既存の解説がMITRE時代のURLを載せたままになっていることが多いので注意が必要です。
ここにも版のねじれがあります。OVALコミュニティは2025年1月24日にOVAL 6.0を出していますが、2026年6月のSCAP 1.4が承認したのは5.12.x系でした。5.12系も6.0の後にv5.12.1（2025年6月）、v5.12.2（2025年12月）、v5.12.3（2026年6月）と更新が続いており、上流でも6.0への一本化は起きていません。SCAPコンテンツを書く際に見るのは6.0ではなく5.12系のスキーマです。
OpenSCAPによるスキャン実行とコンテンツの調達
SCAPは仕様なので、実際に評価を回すにはスキャナとコンテンツが要ります。Linux環境で標準的に使われるのがOpenSCAP（oscapコマンド）と、SCAP Security Guideとして配布されるコンテンツです。
SCAP Security Guide（ComplianceAsCode）の入手とプロファイル確認
スキャナ本体は、RHEL 8以降・CentOS 8以降・Fedoraならdnf install openscap-scanner、Debian 12・Ubuntu 24.04以降ならapt install openscap-scannerで入ります（それ以前のDebian系はlibopenscap8）。
チェック項目そのものは自分で書かず、既存のコンテンツを使うのが現実的です。SCAP Security GuideはComplianceAsCode/contentプロジェクトとして開発され、最新リリースはv0.1.81（2026年6月1日）。RHEL、Ubuntu、SUSE、Fedoraなど主要ディストリビューション向けのデータストリームが同梱され、その中にCIS Benchmark、DISA STIG、PCI-DSSなどのプロファイルが入っています。
dnf install scap-security-guideで導入すると、データストリームは/usr/share/xml/scap/ssg/content/配下に置かれます。まずoscap infoで、そのファイルに含まれるプロファイルIDを確認します。
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xmlOpenSCAP 1.4.4ではoscap infoがプロファイル内のルールと変数まで一覧できるようになりました。適用範囲を事前に把握してから評価に進めます。
oscap xccdf evalでの評価とHTMLレポート出力
プロファイルIDが分かったら評価を実行します。結果XMLと人が読むHTMLレポートを同時に出す形が基本です。
oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
--results result.xml \
--report report.html \
/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml修正まで自動化する場合は--remediateを付けるか、oscap xccdf generate fixで修正スクリプトを生成します。OpenSCAP 1.4.0以降は--fix-type kickstartでキックスタートファイルも生成でき、OSインストール時点から基準を満たした状態にできます。
注意点として、OpenSCAP 1.4.0でcve・cvss・cvrfモジュールと、sds-compose・sds-add・sds-split・rds-create・rds-splitの各データストリームサブコマンドが削除されました。古い記事の手順をそのままコピーすると存在しないサブコマンドを叩くことになります。
Windows環境の非対応と代替手段
OpenSCAPは1.3系でWindows対応を導入しましたが、公式リポジトリのdocs/windows.mdは、Windows上のスキャナ機能について不具合の調査・解決・修正を行わないと明言しています。「まがりなりにも動く最後のリリースは1.3.4」というのが公式の記述で、導入以降ほとんど保守されずコードベースが劣化した、と説明されています。現在の1.4系でWindowsサーバをスキャンする前提は成り立ちません。
Windows中心の環境では、SCAP対応を謳う商用スキャナか、グループポリシーとMicrosoft Security Compliance Toolkitの組み合わせを選ぶことになります。SCAPの識別子やCVSSスコアの考え方は流用できても、OSSツールチェーンはそのまま持ち込めません。
仕様1.4・OpenSCAP 1.3・NIST検証1.2というバージョンの段差
OpenSCAPのマニュアル（docs/manual/manual.adoc）は「OpenSCAP supports SCAP 1.3」と記載しており、対応を宣言しているのはSCAP 1.3です。OVALは1.4.3（2025年11月23日）でOVAL_SUPPORTEDが5.11.3に上がった段階で、SCAP 1.4が承認した5.12.xには届いていません。GitHubリポジトリの説明文は「NIST Certified SCAP 1.2 toolkit」のままで、NISTの検証プログラムで通っている版はさらに古いことになります。
| 層 | 対象 | 版 | 時点 |
|---|---|---|---|
| 仕様 | NIST SP 800-126r4 | SCAP 1.4 | 2026年6月 |
| 仕様（OVAL） | OVAL-Community/OVAL | 5.12.3（6.0も並存） | 2026年6月6日 |
| 実装 | OpenSCAP | 1.4.4／SCAP 1.3対応・OVAL 5.11.3 | 2026年 |
| コンテンツ | ComplianceAsCode/content | 0.1.81 | 2026年6月1日 |
| 第三者検証 | NIST SCAP Validation | SCAP 1.2（リポジトリ表記） | 検証日は未公表 |
意味は明確です。SCAP 1.4の新規定（OVAL 5.12スキーマ、CVSS v4.0優先）に沿ってコンテンツを書くと、手元のOpenSCAPでは読めない可能性があります。当面は配布済みのSCAP Security Guideをそのまま使い、1.4固有の記述は自作コンテンツで慎重に扱うのが安全です。
SCAP導入の判断基準：向く環境と、投資が回収できない環境
SCAPを入れる価値があるのは、同一構成のLinuxサーバが継続的に増減し、かつ設定基準への準拠を外部に証明する必要がある環境です。官公庁・金融・医療でSTIGやCIS Benchmarkへの準拠を求められる案件や、ゴールデンイメージを配布して台数が伸びる案件では、判定ロジックを標準形式で持つ効果が投入工数を上回ります。
逆に、次の条件に当てはまるなら採用を見送るべきです。第一に、サーバの大半がWindowsの環境。前述のとおりOSSツールチェーンが実質使えず、商用製品の購入が前提になるため、SCAPそのものを目的にする意味が薄れます。第二に、インフラがマネージドサービス中心の環境。EC2にOSを載せて運用しているならSCAPは効きますが、構成の実体がクラウド側のリソース設定にあるなら、AWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断を実装者目線で解説【2026年時点】で扱っているような設定評価の仕組みのほうが素直に噛み合います。第三に、目的がアプリ依存ライブラリの脆弱性検出である場合。SCAPのOVAL定義はOSパッケージとシステム設定の検査を主眼に置いており、npmやpipの依存ツリーを追う設計ではありません（後述のSCAの領分）。
台数が10台に満たず構成もばらばらな環境では、SCAPコンテンツの整備とプロファイルのテーラリングにかかる手間が回収できません。その規模ならAnsibleのplaybookと定期的な差分確認のほうが実効性があります。
名前が似ている「SCA」「Rustのscapクレート」との区別
紛らわしい名前が2つあります。ひとつはSCA（Software Composition Analysis）で、アプリが依存するOSSライブラリを解析して既知脆弱性とライセンスを検出する手法です。CVEを参照する点は共通しますが、SCAPがOSの設定と適用済みパッケージの状態を評価するのに対し、SCAはマニフェストとロックファイルを起点にします。監査対象のレイヤーが違うため、一方で他方を代替できません。
もうひとつは、Rustのクレートレジストリcrates.ioで公開されているscapという名前のクレート。こちらは画面キャプチャ用のライブラリで、セキュリティ標準とは無関係です。「scap rust」で検索した場合はこのクレートを指していることがほとんどです。
よくある質問
SCAPの日本語名は何ですか？
IPAは「セキュリティ設定共通化手順」という訳語を当てています。ただし解説ページ（セキュリティ設定共通化手順SCAP概説）は最終更新が2015年7月22日で、SCAPを6つの標準仕様の集合として説明しています。構成要素の数や各仕様のバージョンはNIST SP 800-126r4を参照してください。
SCAPの最新バージョンはどれですか？
SCAP 1.4です。技術仕様書のNIST SP 800-126r4と、構成仕様のバージョン更新を定める附属書SP 800-126Ar4が2026年6月に確定版として公開されました（NIST Editorial Review Boardの承認は2026年4月23日）。1.3の仕様書はSP 800-126 Rev.3です。
SCAP v2（2.0）はどうなったのですか？
NISTのプロジェクトページは現在も存続していますが（作成2018年12月17日、更新2026年4月13日）、記載は「SCAP v2はSCAP 1.x系の刊行物に対する大規模な更新である」という位置づけの説明にとどまり、確定した仕様書は公開されていません。2018年のホワイトペーパーを根拠に「v2が出ている」と書いた記事もありますが、適合性を判断する基準は現時点でもSCAP 1.4です。
OpenSCAPはWindowsで使えますか？
実質使えません。OpenSCAPの公式ドキュメント（docs/windows.md）は、開発チームがWindows上のスキャナ機能の不具合を調査・修正しないと明記しており、まがりなりにも動作する最後のリリースは1.3.4だとしています。Windows対応は1.3で導入されたものの以降ほとんど保守されず、コードベースが劣化したという説明です。Windowsサーバの設定監査には別の手段を選んでください。
OCILとは何ですか？
Open Checklist Interactive Languageの略で、SCAP 1.4に含まれる言語仕様のひとつ（版は2.0）です。OVALがシステムを機械的に検査するのに対し、OCILは人への質問や他システムに蓄積されたデータの参照によって情報を集める検査を記述します。「運用手順書が年1回レビューされているか」のように、コマンドでは判定できない項目をチェックリストに組み込むために使います。
SCAP Security GuideとOpenSCAPは何が違いますか？
OpenSCAPはスキャナ（実行するプログラム）、SCAP Security Guideはチェック項目のコンテンツ（評価される中身）です。OpenSCAPだけ入れても評価対象の基準が無いため何も判定できません。パッケージ名はscap-security-guideで、入れるとデータストリームが/usr/share/xml/scap/ssg/content/に配置されます。
