FedRAMP の提出物を OSCAL でどう書くか — OSCAL Foundation が引き受けた業界主導の作業

米連邦政府向けクラウドのセキュリティ認可制度である FedRAMP が、Word や Excel での書類提出から機械可読な認可パッケージへと舵を切ろうとしています。2026年4月15日に開かれた NIST OSCAL Monthly Workshop（第42回）^{1 2} で、OSCAL の普及を担う非営利団体 OSCAL Foundation の Brian J. Ruf さんと Stephen Banghart さんが、その移行を業界側でどう具体化しているかを公開しました。

注目したいのは、これが技術レベルの話ではなく、FedRAMP の認可プロセスそのものの作り方が「政府が定義する」から「業界が定義したものを、政府が受け取る」へと一段階シフトした瞬間でもあったことです。今回の発表は、その新体制で OSCAL Foundation が最初に出した成果物の中身に関するものでした。

3行サマリー

• FedRAMP PMO は OSCAL の具体形を業界に委ね、OSCAL Foundation がその要請を受けて作業を進めている
• 第一段階は SSP（システムセキュリティ計画）に絞り、既存事業者向けの Retrofit と新規向けの Native という二つの導入経路を提示している
• ベースラインや SSP サンプル、執筆ガイドは OSCAL-Foundation/fedramp-resources と Foundation のパターンライブラリで公開済み

FedRAMP の前提を少しだけ

FedRAMP（Federal Risk and Authorization Management Program）は2011年に米 OMB（Office of Management and Budget、米行政管理予算局）の通達で発足した、連邦政府機関が利用するクラウドサービスの共通セキュリティ認可制度です。長らく通達ベースで運用されてきましたが、2022年成立の FedRAMP Authorization Act によって法律として正式に位置づけられ、運用主体である FedRAMP PMO（Program Management Office、プログラム管理事務局）は GSA（General Services Administration、米連邦調達庁）の中に置かれました。

この制度の現代化を促したのが、2024年7月25日に発出された OMB Memorandum M-24-15³ です。M-24-15 は認可資料の機械可読化を明確に求めており、発出から18か月以内（2026年1月25日まで）に GSA は機械可読な手段で認可資料を受け取れるようにし、24か月以内（2026年7月25日まで）に各連邦機関も自分たちの GRC ツールで OSCAL またはその後継プロトコルの取り込みと出力ができるようにする、という二段構えのデッドラインを設定しました。

今回の発表で語られた OSCAL Foundation の作業は、このスケジュールを Rev 5 側で正面から実装するための土台づくりです。

OSCAL と FedRAMP のこれまで

発表の冒頭で Brian さんがコンパクトにまとめてくれた経緯を、補足を加えて並べ直すとこうなります。

NIST と FedRAMP の協業は2018年に始まりました。2021年に OSCAL 1.0 が公開され、翌2022年5月には AWS が業界初の OSCAL 形式 SSP を FedRAMP に提出します。Brian さんは「2022年から最初の OSCAL 提出があった」と話しており、その後しばらくは目立った進展のない時期が続きます。2024年には GSA と FedRAMP PMO が改めて OSCAL に注力する「フレッシュスタート」の方針を打ち出しますが、2025年に新しい認可プログラム FedRAMP 20x が発表されると、PMO は OSCAL 関連の作業を一旦すべて止めます。

そして2026年、PMO の姿勢が再び変わりました。OSCAL の取り組みの具体は業界（民間）に委ねる、という整理です。発表で Stephen さんが繰り返し強調していたのは、この「業界に委ねる」という言葉の重みでした。

2025年に OSCAL の作業が止まった理由

2025年3月24日、GSA は FedRAMP 20x という新しい認可プログラムを発表します。背景にあったのは、FedRAMP 認可が長年抱えてきた滞留問題でした。300ページ規模の Word 文書を提出して人手で審査する従来のやり方では、認可取得に数年かかることも珍しくなく、これが連邦各機関のクラウド導入を遅らせる構造的な原因になっていました。

20x はそのプロセスを根本から見直し、書類提出ではなく自動化された継続的な検証データのやり取りを軸に据える、という野心的な方針として打ち出されました。ここで Rev 5 と 20x という二つの言葉を整理しておくと、Rev 5 は NIST SP 800-53 Revision 5（連邦情報システム向けセキュリティ統制カタログの第5版）に基づく従来型の認可プロセスで、現時点で唯一稼働しているルートです。20x はその Rev 5 を将来的に置き換えるべく設計された新世代のプロセスで、専用の自動化基盤を持っています。

20x のアプローチは「巨大な Word の SSP を OSCAL に変換する」という発想とは方向性が違うため、PMO は限られたリソースを 20x の構築に集中させ、Rev 5 向けに進んでいた OSCAL 関連作業を停止しました。これを Brian さんは「2025年の OSCAL Shut Down」と表現しています。

20x はその後、Low ベースラインを対象とした Phase 1（FY25 Q3〜Q4、2025年9月までに完了）、Moderate を対象とした Phase 2（FY26 Q1〜Q2、2026年3月までに完了）を経て、現在は本格適用と支援を行う Phase 3 に入っています。High ベースラインの Phase 4 はその先に控えています。

2026年に再び OSCAL に光が当たる

ところが2026年に入ると、PMO は OSCAL の取り扱いを再び変えます。背景には少なくとも二つの事情があります。

一つは、既存の認可済み事業者の多くが当面 Rev 5 のパスに残ってしまうことです。20x が Rev 5 を完全に置き換えるまでには時間がかかり、それまで Rev 5 の運用と機械可読化要件は並行して進む必要があります。もう一つは、すでに触れた M-24-15 が機械可読化を行政全体のスケジュールとして固定していることです。20x は自動化が進んでいますが、従来型の Rev 5 についても、この締切から逃れることはできません。

これを正面から実装する形で、PMO は2026年1月13日に RFC 0024「FedRAMP Rev 5 Machine-Readable Packages」⁴ を公開しました。FedRAMP の RFC は IETF の RFC とは別物で、PMO が方針案を示して業界からのコメントを募集する仕組みです。RFC 0024 は、Rev 5 の事業者が OSCAL を含む承認済みフォーマットを使って認可データを機械可読な形で生成することを正式な要件として位置づけており、コメント募集は2026年3月11日に締め切られました。

RFC 0024 が掲げる実装スケジュールは、業界にとって地味に厳しいものになっています。2026年4月15日（つまり今回の発表当日）までに FedRAMP 側が業界の採用を支える資料を公開し、2026年9月30日までに要件が発効、ここで非対応の場合は公開リストで通知されます。猶予期間は2027年9月30日まで続き、それまでに対応できない事業者は FedRAMP 認証を失う、という建て付けです。既存の認可済み事業者にとっては、次の年次パッケージ提出のタイミングからこの要件が適用されます。

ただし PMO は、OSCAL の具体的な姿そのものは決め打ちにしませんでした。Stephen さんの言葉でいうと「PMO は OSCAL を業界の手に置いた」ということで、実装する側が答えを持ってきてほしい、というメッセージです。

OSCAL Foundation がボールを受け取る

このボールを受け取ったのが OSCAL Foundation でした。Stephen さんは、自分たちが OSCAL に特化した業界団体として最も適切な立場にあるという判断のもと、PMO の要請に応える形で動き始めたと語っています。

ここで重要なのは、Foundation が単独で仕様を決めにいっているわけではない、という点です。FedRAMP PMO とは継続的に対話を持ち、Cloud Service Provider Advisory Board（CSP-AB、クラウド事業者の業界諮問委員会）や、最終的に認可パッケージを受け取る連邦各機関とも調整を続けているそうです。Stephen さんは「PMO が想定していた形と違ったとならないように、最終段階で全員が受け取れる状態に揃えておきたい」と話していました。

フェーズ分けとフィードバックの整理

Foundation の作業はフェーズで切られています。スライドによれば、Phase 0 は「チームを組成し、共有リソースを整える」段階で、こちらはすでに完了しています。現在進行中の Phase 1 が「FedRAMP SSP の OSCAL 化」で、ここに今のリソースが集中している状況です。その先の作業は需要と PMO とのやり取り次第で、20x へのマッピング、POA&M（Plan of Action and Milestones、未対応事項とその対応計画）、SAP（Security Assessment Plan、評価計画書）、SAR（Security Assessment Report、評価報告書）、隣接する制度や他のフレームワークが候補に挙がっています。

Stephen さんが OSCAL に対する業界からのフィードバックを正直に共有していたのが印象的でした。OSCAL の長所として挙がったのは、柔軟性、CMMC（Cybersecurity Maturity Model Certification、米国防総省のサプライチェーン向けサイバーセキュリティ認証）など他フレームワークとのマッピングや統制オーバーレイ（プライバシー保護用などの統制を上乗せする使い方）が扱えること、そしてオープンな業界標準であること。短所として一番繰り返し聞かれたのは「OSCAL は複雑すぎる」という声で、柔軟であるがゆえに表現がバラつきやすく、ゼロから一気に完全な OSCAL に飛び移るのは事業者にとって段差が大きすぎる、というものでした。OSCAL を扱うことができるツールがまだ十分には揃っていないという指摘も、これに重なっていました。

Retrofit と Native、そして MVP

この声に応えるために Brian さんたちが取った戦略が、段階的な採用と「MVP」（minimum viable product、最小限で動く状態）という考え方でした。これまでの OSCAL ドキュメントは「すべてが正規化された理想的な状態」を前提に書かれることが多く、Brian さん自身もその文化に長く関わってきた立場です。だからこそ今回は逆を行き、まずは最小限の機械可読化だけを目指す状態から始めるべきだ、という決断でした。

段階的に採用するといっても、出発点は事業者によって違います。すでに Word の SSP を持っている既存の Cloud Service Provider と、これから FedRAMP に取り組む新規事業者では、最初の一歩が変わってきます。Brian さんはこれを Retrofit と Native という二つの導入経路として整理していました。

Retrofit は既存 Word SSP を持つ事業者向けで、最初は中身を正規化せず、フラットなインベントリとフラットな統制応答の構造でそのまま機械可読化することから始めます。これが MVP の状態です。そこから少しずつ component（コンポーネント、SSP の構成要素を再利用可能な単位で表す OSCAL の概念）を導入し、インベントリや統制応答が component を参照する形に移行していきます。

Native は新規事業者向けで、Word の遺産がない代わりに、最初から component を意識した設計に入ります。ただし PMO の現行方針は新規システムに 20x を勧めていることもあり、Brian さんは「当面は既存事業者の Retrofit パスのほうが現実的に使われる」と話していました。

どちらの経路を通っても、最終的に到達するゴールは同じです。すべてのインベントリと統制応答が component を参照する正規化された SSP に行き着きます。違うのは、そこに至るまでの道筋だけです。

公開されているリソース

実際に手を動かして試したい人のために、OSCAL Foundation はいくつかのリソースを公開しています。中心になるのは GitHub の OSCAL-Foundation/fedramp-resources リポジトリです。

ここには FedRAMP Rev 5 の各ベースライン（HIGH、MODERATE、LOW、LI-SaaS という FedRAMP のインパクトレベル区分ごと）が JSON、XML、YAML の三形式で置かれています。OSCAL の profile 形式と、それを事前解決した resolved profile catalog の両方が手に入る作りです。Brian さんは、入門段階では resolved profile catalog を使うことで profile 解決の処理を省略でき、最初の一歩を軽くできると説明していました。ただしこれはあくまで入り口で、プライバシーオーバーレイや他フレームワークとの重ね合わせを扱うようになると、自分で profile を処理できる必要が出てきます。

SSP のサンプルも retro-mvp、new-core、NORMALIZED の三つが置かれていて、それぞれ Retrofit パスの MVP、Native パスの最初の状態、そして両方が目指す正規化されたゴールに対応しています。実際にファイルを開くと、「OSCAL の SSP ってこんな形になるのか」がかなり具体的につかめるはずです。

もう一つの柱がパターンライブラリです。Web で公開されており、構成は FedRAMP の Word SSP テンプレートのセクション番号と章立てに沿っています。section 1 から 11 と付録について、それぞれの中身を OSCAL でどう書くかが章ごとにまとまっており、現場の人が「いま自分が書いている SSP のあの部分」を起点に引ける作りです。例示は YAML を中心にしているそうで、これも JSON より読みやすいというフィードバックを反映した選択だと話していました。発表時点ではドメインを patterns.rufrisk.com から patterns.oscalfoundation.org へ移行している最中とのことなので、最新の URL は oscalfoundation.org や Foundation の Technology Working Group 経由で確認するのが確実です。

各ページの下部には Google アカウントでログインしてコメントを残す機能もあり、フィードバックの導線も意識して作られていました。発表中で言及があった旧 GSA の fedramp-automation リポジトリは、最近公開状態から外れた可能性があるとのこと。OSCAL Foundation はフォークなどで内容を保持しているそうですが、新しい作業は fedramp-resources を見るのが安全な経路になります。

これからの予定

SSP の表現ガイドは発表時点で約85%が仕上がっており、残りも数週間で完成する見込みだそうです。SSP の次は POA&M、SAP、SAR といった、SSP と並んで認可パッケージを構成する書類に進む予定ですが、最近 FedRAMP 側から「POA&M は将来必須でなくなる可能性がある」という通知が出ており、この部分は PMO の判断と業界対話次第で形が変わってきます。

その先には FedRAMP 20x へのマッピング、CMMC、その他の FISMA（Federal Information Security Modernization Act、米連邦情報セキュリティ近代化法）系フレームワークへの展開も視野に入っています。OSCAL を FedRAMP の枠を越えて使える基盤にしていきたい、という野心が透けて見える構成でした。

日本から見たとき

米国子会社や国際展開で FedRAMP に触れる事業者にとって、OSCAL-Foundation/fedramp-resources は今後の実務の起点になりそうです。NIST 仕様だけ追っていても、現場で動いているプロファイルやサンプルがどこにあるかは見えにくい。OSCAL 化を視野に入れるなら、Foundation 側のリポジトリを一度眺めておく価値があります。

Retrofit MVP のように「まずフラットに機械可読化し、そこから少しずつ正規化していく」という段階的採用は、日本でもそのまま使えそうです。既存のセキュリティ文書を一気に OSCAL 化しようとして頓挫する、という話は国内でも起こりえます。ISMS 文書や政府情報システム統一基準にも、同じ考え方は当てはまるはずです。

OSCAL Foundation の Technology Working Group は毎週火曜の朝（米東部時間11時）に開かれ、会員でなくても参加できると Stephen さんは強調していました。FedRAMP Technology Focus Group も同様にオープンで、メーリングリストや Slack 経由で参加できます。日本から議論に入る余地は、意外とあります。

参考文献

1. NIST OSCAL Monthly Workshop #42, OSCAL Foundation 回トランスクリプト（英語）。https://csrc.nist.gov/csrc/media/Projects/open-security-controls-assessment-language/images-media/2026/oscal-monthly-workshop-42-OSCALFoundation/CAPTIONS_04.16.2026_OSCALFoundation.txt ↩

2. NIST OSCAL Monthly Workshop #42, OSCAL Foundation 回スライド PDF。https://csrc.nist.gov/csrc/media/Projects/open-security-controls-assessment-language/images-media/2026/oscal-monthly-workshop-42-OSCALFoundation/2026-04-15_OSCAL-Foundation_FedRAMP.pdf ↩

3. OMB Memorandum M-24-15「Modernizing the Federal Risk and Authorization Management Program (FedRAMP)」2024年7月25日。https://www.fedramp.gov/docs/authority/m-24-15/ ↩

4. FedRAMP RFC 0024「FedRAMP Rev 5 Machine-Readable Packages」2026年1月13日公開、コメント募集は2026年3月11日まで。https://github.com/FedRAMP/community/discussions/114 ↩