NIST SSDF（SP 800-218）をわかりやすく解説

4つのプラクティスグループ

SSDFは、プラクティスを4つのグループに整理しています。各プラクティスは成果を示すもので、NISTはこれがチェックリストではなく、リスクに基づいて計画を立てるための基礎であると明言しています。

グループ	目標	例
組織の準備（PO）	人、プロセス、ツールが整っている	セキュリティ要件の定義、役割の割り当て、開発環境の保護
ソフトウェアの保護（PS）	コードとリリースが改ざんから守られている	あらゆる形態のコードの保護、リリースの完全性の検証、各リリースのアーカイブ
十分に保護されたソフトウェアの作成（PW）	リリースするものの脆弱性が少ない	セキュリティを考慮した設計、十分に保護されたソフトウェアの再利用、コードのレビューとテスト
脆弱性への対応（RV）	残っている欠陥を見つけて対処する	脆弱性の継続的な特定、優先順位付けと修正、根本原因の分析

サプライチェーンに関わるプラクティス

PO.3（ツールチェーンの整備）とPO.5（セキュアな環境）。CIシステムも保護すべき対象の一部です。CI/CDパイプラインのセキュリティチェックリストをご覧ください。
PS.3（各リリースのアーカイブと保護）。これには各リリースのコンポーネントの来歴データを収集することが含まれ、SSDFはその手段としてSBOMを挙げています。
PW.4（十分に保護されたソフトウェアの再利用）。サードパーティのコンポーネントは精査し、最新の状態に保つべきです。ここでソフトウェアコンポジション解析（SCA）が役立ちます。
RV.1（脆弱性の継続的な特定）。これはリリース時のゲートではなく継続的な義務であるため、すでに出荷したものの監視が必要です。
RV.2（評価、優先順位付け、修正）。脆弱性の優先順位付けの方法をご覧ください。

SSDFは義務ですか

それ自体は義務ではありません。SSDFはNISTの刊行物であり、法律ではありません。数年間、米連邦政府のサプライヤーにとっては直接的な意味を持っていました。OMBの覚書M-22-18とM-23-16が、SSDFから抜き出したプラクティスへの準拠を証明するよう求めていたためです。これは2026年1月23日に変わりました。OMBの覚書M-26-05が両方を廃止し、リスクベースのアプローチに移行したのです。各機関は引き続き共通の証明書フォームやNISTの標準を利用できますが、もはや義務ではないため、サプライヤーは要件が機関ごとに異なることを想定しておくべきです。

連邦政府の調達以外でも、SSDFは共通言語として引き続き有用です。顧客はセキュリティ質問票でSSDFを参考にしており、SSDFはほかの標準とも対応づけられています。

SSDFのバージョン

バージョン1.1（SP 800-218、2022年2月公開）が現在の最終版です。
バージョン1.2（SP 800-218 Revision 1）は、2025年12月にドラフトとして公開されました。
SP 800-218Aは、SSDFを生成AIとデュアルユース基盤モデルに拡張するコミュニティプロファイルです。

SSDFの導入方法

現状を整理する。各プラクティスを確認し、すでに満たしている箇所とそのエビデンスを記録します。
ギャップをリスクで順位付けする。SSDFは自社のリスクに応じた適用を前提としているため、すべてのプラクティスに同じ深さで取り組む必要はありません。
エビデンスを自動化する。パイプラインから出てくるエビデンスは、追加の作業なしに最新の状態に保たれます。手作業で作成したエビデンスはすぐに古くなります。
担当者を割り当てる。各プラクティスには責任者が必要です。その多くはセキュリティ部門ではなくエンジニアリング部門が担うことになります。
定期的に見直す。ツールの変更やバージョン1.2の進捗に合わせて対応表を更新します。

SSDF、SLSA、CRA

SSDFは、セキュアな開発プログラムが達成すべきことを示します。SLSAはその一部であるビルドの完全性を深く掘り下げます。EUのCyber Resilience Actは、独自の義務を持つ法律です。いずれもソフトウェアに何が含まれているかを把握し、その脆弱性に対処することを求めているため、1つのために行った取り組みはほかにも活かせます。

CRACIの位置づけ

SSDFは幅広いプログラムであり、それをカバーできるツールはありません。CRACIは、ビルドと出荷したものに依存するプラクティスのエビデンスを提供します。GitHub Actionsの各ジョブからのSBOM、ビルド環境におけるジョブの分離とエグレス制御、出荷したソフトウェアの継続的な監視、そして検出結果のトリアージです。CRACIによって適合が達成されるわけではなく、対応づけと証明はお客様の責任として残ります。CRACIによるソフトウェアサプライチェーンセキュリティをご覧ください。

NIST SSDF：よくあるご質問

NIST SSDFとは何ですか？

NIST SP 800-218として公開されているセキュアソフトウェア開発フレームワークです。安全なソフトウェアを構築するためのプラクティス集で、組織の準備、ソフトウェアの保護、十分に保護されたソフトウェアの作成、脆弱性への対応の4つのグループに整理されています。

SSDFは何の略ですか？

Secure Software Development Framework（セキュアソフトウェア開発フレームワーク）の略です。

SSDFは義務ですか？

いいえ。SSDFはガイダンスであり、法律ではありません。かつて米連邦政府のサプライヤーはSSDFのプラクティスへの準拠を証明する必要がありましたが、OMBの覚書M-26-05が2026年1月にその要件を廃止しました。各機関は引き続き証明を求めることがあります。

SSDFの最新バージョンは何ですか？

バージョン1.1（SP 800-218、2022年2月）が現在の最終版です。バージョン1.2は2025年12月にドラフトとして公開されたため、その状況はNISTのサイトでご確認ください。

SSDFとSLSAの違いは何ですか？

SSDFは、人、プロセス、技術にわたるセキュアな開発全体を扱います。SLSAはビルドの完全性と来歴を深く掘り下げます。両者は相性良く併用できます。

SSDFはSBOMを求めていますか？

SSDFは各リリースのコンポーネントの来歴データを収集・共有するよう求めており、その手段の1つとしてSBOMを挙げています。特定のツールを義務付けるのではなく、成果を記述しています。