米国 NIST SP 800-218 Rev. 1（初期公開ドラフト）セキュアソフトウェア開発枠組み (SSDF) バージョン 1.2: ソフトウェア脆弱性のリスク緩和に関する推奨事項 (2025.12.17)

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

NISTがSP 800-218 Rev. 1（初期公開ドラフト）セキュアソフトウェア開発枠組み (SSDF) バージョン 1.2: ソフトウェア脆弱性のリスク緩和に関する推奨事項を公表し、意見募集をしていますね.。。

セキュア・バイ・デザインの普及には、こういう標準が必要なんですよね...

今回バージョン1.1から1.2への変更となります...

● NIST - ITL

・2025.12.17 NIST SP 800-218 Rev. 1 (Initial Public Draft) Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities

NIST SP 800-218 Rev. 1 (Initial Public Draft) Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities	NIST SP 800-218 Rev. 1（初期公開ドラフト）セキュアソフトウェア開発枠組み (SSDF) バージョン 1.2: ソフトウェア脆弱性のリスク緩和に関する推奨事項
Announcement	発表
This document describes new and improved practices, tasks, and examples for the secure and reliable development, delivery, and improvement of software.	この文書は、ソフトウェアの安全かつ信頼性の高い開発、提供、改善のための新たな実践方法、タスク、および事例を説明する。
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. SP 800-218 recommends the Secure Software Development Framework (SSDF), which is a core set of high-level secure software development practices that can be integrated into each SDLC implementation.	ソフトウェア開発ライフサイクル（SDLC）モデルでソフトウェアセキュリティを詳細に明示的に扱うものはほとんどないため、通常は各SDLCモデルにセキュアなソフトウェア開発手法を追加する必要がある。SP 800-218は、各SDLC実装に統合可能な高水準のセキュアなソフトウェア開発手法のコアセットであるセキュアソフトウェア開発枠組み（SSDF）を推奨する。
Following such practices should help software producers reduce the number of vulnerabilities in released software, mitigate the potential impacts 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 acquirers can also use it to foster communications with suppliers in acquisition processes and other management activities.	こうした手法に従うことで、ソフトウェア提供者はリリース済みソフトウェアの脆弱性を減らし、検出されなかったり対処されなかったりする脆弱性の悪用による潜在的影響を緩和し、脆弱性の根本原因に対処して将来の再発を防ぐことができる。この枠組みはセキュアなソフトウェア開発のための共通語彙を提供するため、ソフトウェア購入者も調達プロセスやその他の管理活動においてプロバイダとのコミュニケーション促進に活用できる。
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 such practices should help software producers reduce the number of vulnerabilities in released software, reduce 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 acquirers can also use it to foster communications with suppliers in acquisition processes and other management activities.	ソフトウェア開発ライフサイクル（SDLC）モデルでソフトウェアセキュリティを詳細に明示的に扱うものはほとんどない。そのため、開発中のソフトウェアの十分なセキュリティを確保するには、通常、各SDLCモデルにセキュアソフトウェア開発プラクティスを追加する必要がある。本文書は、各SDLC実装に統合可能な高水準のセキュアソフトウェア開発プラクティスのコアセットであるセキュアソフトウェア開発枠組み（SSDF）を推奨する。こうした実践に従うことで、ソフトウェア提供者はリリースされたソフトウェアの脆弱性数を減らし、検出されなかった、あるいは対処されなかった脆弱性の悪用による潜在的な影響を軽減し、脆弱性の根本原因に対処して将来の再発を防ぐことができる。この枠組みはセキュアなソフトウェア開発のための共通語彙を提供するため、ソフトウェア購入者も調達プロセスやその他の管理活動において、サプライヤーとのコミュニケーション促進に活用できる。

・[PDF] NIST.SP.800-218r1.ipd

Reports on Computer Systems Technology	コンピュータシステム技術に関する報告書
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.	米国立標準技術研究所（NIST）の情報技術研究所（ITL）は、国家の測定・標準インフラに対する技術的リーダーシップを提供することで、米国経済と公共の福祉を促進する。ITLは、情報技術の開発と生産的利用を推進するため、試験、試験方法、参照データ、概念実証実装、技術分析を開発する。ITLの責任範囲には、連邦情報システムにおける国家安全保障関連以外の情報の費用対効果の高いセキュリティとプライバシーを確保するための、管理・運営・技術・物理的標準およびガイドラインの開発が含まれる。特別刊行物800シリーズは、ITLの情報システムセキュリティに関する研究、ガイドライン、普及活動、ならびに産業界・政府・学術機関との共同活動を報告するものである。
Audience	対象読者
There are two primary audiences for this document. The first is software producers (e.g., commercial-off-the-shelf [COTS] product vendors, government-off-the-shelf [GOTS] software developers, custom software developers, internal development teams), regardless of size, sector, or level of maturity. The second is software acquirers — both federal agencies and other organizations. Readers of this document are not expected to be experts in secure software development in order to understand it, but such expertise is required to implement its recommended practices.	本文書には主に二つの対象読者が存在する。第一に、規模・業種・成熟度を問わず、ソフトウェア生産者（例：市販製品（COTS）ベンダー、政府向け市販ソフトウェア（GOTS）開発者、カスタムソフトウェア開発者、内部開発チーム）である。第二に、ソフトウェア調達者（連邦機関及びその他の組織）である。本文書を理解するために、読者がセキュアソフトウェア開発の専門家である必要はない。ただし、推奨される実践手法を実装するには、そのような専門知識が求められる。
Personnel within the following Workforce Categories and Specialty Areas from the National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework [SP800-181] are most likely to find this publication of interest:	国家サイバーセキュリティ教育イニシアチブ（NICE）サイバーセキュリティ人材枠組み[SP800-181]における以下の職種カテゴリーおよび専門分野に属する人材が、本出版物に関心を持つ可能性が最も高い：
• Securely Provision (SP): Risk Management (RSK), Software Development (DEV), Systems Requirements Planning (SRP), Test and Evaluation (TST), Systems Development (SYS)	• 安全なプロビジョニング（SP）：リスクマネジメント（RSK）、ソフトウェア開発（DEV）、システム要件計画（SRP）、試験評価（TST）、システム開発（SYS）
• Operate and Maintain (OM): Systems Analysis (ANA)	• 運用・保守（OM）：システム分析（ANA）
• Oversee and Govern (OV): Training, Education, and Awareness (TEA); Cybersecurity Management (MGT); Executive Cyber Leadership (EXL); Program/Project Management (PMA) and Acquisition	• 監督・ガバナンス（OV）：訓練・教育・啓発（TEA）；サイバーセキュリティ管理（MGT）；経営層のサイバーリーダーシップ（EXL）；プログラム／プロジェクト管理（PMA）および調達
• Protect and Defend (PR): Incident Response (CIR), Vulnerability Assessment and Management (VAM)	• 防御（PR）：インシデント対応（CIR）、脆弱性評価と管理（VAM）
• Analyze (AN): Threat Analysis (TWA), Exploitation Analysis (EXP)	• 分析（AN）：脅威分析（TWA）、悪用分析（EXP）
Note to Reviewers	レビュー担当者への注記
Reviewers are encouraged to provide feedback on the SSDF at any time, especially while implementing it into organizational and software development efforts. Input from a variety of software producers will inform the future refinement and periodic revision of the SSDF.	レビュー担当者は、SSDFについて随時フィードバックを提供することが推奨される。特に組織やソフトウェア開発活動への実装過程において重要である。多様なソフトウェア開発者からの意見は、SSDFの将来的な改良と定期的な改訂に反映される。
If you are from a standards-developing organization or another organization that has produced a set of secure practices and you would like to map your secure software development standard or guidance to the SSDF, please contact the authors at ssdf@nist.gov. Additionally, you can use the National Online Informative References Program (OLIR) to submit mappings that augment the existing set of informative references.	標準策定機関またはセキュアな実践手法を策定した組織に所属し、自組織のセキュアソフトウェア開発基準やガイダンスをSSDFにマッピングしたい場合は、ssdf@nist.govまで著者へ連絡すること。さらに、既存の情報参照セットを補完するマッピングを提出するには、National Online Informative References Program (OLIR) を利用できる。
This preliminary revision to the SSDF is in response to Executive Order 14306 [EO14306], which calls for updating “practices, procedures, controls, and implementation examples regarding the secure and reliable development and delivery of software as well as the security of the software itself.” Changes and additions to the examples for several practices were made to address potential areas of concern.	本SSDFの暫定改訂は、大統領令14306号（EO14306）への対応である。同令は「ソフトウェアの安全かつ信頼性の高い開発・提供、ならびにソフトウェア自体のセキュリティに関する実践、手順、制御、実装例」の更新を求めている。懸念される可能性のある領域に対処するため、複数の実践例の変更と追加が行われた。
The authors also request specific feedback on the following:	また、著者らは以下の点について具体的なフィードバックを求めている：
• Are there any additional examples that would further the goal of this update?	• 本更新の目的をさらに推進する追加例はあるか？
• Are there other necessary modifications “regarding the secure and reliable development and delivery of software as well as the security of the software itself”?	• 「ソフトウェアの安全かつ信頼性の高い開発・提供ならびにソフトウェア自体のセキュリティ」に関して、他に必要な修正はあるか？
• Two new practices have been added in this update: PO.6 to address the need for improvement over time and PS.4 to address the need for robust and reliable updates.	• 本更新では2つの新規プラクティスを追加した：PO.6（継続的な改善の必要性に対応）とPS.4（堅牢かつ信頼性の高い更新の必要性に対応）。
o Are more tasks needed for these two practices?	o これら2つのプラクティスには追加のタスクが必要か？
o Are the tasks that are currently there the right ones?	o 現在のタスクは適切か？
o What additional examples would you like to see for these practices/tasks?	o これらのプラクティス／タスクに対して追加でどのような事例を希望するか？
o What additional references are useful to support these practices/tasks?	o これらのプラクティス／タスクを支援する有用な追加参考文献はあるか？

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
2. Secure Software Development Framework	2. セキュアソフトウェア開発フレームワーク
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書A. 記号・略語・頭字語一覧
Appendix B. Change Log	附属書B. 変更履歴

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
This document describes a set of fundamental, sound practices for secure software development called the Secure Software Development Framework (SSDF). Organizations should integrate the SSDF throughout their existing software development practices, express their secure software development requirements to third-party suppliers using SSDF conventions, and acquire software that meets the practices described in the SSDF. Using the SSDF helps organizations to meet the following secure software development recommendations:	本ドキュメントは、セキュアソフトウェア開発のための基本的かつ健全な実践手法群である「セキュアソフトウェア開発枠組み（SSDF）」を説明する。組織は既存のソフトウェア開発手法にSSDFを統合し、SSDFの規約を用いてサードパーティサプライヤーにセキュアソフトウェア開発要件を明示し、SSDFで記述された実践手法を満たすソフトウェアを取得すべきである。SSDFの利用は、組織が以下のセキュアソフトウェア開発推奨事項を満たすのに役立つ：
• Organizations should ensure that their people, processes, and technology are prepared to perform secure software development.	• 組織は、自組織の人材、プロセス、技術がセキュアなソフトウェア開発を実行できる状態にあることを保証すべきである。
• Organizations should protect all components of their software from tampering and unauthorized access.	• 組織は、ソフトウェアの全構成要素を改ざんと不正アクセスから防御すべきである。
• Organizations should produce well-secured software with minimal security vulnerabilities in its releases.	• 組織は、リリース時にセキュリティ脆弱性が最小限に抑えられた、十分に保護されたソフトウェアを生産すべきである。
• Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.	• 組織は、ソフトウェアリリースに残存する脆弱性を識別し、それらに対処し、将来同様の脆弱性が発生するのを防ぐために適切に対応すべきである。
The SSDF does not prescribe how to implement each practice. The focus is on the outcomes of the practices rather than on the tools, techniques, and mechanisms to do so. This means that the SSDF can be used by organizations in any sector or community, regardless of size or cybersecurity sophistication. It can also be used for any type of software development, regardless of technology, platform, programming language, or operating environment.	SSDFは各実践手法の実施方法を規定しない。焦点はツールや技術、メカニズムではなく、実践の結果にある。これはSSDFが規模やサイバーセキュリティの高度さに関わらず、あらゆる分野やコミュニティの組織で使用可能であることを意味する。また技術、プラットフォーム、プログラミング言語、動作環境を問わず、あらゆる種類のソフトウェア開発に適用できる。
The SSDF defines only a high-level subset of what organizations may need to do, so organizations should consult the references and other resources for additional information on implementing the practices. Not all practices are applicable to all use cases; organizations should adopt a risk-based approach to determine what practices are relevant, appropriate, and effective to mitigate the threats to their software development practices.	SSDFは組織が必要とする可能性のある対策のハイレベルな一部を定義するに過ぎないため、各実践手法の実施に関する追加情報は参考文献やその他のリソースを参照すべきである。全ての実践手法が全てのユースケースに適用できるわけではない。組織はリスクベースのアプローチを採用し、自社のソフトウェア開発実践に対する脅威の緩和のために、関連性があり適切かつ効果的な実践手法を判断すべきである。

Talbe1 Ver1.2の一部...

Practices	実践	Tasks	タスク
Prepare the Organization (PO)	組織の準備（PO）
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 the 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 全体を通じて考慮され、要件情報を一度収集して共有できるため、作業の重複を最小限に抑えられるようにする。 これには、内部情報源（組織のポリシー、事業目標、リスクマネジメント戦略など）および外部情報源（適用法など）からの要件が含まれる。	PO.1.1: Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.	PO.1.1：組織のソフトウェア開発インフラストラクチャおよびプロセスに関するすべてのセキュリティ要件を識別し、文書化し、継続的に維持する。
		PO.1.2: Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.	PO.1.2: 組織が開発するソフトウェアが満たすべき全てのセキュリティ要件を識別し文書化し、それらを長期にわたり維持する。
		PO.1.3: Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software. [Formerly PW.3.1]	PO.1.3: 組織が自社ソフトウェアで再利用する商用ソフトウェアコンポーネントを提供する全てのサードパーティに対し、要件を伝達する。 [旧PW.3.1]
Implement Roles and Responsibilities (PO.2): Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLCrelated roles and responsibilities throughout the SDLC.	役割と責任の実施 (PO.2): SDLC に関与する組織内外の全員が、SDLC 全体を通じて SDLC 関連の役割と責任を遂行する準備ができていることを保証する。	PO.2.1: Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC. Periodically review and maintain the defined roles and responsibilities, updating them as needed.	PO.2.1: SDLC の全段階を網羅するために、必要に応じて新しい役割を作成し、既存の役割の責任を変更する。定義された役割と責任を定期的に見直し、維持し、必要に応じて更新する。
		PO.2.2: Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed.	PO.2.2: 安全な開発に貢献する責任を持つ全従業員に対し、役割に基づいた研修をプロバイダとして提供する。従業員の習熟度と役割に基づいた研修を定期的に見直し、必要に応じて研修を更新する。
		PO.2.3: Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with developmentrelated roles and responsibilities.	PO.2.3: 開発の安全確保について、上層部または認可責任者のコミットメントを得て、開発に関連する役割と責任を持つ全員にそのコミットメントを伝えること。
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 (e.g., organization-wide, project-specific) and may address a particular part of the SDLC, like a build pipeline.	サポートツールチェーンの実装（PO.3）：自動化を活用し、SDLC全体におけるセキュリティ慣行の精度、再現性、使いやすさ、包括性を向上させるとともに、人的労力を削減する。また、これらの慣行の使用を文書化し実証する手段を提供する。 ツールチェーンとツールは、組織内の異なるレベル（ ）で利用可能であり（例：組織全体、プロジェクト固有）、ビルドパイプラインのようなSDLCの特定の部分に対応する可能性がある。	PO.3.1: Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other.	PO.3.1: 特定されたリスクを緩和するために、各ツールチェーンに必須または推奨されるツールやツールタイプを明示し、ツールチェーンの構成要素を相互に統合する方法を規定する。
		PO.3.2: Follow recommended security practices to deploy, operate, and maintain tools and toolchains.	PO.3.2：ツールおよびツールチェーンの展開、運用、保守には、推奨されるセキュリティ慣行に従うこと。
		PO.3.3: Configure tools to generate artifacts[1] of their support of secure software development practices as defined by the organization.	PO.3.3: ツールを設定し、組織が定義したセキュアなソフトウェア開発プラクティスへの対応を証明するアーティファクト[1] を生成する。
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から生じるソフトウェアが組織の期待を満たすことを保証する。	PO.4.1: Define criteria for software security checks and track them throughout the SDLC.	PO.4.1: ソフトウェアセキュリティチェックの規準を定義し、SDLC 全体を通じて追跡する。
		PO.4.2: Implement processes and mechanisms to gather and safeguard necessary information in support of the criteria.	PO.4.2: 規準を支援するために必要な情報を収集し保護するプロセスと仕組みを実装する。
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）：ソフトウェア開発環境のすべての構成要素が、内部および外部の脅威から強力に防御され、環境自体やその中で開発・保守されているソフトウェア の侵害を防ぐことを保証する。ソフトウェア開発環境の例としては、開発環境、ビルド環境、テスト環境、配布環境などが挙げられる。	PO.5.1: Separate and protect each environment involved in software development.	PO.5.1: ソフトウェア開発に関わる各環境を分離し防御する。
		PO.5.2: Secure and harden development endpoints (e.g., for software designers, developers, testers, builders) to perform development-related tasks using a risk-based approach.	PO.5.2: 開発エンドポイント（例：ソフトウェア設計者、開発者、テスター、ビルダー向け）を保護し強化し、リスクベースのアプローチを用いて開発関連タスクを実行する。
Define and Implement a Continuous Process Improvement Plan (PO.6): Identify and execute improvements to cybersecurity processes and procedures throughout the SDLC across all SSDF practices.	継続的プロセス改善計画の策定と実施（PO.6）： ソフトウェア開発ライフサイクル（SDLC）全体および全ソフトウェア開発プロセス（SSDF）において、サイバーセキュリティプロセスと手順の改善点を識別し実行する。	PO.6.1: Update and improve software development environments in response to new threats and as new tools are included in the development process.	PO.6.1: の新たな脅威への対応や、開発プロセスに新たなツールが導入されることに伴い、ソフトウェア開発環境を更新し、改善する。
		PO.6.2: Identify new processes, tools, and techniques that can help avoid software errors (see PW.7, RV.3.3).	PO.6.2: ソフトウェアエラーを回避するのに役立つ新しいプロセス、ツール、技術を識別する（PW.7、RV.3.3を参照）。
		PO.6.3: Improve vulnerability response processes, and periodically review prior decisions (see RV.2.2).	PO.6.3: 脆弱性対応プロセスを改善し、過去の決定を定期的に見直す（RV.2.2 参照）。
Protect Software (PS)	ソフトウェア防御（PS）
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 the theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.	あらゆる形態のコードを不正アクセスや改ざんから防御する（PS.1）：ソフトウェアの意図したセキュリティ特性を回避または無効化する可能性のある、意図的・偶発的なコードへの不正変更を防ぐ。公開を意図しないコードについては、ソフトウェアの盗難防止に寄与し、攻撃者がソフトウェアの脆弱性を見つけることを困難または時間のかかるものにする。	PS.1.1: Store all forms of code – including source code, executable code, and configuration as code –  based on the principle of least privilege so that only authorized personnel, tools, and services have access.	PS.1.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.2.1: Make software integrity verification information available to software acquirers.	PS.2.1: ソフトウェアの完全性検証情報をソフトウェア取得者に提供する。
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）：リリース後にソフトウェアで発見された脆弱性を識別、分析、排除するために、ソフトウェアリリースを保存する。	PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.	PS.3.1: 各ソフトウェアリリースについて保持すべき必要なファイルと関連データ（例：完全性検証情報、来歴証明データ）を安全にアーカイブする。
		PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).	PS.3.2: 各ソフトウェアリリースの全コンポーネントについて、来歴証明データを収集、保護、維持、共有する（例：ソフトウェア部品表［SBOM］において）。
Ensure Software Updates Are Robust and Reliable (PS.4): Implement robust and reliable software update strategies, preferably allowing customers to control any updates to the software package and application configurations. Help software acquirers maintain operations and minimize disruptions by ensuring that software updates are tested and responsibly delivered.	ソフトウェア更新の堅牢性と信頼性を確保する（PS.4）：堅牢かつ信頼性の高いソフトウェア更新戦略を実施する。可能であれば、顧客がソフトウェアパッケージとアプリケーション構成の更新を制御できるようにする。ソフトウェア更新がテストされ、責任を持って提供されることを保証することで、ソフトウェア取得者が運用を維持し、混乱を最小限に抑えるのを支援する。	PS.4.1: Thoroughly test all releases following all guidance in PW.	PS.4.1: PW のすべてのガイダンスに従い、すべてのリリースを徹底的にテストする。
		PS.4.2: Use tiered update and release strategies, such as canaries, staged roll-out, and test deployments.	PS.4.2: カナリア、段階的展開、テスト展開などの段階的な更新・リリース戦略を採用する。
		PS.4.3: Include robust rollback mechanisms for updates.	PS.4.3: 更新のための堅牢なロールバックメカニズムを含めること。
		PS.4.4: Maintain robust and reliable update engines and associated infrastructure for the delivery of updates.	PS.4.4: 更新プログラムの配信のために、堅牢で信頼性の高い更新エンジンと関連インフラを維持する。
Produce Well-Secured Software (PW)	十分に保護されたソフトウェアの作成 (PW)
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 for which riskbased analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (i.e., secure by design) is key to improving software security and also helps improve development efficiency.	セキュリティ要件を満たし、セキュリティリスクを緩和するソフトウェアを設計する（PW.1）：ソフトウェアのセキュリティ要件を識別し評価する。運用中にソフトウェアが直面する可能性のあるセキュリティリスクを識別し、ソフトウェアの設計とアーキテクチャがそれらのリスクをどのように緩和すべきかを決定する。リスクベースの分析によりセキュリティ要件を緩和または免除すべきと示された事例については、その正当性を説明する。 ソフトウェア設計段階でセキュリティ要件とリスクに対処すること（すなわち設計段階でのセキュリティ確保）は、ソフトウェアのセキュリティ向上に不可欠であり、開発効率の向上にも寄与する。	PW.1.1: Use forms of risk modeling (e.g., threat modeling, attack modeling, attack surface mapping) to help assess the security risk for the software.	PW.1.1: リスクモデリングの手法（脅威モデリング、攻撃モデリング、攻撃対象領域マッピングなど）を用いて、ソフトウェアのセキュリティリスク評価を支援する。
		PW.1.2: Track and maintain the software’s security requirements, risks, and design decisions.	PW.1.2: ソフトウェアのセキュリティ要件、リスク、設計上の決定事項を追跡し、維持する。
		PW.1.3: Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services. [Formerly PW.4.3]	PW.1.3: 適切な場合には、独自のセキュリティ機能やサービスの実装を作成する代わりに、標準セキュリティ機能やサービスの利用をサポートする仕組みを組み込むこと（例：ソフトウェアが既存のログ管理、ID管理、アクセス管理、脆弱性管理システムと連携できるようにする）。[旧PW.4.3]
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）：ソフトウェアがセキュリティ要件を満たし、識別されたリスク情報に適切に対処することを保証する。	PW.2.1: Have 1) a qualified person (or people) who were not involved with the design and/or 2) automated processes instantiated in the toolchain review the software design to confirm and enforce that it meets all of the security requirements and satisfactorily addresses the identified risk information.	PW.2.1: 1) 設計に関与していない有資格者（または複数名）および/または 2) ツールチェーンに実装された自動化プロセスにより、ソフトウェア設計をレビューし、全てのセキュリティ要件を満たし、特定されたリスク情報を適切に対処していることを確認し、強制する。
Verify Third-Party Software Complies with Security Requirements (PW.3): Moved to PW.4	サードパーティ製ソフトウェアのセキュリティ要件適合性確認（PW.3）：PW.4へ移動	PW.3.1: Moved to PO.1.3	PW.3.1：PO.1.3へ移動
		PW.3.2: Moved to PW.4.4	PW.3.2：PW.4.4へ移動
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）：セキュリティ態勢が既に確認済みのソフトウェアモジュールやサービスを再利用することで、ソフトウェア開発コストを削減し、ソフトウェア開発を迅速化（ ）し、ソフトウェアに追加のセキュリティ脆弱性が導入される可能性を低減する。これは、暗号モジュールやプロトコルなど、セキュリティ機能を実装するソフトウェアにおいて特に重要である。	PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, opensource, and other third- party developers for use by the organization’s software.	PW.4.1: 組織のソフトウェアで使用するため、商用、オープンソース、その他のサードパーティ製ソフトウェア開発者から、十分にセキュリティ対策されたソフトウェアコンポーネント（例：ソフトウェアライブラリ、モジュール、ミドルウェア、枠組み）を取得し、維持する。
		PW.4.2: Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components.	PW.4.2：サードパーティソフトウェアコンポーネントでは十分に満たせない、一般的な内部ソフトウェア開発ニーズに対応するため、SDLCプロセスに従い、社内で十分に保護されたソフトウェアコンポーネントを作成し維持する。
		PW.4.3: Moved to PW.1.3	PW.4.3: PW.1.3 に移動した
		PW.4.4: Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles.	PW.4.4: 取得した商用ソフトウェア、オープンソースソフトウェア、その他すべてのサードパーティ製ソフトウェアコンポーネントが、組織が定義した要件に、そのライフサイクル全体を通じて準拠していることを確認する。
		PW.4.5: Moved to PW.4.1 and PW.4.4	PW.4.5: PW.4.1 および PW.4.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 organizationdefined vulnerability severity criteria.	セキュアコーディング慣行に従ってソースコードを作成する（PW.5）：ソフトウェアのセキュリティ脆弱性の数を減らし、ソースコード作成時に導入される脆弱性を最小限に抑えることでコストを削減する。これらの脆弱性は、組織が定義した脆弱性の規準を満たすか、それを超えるものである。	PW.5.1: Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.	PW.5.1: 組織の要件を満たすために、開発言語および環境に適したすべてのセキュアコーディング慣行に従う。
		PW.5.2: Moved to PW.5.1 as example	PW.5.2: 例としてPW.5.1に移動した
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）：テストが行われる前に脆弱性を排除することで、ソフトウェアのセキュリティ脆弱性の数を減らし、コストを削減する。	PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security.	PW.6.1: 実行ファイルのセキュリティを向上させる機能を備えたコンパイラ、インタプリタ、ビルドツールを使用する。
		PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.	PW.6.2: 使用すべきコンパイラ、インタプリタ、ビルドツールの機能を決定し、それぞれの設定方法を定めた上で、承認された設定を実装し使用する。
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）：脆弱性を識別し、ソフトウェアリリース前に修正して悪用を防ぐ。自動化された手法を用いることで、脆弱性検知に必要な労力とリソースを削減できる。 可読コードには、ソースコード、スクリプト、および組織が可読と判断するその他の形式のコードが含まれる。	PW.7.1: Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization.	PW.7.1: 組織の定義に基づき、コードレビュー（人が直接コードを確認して問題を発見する方法）とコード分析（ツールを用いてコード内の問題を発見する方法。完全自動化または人と連携して実施）のいずれか、あるいは両方を採用すべきかを決定する。
		PW.7.2: Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.	PW.7.2: 組織のセキュアコーディング標準に基づき、コードレビューおよび／またはコード分析を実施する。発見された全問題と推奨される是正措置を開発チームのワークフローまたは課題追跡システムに記録し、優先順位付けを行う。
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）：ソフトウェアリリース前に 脆弱性を識別し修正することで、悪用を防止する。自動化された手法を用いることで、脆弱性検知に必要な労力とリソースを削減し、追跡可能性と再現性を向上させる。実行可能コードには、バイナリ、直接実行可能なバイトコード、ソースコード、および組織が実行可能と判断するその他の形式のコードが含まれる。	PW.8.1: Determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing and, if so, which types of testing should be used.	PW.8.1: これまでのレビュー、分析、テストでは識別されなかった脆弱性を見つけるために、実行可能コードのテストを実施すべきかどうかを判断する。実施する場合、どの種類のテストを使用すべきかを決定する。
		PW.8.2: Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.	PW.8.2: テストの範囲を定め、テストを設計し、テストを実施し、結果を文書化する。これには、発見された全問題と推奨される是正措置を記録し、開発チームのワークフローまたは問題追跡システムで優先順位付けすることを含む。
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）：インストール時にソフトウェアのセキュリティを向上させ、脆弱なセキュリティ設定で展開される可能性を減らす。これにより、侵害リスクが高まるのを防ぐ。	PW.9.1: Define a secure baseline by determining how to configure each setting that has an effect on security or a security-related setting so that the default settings are secure and do not weaken the security functions provided by the platform, network infrastructure, or services.	PW.9.1：セキュリティに影響を与える設定やセキュリティ関連設定のデフォルト値を、プラットフォーム・ネットワークインフラ・サービスが提供するセキュリティ機能を弱体化させない安全な基準値に設定する。
		PW.9.2: Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators.	PW.9.2: デフォルト設定（該当する場合はデフォルト設定のグループ）を実装し、各設定をソフトウェア管理者向けに文書化する。
Respond to Vulnerabilities (RV)	脆弱性への対応（RV）
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）：脆弱性をより迅速に識別し、リスクに応じてより迅速に修正することで、攻撃者の機会を減少させることを支援する。	RV.1.1: Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports.	RV.1.1: ソフトウェアおよびソフトウェアが使用するサードパーティ製コンポーネントの潜在的な脆弱性について、ソフトウェア購入者、ユーザー、公開情報源から情報を収集し、信頼性のある報告はすべて調査する。
		RV.1.2: Review, analyze, and/or test the software’s code and its default and other common configurations to identify or confirm the presence of previously undetected vulnerabilities.	RV.1.2: ソフトウェアのコード、デフォルト設定、その他の一般的な設定をレビュー、分析、および／またはテストし、これまで検出されなかった脆弱性の存在を識別または確認する。
		RV.1.3: Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy.	RV.1.3: 脆弱性の開示と修正に対処する方針を定め、その方針を支えるために必要な役割、責任、プロセスを実施する。
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）：脆弱性がリスクに応じて修正され、攻撃者の機会を減少させることを支援する。	RV.2.1: Analyze each vulnerability to gather sufficient information about risk and plan its remediation or other risk response.	RV.2.1: 各脆弱性を分析し、リスクに関する十分な情報を収集し、その修正またはその他のリスク対応を計画する。
		RV.2.2: Plan and implement risk responses for vulnerabilities.	RV.2.2: 脆弱性に対するリスク対応策を計画し、実施する。
Analyze Vulnerabilities to Identify Their Root Causes (RV.3): Help reduce the frequency of vulnerabilities in the future.	脆弱性を分析して根本原因を識別する（RV.3）：将来の脆弱性の発生頻度を減らすのに役立つ。	RV.3.1: Analyze identified vulnerabilities to determine their root causes.	RV.3.1: 特定された脆弱性を分析し、その根本原因を特定する。
		RV.3.2: Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently.	RV.3.2: 時間の経過とともに根本原因を分析し、特定のセキュアコーディング手法が一貫して守られていないといったパターンを識別する。
		RV.3.3: Review software for similar vulnerabilities to eradicate a class of vulnerabilities and proactively remediate them rather than waiting for external reports.	RV.3.3: ソフトウェアをレビューし、類似の脆弱性を排除して脆弱性のクラスを根絶し、外部からの報告を待つのではなく、積極的に修正する。
		RV.3.4: Review the SDLC process, and update it if appropriate to prevent (or reduce the likelihood of) the root cause recurring in updates to the software or in new software that is created.	RV.3.4: SDLCプロセスを見直し、必要に応じて更新する。これにより、ソフトウェアの更新時や新規ソフトウェア開発時に根本原因が再発する可能性を防止（または低減）する。

関連

・Secure Software Development Framework SSDF

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2024.07.31 米国 NIST SP 800-218A 生成的AIとデュアルユース基盤モデルのための安全なソフトウェア開発プラクティス： SSDFコミュニティプロファイル

・2024.05.03 米国 商務省 NISTがAIに関する4つのドラフトを公開し、意見募集を開始 (2023.04.29)