PMBOK、ウォータフォール、アジャイルなどをフレームワークとする今のプロジェクトマネジメントにおいて、セキュリティの観点は特に触れられていません。
セキュリティを観点とした代表的な開発基準には、「NIST SP 800-218」があります。
プロジェクトマネジメントで開発プロセスを考える際に、サブセットとしてこのような開発基準を組み込み、セキュア開発プロセスとして定義します。
NIST SP 800-218
NIST SP 800-218 は、正式名称を “Secure Software Development Framework (SSDF) Version 1.1” といい、アメリカ国立標準技術研究所（NIST） が発行した、ソフトウェア開発におけるセキュリティ強化のためのフレームワークです。
ソフトウェアのセキュリティを向上させるために、開発ライフサイクル全体にわたってベストプラクティスを体系化。以下の 4つの主要カテゴリー に分類された プラクティス群 から構成されます。
- Prepare the Organization (PO)
組織としてセキュア開発を可能にする基盤づくり。
例：セキュア開発方針の定義、役割と責任の明確化、トレーニング。
- Protect the Software (PS)
ソースコードやコンポーネントの保護。
例：コードのアクセス制御、依存関係の管理、署名・整合性チェック。
- Produce Well-Secured Software (PW)
セキュアなソフトウェアを開発・テストする活動。
例：脆弱性スキャン、静的解析、セキュリティ要件の実装、レビュー。
- Respond to Vulnerabilities (RV)
発見された脆弱性への対応と、ソフトウェアの改善。
例：脆弱性管理プロセス、修正の優先順位づけ、ユーザーへの通知。
・PO（Prepare the Organization）カテゴリのプラクティス一覧
| 番号 | プラクティス ID | タイトル（英語） | 概要（日本語要約） |
|---|---|---|---|
| 1 | PO.1 | Define Security Requirements for Software Development | ソフトウェア開発におけるセキュリティ要件（組織ポリシー、法規制、契約など）を明文化し、開発工程に統合する。 |
| 2 | PO.2 | Implement Roles and Responsibilities | セキュリティに関連する責任と役割を明確にし、開発関係者に割り当てる。例：セキュリティ責任者、レビュー担当者など。 |
| 3 | PO.3 | Implement Supporting Toolchains | セキュア開発に必要なツールやサービス（静的解析、依存関係管理など）を整備し、標準化・共有する。 |
| 4 | PO.4 | Define and Use Criteria for Software Reuse | OSSなど再利用コンポーネントを安全に活用するための選定・承認・管理基準を策定し、適用する。 |
| 5 | PO.5 | Establish and Maintain a Secure Development Environment | 開発環境（ネットワーク、認証、アクセス制御など）を保護し、不正アクセスや改ざんのリスクを低減する。 |
| 6 | PO.6 | Protect All Forms of Code from Unauthorized Access and Tampering | ソースコードや構成ファイル、スクリプト等をあらゆる段階で不正アクセス・改ざんから保護する。 |
| 7 | PO.7 | Provide Security Awareness and Training | 開発者や関係者に対し、セキュア開発に関する教育・トレーニングを継続的に実施する。内容は役割に応じて調整する。 |
・PS（Protect the Software）カテゴリのプラクティス一覧
| 番号 | プラクティス ID | タイトル（英語） | 概要（日本語要約） |
|---|---|---|---|
| 1 | PS.1 | Protect Code from Unauthorized Access | ソースコード・スクリプト・設定ファイルなどを、保存・転送・利用のすべての段階で不正アクセスから保護する。アクセス制御、認証、ログの活用などを含む。 |
| 2 | PS.2 | Provide a Mechanism for Verifying Software Integrity | ソフトウェアや構成ファイルに改ざんがないことを検証できる仕組み（例：署名、ハッシュ値の照合）を導入し、整合性を担保する。 |
| 3 | PS.3 | Archive and Protect Each Software Release | 各ソフトウェアリリースのバージョンや構成情報を記録し、信頼性ある形で保存・保護する。将来の検証や復元にも活用可能にする。 |
・PW（Produce Well-Secured Software）カテゴリのプラクティス一覧
| 番号 | プラクティス ID | タイトル（英語） | 日本語要約 |
|---|---|---|---|
| 1 | PW.1 | Define and Maintain Secure Software Development Standards | セキュアコーディング標準（例：入力検証、エラー処理、認証の実装ルールなど）を定義・整備し、開発において継続的に活用する。 |
| 2 | PW.2 | Perform Threat Modeling | 設計段階で脅威分析（例：STRIDE、DREAD）を行い、セキュリティ対策を事前に計画・実装する。 |
| 3 | PW.3 | Use Approved Software Architectures | セキュリティ要件を満たすことが確認されたアーキテクチャや設計パターンを採用する（例：ゼロトラスト、最小特権）。 |
| 4 | PW.4 | Perform Security Testing | セキュリティテスト（静的解析、動的解析、ファジングなど）を実施して脆弱性を検出し、修正する。 |
| 5 | PW.5 | Configure the Compilation, Build, and Packaging Processes to Improve Executable Security | ビルド時にセキュリティ強化設定（例：ASLR, DEP, stack canaries）を有効化して、実行ファイルの安全性を高める。 |
| 6 | PW.6 | Provide a Mechanism for Verifying Software Release Integrity | 配布物に対して署名やハッシュなどの整合性検証機構を付与する。利用者が正当性を確認可能にする。 |
| 7 | PW.7 | Verify the Provenance of All Software Components | 自社・サードパーティ・OSSを含むすべてのソフトウェアコンポーネントについて、出所・信頼性・整合性を確認する。SBOM（ソフトウェア部品表）の活用が推奨される。 |
| 8 | PW.8 | Perform Code Reviews | 手動または自動でコードレビューを行い、セキュリティ上の問題を早期に発見・修正する。ピアレビューやツール（Lint等）を活用。 |
・RV（Respond to Vulnerabilities）カテゴリのプラクティス一覧
| 番号 | プラクティス ID | タイトル（英語） | 日本語要約 |
|---|---|---|---|
| 1 | RV.1 | Identify and Confirm Vulnerabilities on an Ongoing Basis | 脆弱性を継続的に把握・確認する体制を確立。社内報告、脆弱性データベース（NVD, JVN）、ツールによる検出、第三者報告などを活用。 |
| 2 | RV.2 | Assess and Prioritize the Remediation of Vulnerabilities | 発見された脆弱性の重大度・影響度を評価し、対応の優先順位を決定。CVSSスコア、脅威モデル、ビジネスインパクトなどを考慮。 |
| 3 | RV.3 | Remediate Vulnerabilities | 実際に脆弱性の修正（パッチ適用、コード修正、構成変更など）を行い、再発防止策も検討する。修正後の検証も実施。 |
| 4 | RV.4 | Analyze Vulnerabilities to Identify Their Root Causes | 発生した脆弱性の原因を根本的に分析（例：再発防止のための設計改善、レビュー強化など）し、組織的な改善につなげる。 |
ソフトウェア開発ライフサイクルとの対応
NIST SP 800-218（SSDF）は、ソフトウェア開発ライフサイクル（SDLC）における各フェーズに対して、セキュリティプラクティスを統合することを目的としています。以下に、一般的なSDLCの工程と SSDF の4カテゴリ（PO, PS, PW, RV）との対応関係を示します。
| プラクティスID | 名称 | 企画・ 要件定義 |
設計 | 実装 | ビルド・ 統合 |
テスト | リリース・ 配布 |
運用・ 保守 |
|---|---|---|---|---|---|---|---|---|
| PO.1 | セキュリティ要件の定義 | ● | ||||||
| PO.2 | 役割と責任の実装 | ● | ||||||
| PO.3 | 支援ツールチェーン整備 | ● | ● | |||||
| PO.4 | チェック基準の整備 | ● | ● | ● | ||||
| PO.5 | セキュアな開発環境 | ● | ● | |||||
| PO.6 | コード保護 | ● | ● | |||||
| PO.7 | セキュリティ教育 | ● | ||||||
| PS.1 | コードの改ざん防止 | ● | ● | |||||
| PS.2 | 整合性確認機構 | ● | ||||||
| PS.3 | リリースの保護 | ● | ● | |||||
| PW.1 | リスク低減設計 | ● | ||||||
| PW.2 | 設計レビュー | ● | ||||||
| PW.4 | ソフトウェア再利用 | ● | ● | |||||
| PW.5 | セキュアコーディング | ● | ||||||
| PW.6 | セキュアビルド | ● | ||||||
| PW.7 | コードレビュー・解析 | ● | ||||||
| PW.8 | 実行コードのテスト | ● | ||||||
| PW.9 | セキュアな初期設定 | ● | ||||||
| RV.1 | 脆弱性の継続的特定 | ● | ||||||
| RV.2 | 脆弱性評価と対応 | ● | ||||||
| RV.3 | 原因分析と再発防止 | ● |
・企画・要件定義では、PO・PWを反映：
セキュリティ要求は最初から定義（PO.1, PW.2）しておくことで後工程の修正コストを削減。
・実装・ビルドでは、PS・PWが重要：
実装時にセキュアコーディング（PW.1）やアクセス制御（PS.1）を徹底。
ビルド時に署名・ハッシュなど整合性確保（PW.5, PS.2）。
・運用後は、RVの役割が中心：
脆弱性検出・修正・再発防止（RV.1〜RV.4）が、ソフトウェアの信頼性と継続性を担保。
