OSCAL カタログをサイバーセキュリティの外でも使う — Easy Dynamics が示した Federal PKI への適用と GUI 編集ツール Comply0

OSCAL カタログという言葉は、たいてい NIST SP 800-53 のような統制ベースのコンプライアンスフレームワークと一緒に語られます。2025年4月16日に開かれた NIST OSCAL Monthly Workshop（第34回）^{1 2 3} では、その認識を意図的に広げる議題が取り上げられました。Easy Dynamics の Pirooz Javan さん（CTO）、独立コンサルタント Brian Ruf さん（同社の OSCAL 案件を継続的に支援）、Juan Risso さん（リードソフトウェアエンジニア）の3人が「OSCAL カタログはサイバーセキュリティに限らず『要件と評価のひと組』が成り立つあらゆる領域に使える、汎用の容れ物として設計されている」という主張から始めていました。

セッションは前半が概念整理で、後半が彼らが開発中の OSCAL 編集ツール Comply0⁴ のライブデモという二本立てでした。今回は、その「カタログを広く使う」という主張がどこまで具体的なものなのか、そして OSCAL を JSON で直接書かずに済ませる編集ツールがどのような形に着地しつつあるのかを順に追います。

3行サマリー

• OSCAL カタログは「要件 → 実装 → 評価」というループが成り立つあらゆる領域に適用できる設計で、サイバーセキュリティ統制はその応用先の一つでしかないという整理
• 実例として Federal PKI（米連邦政府の公開鍵基盤）の証明書ポリシーを取り上げ、文書中の一節を statement / assessment-objective / assessment-method という OSCAL の構造に落とすパターンを示した
• Easy Dynamics は OSCAL を JSON で直接書かずに編集できる GUI ツール Comply0 を開発中で、UI 操作だけでなく REST API、さらに既存の Excel シートからのバルクアップロードまでを通せる作りになっている

Easy Dynamics の立ち位置を押さえておく

発表内容を評価するうえで、Easy Dynamics がコミュニティに対してどう関わってきたかを知っておくと、何が彼らならではの主張で、何が業界の共通認識なのかが見えやすくなります。

Easy Dynamics はバージニア州マクリーンに本社を置くシステムインテグレーターで、米連邦政府向けの FISMA（Federal Information Security Modernization Act、米連邦情報セキュリティ近代化法）対応や Federal PKI 監査、デジタルアイデンティティ評価などを手掛けてきました。OSCAL コミュニティとの関わりも長く、Pirooz さん自身が冒頭で挙げていたように、ATO as Code プロジェクトへの参加、OSCAL React Component Library と OSCAL REST API 仕様の公開（2021年）、OSCAL Editor の Docker イメージ提供、そして OSCAL コンテンツのレジストリと閲覧機能を持つ OSCAL.io の運営など、複数の地ならしを継続してきています⁵。米国大西洋岸中部（ワシントン DC 周辺）の実務者コミュニティ Mid-Atlantic OSCAL Community（約140名規模）の取りまとめ役でもあります⁴。

Brian Ruf さんは Easy Dynamics 出身の OSCAL 専門家で、現在は独立コンサルタント RufRisk として活動しつつ Easy Dynamics の OSCAL 関連案件を支援しています。後に OSCAL Foundation の活動にも深く関わっていきますが、この発表時点では Easy Dynamics 寄りの整理を Brian さんが、ツール側のデモを Pirooz さんと Juan さんが担当する構図でした。

OSCAL という4語をもう一度ばらして読む

Brian さんが最初に置いたのは、OSCAL という頭字語を一語ずつばらして意味を確認する話でした。

Open は NIST 標準であるという以上の意味を持っていて、「特定ベンダーの独占がない、誰でも自由に使えるオープン仕様」という宣言だと整理されていました。OSCAL の各モデルが特定の商用ツールに縛られていないことが、結果として後で出てくる「ツール間で OSCAL を渡し合う」発想を成立させる前提になります。

Security Controls は、要件の定義と実装が分けて語れるという OSCAL の世界観を象徴しています。Brian さんは「コントロールには定義と実装の二面がある。定義は要件記述、実装は誰かがその要件に沿って作ったもの」と言い直しており、本人もそのつもりで OSCAL カタログ＝要件定義の置き場、OSCAL SSP（System Security Plan、システムセキュリティ計画書）や Component Definition＝実装記述の置き場、という対応で語っていました。

Assessment Language は、定義と実装に加えて「第三者が要件に対する実装の適合を評価する」段階まで含めた語彙が用意されている、という意味でした。OSCAL の Assessment Plan / Assessment Results / POA&M はその評価サイクルを記述するためのモデル群です。

ここまでをまとめると、OSCAL とは「要件 → 実装 → 第三者評価」というひと続きの活動を、機械可読な共通形式で表現するための言語のセットだという理解になります。Brian さんはこの定義を、後半でサイバー以外の応用に飛ばすときの根拠として何度も引き戻していました。

OSCAL カタログを同心円で捉え直す

Brian さんは OSCAL の世界を同心円として整理して見せました。中心から外に向かって、OSCAL 仕様とツール群 → OSCAL カタログ（要件） → 実装 → 第三者評価 → 結果を受け取って判断するステークホルダー、という順で広がっていく構造です。

この同心円は「どの領域でも変わらない汎用構造」だ、というのが Brian さんの主張の核でした。ところがこの構造を別の領域に持ち込んでも、構図はそのまま成立する、というわけです。

スライドでは具体例として、ANSI 規格に基づくボルトの強度要件、SDS（Safety Data Sheets、安全データシート）に基づく化学物質の取り扱い要件、Federal PKI の証明書ポリシー、金融業界の取引処理要件、建築基準法系の要件などが挙げられていました。たとえば ANSI のボルト規格なら、要件は「このボルトはこの荷重に耐えること」、実装はメーカーが選ぶ素材と製造プロセス、第三者評価は試験ラボの強度試験、ステークホルダーはそのボルトを使う建設会社、という分担になります。

Brian さんの主張の根拠は、OSCAL がもともとサイバーセキュリティ専用の言語として切り出されたわけではない、という点にあります。実際 OSCAL の語彙には NIST SP 800-53 特有の語はほとんど含まれておらず、control、statement、parameter、assessment-objective、assessment-method といった汎化された名前で構成されています。Brian さんが意図していたのは、この汎化を額面どおりに受け取って業界をまたいで使ってみよう、という呼びかけでした。

実例として Federal PKI ポリシーを OSCAL に落とす

抽象論だけでは伝わりにくいので、スライドの中で具体的に取り上げられたのが Federal PKI 証明書ポリシーの一節です。この OSCAL 化の作業は、長年 Federal PKI に関わってきた Rob Sherwood さんの貢献で、Easy Dynamics の Comply0 にも実際にカタログとして取り込まれていました。

Federal PKI は GSA（General Services Administration、米連邦調達庁）が管理する公開鍵基盤で、米連邦政府機関とその取引相手が同じ証明書の信頼基盤を共有するための制度です。その運用ルールを定めるのが Federal PKI Certificate Policy という文書で、Section 2.2.2「Publication of CA Information」では、認証局や関連組織が次の3点を一定の場所に公開せよ、と要求しています。

1. 証明書ポリシー本体は idmanagement.gov で一般公開すること
2. 同じ場所で、Federal Common Policy CA の証明書実施規程（CPS、Certification Practice Statement）と年次の PKI コンプライアンス監査結果書（PKI Compliance Audit Letter）を公開すること
3. 各組織は、自分が運用する認証局に関する情報（編集済みの CPS と監査結果書）を、組織の公開リポジトリに掲載すること

評価担当者はそれぞれの公開状況を実地検査（INSPECT、いわゆる「目で確認する」）で点検します。要件ごとに対応する評価目的があり、評価方法はすべて INSPECT、対象は対応する公開ウェブサイトという形です。

これを OSCAL に置き換えるときに重要なのが、文書中の一文一文に必ず識別子を振り、評価目的と評価方法もそれぞれ独立した要素として持たせる、という分解です。スライドでは中間ステップを挟みつつ、OSCAL JSON に落とした形を示していました。ここでは最小骨格だけ取り出すと次のような構造になります。

{
  "id": "fpki-2.2.2",
  "title": "Publication of CA Information",
  "props": [
    { "name": "label", "value": "2.2.2" }
  ],
  "parts": [
    {
      "id": "fpki-2.2.2_smt",
      "name": "statement",
      "parts": [
        { "id": "fpki-2.2.2_smt_1", "name": "item", "prose": "This CP must be publicly available on https://www.idmanagement.gov/." },
        { "id": "fpki-2.2.2_smt_2", "name": "item", "prose": "The CPS and annual PKI Compliance Audit Letter ... are publicly available on https://www.idmanagement.gov/." },
        { "id": "fpki-2.2.2_smt_3", "name": "item", "prose": "Other CAs operating under this policy should make available a redacted CPS ..." }
      ]
    },
    {
      "id": "fpki-2.2.2_obj_1",
      "name": "assessment-objective",
      "prose": "Ensure the Federal PKI Certificate Policy is published in the appropriate location.",
      "links": [{ "rel": "assessment-for", "href": "#fpki-2.2.2_smt_1" }]
    },
    {
      "id": "fpki-2.2.2_asm",
      "name": "assessment-method",
      "props": [{ "name": "method", "value": "EXAMINE" }],
      "parts": [
        { "name": "assessment-objects", "prose": "https://www.idmanagement.gov/" },
        { "name": "assessment-objects", "prose": "organizationally identified public repository" }
      ]
    }
  ]
}

ポイントは三つあります。一つ目は、人間の文書では1段落で済む内容が、OSCAL では id を持つ複数の item に分解されることです。これは後で評価結果を「どの一文に対する所見か」まで遡れるようにするための識別子です。二つ目は、評価目的が assessment-for というリンクで対応する item を指し、評価方法が EXAMINE のような統制された値で記述されることです。三つ目は、assessment-objects で「どの実物を見にいくか」を文字列で持ち、ここに idmanagement.gov のような URL や「組織の公開リポジトリ」のような抽象的な場所まで入ることです。

NIST SP 800-53 を扱ったことのある人にはおなじみの形ですが、これがサイバーセキュリティ統制ではない Federal PKI のポリシー文に対してもそのまま当てはまる、という事実が、Brian さんが「OSCAL カタログは汎用」と主張する具体的な裏付けになっていました。

なぜわざわざ機械可読化するのか

ここまで来て読み手が抱きやすいのが「Word 文書のままで何が困るのか」という素朴な疑問です。Brian さんはこの問いに対して、機械可読化の利点を四つに整理していました。

一つ目は、要件を受け取って実装する側や評価する側にとって取り込みが容易になる点です。要件が機械可読な構造で配布されれば、それを取り込むツールを誰でも開発できます。二つ目は、人間向けの出力への逆変換がしやすい点で、OSCAL を正本に据えれば HTML、Word、Excel、PDF などへの書き出しは機械的に作れる一方、逆に Word から OSCAL を作るのは大幅に手作業が増えます。三つ目は、要件側が機械可読になると、実装側の応答（implementation statement）も機械可読で書く土台が成り立つ、という点。四つ目は、評価側の所見（assessment result）まで機械可読化が広がると、要件・実装・評価の三者を ID で対応づけて見られるようになる、ということでした。

Brian さんが最後にまとめていたのは、「機械可読化していなくても評価作業はできるが、人手で複数文書を照合しなければならない。OSCAL で揃えれば、ツールが要件と実装と評価を1画面で並べて表示できる」という言い方です。サイバーセキュリティ以外の領域でも同じ効用が出るはずだ、というのが彼の主張でした。

OSCAL を JSON で書かずに済ませる Comply0

理屈はわかっても、現場の人に「では OSCAL JSON を直接書いてください」と頼むのは現実的ではありません。Pirooz さんがここから紹介したのが、Easy Dynamics が開発している OSCAL 編集プラットフォーム Comply0 でした⁴。発音はそのまま「コンプライ・ゼロ」で、Easy Dynamics の資料では 0 を数字のまま使った「Comply0」表記が公式です。

Comply0 が掲げている設計方針は三つです。一つ目は API ファーストで、REST API を先に設計してその上に UI を被せる構成にしているため、UI で実現できることは原理的にすべて API でも実現できます。二つ目は OSCAL ネイティブで、データを内部で OSCAL JSON のまま保持し、すべてのトランザクションで OSCAL スキーマに対する検証を回します。三つ目は OSCAL 仕様の進化に追随する方針で、props や links などの拡張領域も含めて忠実に扱える「高忠実度の OSCAL」を維持できるよう作られています。

デモではまず空のカタログを作るところから始まりました。Pirooz さんは画面上で「NIST Workshop Digital Identity Guidelines v3.0」というカタログを新規作成し、その中に Key Management（KM）というグループを置き、Key Generation Entropy というネストした統制を作ります。ここで Markdown 記法で statement と guidance を書き、評価目的と評価方法（EXAMINE）を追加し、112-bit symmetric のような数値を組織定義パラメータ（Organization-Defined Parameter）に差し替え、2048 を「2048 か 4096 から選ぶ選択型パラメータ」に置き換える、という作業が専用のドロワー UI で完結していました。出来上がったカタログを JSON として書き出すと、controls と parts と params がきれいに揃った OSCAL カタログが手元に保存される、というのが最初のデモの締めです。

続いて Pirooz さんは、すでに OSCAL 化されている既存カタログを11本まとめてインポートして見せました。米 SP 800-53 Rev 5 High、Federal PKI（X.509 ポリシー）、オーストラリアの情報セキュリティマニュアル、シンガポールのセキュリティマニュアルなどを並べると、それぞれが OSCAL の groups と controls をどう違う使い方で扱っているかが画面上で比較できます。シンガポール版は一部修正が必要で Easy Dynamics 側からプルリクエストを送ったとのこと。「同じ仕様の上でこれだけ表現の幅が出る」という現状がそのまま見える形になっていました。

REST API と Excel スプレッドシートを橋渡しする

Juan さんが受け持った後半のデモは、Comply0 の API 側を実際に叩いてみる内容でした。先ほどの空カタログに対して、Excel に整理されていた統制の一覧を REST API 経由で流し込むと、ブラウザで該当カタログを開き直したときに統制群が一気に追加されている、というところまでが API デモの第一段です。

第二段で Juan さんが見せたのが、同じ ID を持つ統制を二重に登録しようとするとサーバー側のバリデーションで弾かれる挙動でした。OSCAL の id は本来 token 型で、同一スコープ内で重複してはいけないことになっています。Comply0 はこのルールを API レベルで保証しているので、入力経路がどうであれ OSCAL として壊れたデータを書き込めない、という設計でした。

最後に Brian さんに戻り、Easy Dynamics が以前から内部で使っていたという Excel スプレッドシートが紹介されました。これは NIST SP 800-63B の本文を、シート上で「id、title、statement、guidance、assessment-objective、assessment-method」の列に人手で分解して埋めたものです。もともとは VBA で直接 OSCAL XML / JSON を書き出すスクリプトを背負っていましたが、Comply0 ができてからは「API 経由で送る」ボタンを追加して、シートの内容を1回のクリックで API に流すように作り替えていました。デモでは800-63B から約200の統制を約30秒でアップロードし、画面側で順次表示されていく様子を見せ、最後にエクスポートした OSCAL JSON を Oxygen エディタに入れて、NIST の OSCAL v1.1.3 スキーマで全文が緑（バリデーション成功）になる、という締めでした。

このスプレッドシート + API の組み合わせは、地味ですが現場感のある工夫です。Word の文書を担当者にそのまま OSCAL にしてくれと頼んでも続きませんが、列ごとに「ここに本文を、ここに評価目的を貼り付けて」と作業を分解した Excel なら、非エンジニアであるコンプライアンス担当者にとっても日常業務の延長で扱えます。そのうえでツール側が API で受け取って OSCAL に成形する、という分担は、JSON や XML を直接書かない人を OSCAL の入り口に立たせるための現実解になります。

日本から見たとき

日本のセキュリティ・コンプライアンス実務者の立場で見ると、OSCAL カタログをサイバーセキュリティ統制以外の要件文にも使える、という発想がまず目に付きます。ISO 27001、ISMAP、政府情報システム統一基準、業界別ガイドライン、社内規程など、要件と評価がひと組になった文書は日本にも多く、大半は Word・Excel・PDF のままです。社内規程の要件文に ID を振り、評価目的と評価方法を併記して、年次の内部監査結果と紐づける、といった使い方は十分考えられます。

Comply0 のような GUI 編集ツールが出てきたことも無視できません。これまで OSCAL を触る手段は CLI、JSON の直書き、自前スクリプトに偏りがちで、非エンジニアであるコンプライアンス担当者の手元には届きにくかった。Comply0 がどこまで広がるかはこれからですが、GUI でカタログを編集できる商用級のプラットフォームが増えれば、その分だけ現場のハードルは下がります。

Excel と API を組み合わせるやり方も、日本の現場には合いそうです。「JSON を書け」と頼むより、「列を分けた Excel に入れてボタンを押す」ほうが通りやすいチームは多いはずです。

Easy Dynamics の OSCAL 関連リソース（OSCAL.io レジストリ、OSCAL Viewer、OSCAL REST API 仕様、各種 OSS）は easydynamics.com と OSCAL.io から辿れます。Mid-Atlantic OSCAL Community も同じ窓口で告知されていますが、現地参加が前提です。Comply0 は記事執筆時点ではプレビュー段階で、商用提供のロードマップは Easy Dynamics の OSCAL 紹介資料に SSP・コンポーネント定義・POA&M を順次追加していく計画が書かれています⁴。