この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。2026年1月23日付のOMB M-26-05公式文書を確認し、旧記事の公開日・内容・SBOM義務化に関する誤りを修正しました。検証ステータス：✅ OMB公式文書確認済み／各省庁の個別調達要件は未確認
OMBのM-26-05は、SBOM提出を一律に義務化した文書ではありません。むしろ、従来のM-22-18とM-23-16を撤回し、各連邦機関がミッションやリスクに応じてソフトウェアとハードウェアの保証方法を選ぶリスクベースのアプローチへ転換する内容です。
M-26-05の要点
- 発行日：2026年1月23日。
- 旧方針：M-22-18とM-23-16を撤回。
- 基本方針：各機関がソフトウェア・ハードウェアのリスク評価に応じて保証方針を定める。
- SBOM：一律必須ではなく、契約条件として必要に応じ「最新のSBOMを要求できる」選択肢として示される。
- 既存資源：Secure Software Development Attestation Formなど、M-22-18で整備された政府横断資源は任意で継続利用できる。
旧記事の『SBOM提出義務化』はなぜ修正が必要か
旧記事では、M-26-05が2024年11月に発行され、SBOM提出を原則義務化し、RSAAを通じた提出が必須になったと説明していました。しかし、公式M-26-05の発行日は2026年1月23日であり、本文は一律のSBOM提出義務を定めていません。
公式文書では、政府機関がリスクに応じて契約条項を設計し、その選択肢の一つとしてSBOMを要求できるとしています。したがって、実務では「米連邦政府向けなら常にSBOM提出必須」と単純化せず、対象機関・契約・調達仕様を個別に確認する必要があります。
RSAAは何のための仕組みか
CISAのRepository for Software Attestations and Artifacts（RSAA）は、Secure Software Development Attestation Formなどの提出・管理に使われる仕組みです。M-26-05後も既存資源として参照価値はありますが、M-26-05そのものが全案件でSBOMをRSAAへ提出するよう一律命令しているわけではありません。
企業側で確認するポイント
- 対象の連邦機関が独自に定めたソフトウェア／ハードウェア保証方針。
- RFP、契約条項、調達仕様でSBOMやAttestationが要求されているか。
- 要求されるSBOM形式、更新頻度、提出方法、機密情報の扱い。
- クラウドの場合、ランタイム本番環境のSBOM要求が契約に含まれるか。
- NIST SP 800-218など、指定された安全な開発フレームワークとの対応関係。
SBOMを自社で作る最小確認
SBOM提出が契約で求められる場合に備え、まずは自社のビルド成果物からSBOMを生成できるか確認しておくと実務的です。たとえばSyftではコンテナイメージからCycloneDX JSONを生成できます。
syft <IMAGE_NAME> -o cyclonedx-json > sbom.jsonここで確認したいのは「コマンドが動いたか」だけではなく、生成されたSBOMに期待するパッケージ名・バージョン・識別子が含まれているかです。提出形式や必須フィールドは契約要件に合わせて確認してください。
公式情報
- OMB M-26-05 ― Adopting a Risk-based Approach to Software and Hardware Security
- CISA ― RSAA User Guide
この記事の更新履歴
- 2026-09-14 追加：M-26-05の正式発行日、M-22-18/M-23-16撤回、リスクベース方針を追加。
- 2026-09-14 変更：「SBOM一律義務化」という説明を、契約・機関ごとのリスクベース確認へ修正。
- 2026-09-14 削除：内部執筆指示、重複H1、2024年11月発行という誤記、RSAAへのSBOM一律提出を断定する記述、未検証の将来予測を削除。
