OSCAL.io — SSP の継承関係をたどれる Content Registry と Viewer

2026年5月20日の NIST OSCAL Monthly Workshop（第43回）で、Easy Dynamics の CTO である Pirooz Javan さんは、一つの Viewer に profile、SSP、assessment results を次々と読み込ませました。すると Viewer は参照先の catalog や別の SSP まで取得し、文書をまたいで統制実装を表示しました。^{1 2}

使ったのは OSCAL.io の Content Registry と Viewer です。SSP（システムセキュリティ計画）が別の SSP から統制実装を継承し、assessment results が assessment plan や profile を参照するなら、評価者は文書どうしのつながりまで確認しなければなりません。今回のデモは、あるツールで作った OSCAL を別のツールが同じ意味で読めるか試すものでした。

3行サマリー

• OSCAL Viewer はブラウザ上で OSCAL JSON を開き、profile から catalog、SSP から継承元 SSP といった文書間の参照をたどれる
• Content Registry は7種類の OSCAL モデルを公開・検索・再利用するための保管場所で、Viewer から直接開ける
• デモでは架空の連邦システムを使い、クラウドや認証基盤など4つの認可済みシステムから統制実装を継承する SSP を検証した

OSCAL Viewer の参照解決

OSCAL は、catalog、profile、SSP、assessment plan、assessment results などを別々の文書として持ち、参照で結びます。たとえば profile は catalog を取り込み、SSP は profile を取り込みます。assessment results まで進めば、assessment plan、SSP、profile、catalog へと参照が連なります。Viewer はこの参照関係を有向グラフとして扱い、URL で取得できる文書を自動的に読み込みます。³

この仕組みが必要になる理由は、下流の文書が統制の全文を複製しないからです。SSP に ac-2 と書かれていても、その統制の本文やパラメーターは参照先の catalog にあります。profile による選択や調整も重ねて読まなければ、SSP の実装記述を正しく評価できません。

Viewer は OSCAL の7種類の主要モデルに対応し、ローカルファイルのドラッグ＆ドロップと URL からの読み込みを受け付けます。処理はブラウザ内で完結し、ローカルから開いた文書を保存するためのサーバーやデータベースは使いません。ソースコードも EasyDynamics/oscal-viewer で MIT ライセンスのもと公開されています。⁴

ただし、対応するファイル形式は発表時点でも現在の案内でも JSON に限られます。JSON、XML、YAML の三形式を定める OSCAL 仕様のすべてを表示できるわけではありません。また、発表では新しい mapping モデルへの対応は今後の課題とされていました。ここは「どんな OSCAL ファイルでも開ける」と広く受け取らないほうがよいでしょう。

Content Registry と文書間参照

Content Registry は OSCAL 文書をモデル別に検索し、公開・共有するためのサービスです。サンプルを集めるだけでなく、文書間参照を実際に動かすための置き場所にもなります。

ローカルに profile と catalog を並べただけでは、別の利用者や別のツールが同じ参照先を取得できるとは限りません。参照される文書を安定した URL で公開し、API から取得できれば、作成者の環境を離れても参照関係を再現できます。Registry 上の文書はそのまま Viewer で開けるため、「公開する場所」と「下流の利用者として読む場所」がつながっています。発表時点では83文書でしたが、現在の Registry には catalog、profile、component definition、SSP、assessment plan、assessment results が公開されています。⁵

公開されている実例が増えることにも意味があります。Pirooz さんは、catalog や profile に比べて SSP 以降のモデルは例が急に少なくなると指摘していました。スキーマに適合するだけでは、複数のツールが同じ構造を同じ意図で使うとは限りません。実際の文書を別のツールで開き、どの参照や記述が解釈できないかを見つけることで、書き方を揃えられます。

FSEA の継承モデル

デモ用に用意されたのは、Federal Space Exploration Administration（FSEA）という架空の政府機関です。中心となる Orion Mission Platform の認可境界には、一般向けポータルと組織間連携 API という二つの機能があります。Orion は次の4つの認可済みシステムから統制実装を継承します。

• AWS FedRAMP High 環境：計算資源、ストレージ、ネットワーク、鍵管理など
• Gemini Enterprise ICAM：職員認証、特権アクセス、アクセス権の定期確認
• Voyager Public Identity：一般利用者の本人確認とセッション管理
• Houston SOC：セキュリティ監視とインシデント対応

OSCAL の SSP には、別の認可済みシステムを leveraged-authorization として記述できます。NIST のモデル定義では、これは「統制要件を満たす能力を継承する別の認可済みシステム」であり、共通統制提供者とも説明されています。継承元は export の下で外部に提供できる実装内容を示し、利用する側は inherited で何を引き継ぐかを記述します。⁶

system-implementation:
  leveraged-authorizations:
    - uuid: <継承元を表す UUID>
      title: AWS FedRAMP High
      links:
        - rel: system-security-plan
          href: https://example.org/aws-ssp.json
 
control-implementation:
  implemented-requirements:
    - uuid: <実装要件の UUID>
      control-id: ac-2
      by-components:
        - uuid: <コンポーネント別記述の UUID>
          component-uuid: <利用側コンポーネントの UUID>
          description: アカウント管理の実装
          inherited:
            - uuid: <継承記述の UUID>
              provided-uuid: <継承元が公開した実装の UUID>
              description: 継承するアカウント管理の実装

この例は関係だけを示すために簡略化しています。Orion の SSP はクラウド側の実装説明をコピーせず、継承元の SSP と UUID で結びつきます。Viewer では Orion から4つの SSP を読み込み、どの統制実装がどのシステムから提供されているかを重ねて確認できました。

デモのダッシュボードでは、4つの継承元から提供される46件の統制実装を確認できました。さらに Voyager には、タグ付けが完了していない継承記述が1件残っていました。SSP の本文では「外部の認証サービスを利用する」と説明しているのに機械可読な継承関係が欠けている、といった不整合を評価前に探せます。

SSP の添付資料

Orion の SSP には、認可境界図、ネットワーク図、データフロー図も back-matter のリソースとして埋め込まれていました。Viewer は Mermaid や draw.io のデータを表示し、統制実装に添付された Markdown 文書も開けます。発表では、継続的モニタリング計画を特定の統制実装に結びつける例が示されました。

OSCAL の back-matter では、各リソースに UUID を付け、本文中の link から参照できます。NIST のモデル定義では、外部リソースのハッシュ値を保持する場合にも、back-matter のリソースを介して記述します。⁶ 評価者にフォルダ一式を渡して対応関係を説明する代わりに、どの統制実装の根拠資料なのかを文書内で明示できます。

スキーマ適合と解釈の違い

発表の後半では、CISA SCuBA、CIS Benchmarks、STIG といったセキュリティ設定ガイドを assessment plan に変換する例も紹介されました。チェック手順を assessment plan の task として表し、自動評価の結果を assessment results に残す流れです。ここでも Registry に置いた文書を Viewer が参照し、評価対象の SSP や profile、catalog までさかのぼります。

Pirooz さんが繰り返していたのは、組織ごとの独自プロパティを増やすより、まず OSCAL が標準で用意する構造を揃えて使うことでした。同じ JSON Schema を通過する二つの文書でも、実装者が props に独自の意味を持たせ、標準の構造を別々の方法で使えば、受け取ったツールは解釈できません。

このため OSCAL.io の Content Registry と、OSCAL 拡張の名前空間を管理するためにコミュニティで検討されているレジストリは別物です。今回紹介された Registry は OSCAL 文書を保管・共有するサービスであり、拡張仕様を登録する仕組みではありません。Easy Dynamics は拡張の実例が増えれば対応を検討するとしつつ、当面は標準の構造を使った文書間の相互運用を優先しています。

日本での試し方

日本で OSCAL を使う場合も、最初から大規模な作成基盤を整える必要はありません。自社で作った SSP や component definition を、作成に使ったツールとは別の Viewer で開いてみるだけでも確認できることがあります。profile と catalog の参照先が解決できるか、統制 ID から本文へ移動できるか、継承元と継承内容が対応しているか、添付資料が統制実装からたどれるかを見るのです。

特にクラウドサービス、ID 基盤、監視サービスを組み合わせるシステムでは、責任分界の説明が複数の文書に散らばりやすくなります。FSEA の例は米連邦政府向けですが、「外部サービスが提供する統制実装を、自社システムがどう引き継ぐか」という問いは日本のクラウド利用にもそのまま持ち込めます。

紙の文書を JSON に置き換えただけでは、OSCAL の相互運用性を確認したことにはなりません。作成者の手元を離れた文書を別のツールで読み、参照先と継承関係を同じ意味で再構成できるか。OSCAL.io なら、そのテストをブラウザだけで始められます。