diff --git a/README.md b/README.md index 6315a3402..dff9d7fdd 100644 --- a/README.md +++ b/README.md @@ -102,6 +102,7 @@ Check out the online documentation on https://intuitem.gitbook.io/ciso-assistant 30. FADP (Federal Act on Data Protection) 🇨🇭 31. NIST SP 800-171 rev2 🇺🇸 32. ANSSI : recommandations de sécurité pour un système d'IA générative 🇫🇷🤖 +33. NIST SP 800-218: Secure Software Development Framework (SSDF) 🖥️
diff --git a/backend/library/libraries/nist-ssdf-1.1.yaml b/backend/library/libraries/nist-ssdf-1.1.yaml new file mode 100644 index 000000000..1ab939427 --- /dev/null +++ b/backend/library/libraries/nist-ssdf-1.1.yaml @@ -0,0 +1,1237 @@ +urn: urn:intuitem:risk:library:nist-ssdf-1.1 +locale: en +ref_id: nist-ssdf-1.1 +name: Secure Software Development Framework (SSDF) +description: The Secure Software Development Framework (SSDF), SP 800-218, is a set + of fundamental, sound, and secure software development practices based on established + secure software development practice documents from organizations such as BSA, OWASP, + and SAFECode +copyright: With the exception of material marked as copyrighted, information presented + on NIST sites are considered public information and may be distributed or copied. +version: 1 +provider: NIST +packager: intuitem +objects: + framework: + urn: urn:intuitem:risk:framework:nist-ssdf-1.1 + ref_id: nist-ssdf-1.1 + name: Secure Software Development Framework (SSDF) + description: The Secure Software Development Framework (SSDF), SP 800-218, is + a set of fundamental, sound, and secure software development practices based + on established secure software development practice documents from organizations + such as BSA, OWASP, and SAFECode + requirement_nodes: + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po + assessable: false + depth: 1 + ref_id: PO + name: Prepare the Organization + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po + ref_id: PO.1 + name: Define Security Requirements for Software Development + description: "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\u2019s policies, business\ + \ objectives, and risk management strategy) and external sources (e.g., applicable\ + \ laws and regulations)." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1 + ref_id: PO.1.1 + description: "Identify and document all security requirements for the organization\u2019\ + s software development infrastructures and processes, and maintain the requirements\ + \ over time." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node5 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1.1 + description: "Example 1: Define policies for securing software development infrastructures\ + \ and their components, including development endpoints, throughout the SDLC\ + \ and maintaining that security.\nExample 2: Define policies for securing\ + \ software development processes throughout the SDLC and maintaining that\ + \ security, including for open-source and other third-party software components\ + \ utilized by software being developed.\nExample 3: Review and update security\ + \ requirements at least annually, or sooner if there are new requirements\ + \ from internal or external sources, or a major security incident targeting\ + \ software development infrastructure has occurred. \nExample 4: Educate affected\ + \ individuals on impending changes to requirements." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1 + ref_id: PO.1.2 + description: Identify and document all security requirements for organization-developed + software to meet, and maintain the requirements over time. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node7 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1.2 + description: "Example 1: Define policies that specify risk-based software architecture\ + \ and design requirements, such as making code modular to facilitate code\ + \ reuse and updates; isolating security components from other components during\ + \ execution; avoiding undocumented commands and settings; and providing features\ + \ that will aid software acquirers with the secure deployment, operation,\ + \ and maintenance of the software.\nExample 2: Define policies that specify\ + \ the security requirements for the organization\u2019s software, and verify\ + \ compliance at key points in the SDLC (e.g., classes of software flaws verified\ + \ by gates, responses to vulnerabilities discovered in released software).\n\ + Example 3: Analyze the risk of applicable technology stacks (e.g., languages,\ + \ environments, deployment models), and recommend or require the use of stacks\ + \ that will reduce risk compared to others.\nExample 4: Define policies that\ + \ specify what needs to be archived for each software release (e.g., code,\ + \ package files, third-party libraries, documentation, data inventory) and\ + \ how long it needs to be retained based on the SDLC model, software end-of-life,\ + \ and other factors. \nExample 5: Ensure that policies cover the entire software\ + \ life cycle, including notifying users of the impending end of software support\ + \ and the date of software end-of-life.\nExample 6: Review all security requirements\ + \ at least annually, or sooner if there are new requirements from internal\ + \ or external sources, a major vulnerability is discovered in released software,\ + \ or a major security incident targeting organization-developed software has\ + \ occurred. \nExample 7: Establish and follow processes for handling requirement\ + \ exception requests, including periodic reviews of all approved exceptions." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1.3 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1 + ref_id: PO.1.3 + description: "Communicate requirements to all third parties who will provide\ + \ commercial software components to the organization for reuse by the organization\u2019\ + s own software. [Formerly PW.3.1]" + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node9 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.1.3 + description: "Example 1: Define a core set of security requirements for software\ + \ components, and include it in acquisition documents, software contracts,\ + \ and other agreements with third parties.\nExample 2: Define security-related\ + \ criteria for selecting software; the criteria can include the third party\u2019\ + s vulnerability disclosure program and product security incident response\ + \ capabilities or the third party\u2019s adherence to organization-defined\ + \ practices.\nExample 3: Require third parties to attest that their software\ + \ complies with the organization\u2019s security requirements.\nExample 4:\ + \ Require third parties to provide provenance data and integrity verification\ + \ mechanisms for all components of their software.\nExample 5: Establish and\ + \ follow processes to address risk when there are security requirements that\ + \ third-party software components to be acquired do not meet; this should\ + \ include periodic reviews of all approved exceptions to requirements." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po + ref_id: PO.2 + name: Implement Roles and Responsibilities + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2 + ref_id: PO.2.1 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node12 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2.1 + description: 'Example 1: Define SDLC-related roles and responsibilities for + all members of the software development team. + + Example 2: Integrate the security roles into the software development team. + + Example 3: Define roles and responsibilities for cybersecurity staff, security + champions, project managers and leads, senior management, software developers, + software testers, software assurance leads and staff, product owners, operations + and platform engineers, and others involved in the SDLC. + + Example 4: Conduct an annual review of all roles and responsibilities. + + Example 5: Educate affected individuals on impending changes to roles and + responsibilities, and confirm that the individuals understand the changes + and agree to follow them. + + Example 6: Implement and use tools and processes to promote communication + and engagement among individuals with SDLC-related roles and responsibilities, + such as creating messaging channels for team discussions. + + Example 7: Designate a group of individuals or a team as the code owner for + each project.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2 + ref_id: PO.2.2 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node14 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2.2 + description: 'Example 1: Document the desired outcomes of training for each + role. + + Example 2: Define the type of training or curriculum required to achieve the + desired outcome for each role. + + Example 3: Create a training plan for each role. + + Example 4: Acquire or create training for each role; acquired training may + need to be customized for the organization. + + Example 5: Measure outcome performance to identify areas where changes to + training may be beneficial.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2.3 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2 + ref_id: PO.2.3 + description: Obtain upper management or authorizing official commitment to secure + development, and convey that commitment to all with development-related roles + and responsibilities. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node16 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.2.3 + description: "Example 1: Appoint a single leader or leadership team to be responsible\ + \ for the entire secure software development process, including being accountable\ + \ for releasing software to production and delegating responsibilities as\ + \ appropriate.\nExample 2: Increase authorizing officials\u2019 awareness\ + \ of the risks of developing software without integrating security throughout\ + \ the development life cycle and the risk mitigation provided by secure development\ + \ practices.\nExample 3: Assist upper management in incorporating secure development\ + \ support into their communications with personnel with development-related\ + \ roles and responsibilities.\nExample 4: Educate all personnel with development-related\ + \ roles and responsibilities on upper management\u2019s commitment to secure\ + \ development and the importance of secure development to the organization." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po + ref_id: PO.3 + name: Implement Supporting Toolchains + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3 + ref_id: PO.3.1 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node19 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3.1 + description: "Example 1: Define categories of toolchains, and specify the mandatory\ + \ tools or tool types to be used for each category.\nExample 2: Identify security\ + \ tools to integrate into the developer toolchain.\nExample 3: Define what\ + \ information is to be passed between tools and what data formats are to be\ + \ used.\nExample 4: Evaluate tools\u2019 signing capabilities to create immutable\ + \ records/logs for auditability within the toolchain.\nExample 5: Use automated\ + \ technology for toolchain management and orchestration." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3 + ref_id: PO.3.2 + description: Follow recommended security practices to deploy, operate, and maintain + tools and toolchains. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node21 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3.2 + description: 'Example 1: Evaluate, select, and acquire tools, and assess the + security of each tool. + + Example 2: Integrate tools with other tools and existing software development + processes and workflows. + + Example 3: Use code-based configuration for toolchains (e.g., pipelines-as-code, + toolchains-as-code). + + Example 4: Implement the technologies and processes needed for reproducible + builds. + + Example 5: Update, upgrade, or replace tools as needed to address tool vulnerabilities + or add new tool capabilities. + + Example 6: Continuously monitor tools and tool logs for potential operational + and security issues, including policy violations and anomalous behavior. + + Example 7: Regularly verify the integrity and check the provenance of each + tool to identify potential problems. + + Example 8: See PW.6 regarding compiler, interpreter, and build tools. + + Example 9: See PO.5 regarding implementing and maintaining secure environments.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3.3 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3 + ref_id: PO.3.3 + description: Configure tools to generate artifacts of their support of secure + software development practices as defined by the organization. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node23 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.3.3 + description: 'Example 1: Use existing tooling (e.g., workflow tracking, issue + tracking, value stream mapping) to create an audit trail of the secure development-related + actions that are performed for continuous improvement purposes. + + Example 2: Determine how often the collected information should be audited, + and implement the necessary processes. + + Example 3: Establish and enforce security and retention policies for artifact + data. + + Example 4: Assign responsibility for creating any needed artifacts that tools + cannot generate.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.4 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po + ref_id: PO.4 + name: Define and Use Criteria for Software Security Checks + description: "Help ensure that the software resulting from the SDLC meets the\ + \ organization\u2019s expectations by defining and using criteria for checking\ + \ the software\u2019s security during development." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.4.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.4 + ref_id: PO.4.1 + description: Define criteria for software security checks and track throughout + the SDLC. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node26 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.4.1 + description: "Example 1: Ensure that the criteria adequately indicate how effectively\ + \ security risk is being managed.\nExample 2: Define key performance indicators\ + \ (KPIs), key risk indicators (KRIs), vulnerability severity scores, and other\ + \ measures for software security.\nExample 3: Add software security criteria\ + \ to existing checks (e.g., the Definition of Done in agile SDLC methodologies).\n\ + Example 4: Review the artifacts generated as part of the software development\ + \ workflow system to determine if they meet the criteria. \nExample 5: Record\ + \ security check approvals, rejections, and exception requests as part of\ + \ the workflow and tracking system.\nExample 6: Analyze collected data in\ + \ the context of the security successes and failures of each development project,\ + \ and use the results to improve the SDLC." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.4.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.4 + ref_id: PO.4.2 + description: Implement processes, mechanisms, etc. to gather and safeguard the + necessary information in support of the criteria. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node28 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.4.2 + description: 'Example 1: Use the toolchain to automatically gather information + that informs security decision-making. + + Example 2: Deploy additional tools if needed to support the generation and + collection of information supporting the criteria. + + Example 3: Automate decision-making processes utilizing the criteria, and + periodically review these processes. + + Example 4: Only allow authorized personnel to access the gathered information, + and prevent any alteration or deletion of the information.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.5 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po + ref_id: PO.5 + name: Implement and Maintain Secure Environments for Software Development + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.5.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.5 + ref_id: PO.5.1 + description: Separate and protect each environment involved in software development. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node31 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.5.1 + description: "Example 1: Use multi-factor, risk-based authentication and conditional\ + \ access for each environment.\nExample 2: Use network segmentation and access\ + \ controls to separate the environments from each other and from production\ + \ environments, and to separate components from each other within each non-production\ + \ environment, in order to reduce attack surfaces and attackers\u2019 lateral\ + \ movement and privilege/access escalation.\nExample 3: Enforce authentication\ + \ and tightly restrict connections entering and exiting each software development\ + \ environment, including minimizing access to the internet to only what is\ + \ necessary.\nExample 4: Minimize direct human access to toolchain systems,\ + \ such as build services. Continuously monitor and audit all access attempts\ + \ and all use of privileged access.\nExample 5: Minimize the use of production-environment\ + \ software and services from non-production environments.\nExample 6: Regularly\ + \ log, monitor, and audit trust relationships for authorization and access\ + \ between the environments and between the components within each environment.\n\ + Example 7: Continuously log and monitor operations and alerts across all components\ + \ of the development environment to detect, respond, and recover from attempted\ + \ and actual cyber incidents.\nExample 8: Configure security controls and\ + \ other tools involved in separating and protecting the environments to generate\ + \ artifacts for their activities.\nExample 9: Continuously monitor all software\ + \ deployed in each environment for new vulnerabilities, and respond to vulnerabilities\ + \ appropriately following a risk-based approach.\nExample 10: Configure and\ + \ implement measures to secure the environments\u2019 hosting infrastructures\ + \ following a zero trust architecture." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.5.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.5 + ref_id: PO.5.2 + description: Secure and harden development endpoints (i.e., endpoints for software + designers, developers, testers, builders, etc.) to perform development-related + tasks using a risk-based approach. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node33 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:po.5.2 + description: 'Example 1: Configure each development endpoint based on approved + hardening guides, checklists, etc.; for example, enable FIPS-compliant encryption + of all sensitive data at rest and in transit. + + Example 2: Configure each development endpoint and the development resources + to provide the least functionality needed by users and services and to enforce + the principle of least privilege. + + Example 3: Continuously monitor the security posture of all development endpoints, + including monitoring and auditing all use of privileged access. + + Example 4: Configure security controls and other tools involved in securing + and hardening development endpoints to generate artifacts for their activities. + + Example 5: Require multi-factor authentication for all access to development + endpoints and development resources. + + Example 6: Provide dedicated development endpoints on non-production networks + for performing all development-related tasks. Provide separate endpoints on + production networks for all other tasks. + + Example 7: Configure each development endpoint following a zero trust architecture.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps + assessable: false + depth: 1 + ref_id: PS + name: Protect the Software + description: Organizations should protect all components of their software from + tampering and unauthorized access. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.1 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps + ref_id: PS.1 + name: Protect All Forms of Code from Unauthorized Access and Tampering + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.1.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.1 + ref_id: PS.1.1 + description: "Store all forms of code \u2013 including source code, executable\ + \ code, and configuration-as-code \u2013 based on the principle of least\ + \ privilege so that only authorized personnel, tools, services, etc. have\ + \ access." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node37 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.1.1 + description: 'Example 1: Store all source code and configuration-as-code in + a code repository, and restrict access to it based on the nature of the code. + For example, open-source code intended for public access may need its integrity + and availability protected; other code may also need its confidentiality protected. + + Example 2: Use version control features of the repository to track all changes + made to the code with accountability to the individual account. + + Example 3: Use commit signing for code repositories. + + Example 4: Have the code owner review and approve all changes made to the + code by others. + + Example 5: Use code signing to help protect the integrity of executables. + + Example 6: Use cryptography (e.g., cryptographic hashes) to help protect file + integrity.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.2 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps + ref_id: PS.2 + name: Provide a Mechanism for Verifying Software Release Integrity + description: Help software acquirers ensure that the software they acquire is + legitimate and has not been tampered with. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.2.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.2 + ref_id: PS.2.1 + description: Make software integrity verification information available to software + acquirers. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node40 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.2.1 + description: "Example 1: Post cryptographic hashes for release files on a well-secured\ + \ website.\nExample 2: Use an established certificate authority for code signing\ + \ so that consumers\u2019 operating systems or other tools and services can\ + \ confirm the validity of signatures before use.\nExample 3: Periodically\ + \ review the code signing processes, including certificate renewal, rotation,\ + \ revocation, and protection." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.3 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps + ref_id: PS.3 + name: Archive and Protect Each Software Release + description: Preserve software releases in order to help identify, analyze, + and eliminate vulnerabilities discovered in the software after release. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.3.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.3 + ref_id: PS.3.1 + description: Securely archive the necessary files and supporting data (e.g., + integrity verification information, provenance data) to be retained for each + software release. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node43 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.3.1 + description: "Example 1: Store the release files, associated images, etc. in\ + \ repositories following the organization\u2019s established policy. Allow\ + \ read-only access to them by necessary personnel and no access by anyone\ + \ else.\nExample 2: Store and protect release integrity verification information\ + \ and provenance data, such as by keeping it in a separate location from the\ + \ release files or by signing the data." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.3.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.3 + ref_id: PS.3.2 + description: Collect, safeguard, maintain, and share provenance data for all + components of each software release (e.g., in a software bill of materials + [SBOM]). + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node45 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:ps.3.2 + description: "Example 1: Make the provenance data available to software acquirers\ + \ in accordance with the organization\u2019s policies, preferably using standards-based\ + \ formats.\nExample 2: Make the provenance data available to the organization\u2019\ + s operations and response teams to aid them in mitigating software vulnerabilities.\n\ + Example 3: Protect the integrity of provenance data, and provide a way for\ + \ recipients to verify provenance data integrity.\nExample 4: Update the provenance\ + \ data every time any of the software\u2019s components are updated." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + assessable: false + depth: 1 + ref_id: PW + name: Produce Well-Secured Software + description: Organizations should produce well-secured software with minimal + security vulnerabilities in its releases. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.1 + name: Design Software to Meet Security Requirements and Mitigate Security Risks + description: "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\u2019s 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." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1 + ref_id: PW.1.1 + description: "Use forms of risk modeling \u2013 such as threat modeling, attack\ + \ modeling, or attack surface mapping \u2013 to help assess the security risk\ + \ for the software." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node49 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1.1 + description: 'Example 1: Train the development team (security champions, in + particular) or collaborate with a risk modeling expert to create models and + analyze how to use a risk-based approach to communicate the risks and determine + how to address them, including implementing mitigations. + + Example 2: Perform more rigorous assessments for high-risk areas, such as + protecting sensitive data and safeguarding identification, authentication, + and access control, including credential management. + + Example 3: Review vulnerability reports and statistics for previous software + to inform the security risk assessment. + + Example 4: Use data classification methods to identify and characterize each + type of data that the software will interact with.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1 + ref_id: PW.1.2 + description: "Track and maintain the software\u2019s security requirements,\ + \ risks, and design decisions." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node51 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1.2 + description: "Example 1: Record the response to each risk, including how mitigations\ + \ are to be achieved and what the rationales are for any approved exceptions\ + \ to the security requirements. Add any mitigations to the software\u2019\ + s security requirements.\nExample 2: Maintain records of design decisions,\ + \ risk responses, and approved exceptions that can be used for auditing and\ + \ maintenance purposes throughout the rest of the software life cycle.\nExample\ + \ 3: Periodically re-evaluate all approved exceptions to the security requirements,\ + \ and implement changes as needed." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1.3 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1 + ref_id: PW.1.3 + description: 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] + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node53 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.1.3 + description: 'Example 1: Maintain one or more software repositories of modules + for supporting standardized security features and services. + + Example 2: Determine secure configurations for modules for supporting standardized + security features and services, and make these configurations available (e.g., + as configuration-as-code) so developers can readily use them. + + Example 3: Define criteria for which security features and services must be + supported by software to be developed.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.2 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.2 + name: Review the Software Design to Verify Compliance with Security Requirements + and Risk Information + description: Help ensure that the software will meet the security requirements + and satisfactorily address the identified risk information. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.2.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.2 + ref_id: PW.2.1 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node56 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.2.1 + description: "Example 1: Review the software design to confirm that it addresses\ + \ applicable security requirements.\nExample 2: Review the risk models created\ + \ during software design to determine if they appear to adequately identify\ + \ the risks.\nExample 3: Review the software design to confirm that it satisfactorily\ + \ addresses the risks identified by the risk models.\nExample 4: Have the\ + \ software\u2019s designer correct failures to meet the requirements.\nExample\ + \ 5: Change the design and/or the risk response strategy if the security requirements\ + \ cannot be met.\nExample 6: Record the findings of design reviews to serve\ + \ as artifacts (e.g., in the software specification, in the issue tracking\ + \ system, in the threat model)." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.4 + name: Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating + Functionality + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4 + ref_id: PW.4.1 + description: "Acquire and maintain well-secured software components (e.g., software\ + \ libraries, modules, middleware, frameworks) from commercial, open-source,\ + \ and other third-party developers for use by the organization\u2019s software." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node59 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4.1 + description: "Example 1: Review and evaluate third-party software components\ + \ in the context of their expected use. If a component is to be used in a\ + \ substantially different way in the future, perform the review and evaluation\ + \ again with that new context in mind.\nExample 2: Determine secure configurations\ + \ for software components, and make these available (e.g., as configuration-as-code)\ + \ so developers can readily use the configurations.\nExample 3: Obtain provenance\ + \ information (e.g., SBOM, source composition analysis, binary software composition\ + \ analysis) for each software component, and analyze that information to better\ + \ assess the risk that the component may introduce.\nExample 4: Establish\ + \ one or more software repositories to host sanctioned and vetted open-source\ + \ components.\nExample 5: Maintain a list of organization-approved commercial\ + \ software components and component versions along with their provenance data.\n\ + Example 6: Designate which components must be included in software to be developed.\n\ + Example 7: Implement processes to update deployed software components to newer\ + \ versions, and retain older versions of software components until all transitions\ + \ from those versions have been completed successfully.\nExample 8: If the\ + \ integrity or provenance of acquired binaries cannot be confirmed, build\ + \ binaries from source code after verifying the source code\u2019s integrity\ + \ and provenance." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4 + ref_id: PW.4.2 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node61 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4.2 + description: 'Example 1: Follow organization-established security practices + for secure software development when creating and maintaining the components. + + Example 2: Determine secure configurations for software components, and make + these available (e.g., as configuration-as-code) so developers can readily + use the configurations. + + Example 3: Maintain one or more software repositories for these components. + + Example 4: Designate which components must be included in software to be developed. + + Example 5: Implement processes to update deployed software components to newer + versions, and maintain older versions of software components until all transitions + from those versions have been completed successfully.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4.4 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4 + ref_id: PW.4.4 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node63 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.4.4 + description: 'Example 1: Regularly check whether there are publicly known vulnerabilities + in the software modules and services that vendors have not yet fixed. + + Example 2: Build into the toolchain automatic detection of known vulnerabilities + in software components. + + Example 3: Use existing results from commercial services for vetting the software + modules and services. + + Example 4: Ensure that each software component is still actively maintained + and has not reached end of life; this should include new vulnerabilities found + in the software being remediated. + + Example 5: Determine a plan of action for each software component that is + no longer being maintained or will not be available in the near future. + + Example 6: Confirm the integrity of software components through digital signatures + or other mechanisms. + + Example 7: Review, analyze, and/or test code. See PW.7 and PW.8.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.5 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.5 + name: Create Source Code by Adhering to Secure Coding Practices + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.5.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.5 + ref_id: PW.5.1 + description: "Follow all secure coding practices that are appropriate to the\ + \ development languages and environment to meet the organization\u2019s requirements." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node66 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.5.1 + description: 'Example 1: Validate all inputs, and validate and properly encode + all outputs. + + Example 2: Avoid using unsafe functions and calls. + + Example 3: Detect errors, and handle them gracefully. + + Example 4: Provide logging and tracing capabilities. + + Example 5: Use development environments with automated features that encourage + or require the use of secure coding practices with just-in-time training-in-place. + + Example 6: Follow procedures for manually ensuring compliance with secure + coding practices when automated methods are insufficient or unavailable. + + Example 7: Use tools (e.g., linters, formatters) to standardize the style + and formatting of the source code. + + Example 8: Check for other vulnerabilities that are common to the development + languages and environment. + + Example 9: Have the developer review their own human-readable code to complement + (not replace) code review performed by other people or tools. See PW.7.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.6 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.6 + name: Configure the Compilation, Interpreter, and Build Processes to Improve + Executable Security + description: Decrease the number of security vulnerabilities in the software + and reduce costs by eliminating vulnerabilities before testing occurs. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.6.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.6 + ref_id: PW.6.1 + description: Use compiler, interpreter, and build tools that offer features + to improve executable security. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node69 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.6.1 + description: 'Example 1: Use up-to-date versions of compiler, interpreter, and + build tools. + + Example 2: Follow change management processes when deploying or updating compiler, + interpreter, and build tools, and audit all unexpected changes to tools. + + Example 3: Regularly validate the authenticity and integrity of compiler, + interpreter, and build tools. See PO.3.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.6.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.6 + ref_id: PW.6.2 + description: Determine which compiler, interpreter, and build tool features + should be used and how each should be configured, then implement and use the + approved configurations. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node71 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.6.2 + description: "Example 1: Enable compiler features that produce warnings for\ + \ poorly secured code during the compilation process.\nExample 2: Implement\ + \ the \u201Cclean build\u201D concept, where all compiler warnings are treated\ + \ as errors and eliminated except those determined to be false positives or\ + \ irrelevant.\nExample 3: Perform all builds in a dedicated, highly controlled\ + \ build environment.\nExample 4: Enable compiler features that randomize or\ + \ obfuscate execution characteristics, such as memory location usage, that\ + \ would otherwise be predictable and thus potentially exploitable.\nExample\ + \ 5: Test to ensure that the features are working as expected and are not\ + \ inadvertently causing any operational issues or other problems.\nExample\ + \ 6: Continuously verify that the approved configurations are being used.\n\ + Example 7: Make the approved tool configurations available as configuration-as-code\ + \ so developers can readily use them." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.7 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.7 + name: Review and/or Analyze Human-Readable Code to Identify Vulnerabilities + and Verify Compliance with Security Requirements + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.7.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.7 + ref_id: PW.7.1 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node74 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.7.1 + description: "Example 1: Follow the organization\u2019s policies or guidelines\ + \ for when code review should be performed and how it should be conducted.\ + \ This may include third-party code and reusable code modules written in-house.\n\ + Example 2: Follow the organization\u2019s policies or guidelines for when\ + \ code analysis should be performed and how it should be conducted.\nExample\ + \ 3: Choose code review and/or analysis methods based on the stage of the\ + \ software." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.7.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.7 + ref_id: PW.7.2 + description: "Perform the code review and/or code analysis based on the organization\u2019\ + s secure coding standards, and record and triage all discovered issues and\ + \ recommended remediations in the development team\u2019s workflow or issue\ + \ tracking system." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node76 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.7.2 + description: "Example 1: Perform peer review of code, and review any existing\ + \ code review, analysis, or testing results as part of the peer review.\n\ + Example 2: Use expert reviewers to check code for backdoors and other malicious\ + \ content.\nExample 3: Use peer reviewing tools that facilitate the peer review\ + \ process, and document all discussions and other feedback.\nExample 4: Use\ + \ a static analysis tool to automatically check code for vulnerabilities and\ + \ compliance with the organization\u2019s secure coding standards with a human\ + \ reviewing the issues reported by the tool and remediating them as necessary.\n\ + Example 5: Use review checklists to verify that the code complies with the\ + \ requirements.\nExample 6: Use automated tools to identify and remediate\ + \ documented and verified unsafe software practices on a continuous basis\ + \ as human-readable code is checked into the code repository.\nExample 7:\ + \ Identify and document the root causes of discovered issues.\nExample 8:\ + \ Document lessons learned from code review and analysis in a wiki that developers\ + \ can access and search." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.8 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.8 + name: Test Executable Code to Identify Vulnerabilities and Verify Compliance + with Security Requirements + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.8.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.8 + ref_id: PW.8.1 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node79 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.8.1 + description: "Example 1: Follow the organization\u2019s policies or guidelines\ + \ for when code testing should be performed and how it should be conducted\ + \ (e.g., within a sandboxed environment). This may include third-party executable\ + \ code and reusable executable code modules written in-house.\nExample 2:\ + \ Choose testing methods based on the stage of the software." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.8.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.8 + ref_id: PW.8.2 + description: "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\u2019s workflow or\ + \ issue tracking system." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node81 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.8.2 + description: "Example 1: Perform robust functional testing of security features.\n\ + Example 2: Integrate dynamic vulnerability testing into the project\u2019\ + s automated test suite.\nExample 3: Incorporate tests for previously reported\ + \ vulnerabilities into the project\u2019s test suite to ensure that errors\ + \ are not reintroduced.\nExample 4: Take into consideration the infrastructures\ + \ and technology stacks that the software will be used with in production\ + \ when developing test plans.\nExample 5: Use fuzz testing tools to find issues\ + \ with input handling.\nExample 6: If resources are available, use penetration\ + \ testing to simulate how an attacker might attempt to compromise the software\ + \ in high-risk scenarios.\nExample 7: Identify and record the root causes\ + \ of discovered issues.\nExample 8: Document lessons learned from code testing\ + \ in a wiki that developers can access and search.\nExample 9: Use source\ + \ code, design records, and other resources when developing test plans." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.9 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw + ref_id: PW.9 + name: Configure Software to Have Secure Settings by Default + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.9.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.9 + ref_id: PW.9.1 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node84 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.9.1 + description: 'Example 1: Conduct testing to ensure that the settings, including + the default settings, are working as expected and are not inadvertently causing + any security weaknesses, operational issues, or other problems.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.9.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.9 + ref_id: PW.9.2 + description: Implement the default settings (or groups of default settings, + if applicable), and document each setting for software administrators. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node86 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:pw.9.2 + description: "Example 1: Verify that the approved configuration is in place\ + \ for the software.\nExample 2: Document each setting\u2019s purpose, options,\ + \ default value, security relevance, potential operational impact, and relationships\ + \ with other settings.\nExample 3: Use authoritative programmatic technical\ + \ mechanisms to record how each setting can be implemented and assessed by\ + \ software administrators.\nExample 4: Store the default configuration in\ + \ a usable format and follow change control practices for modifying it (e.g.,\ + \ configuration-as-code)." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv + assessable: false + depth: 1 + ref_id: RV + name: Respond to Vulnerabilities + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv + ref_id: RV.1 + name: Identify and Confirm Vulnerabilities on an Ongoing Basis + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1 + ref_id: RV.1.1 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node90 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1.1 + description: 'Example 1: Monitor vulnerability databases , security mailing + lists, and other sources of vulnerability reports through manual or automated + means. + + Example 2: Use threat intelligence sources to better understand how vulnerabilities + in general are being exploited. + + Example 3: Automatically review provenance and software composition data for + all software components to identify any new vulnerabilities they have.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1 + ref_id: RV.1.2 + description: "Review, analyze, and/or test the software\u2019s code to identify\ + \ or confirm the presence of previously undetected vulnerabilities." + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node92 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1.2 + description: 'Example 1: Configure the toolchain to perform automated code analysis + and testing on a regular or continuous basis for all supported releases. + + Example 2: See PW.7 and PW.8.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1.3 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1 + ref_id: RV.1.3 + description: Have a policy that addresses vulnerability disclosure and remediation, + and implement the roles, responsibilities, and processes needed to support + that policy. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node94 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.1.3 + description: 'Example 1: Establish a vulnerability disclosure program, and make + it easy for security researchers to learn about your program and report possible + vulnerabilities. + + Example 2: Have a Product Security Incident Response Team (PSIRT) and processes + in place to handle the responses to vulnerability reports and incidents, including + communications plans for all stakeholders. + + Example 3: Have a security response playbook to handle a generic reported + vulnerability, a report of zero-days, a vulnerability being exploited in the + wild, and a major ongoing incident involving multiple parties and open-source + software components. + + Example 4: Periodically conduct exercises of the product security incident + response processes.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.2 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv + ref_id: RV.2 + name: Assess, Prioritize, and Remediate Vulnerabilities + description: Help ensure that vulnerabilities are remediated in accordance with + risk to reduce the window of opportunity for attackers. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.2.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.2 + ref_id: RV.2.1 + description: Analyze each vulnerability to gather sufficient information about + risk to plan its remediation or other risk response. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node97 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.2.1 + description: 'Example 1: Use existing issue tracking software to record each + vulnerability. + + Example 2: Perform risk calculations for each vulnerability based on estimates + of its exploitability, the potential impact if exploited, and any other relevant + characteristics.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.2.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.2 + ref_id: RV.2.2 + description: Plan and implement risk responses for vulnerabilities. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node99 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.2.2 + description: 'Example 1: Make a risk-based decision as to whether each vulnerability + will be remediated or if the risk will be addressed through other means (e.g., + risk acceptance, risk transference), and prioritize any actions to be taken. + + Example 2: If a permanent mitigation for a vulnerability is not yet available, + determine how the vulnerability can be temporarily mitigated until the permanent + solution is available, and add that temporary remediation to the plan. + + Example 3: Develop and release security advisories that provide the necessary + information to software acquirers, including descriptions of what the vulnerabilities + are, how to find instances of the vulnerable software, and how to address + them (e.g., where to get patches and what the patches change in the software; + what configuration settings may need to be changed; how temporary workarounds + could be implemented). + + Example 4: Deliver remediations to acquirers via an automated and trusted + delivery mechanism. A single remediation could address multiple vulnerabilities. + + Example 5: Update records of design decisions, risk responses, and approved + exceptions as needed. See PW.1.2.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3 + assessable: false + depth: 2 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv + ref_id: RV.3 + name: Analyze Vulnerabilities to Identify Their Root Causes + description: Help reduce the frequency of vulnerabilities in the future. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.1 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3 + ref_id: RV.3.1 + description: Analyze identified vulnerabilities to determine their root causes. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node102 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.1 + description: 'Example 1: Record the root cause of discovered issues. + + Example 2: Record lessons learned through root cause analysis in a wiki that + developers can access and search.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.2 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3 + ref_id: RV.3.2 + description: Analyze the root causes over time to identify patterns, such as + a particular secure coding practice not being followed consistently. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node104 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.2 + description: 'Example 1: Record lessons learned through root cause analysis + in a wiki that developers can access and search. + + Example 2: Add mechanisms to the toolchain to automatically detect future + instances of the root cause. + + Example 3: Update manual processes to detect future instances of the root + cause.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.3 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3 + ref_id: RV.3.3 + description: Review the software for similar vulnerabilities to eradicate a + class of vulnerabilities, and proactively fix them rather than waiting for + external reports. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node106 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.3 + description: 'Example 1: See PW.7 and PW.8.' + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.4 + assessable: true + depth: 3 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3 + ref_id: RV.3.4 + description: 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. + - urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:node108 + assessable: false + depth: 4 + parent_urn: urn:intuitem:risk:req_node:nist-ssdf-1.1:rv.3.4 + description: 'Example 1: Record lessons learned through root cause analysis + in a wiki that developers can access and search. + + Example 2: Plan and implement changes to the appropriate SDLC practices.' diff --git a/tools/nist/sp-800-218/nist-ssdf-1.1.xlsx b/tools/nist/sp-800-218/nist-ssdf-1.1.xlsx new file mode 100644 index 000000000..d3d335dd6 Binary files /dev/null and b/tools/nist/sp-800-218/nist-ssdf-1.1.xlsx differ