| 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プロセスを見直し、必要に応じて更新する。これにより、ソフトウェアの更新時や新規ソフトウェア開発時に根本原因が再発する可能性を防止（または低減）する。 |
Recent Comments