NIST SP 800-218 セキュアソフトウェア開発フレームワーク (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項: まるちゃんの情報セキュリティ気まぐれ日記

June 2023
Sun	Mon	Tue	Wed	Thu	Fri	Sat
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

2022.02.06

NIST SP 800-218 セキュアソフトウェア開発フレームワーク (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項

こんにちは、丸山満彦です。

NISTが、SP 800-218 セキュアソフトウェア開発フレームワーク (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項を公表していますね。。。

● NIST - ITL

・2022.02.03 SP 800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities

SP 800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities	SP 800-218 Secure Software Development Framework (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項
Abstract	概要
Few software development life cycle (SDLC) models explicitly address software security in detail, so secure software development practices usually need to be added to each SDLC model to ensure that the software being developed is well-secured. This document recommends the Secure Software Development Framework (SSDF) – a core set of high-level secure software development practices that can be integrated into each SDLC implementation. Following these practices should help software producers reduce the number of vulnerabilities in released software, mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences. Because the framework provides a common vocabulary for secure software development, software purchasers and consumers can also use it to foster communications with suppliers in acquisition processes and other management activities.	ソフトウェア開発ライフサイクル（SDLC）モデルの中で、ソフトウェアのセキュリティを明示的に詳細に扱っているものはほとんどありません。そのため、開発するソフトウェアのセキュリティを確保するためには、通常、各SDLCモデルにセキュアなソフトウェア開発手法を追加する必要があります。このドキュメントでは、セキュアソフトウェア開発フレームワーク（SSDF）を推奨しています。SSDFは、各SDLCの実装に統合可能な、高レベルのセキュアソフトウェア開発プラクティスのコアセットです。これらのプラクティスに従うことで、ソフトウェア製造者は、リリースされたソフトウェアの脆弱性の数を減らし、未検出または未対処の脆弱性が悪用された場合の潜在的な影響を軽減し、将来の再発を防ぐために脆弱性の根本原因に対処することができます。このフレームワークは、安全なソフトウェア開発のための共通の語彙を提供するものであるため、ソフトウェアの購入者および利用者は、取得プロセスやその他の管理活動においてサプライヤーとのコミュニケーションを促進するためにも使用することができます。

・[PDF] SP 800-218

1. Prepare the Organization (PO): Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.	1. 組織の準備（PO）：組織は、組織レベルで安全なソフトウエア開発を行うために、人材、プロセス、技術を準備する必要がある。多くの組織は、個々の開発グループやプロジェクトなど、ソフトウェア開発のサブセットにも適用可能なPOプラクティスがあると考える。
2. Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access.	2. ソフトウェアの保護（PS）：組織は、ソフトウェアのすべてのコンポーネントを、改ざんや不正アクセスから保護する。
3. Produce Well-Secured Software (PW): Organizations should produce well-secured software with minimal security vulnerabilities in its releases.	3. 安全なソフトウェアを作成する（PW）：組織は、リリースされるソフトウェアのセキュリティ脆弱性を最小限に抑え、十分なセキュリティを備えたソフトウェアを製造すべきである。
4. Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately	4. 脆弱性への対応（RV）：組織は、リリースするソフトウェアに残存する脆弱性を特定し、適切に対応する。

Practices	実施内容
Define Security Requirements for Software Development (PO.1): Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).	ソフトウェア開発のセキュリティ要件を定義する（PO.1）:ソフトウェア開発に対するセキュリティ要求事項を常に把握し、SDLC 全体で考慮できるようにする。また、要求事項の情報を一度収集して共有できるため、作業の重複を最小限に抑えることができる。これには、内部ソース（組織の方針、事業目的、リスク管理戦略など）及び外部ソース（適用される法律や規制など）からの要件が含まれる。
Implement Roles and Responsibilities (PO.2): Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.	役割と責任の実施（PO.2）：SDLC に関与する組織内外の全員が、SDLC 全体を通じて、SDLC に関連する役割と責任を果たすための準備ができていることを確認する。
Implement Supporting Toolchains (PO.3): Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Toolchains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.	支援ツールチェーンの導入（PO.3）：自動化を使用して人手を減らし、SDLC 全体のセキュリティ対策の正確性、再現性、使いやすさ、および包括性を向上させるとともに、これらの対策の使用を文書化して実証する方法を提供する。ツールチェーンやツールは、組織全体やプロジェクトごとなど、組織のさまざまなレベルで使用することができ、また、ビルドパイプラインのようなSDLCの特定の部分に対応することができる。
Define and Use Criteria for Software Security Checks (PO.4): Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development.	ソフトウェアのセキュリティチェックのための基準を定義して使用する（PO.4）：開発中にソフトウェアのセキュリティをチェックするための基準を定義して使用することにより、SDLCの結果として得られるソフトウェアが組織の期待を満たすことを支援する。
Implement and Maintain Secure Environments for Software Development (PO.5): Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.	ソフトウェア開発のための安全な環境を導入・維持する（PO.5）：ソフトウェア開発環境のすべてのコンポーネントが、内部および外部の脅威から強力に保護され、環境やその中で開発・維持されているソフトウェアが危険にさらされることがないようにする。ソフトウェア開発環境の例としては、開発環境、ビルド環境、テスト環境、配布環境などがある。
Protect All Forms of Code from Unauthorized Access and Tampering (PS.1): Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.	あらゆる形態のコードを不正なアクセスや改ざんから保護する（PS.1）：ソフトウェアの意図されたセキュリティ特性を回避または否定する可能性のあるコードへの不正な変更を、不注意または意図的に防止する。一般に公開されることが意図されていないコードについては、ソフトウェアの盗難を防止し、攻撃者がソフトウェアの脆弱性を見つけることをより困難または時間のかかるものにすることができる。
Provide a Mechanism for Verifying Software Release Integrity (PS.2): Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with.	ソフトウェアリリースの完全性を検証する仕組みを提供する（PS.2）：ソフトウェアの取得者が、取得したソフトウェアが正規のものであり、改ざんされていないことを確認できるようにする（PS.3）。
Archive and Protect Each Software Release (PS.3): Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.	各ソフトウェアリリースのアーカイブと保護（PS.3）：リリース後にソフトウェアに発見された脆弱性を特定、分析、排除するために、ソフトウェアリリースを保存する。
Design Software to Meet Security Requirements and Mitigate Security Risks (PW.1): Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.	セキュリティ要件を満たし、セキュリティリスクを軽減するようにソフトウェアを設計する（PW.1）：ソフトウェアのセキュリティ要件を特定および評価し、運用中にソフトウェアが直面する可能性のあるセキュリティリスクを特定し、ソフトウェアの設計およびアーキテクチャによってこれらのリスクをどのように軽減すべきかを決定する。また、リスクベースの分析によってセキュリティ要件を緩和または免除すべきであることが示された場合には、それを正当化する。ソフトウェアの設計時にセキュリティ要件とリスクに対処する（Secure by design）ことは、ソフトウェアのセキュリティを向上させる上で重要であり、開発効率の向上にもつながる。
Review the Software Design to Verify Compliance with Security Requirements and Risk Information (PW.2): Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.	ソフトウェア設計をレビューして、セキュリティ要件とリスク情報への適合性を検証する（PW.2）：ソフトウェアがセキュリティ要件を満たし、特定されたリスク情報に十分に対応していることを確認する。
Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality (PW.4): Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.	実現可能な場合には、機能を重複させるのではなく、既存の十分に保護されたソフトウェアを再利用する（PW.4）：ソフトウェアの開発コストを削減し、ソフトウェアの開発を迅速化し、すでにセキュリティの状態がチェックされているソフトウェア・モジュールやサービスを再利用することで、ソフトウェアに新たなセキュリティ脆弱性が発生する可能性を低減する。これは、暗号モジュールやプロトコルなど、セキュリティ機能を実装するソフトウェアでは特に重要です。
Create Source Code by Adhering to Secure Coding Practices (PW.5): Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.	セキュアコーディングの実践を遵守してソースコードを作成する（PW.5）：ソフトウェアに含まれるセキュリティ脆弱性の数を減らし、組織で定義された脆弱性の深刻度基準を満たす、またはそれ以上のソースコード作成時に導入される脆弱性を最小限に抑えることで、コストを削減する。
Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security (PW.6): Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.	実行可能なセキュリティを向上させるために、コンパイル、インタプリタ、およびビルドプロセスを構成する（PW.6）：テストを行う前に脆弱性を排除することにより、ソフトウェアのセキュリティ脆弱性の数を減らし、コストを削減する。
Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.7): Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems human-readable.	人間が読めるコードをレビューおよび／または分析して、脆弱性を特定し、セキュリティ要求事項への準拠を検証する（PW.7）：脆弱性を特定して、悪用を防ぐためにソフトウェアがリリースされる前に修正できるようにします。自動化された方法を使用することで、脆弱性を検出するために必要な労力とリソースを削減できます。人間が読めるコードとは、ソースコード、スクリプト、および組織が人間が読めると判断したその他の形式のコードを含みます。
Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.8): Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.	実行コードをテストして脆弱性を特定し、セキュリティ要求事項への準拠を検証する（PW.8）：脆弱性を特定し、悪用を防ぐためにソフトウェアがリリースされる前に修正できるようにする。自動化された方法を使用することで、脆弱性を検出するために必要な労力とリソースを削減し、トレーサビリティと再現性を向上させます。実行可能なコードとは、バイナリー、直接実行されるバイトコードやソースコード、その他組織が実行可能と判断したコードのことです。
Configure Software to Have Secure Settings by Default (PW.9): Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.	ソフトウェアをデフォルトで安全な設定にする（PW.9）：インストール時にソフトウェアのセキュリティを向上させ、脆弱なセキュリティ設定でソフトウェアが展開され、侵害のリスクが高まる可能性を低減します。
Identify and Confirm Vulnerabilities on an Ongoing Basis (RV.1): Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.	脆弱性の継続的な把握と確認（RV.1）：脆弱性がより迅速に特定されるようにすることで、リスクに応じてより迅速に修正することができ、攻撃者の機会を減らすことができる。
Assess, Prioritize, and Remediate Vulnerabilities (RV.2): Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.	脆弱性の評価、優先順位付け、修正（RV.2）：攻撃者の機会を減らすために、リスクに応じて脆弱性が修正されることを確実にする。
Analyze Vulnerabilities to Identify Their Root Causes (RV.3): Help reduce the frequency of vulnerabilities in the future.	脆弱性の分析とその根本原因の特定（RV.3）：将来的な脆弱性の発生頻度の低減に貢献します。