.png)
TL;DR
NIST SSDFは、SDLC 全体にわたって安全なソフトウェアを構築するための高レベルのフレームワークです。
4つのバケツに整理：準備、保護、生産、対応。
OWASP、SAFECode、実世界のベストプラクティスを統合。
セキュア・バイ・デザインとは、コンプライアンス（法令順守）のための劇場ではなく、セキュアな設計のことであり、米国政府向けのソフトウェアを構築している場合や、サプライチェーンに配慮している場合には必須である。
NIST SSDF (SP 800-218) スコアカードの概要：
- 開発者の努力：中程度（脅威モデリング、セキュアコーディング、テスト、脆弱性管理など、開発者が理想的にはすでに学習/実施しているはずのセキュアなプラクティスを統合することに重点を置く）。これらのプラクティスを形式化し、一貫して適用することに労力がかかる。
- ツールコスト：中程度（標準的なDevSecOpsツールに大きく依存する：SAST、DAST、SCA、IAST、脅威モデリングツール、セキュアリポジトリ、脆弱性管理プラットフォーム）。
- 市場への影響：高い（EO 14028 による米国連邦政府の要求により、重要性が増している。）
- 柔軟性:高い (厳格な管理ではなく、プラクティスとタスクを提供する。アジャイル、ウォーターフォール、DevOps のような様々な SDLC モデルに適応できる)。
- 監査の強度：中程度（正式な認証はないが、連邦政府のサプライヤーには自己申告を要求。）
NIST SSDF（SP 800-218）とは何ですか？
NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1 は、安全なソフトウェアを構築するための推奨される高レベルのプラクティスを提供します。これは、どのような SDLC モデル（アジャイル、DevOps、ウォーターフォールなど）にも統合できるように設計されており、ソフトウ ェアの製造者が脆弱性を低減し、残っている欠陥の影響を緩和し、再発を防止するために根本原因に対処することを支援します。
NIST SSDFは、具体的にどのように実施すべきかを規定するものではなく、どのような成果を達成すべきかを定義するものである。これらの成果は、ライフサイクルを反映した4つのカテゴリーに分類される「実践」に整理されている：
- 組織（PO）を準備する： 人材、プロセス、テクノロジーの準備を整える。
- 例セキュリティの役割／責任を定義する（PO.1）、サポートプロセスを実装する（PO.2）、セキュリティ要件を定義する（PO.3）。
- ソフトウェアの保護（PS）： ソフトウェアコンポーネントを改ざんから保護する。
- 例あらゆる形態のコードを不正アクセス/改ざんから保護する（PS.1）、ソフトウェアリリースの完全性を検証するメカニズムを提供する（PS.2）、リリースコンポーネントをアーカイブし保護する（PS.3）。
- 安全性の高いソフトウェアを作る（PW）： 開発中の脆弱性を最小限に抑える。
- 例セキュリティ要件を満たし/リスクを軽減するようにソフトウエアを設計する（PW.1）、コンプライアンスに適合するように設計をレビューする（PW.2）、安全な既存ソフトウエアを再利用する（PW.3）、安全なコーディング手法に従ってソースコードを作成する（PW.4）、ビルドプロセスを安全に設定する（PW.5）、コードをレビューしてテストする（PW.6/PW.7）、安全な配備のためにソフトウエアを設定する（PW.8）。
- 脆弱性への対応（RV）： リリース後の脆弱性の特定と対処。
- 例脆弱性の特定と分析(RV.1)、脆弱性の評価、優先順位付け、修正(RV.2)、根本原因の分析(RV.3)
各「対策」は、さらに「タスク」（具体的な行動）に分けられ、「想定実施例」（ツール／プロセスの提案）と「参考文献」（OWASP SAMM や BSIMM のような確立された対策へのポインタ）が含まれている。
NISTのSSDFは、米国の「国家のサイバーセキュリティの改善に関する大統領令14028」によって注目を集め、連邦政府機関は、SSDFのような安全な開発慣行に従っていることを証明する製造者のソフトウェアのみを使用することを義務付けられた。
なぜ重要なのか？
NIST SSDFが重要である理由はいくつかある：
- 根本原因に対処する：後で脆弱性を発見するのではなく、脆弱性を予防するために、SDLC 全体を通じてセキュリティを統合することに重点を置く。
- 共通言語：開発者、セキュリティチーム、買収者の間で、安全な開発プラクティスを議論するための共有語彙を提供する。
- 柔軟性：どのような開発手法や組織の状況にも適応できる。
- ベストプラクティスの統合OWASP、SAFECode、BSA などの信頼できる情報源から得られた実証済みのプラクティスを基に構築されています。
- ソフトウェア・サプライチェーンのセキュリティ最近のサイバー脅威と規制の主要な焦点であるソフトウェアサプライチェーンのセキュリティを改善するための基礎を提供する。
- 連邦政府の要件：EO 14028および関連するOMB覚書（M-22-18など）により自己認証が義務付けられているため、米国連邦政府向けに販売するソフトウェアメーカーには必須。
- 業界のベンチマーク：連邦政府の要件以外でも、安全な開発プラクティスのベンチマークとして見なされるようになってきている。
NIST SSDF を採用することで、よりセキュアなソフトウェアを一から構築し、後発の脆弱性を修正することによる手戻りを減らし、ソフトウェアセキュリティに対する顧客や規制当局の期待の高まりに応えることができます。
何をどのように実施するか（技術・政策）
NIST SSDF を実装するには、そのプラクティスとタスクを既存の SDLC に統合する必要があります：
- 組織（PO）を準備する：
- 役割（セキュリティチャンピオン、AppSec チーム）を定義する。
- 安全な開発、脆弱性管理、情報開示のためのポリシーを導入する。
- 開発者、テスター、アーキテクトに役割に応じたセキュリティトレーニングを提供する。
- ソフトウェア開発に適用されるセキュリティ要件を定義し、伝達する。
- ソフトウェアの保護（PS）：
- 強力なアクセス制御を備えたバージョン管理システム（Gitなど）を使用する。
- リリースの完全性を検証するために、コード署名やその他のメカニズムを実装する。
- アーティファクト・リポジトリ（Artifactory、Nexusなど）をセキュリティ・スキャンとともに使用する。
- 過去のリリースを安全にアーカイブ。
- 安全性の高いソフトウェアを作る（PW）：
- 脅威モデリング（PW.1）：脅威モデリングを設計フェーズに組み込む（STRIDE を使用するなど）。
- セキュア設計レビュー（PW.2）：セキュリティ要件に照らしてアーキテクチャ／設計をレビューする。
- 安全なコンポーネントの再利用 (PW.3/PW.4)：ソフトウェア構成分析（SCA）ツールを使用してオープンソースコンポーネントを審査する。
- セキュアなビルドプロセス (PW.5)：CI/CDパイプラインを強化し、ビルド成果物をスキャンする。
- コードレビュー（PW.6）：セキュリティに主眼を置いたコードレビュー（手作業またはツール支援）を義務化する。
- セキュリティテスト（PW.7）：SAST、DAST、IAST、および手動侵入テストを SDLC 全体にわたって統合する。
- セキュアなコンフィギュレーション(PW.8)：セキュアなデフォルト設定の定義。Infrastructure as Code (IaC)のスキャン。
- 脆弱性への対応（RV）：
- 脆弱性の特定（RV.1）：様々なツール（SAST、DAST、SCA、バグバウンティなど）からの発見を中央システムに集約する。
- 修復（RV.2）：脆弱性管理プラットフォームを使用して、定義された SLA の範囲内で、（CVSS や EPSS を使用するなどして）修正の追跡、優先順位付け、割り当て、検証を行う。
- 根本原因分析（RV.3）：繰り返し発生する脆弱性につながるシステム的な問題を分析し、プロセス/トレーニングを更新する。
多くの場合、実装には、明確なプロセスの確立とトレーニングの提供とともに、適切なセキュリティツール（SAST、DAST、SCA、IAST、秘密スキャン、IaCスキャン）を選択し、CI/CDパイプラインと開発者のワークフローに統合することが含まれる。例えば、Aikido Securityは、複数のスキャナ（SCA、SAST、Secrets、IaCなど）を単一のプラットフォームに統合し、PWとRVの実践に対処するのを支援する。
避けるべき一般的な間違い
NIST SSDFを採用する際には、これらの落とし穴に注意すること：
- 堅苦しい標準として扱うこと： NIST SSDFは柔軟なガイダンスであるため、各自の状況に適応させることなく、すべての事例を文字通り実施しようとするのは非効率的である。各実施例の結果に焦点を合わせる。
- 組織的バイ・イン（PO）の欠如：技術的な実装に入る前に、明確な役割、責任、トレーニング、サポートポリシーを確立していない。
- ツール中心の実装：ツールを SDLC のワークフローに適切に統合することなく、また、根本的なプロセスや人の側面に対処することなく、ツールを購入すること。
- 既存の SDLC を無視する：SSDF のプラクティスを、現在の開発プロセス（アジャイルスプリント、CI/CD ステージなど）にどのように自然に適合させるかを考慮せずに、ボルトで固定しようとすること。
- トレーニング不足：役割に応じた適切なトレーニングを提供することなく、開発者が安全なプラクティスに従うことを期待する。
- 脆弱性管理（RV）の不備：脆弱性を特定するものの、優先順位付け、修復の追跡、根本原因分析のための明確なプロセスが欠如している。
- 生産物」（PW）だけに焦点を当てる：重要な準備（PO）、保護（PS）、対応（RV）の側面を軽視。
監査人／評価者が尋ねそうなこと（開発者フォーカス）
正式なNIST SSDF監査はないが、（特に連邦政府との契約において）準拠を証明する組織は、査定を受けるかもしれない。開発チームに対する質問には、以下のようなものがある：
- (PO.1)"開発チーム内でセキュリティ責任をどのように定義し、割り当てているか？"
- (PO.4)「開発者は最近どのようなセキュリティ・トレーニングを受けましたか？
- (PS.1)"ソースコード・リポジトリへのアクセスをどのように管理していますか？"
- (PW.1)「このアプリケーションのために行われた脅威モデリングの証拠を示せますか？
- (PW.4)「チームはどのようなセキュアコーディングの標準やガイドラインに従っていますか?遵守状況はどのように確認されていますか？"
- (PW.6/PW.7)「コードレビュープロセスについて説明してください。どのようなセキュリティテストツール（SAST、DAST、SCA）が、あなたの CI/CD パイプラインに統合されていますか？最近の結果を示してください。"
- (PW.8)"デプロイされたアプリケーションとインフラストラクチャの安全なコンフィギュレーションをどのように確保していますか？"
- (RV.1/RV.2)「サードパーティライブラリに新たに発見された脆弱性を処理するプロセスを教えてください。
評価者は、文書化されたプロセス、ツール使用の証拠（スキャンレポート、脅威モデル）、トレーニング記録、および、SDLC 全体を通して一貫した安全な実施方法の適用を調べます。
開発チームのクイックウィン
NIST SSDFアライメントを始めるには、達成可能なステップから始めることができます：
- 基本的なSAST/SCAの統合(PW.7)：自動化された静的解析とソフトウェア構成解析ツールをメインのCIパイプラインに追加します。
- 秘密のスキャン (PW.4/PS.1)：コード・リポジトリへの秘密のコミットを防ぐために、自動スキャンを導入する。
- コードレビューの義務化（PW.6）：すべてのコード変更に対してピアレビューを強制する。おそらく、単純なセキュ リティチェックリストを使用する。
- 依存関係の更新(RV.2)：脆弱性のあるサードパーティライブラリを定期的に更新する基本プロセスを確立する。
- OWASP トップ 10 トレーニング (PO.4)：一般的な Web 脆弱性に関する基礎的なトレーニングを開発者に提供する。
- 簡単な脅威モデリング（PW.1）：新機能の基本的な脅威モデリング（設計中のホワイトボードセッションなど）を取り入れ始める。
これを無視すれば...（コンプライアンス違反の結果）
NIST SSDF自体に直接的な罰金はないが、その原則を無視することは（特に米国連邦政府の要求事項の対象となる場合）、以下のような事態を招く可能性がある：
- 米国政府への販売不能：SSDF の慣行に基づく必要な自己証明書を提出しなかった場合、連邦政府機関へのソフトウェア販売ができなくなる可能性がある。
- 脆弱性の増加：安全な開発プラクティスに従わないことは、リリースされたソフトウェアのセキュリティ上の欠陥を増やし、侵害リスクを増大させることに直結する。
- 高い修復コスト：SDLC の後半（あるいはリリース後）に脆弱性を修正することは、早期に脆弱性を防止することよりもかなりコストがかかります。
- サプライチェーンリスク：安全でないソフトウェアを製造することは、顧客にとってより広範なソフトウェアサプライチェーンリスクにつながります。
- 風評被害：予防可能な重大な脆弱性を持つソフトウェアをリリースすることは、信頼と評判を損なう。
- 非効率な開発：安全なプラクティスの欠如は、手戻り、遅延、予測不可能なセキュリティ防災訓練につながる可能性がある。
よくあるご質問
NIST SSDF (SP 800-218) は必須ですか？
すべての組織に義務付けられているわけではありません。しかし、米国連邦政府に販売するソフトウェア製造者には、大統領令14028およびOMB Memo M-22-18によって義務付けられているため、（自己認証による）準拠が義務付けられています。これは、すべてのソフトウェア製造者にとってのベストプラクティスのフレームワークと考えられています。
NISTのSSDF認証はありますか？
いいえ、NIST は SSDF の認証を提供していません。コンプライアンスは、特に連邦政府のサプライヤの場合、自己認証によって証明されます。第三者による評価は、この証明書を検証することはできますが、NIST の正式な証明書にはなりません。
NIST SSDF と NIST CSF または NIST 800-53 との関係は？
NIST SSDFは、特に SDLC 全体を通して安全なソフトウェア開発の実践に焦点を当てている。NIST CSF は、組織全体のサイバーセキュリティリスクを管理するための広範な枠組みである。NIST 800-53 は、セキュリティ/プライバシー管理の詳細なカタログです。SSDF の実践は、特定の CSF の機能（Protect、Detect のような）と、ソフトウェア開発に関連する特定の 800-53 管理（SA - System Acquisition ファミリのような）の実装を支援します。
NIST SSDFとOWASP SAMMやBSIMMとの関係は？
NIST の SSDFは、OWASP の SAMM（ソフトウェア保証成熟度モデル）や BSIMM（セキュリティ成熟度モデルの構築）のような確立されたモデルから大きく引用した。SSDF は、より高水準のプラクティスを提供し、SAMM と BSIMM は、より詳細な成熟度モデルと活動の記述を提供する。組織は、SSDF の実践を支援する特定の活動を評価し、改善するために、SAMM や BSIMM を使用することができる。
SSDFはアジャイル/DevOpsに適用できるか？
はい、その通りです。NIST SSDFは、方法論にとらわれないように設計されている。そのプラクティスとタスクは、アジャイルスプリント、CI/CD パイプライン、および、DevOps ワークフロー（例えば、セキュリティテストの自動化、反復的な脅威モデリング）に統合することが可能であり、また、統合すべきである。
セキュアソフトウェア証明書とは何ですか？
これは、OMB Memo M-22-18で義務付けられている書式で、米国連邦政府に販売するソフトウェア製造者は、そのソフトウェアがNIST SSDFに沿った安全な慣行に従って開発されたことを証明しなければならない。
SSDFに従えば安全なソフトウェアが保証されるのか？
どのようなプロセスも、100%安全なソフトウェアを保証することはできない。しかし、NIST SSDFを一貫して適用することで、脆弱性の可能性を大幅に低減し、欠陥の影響を緩和し、より安全な開発文化を醸成することができる。
