.png)
要約
NIST SSDFは、SDLC全体でセキュアなソフトウェアを構築するための高レベルのフレームワークです。
「準備」「保護」「生成」「対応」の4つのカテゴリに整理されています。
OWASP、SAFECode、および実世界のベストプラクティスを統合します。
これはセキュアバイデザインに関するものであり、コンプライアンスのための見せかけではありません。米国政府向けにソフトウェアを構築している場合、またはサプライチェーンを重視する場合には必須となります。
NIST SSDF (SP 800-218) スコアカード概要:
- 開発者の労力: 中程度（開発者が理想的にはすでに学習/実行しているべきセキュアなプラクティス（脅威モデリング、セキュアコーディング、テスト、脆弱性管理）の統合に焦点を当てます）。労力は、これらのプラクティスを形式化し、一貫して適用することにあります。
- ツール費用: 中程度（標準的なDevSecOpsツールに大きく依存：SAST、DAST、SCA、IAST、脅威モデリングツール、セキュアなリポジトリ、脆弱性管理プラットフォーム）。
- 市場への影響: 高い（EO 14028による米国連邦政府の要件により重要性が増しており、グローバルなセキュアSDLCのベストプラクティスと見なされ、サプライチェーンセキュリティの期待に影響を与えます。）
- 柔軟性: 高い（厳格な管理策ではなく、プラクティスとタスクを提供し、Agile、Waterfall、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):
- 役割を定義します（Security Champions、AppSecチーム）。
- セキュアな開発、脆弱性管理、開示に関するポリシーを実装します。
- 開発者、テスター、アーキテクト向けにロールベースのセキュリティトレーニングを提供します。
- ソフトウェア開発に適用されるセキュリティ要件を定義し、伝達します。
- ソフトウェアの保護 (PS):
- 強力なアクセス制御を備えたバージョン管理システム（例：Git）を使用します。
- リリース整合性を検証するために、コード署名またはその他のメカニズムを導入します。
- セキュリティスキャン機能を備えたアーティファクトリポジトリ（例：Artifactory、Nexus）を使用します。
- 過去のリリースを安全にアーカイブします。
- 安全性の高いソフトウェアの生成 (PW):
- 脅威モデリング (PW.1): 設計フェーズに脅威モデリングを統合します（例：STRIDEを使用）。
- セキュア設計レビュー（PW.2）: セキュリティ要件に対してアーキテクチャ/設計をレビューします。
- Secure Component Reuse (PW.3/PW.4): ソフトウェアコンポジション解析 (SCA) ツールを使用してオープンソースコンポーネントを精査し、セキュアコーディング標準（例：OWASP Secure Coding Practices）に従います。
- 安全なビルドプロセス (PW.5): CI/CDパイプラインを強化し、ビルド成果物をスキャンします。
- コードレビュー (PW.6): 必須のセキュリティに焦点を当てたコードレビュー（手動またはツール支援）を実施します。
- Security Testing (PW.7): SDLC全体でSAST、DAST、IAST、および手動ペネトレーションテストを統合します。
- セキュアな設定（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ワークフローに適切に統合せず、根本的なプロセスや人的側面に対処しないこと。
- Ignoring Existing SDLC: 現在の開発プロセス（アジャイルスプリント、CI/CDステージなど）にどのように自然に適合するかを考慮せずに、SSDFプラクティスを無理に導入しようとすること。
- 不十分なトレーニング：開発者に適切な役割別トレーニングを提供することなく、安全なプラクティスに従うことを期待すること。
- 不十分な脆弱性管理 (RV): 脆弱性を特定するものの、優先順位付け、修正の追跡、根本原因分析のための明確なプロセスが欠如しています。
- 「Produce」（PW）のみに焦点を当てること: 重要な準備（PO）、保護（PS）、および対応（RV）の側面を怠ること。
監査人/評価者が尋ねる可能性のあること（開発者向け）
正式なNIST SSDF監査はありませんが、コンプライアンスを証明する組織（特に連邦政府契約の場合）は評価を受ける可能性があります。開発チームへの質問には以下が含まれる場合があります。
- (PO.1) 「開発チーム内でセキュリティ責任はどのように定義され、割り当てられていますか？」
- (PO.4) 「開発者は最近どのようなセキュリティトレーニングを受けましたか？」
- (PS.1) 「ソースコードリポジトリへのアクセスはどのように制御していますか？」
- (PW.1) 「このアプリケーションに対して実施された脅威モデリングの証拠を示すことができますか？」
- (PW.4) 「チームはどのようなセキュアコーディング標準またはガイドラインに従っていますか？コンプライアンスはどのように確認されていますか？」
- (PW.6/PW.7) 「コードレビュープロセスを説明してください。CI/CDパイプラインに統合されているセキュリティテストツール（SAST、DAST、SCA）は何ですか？最近の結果を提示してください。」
- (PW.8) 「デプロイされたアプリケーションおよびインフラストラクチャのセキュアな構成をどのように確保していますか？」
- (RV.1/RV.2) 「サードパーティライブラリで新たに発見された脆弱性に対処するプロセスを説明してください。」
評価者は、文書化されたプロセス、ツール使用の証拠（スキャンレポート、脅威モデル）、トレーニング記録、およびSDLC全体を通じたセキュアなプラクティスの継続的な適用を求めます。
開発チームのためのクイックウィン
NIST SSDFへのアラインメントは、達成可能なステップから始めることができます。
- 基本的なSAST/SCA連携 (PW.7): メインのCIパイプラインに、自動静的解析およびソフトウェア構成解析ツールを追加してください。
- シークレットスキャン (PW.4/PS.1): 自動スキャンを実装し、シークレットがコードリポジトリにコミットされるのを防ぎます。
- コードレビューの義務化 (PW.6): すべてのコード変更に対してピアレビューを義務付け、場合によってはシンプルなセキュリティチェックリストを使用します。
- 依存関係の更新 (RV.2): 脆弱なサードパーティライブラリを定期的に更新するための基本的なプロセスを確立します。
- OWASP Top 10トレーニング（PO.4）：開発者に一般的なウェブ脆弱性に関する基礎トレーニングを提供します。
- シンプルな脅威モデリング（PW.1）: 新機能のために基本的な脅威モデリング（例：設計時のホワイトボードセッション）を取り入れ始めます。
これを無視すると...（非準拠の結果）
NIST SSDF自体に直接的な罰金はありませんが、その原則を無視した場合（特に米国の連邦要件の対象となる場合）、以下につながる可能性があります。
- 米国政府への販売不能: SSDFプラクティスに基づく必要な自己証明を提供できない場合、連邦政府機関へのソフトウェア販売が阻害される可能性があります。
- 脆弱性の増加: 安全な開発プラクティスに従わないことは、リリースされたソフトウェアにおけるセキュリティ上の欠陥を直接的に増加させ、侵害のリスクを高めます。
- Higher Remediation Costs: SDLCの後半（またはリリース後）に脆弱性を修正することは、早期に防止するよりもはるかに費用がかかります。
- サプライチェーンリスク: 安全でないソフトウェアを生産することは、顧客にとってより広範なソフトウェアサプライチェーンリスクに寄与します。
- 評判の損害: 重大で予防可能な脆弱性を含むソフトウェアをリリースすることは、信頼と評判を損ないます。
- 非効率な開発: 安全なプラクティスの欠如は、手戻り、遅延、予測不能なセキュリティ緊急対応につながる可能性があります。
よくあるご質問
NIST SSDF (SP 800-218) は必須ですか？
すべての組織にとって必須ではありません。しかし、大統領令14028およびOMBメモ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 (Software Assurance Maturity Model) やBSIMM (Building Security In Maturity Model) といった確立されたモデルから大きく影響を受けています。SSDFはより高レベルのプラクティスを提供しますが、SAMMとBSIMMはより詳細な成熟度モデルと活動記述を提供します。これらは補完的であり、組織はSAMMやBSIMMを使用して、SSDFプラクティスをサポートする特定の活動を評価し、改善することができます。
SSDFはAgile/DevOpsに適用できますか？
はい、その通りです。NIST SSDFは、手法に依存しないように設計されています。そのプラクティスとタスクは、アジャイルスプリント、CI/CDパイプライン、DevOpsワークフローに統合することができ、またそうすべきです（例：セキュリティテストの自動化、脅威モデリングの反復実施など）。
Secure Software Attestation Form とは何ですか？
これは、OMB Memo M-22-18によって義務付けられているフォームであり、米連邦政府にソフトウェアを販売するソフトウェア生産者が、NIST SSDFに準拠したセキュアなプラクティスに従ってソフトウェアが開発されたことを証明する必要があります。
SSDFに従うことは安全なソフトウェアを保証しますか？
どのプロセスも100%安全なソフトウェアを保証することはできません。しかし、NIST SSDFのプラクティスを一貫して適用することで、脆弱性の発生可能性を大幅に低減し、欠陥の影響を軽減し、より安全な開発文化を育み、結果として、より確実に安全なソフトウェア製品につながります。
