LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

規制が緩むという知らせは、受注する側にとって必ずしも楽になる知らせではありません。一律の様式が消えると、代わりに相手ごとの要求が立ち上がるためです。

米国の行政管理予算局（OMB）は2026年1月23日、覚書M-26-05「ソフトウェアおよびハードウェアのセキュリティへのリスクベースの手法の採用」を発出しました*1。ソフトウェアの自己証明を求めてきたM-22-18とM-23-16を、あわせて廃止しています*1。

受注と実装の立場から確かめたい点は4つあります。何が廃止されたのか、何が残ったのか、何が任意になったのか、取引の場では何が変わるのか。原文から順に見ていきます。

廃止の理由が、原文にはっきり書かれている

まず、覚書そのものを確認します*1。

M-26-05は、前提の確認から始まります*1。連邦の機関は、その任務を支えるために市販の既製のハードウェアとソフトウェアに大きく依存している。その結果、機関は、製品のセキュリティが確保されており、したがってますます高度化するサイバー脅威の主体による攻撃に対して回復力があることを確保するために、ハードウェアとソフトウェアの生産者に頼らざるをえないという書き出しです*1。

そのうえで責任の所在を置き直しました*1。各機関の長は、当該機関のネットワーク上での稼働を許されたソフトウェアとハードウェアのセキュリティを保証することについて、最終的な責任を負う。その結果を達成するための、普遍的で画一的な方法は存在しないとし、各機関は、セキュアな開発の原則を用い、包括的なリスク評価に基づいて、提供者のセキュリティを検証すべきであると述べます*1。

廃止の理由も明示されています*1。M-22-18について真のセキュリティへの投資よりも遵守を優先させる、実証されておらず負担の大きいソフトウェアの計上の手続を課したとし、この方針は、ソフトウェアについて機関ごとに調整された保証の要件を策定することから機関を逸らし、セキュリティが確保されていないハードウェアがもたらす脅威を考慮しなかったと述べました*1。したがって、OMB覚書M-22-18および、その付随する方針であるM-23-16は、ここに廃止されるという結びです*1。

批判の対象が2つある点に注意が要ります*1。手続の負担だけでなく、ハードウェアが視野に入っていなかったことも理由に挙げられています*1。緩和ではなく、対象の付け替えという読み方ができます*1。

廃止された仕組みは、何を求めていたのか

比較のために、M-22-18の骨格を確認します*2。

対象は第三者のソフトウェアでした*2。この覚書の目的における「ソフトウェア」という語には、ファームウェア、オペレーティングシステム、アプリケーション、およびアプリケーションのサービス（例：クラウドを基盤とするソフトウェア）のほか、ソフトウェアを含む製品が含まれるとされます*2。機関が自ら開発したソフトウェアは対象外で、施行日以後に開発されたものと、施行日後にメジャー版の変更がされた既存のソフトウェアに適用されました*2。

中核は自己証明です*2。連邦の機関は、NIST指針に記されたとおり、政府が定めるセキュアなソフトウェア開発の実務に従っていることを証明できるソフトウェア生産者が提供するソフトウェアのみを使用しなければならないとされ、使用前に生産者から自己証明を取得することが求められました*2。

代替の道も置かれていました*2。証明できない実務がある場合は、その実務を特定し、リスクを緩和するために実施している実務を文書化し、行動計画とマイルストーン（POA&M）を作らせる仕組みです*2。またFedRAMPの認定を受けた第三者評価機関（3PAO）または機関が承認した機関による第三者評価は、生産者の自己証明に代えて受け入れられるとされ、オープンソースやそれを組み込んだ製品も含むとされました*2。

SBOMは、この時点では条件付きの要求でした*2。SBOMは、M-21-30に定義されるソフトウェアの重要性に基づき、または機関の判断により、調達の要件において機関が求めることができるとされ、形式はNTIAの報告書「SBOMの最低要素」に定義されたデータ形式、またはCISAが公表する後継の指針によるものとされています*2。脆弱性開示プログラムへの参加の証跡を求めることもできました*2。

期限も細かく置かれていました*2。90日以内に対象ソフトウェアの棚卸し（重要ソフトウェアは別立て）、120日以内に要件を伝える手続の整備と証明書の一元的な収集、270日以内に重要ソフトウェアの証明書を収集、365日以内に全対象ソフトウェアの証明書を収集という並びです*2。

M-23-16が足したのは、期限と範囲の整理だった

2023年の更新は、実務の詰まりに応えるものでした*3。

第一に、期限の付け替えです*3。機関は、M-22-18および本覚書の要件の対象となる重要ソフトウェアについて、CISAが公表するM-22-18の証明の共通様式が文書業務削減法（PRA）に基づきOMBによって承認された後、遅くとも3か月以内に証明書を収集しなければならないとされ、共通様式のPRA承認から6か月後には、対象となるすべてのソフトウェアについて収集しなければならないとされました*3。日付ではなく、様式の承認を起点にした書き方です*3。

第二に、範囲の明確化です*3。機関は、機関が使用するソフトウェアの最終製品に組み込まれた第三者のソフトウェア構成要素の生産者から、証明を収集することを求められないとされました*3。理由は最終製品の生産者が、そのセキュリティを確保するのにもっとも適した立場にあるためです*3。オープンソースでも専有でも同じ扱いです*3。

連邦の契約で開発されたソフトウェアの扱いも整理されました*3。それが「機関が開発したソフトウェア」に当たるかは、要件定義、設計、開発、試験、配備、保守という開発の全ライフサイクルを通じて、契約する機関がセキュアな開発の実務が守られていることを確保できるかどうかによるとされ、判断は機関のCIOが行うとされています*3。

第三に、POA&Mの扱いです*3。生産者がPOA&Mを出し、機関がそれを満足のいくものと認めた場合、機関は使用を続けられますが、同時にOMBに対して証明の期限の延長を求めなければならないとされました*3。機関が延長の申請を提出しない場合、当該POA&Mは有効とみなされず、機関は当該ソフトウェアの使用を中止しなければならないという書き方です*3。

この3年半の積み上げが、2026年1月にまとめて外れました*1*2*3。ソフトウェアサプライチェーンのセキュリティで扱う枠組みのうち、米国政府調達を通じて広まっていた部分が、根拠を1つ失った形です。

残ったのは2つ、任意になったのは2つ

M-26-05が機関に課しているのは、短い1文です*1。

機関は、ソフトウェアとハードウェアの完全な棚卸しを維持し続け、かつ、自らのリスクの判定と任務上の必要に見合うソフトウェアとハードウェアの保証の方針と手続を策定しなければならない*1。義務はこの2つに絞られました*1。

そのうえで、選択肢が2つ示されます*1。機関は、セキュアなソフトウェア開発の自己証明様式など、M-22-18のもとで策定された政府全体のセキュアなソフトウェア開発の資源を使用することを選ぶことができる、そして機関は、ソフトウェア生産者に対し、要請に応じて最新のソフトウェア部品表（SBOM）を提供するよう求める契約上の条項を採用することを選ぶこともできるです*1。

クラウドについては脚注で粒度が指定されました*1。クラウド基盤については、そうした契約条項を採用する機関は、生産者が要請に応じて実行時の本番環境のSBOMを提供しなければならない旨を明記すべきであるとされています*1。出荷物の部品表ではなく、動いている環境の部品表を求める書き方です*1。

参照先として3つの文書が挙げられました*1。NIST SP 800-218「セキュアソフトウェア開発フレームワーク」および関連する附属書、CISA「2025年版 SBOMの最低要素」（2025年8月22日に草案の形で公表）、CISA「サプライチェーンリスク管理のためのHBOMフレームワーク」（2023年9月）です*1。

3つ目のHBOMが、この覚書の性格をよく示しています*1。ソフトウェアの部品表だけでなく、ハードウェアの部品表が並んで参照されました*1。SBOMの作成と管理を整えてきた組織にとっては、隣に同じ発想の作業が増えたことになります。

受注する側から見ると、要求は分散する

ここまでを、取引の言葉に置き換えます*1*2*3。

第一に、窓口が1つではなくなります*1。共通様式に一度記入すれば複数の機関へ同じものを出せる、という前提が外れました*1。各機関が自らのリスクの判定と任務上の必要に見合う方針と手続を作る以上、求められる形式は機関ごとに分かれうる、というのが条文の帰結です*1。

第二に、SBOMが契約の条項として現れます*1。義務ではなく採用することを選ぶことができるものになったため、法令の一覧ではなく個々の契約書を読む作業に移ります*1。とくにクラウドで提供する場合は、実行時の本番環境という粒度を出せるかどうかが論点になります*1。

第三に、ハードウェアが範囲に入ります*1。棚卸しの義務がソフトウェアとハードウェアと書かれ、参照先にHBOMのフレームワークが並びました*1。機器を含めて納める案件では、構成要素の出所を説明できる資料が求められる可能性が上がります*1。

第四に、参照される技術文書は変わっていません*1*2。NIST SP 800-218は廃止された覚書の中核でしたが、M-26-05でも参照先として挙げられています*1。SSDFに沿って整えてきた開発の実務そのものは、根拠を失っていません*1*2。

調達の枠組み全体は、別の動きとも重なっています。連邦調達規則の全面改訂ではIT調達と情報セキュリティの部が書き直されており、覚書の側だけを追っても全体像は見えません。

何を続け、何を作り直すか

最後に、実務の整理です*1。

続けるのは、部品表を出せる状態を保つことです*1。要求の根拠が法令から契約へ移っただけで、求められる中身は変わっていません*1。むしろ要請に応じてという書き方は、随時の照会に短い時間で応じられることを前提にしています*1。

作り直すのは、証明の出し方です*1。共通様式に合わせて1通用意する運用から、相手ごとの質問に答えられる素材を持っておく運用に変わります*1。開発の実務をSSDFの慣行の単位で棚卸しし、どの慣行をどう実施しているかを、様式に依存しない形で記述しておくと、形式が変わっても使い回せます*1。

あわせて、ハードウェアの構成情報を誰が持つかを決めておく必要があります*1。CISAのHBOMフレームワークが参照先に入った以上、機器を含む納品では、部材の出所を答える場面が想定されます*1。

そして、これは米国連邦の調達方針の話であって、他の制度が緩んだわけではありません*1。EUや各国の枠組みは別に走っています。根拠が1つ外れたことを、開発の実務を薄くする理由に使わないほうが、結果として説明しやすくなります。

まとめ：M-26-05で押さえる3つの視点

米国の行政管理予算局（OMB）は2026年1月23日、覚書M-26-05「ソフトウェアおよびハードウェアのセキュリティへのリスクベースの手法の採用」を発出し、M-22-18とM-23-16を廃止しました。押さえたい視点は三つあります。第一に、廃止の理由。覚書は、各機関の長がネットワーク上で稼働するソフトウェアとハードウェアのセキュリティに最終的な責任を負うとし、その達成に普遍的で画一的な方法は存在しないと述べます。M-22-18については、真のセキュリティへの投資よりも遵守を優先させる実証されていない負担の大きい手続を課し、機関ごとに調整された保証要件の策定から機関を逸らし、セキュリティが確保されていないハードウェアの脅威を考慮しなかったと指摘しました。第二に、廃止された内容。M-22-18は、ファームウェア、OS、アプリケーション、クラウドを含むアプリケーションサービス、ソフトウェアを含む製品を対象に、使用前の自己証明の取得を求め、証明できない場合のPOA&M、FedRAMP 3PAOによる第三者評価での代替、重要性に応じたSBOMの要求、90日から365日の期限を置いていました。M-23-16は、期限を共通様式のPRA承認から3か月・6か月に付け替え、第三者コンポーネントの生産者からは証明を収集しないことを明確にし、POA&Mを有効とするには機関がOMBへ延長を申請することを要件としました。第三に、残ったものと任意になったもの。M-26-05のもとで機関に残る義務は、ソフトウェアとハードウェアの完全な棚卸しの維持と、自らのリスク判定と任務上の必要に見合う保証の方針と手続の策定の2つです。自己証明様式の使用と、要請に応じたSBOMの提供を求める契約条項の採用は、いずれも選択肢とされました。クラウド基盤では実行時の本番環境のSBOMを明記すべきとされ、参照先としてNIST SP 800-218、CISAの2025年版SBOMの最低要素、CISAのHBOMフレームワークが挙げられています。

よくある質問

出典

1. *1　参考：米国行政管理予算局（OMB）覚書 M-26-05「Adopting a Risk-based Approach to Software and Hardware Security」（2026年1月23日）（https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf）。本文の一次情報として。発出日と発出者、市販の既製品への依存に関する前提、各機関の長の責任と画一的な方法が存在しない旨、M-22-18への評価とM-22-18およびM-23-16の廃止、残る義務（ソフトウェアとハードウェアの完全な棚卸しの維持、リスク判定と任務上の必要に見合う保証の方針と手続の策定）、選択肢（政府全体の資源の使用、要請に応じたSBOMの契約条項）、クラウド基盤に関する脚注（実行時の本番環境のSBOM）、参照先3文書（NIST SP 800-218、CISA 2025年版SBOMの最低要素〈2025年8月22日草案公表〉、CISA HBOMフレームワーク〈2023年9月〉）を確認した。確認日は2026年9月9日。（2026年9月確認）
2. *2　参考：米国行政管理予算局（OMB）覚書 M-22-18「Enhancing the Security of the Software Supply Chain through Secure Software Development Practices」（2022年9月14日）（https://bidenwhitehouse.archives.gov/wp-content/uploads/2022/09/M-22-18.pdf）。廃止された仕組みの一次情報として。適用範囲（ファームウェア、OS、アプリケーション、クラウドを含むアプリケーションサービス、ソフトウェアを含む製品）、機関開発ソフトウェアの除外、施行日後の開発とメジャー版変更という条件、使用前の自己証明の取得、自己証明の最低記載事項4項目、POA&Mによる代替、FedRAMP 3PAOまたは機関承認の第三者評価による代替、SBOMの要求（M-21-30の重要性に基づく／NTIA最低要素の形式／相互承認の考慮）、脆弱性開示プログラムの証跡、ならびに90日・120日・270日・365日の期限を確認した。確認日は2026年9月9日。（2026年9月確認）
3. *3　参考：米国行政管理予算局（OMB）覚書 M-23-16「Update to M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices」（2023年6月9日）（https://bidenwhitehouse.archives.gov/wp-content/uploads/2023/06/M-23-16-Update-to-M-22-18-Enhancing-Software-Security.pdf）。更新内容の一次情報として。期限を共通様式のPRA承認から3か月（重要ソフトウェア）および6か月（全ソフトウェア）へ付け替えたこと、第三者のソフトウェア構成要素の生産者から証明を収集する必要がないこと（オープンソース・専有を問わない）、連邦契約で開発されたソフトウェアが機関開発に当たるかの判断をCIOが行うこと、POA&Mを有効とするには機関がOMBへ延長を申請する必要があり、申請しない場合は使用を中止しなければならないこと、および附属Aの期日の一覧を確認した。確認日は2026年9月9日。（2026年9月確認）

Tweet