ezesecops/rmf-ato-core huggingface dataset:
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > PW > PW.8 > PW.8.2

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. Example 1: Perform robust functional testing of security features. Example 2: Integrate dynamic vulnerability testing into the project's automated test suite. Example 3: Incorporate tests for previously reported vulnerabilities into the project's test suite to ensure that errors are not reintroduced. Example 4: Take into consideration the infrastructures and technology stacks that the software will be used with in production when developing test plans. Example 5: Use fuzz testing tools to find issues with input handling. Example 6: If resources are available, use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios. Example 7: Identify and record the root causes of discovered issues. Example 8: Document lessons learned from code testing in a wiki that developers can access and search. Example 9: Use source code, design records, and other resources when developing test plans. BSAFSS: TV.3, TV.5, PD.1-4 BSIMM: ST1.1, ST1.3, ST1.4, ST2.4, ST2.5, ST2.6, ST3.3, ST3.4, ST3.5, ST3.6, PT1.1, PT1.2, PT1.3, PT3.1 EO14028: 4e(iv), 4e(v), 4e(ix) IDASOAR: 7, 8, 10, 11, 38, 39, 43, 44, 48, 55, 56, 57 IEC62443: SM-5, SM-13, SI-1, SVV-1, SVV-2, SVV-3, SVV-4, SVV-5 IR8397: 2.6, 2.7, 2.8, 2.9, 2.10, 2.11 ISO27034: 7.3.6 MSSDL: 10, 11 NISTLABEL: 2.2.2.2 OWASPMASVS: 7.5 OWASPSAMM: ST1-A, ST1-B, ST2-A, ST2-B, ST3-A PCISSLC: 4.1 SCAGILE: Operational Security Tasks 10, 11; Tasks Requiring the Help of Security Experts 4, 5, 6, 7 SCFPSSD: Perform Dynamic Analysis Security Testing, Fuzz Parsers, Network Vulnerability Scanning, Perform Automated Functional Testing of Security Features/Mitigations, Perform Penetration Testing SCSIC: Peer Reviews and Security Testing SP80053: SA-11, SA-11(5), SA-11(8), SA-15(7) SP800161: SA-11, SA-11(5), SA-11(8), SA-15(7) SP800181: SP-DEV-001, SP-DEV-002; T0013, T0028, T0169, T0176, T0253, T0266, T0456, T0516; K0009, K0039, K0070, K0272, K0339, K0342, K0362, K0536, K0624; S0001, S0015, S0046, S0051, S0078, S0081, S0083, S0135, S0137, S0167, S0242; A0015 Practices Tasks Notional Implementation Examples References 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.
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > PW > PW.9 > PW.9.1

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. 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. BSAFSS: CF.1 BSIMM: SE2.2 EO14028: 4e(iv), 4e(ix) IDASOAR: 23 IEC62443: SD-4, SVV-1, SG-1 ISO27034: 7.3.5 SCAGILE: Tasks Requiring the Help of Security Experts 12 SCSIC: Vendor Software Delivery Integrity Controls, Vendor Software Development Integrity Controls SP800181: SP-DEV-002; K0009, K0039, K0073, K0153, K0165, K0275, K0531; S0167
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > PW > PW.9 > PW.9.2

PW.9.2: Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators. Example 1: Verify that the approved configuration is in place for the software. Example 2: Document each setting's purpose, options, default value, security relevance, potential operational impact, and relationships with other settings. Example 3: Use authoritative programmatic technical mechanisms to record how each setting can be implemented and assessed by software administrators. Example 4: Store the default configuration in a usable format and follow change control practices for modifying it (e.g., configuration-as-code). BSAFSS: CF.1 BSIMM: SE2.2 EO14028: 4e(iv), 4e(ix) IDASOAR: 23 IEC62443: SG-3 OWASPSAMM: OE1-A PCISSLC: 8.1, 8.2 SCAGILE: Tasks Requiring the Help of Security Experts 12 SCFPSSD: Verify Secure Configurations and Use of Platform Mitigation SCSIC: Vendor Software Delivery Integrity Controls, Vendor Software Development Integrity Controls SP80053: SA-5, SA-8(23) SP800161: SA-5, SA-8(23) SP800181: SP-DEV-001; K0009, K0039, K0073, K0153, K0165, K0275, K0531 Respond to Vulnerabilities (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.
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.1 > RV.1.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. Example 1: Monitor vulnerability databases9, 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. BSAFSS: VM.1-3, VM.3 BSIMM: AM1.5, CMVM1.2, CMVM2.1, CMVM3.4, CMVM3.7 CNCFSSCP: Securing Materials-Verification EO14028: 4e(iv), 4e(vi), 4e(viii), 4e(ix) IEC62443: DM-1, DM-2, DM-3 ISO29147: 6.2.1, 6.2.2, 6.2.4, 6.3, 6.5 ISO30111: 7.1.3 OWASPSAMM: IM1-A, IM2-B, EH1-B OWASPSCVS: 4 PCISSLC: 3.4, 4.1, 9.1 SCAGILE: Operational Security Task 5 SCFPSSD: Vulnerability Response and Disclosure SCTPC: MONITOR1 SP80053: SA-10, SR-3, SR-4 SP800161: SA-10, SR-3, SR-4 SP800181: K0009, K0038, K0040, K0070, K0161, K0362; S0078
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.1 > RV.1.2

RV.1.2: Review, analyze, and/or test the software's code to identify or confirm the presence of previously undetected vulnerabilities. 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. BSAFSS: VM.1-2, VM.2-1 BSIMM: CMVM3.1 EO14028: 4e(iv), 4e(vi), 4e(viii), 4e(ix) IEC62443: SI-1, SVV-2, SVV-3, SVV-4, DM-1, DM-2 ISO27034: 7.3.6 An example is the National Vulnerability Database (NVD) (https://nvd.nist.gov/). Practices Tasks Notional Implementation Examples References ISO29147: 6.4 ISO30111: 7.1.4 PCISSLC: 3.4, 4.1 SCAGILE: Operational Security Tasks 10, 11 SP80053: SA-11 SP800161: SA-11 SP800181: SP-DEV-002; K0009, K0039, K0153
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.1 > RV.1.3

RV.1.3: Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy. 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. BSAFSS: VM.1-1, VM.2 BSIMM: CMVM1.1, CMVM2.1, CMVM3.3, CMVM3.7 EO14028: 4e(viii), 4e(ix) IEC62443: DM-1, DM-2, DM-3, DM-4, DM-5 ISO29147: All ISO30111: All MSSDL: 12 NISTLABEL: 2.2.2.3 OWASPMASVS: 1.11 OWASPSAMM: IM1-A, IM1-B, IM2-A, IM2-B PCISSLC: 9.2, 9.3 SCFPSSD: Vulnerability Response and Disclosure SP80053: SA-15(10) SP800160: 3.3.8 SP800161: SA-15(10) SP800181: K0041, K0042, K0151, K0292, K0317; S0054; A0025 SP800216: All 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.
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.2 > RV.2.1

RV.2.1: Analyze each vulnerability to gather sufficient information about risk to plan its remediation or other risk response. 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. BSAFSS: VM.2 BSIMM: CMVM1.2, CMVM2.2 EO14028: 4e(iv), 4e(viii), 4e(ix) IEC62443: DM-2, DM-3 ISO30111: 7.1.4 NISTLABEL: 2.2.2.2 PCISSLC: 3.4, 4.2 SCAGILE: Operational Security Task 1, Tasks Requiring the Help of Security Experts 10 SP80053: SA-10, SA-15(7) SP800160: 3.3.8 SP800161: SA-15(7) SP800181: K0009, K0039, K0070, K0161, K0165; S0078 Practices Tasks Notional Implementation Examples References
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.2 > RV.2.2

RV.2.2: Plan and implement risk responses for vulnerabilities. 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. BSAFSS: VM.1-1, VM-2 BSIMM: CMVM2.1 EO14028: 4e(iv), 4e(vi), 4e(viii), 4e(ix) IEC62443: DM-4 ISO30111: 7.1.4, 7.1.5 NISTLABEL: 2.2.2.2 PCISSLC: 4.1, 4.2, 10.1 SCAGILE: Operational Security Task 2 SCFPSSD: Fix the Vulnerability, Identify Mitigating Factors or Workarounds SCTPC: MITIGATE SP80053: SA-5, SA-10, SA-11, SA-15(7) SP800160: 3.3.8 SP800161: SA-5, SA-8, SA-10, SA-11, SA-15(7) SP800181: T0163, T0229, T0264; K0009, K0070 Analyze Vulnerabilities to Identify Their Root Causes (RV.3): Help reduce the frequency of vulnerabilities in the future.
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.3 > RV.3.1

RV.3.1: Analyze identified vulnerabilities to determine their root causes. 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. BSAFSS: VM.2-1 BSIMM: CMVM3.1, CMVM3.2 EO14028: 4e(ix) IEC62443: DM-3 ISO30111: 7.1.4 OWASPSAMM: IM3-A PCISSLC: 4.2 SCFPSSD: Secure Development Lifecycle Feedback SP800181: T0047, K0009, K0039, K0070, K0343
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.3 > RV.3.2

RV.3.2: Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently. 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. BSAFSS: VM.2-1, PD.1-3 BSIMM: CP3.3, CMVM3.2 EO14028: 4e(ix) IEC62443: DM-4 ISO30111: 7.1.7 OWASPSAMM: IM3-B PCISSLC: 2.6, 4.2 SCFPSSD: Secure Development Lifecycle Feedback SP800160: 3.3.8 SP800181: T0111, K0009, K0039, K0070, K0343
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.3 > RV.3.3

RV.3.3: Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, and proactively fix them rather than waiting for external reports. Example 1: See PW.7 and PW.8. BSAFSS: VM.2 BSIMM: CR3.3, CMVM3.1 EO14028: 4e(iv), 4e(viii), 4e(ix) IEC62443: SI-1, DM-3, DM-4 ISO30111: 7.1.4 PCISSLC: 4.2 SP80053: SA-11 SP800161: SA-11 SP800181: SP-DEV-001, SP-DEV-002; K0009, K0039, K0070
Secure Software Development Framework (SSDF) Version 1.1
SSDF Practices > RV > RV.3 > RV.3.4

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. 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. BSAFSS: PD.1-3 BSIMM: CP3.3, CMVM3.2 EO14028: 4e(ix) IEC62443: DM-6 ISO30111: 7.1.7 MSSDL: 2 Practices Tasks Notional Implementation Examples References PCISSLC: 2.6, 4.2 SCFPSSD: Secure Development Lifecycle Feedback SP80053: SA-15 SP800161: SA-15 SP800181: K0009, K0039, K0070
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > 2.0 [8], Security and Privacy Controls for Information Systems and Organizations [9], and

2.0 [8], Security and Privacy Controls for Information Systems and Organizations [9], and

Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
[10].
• AI model developers, AI researchers, AI system developers, and secure software
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > [4]

2e2023. https://doi.org/10.6028/NIST.AI.100-2e2023

[4]

Schwartz R, Vassilev A, Greene K, Perine L, Burt A, Hall P (2022) Towards a Standard for
Identifying and Managing Bias in Artificial Intelligence. (National Institute of Standards
and Technology, Gaithersburg, MD), NIST Special Publication (SP) 1270.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > [9]

MD.) Available at https://pages.nist.gov/dioptra/

Souppaya MP, Scarfone KA, Dodson DF (2022) Secure Software Development

Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software

NIST Special Publication (SP) 800-218. https://doi.org/10.6028/NIST.SP.800-218

[7]

Executive Order 14028 (2021) Improving the Nation's Cybersecurity. (The White House,

Washington, DC), DCPD-202100401, May 12, 2021. Available at

https://www.govinfo.gov/app/details/DCPD-202100401

MD). https://doi.org/10.6028/NIST.CSWP.29

[9]

Joint Task Force (2020) Security and Privacy Controls for Information Systems and
Special Publication (SP) 800-53, Rev. 5. Includes updates as of December 10, 2020.
[10] Boyens JM, Smith AM, Bartol N, Winkler K, Holbrook A, Fallon M (2022) Cybersecurity
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Abstract

Abstract

This document augments the secure software development practices and tasks defined in
Secure Software Development Framework (SSDF) version 1.1 by adding practices, tasks,
recommendations, considerations, notes, and informative references that are specific to AI
model development throughout the software development life cycle. These additions are
documented in the form of an SSDF Community Profile to support Executive Order (EO) 14110,
Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, which tasked NIST
with "developing a companion resource to the [SSDF] to incorporate secure development
practices for generative AI and for dual-use foundation models." This Community Profile is
intended to be useful to the producers of AI models, the producers of AI systems that use those
models, and the acquirers of those AI systems. This Profile should be used in conjunction with
NIST Special Publication (SP) 800-218, Secure Software Development Framework (SSDF) Version
1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Appendix A. Glossary > artificial intelligence model

Available at https://ieeexplore.ieee.org/book/9562694

artificial intelligence

A machine-based system that can, for a given set of human-defined objectives, make predictions,
recommendations, or decisions influencing real or virtual environments. [1]

artificial intelligence model

A component of an information system that implements AI technology and uses computational, statistical, or
machine-learning techniques to produce outputs from a given set of inputs. [1]
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook

Supply Chain Risk Management Practices for Systems and Organizations. (National

Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP)

800-161r1. https://doi.org/10.6028/NIST.SP.800-161r1

https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook

Management Framework: Generative Artificial Intelligence Profile. (National Institute of
Standards and Technology, Gaithersburg, MD), NIST Artificial Intelligence (AI) Report,
NIST AI 600-1. Available at https://airc.nist.gov/docs/NIST.AI.600-1.GenAI-Profile.ipd.pdf
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > Intelligence Risk Management Framework (AI RMF 1.0) [2], Adversarial Machine

This document leverages and integrates numerous sources of expertise, including:

• NIST research and publications on trustworthy and responsible AI, including the Artificial

Intelligence Risk Management Framework (AI RMF 1.0) [2], Adversarial Machine

Learning: A Taxonomy and Terminology of Attacks and Mitigations [3], Towards a
Standard for Identifying and Managing Bias in Artificial Intelligence [4], and the Dioptra
experimentation testbed for security evaluations of machine learning algorithms [5].
• NIST's Secure Software Development Framework (SSDF) Version 1.1 [6], which is a set of
fundamental, sound, and secure software development practices. It provides a common
language to help facilitate communications among stakeholders, including software
producers and software acquirers. The SSDF has also been used in support of EO 14028,
Improving the Nation's Cybersecurity [7], to enhance software supply chain security.
• NIST general cybersecurity resources, including The NIST Cybersecurity Framework (CSF)
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > o “N” (note: additional information besides recommendations and considerations)

Each item has an ID starting with one of the following:

o "R" (recommendation: something the organization should do)

o "C" (consideration: something the organization should consider doing)

o "N" (note: additional information besides recommendations and considerations)

An R, C, or N designation and its number can be appended to the task ID to create a
unique identifier (e.g., "PO.1.2.R1" is the first recommendation for task PO.1.2).
Note that a value of "No additions to SSDF 1.1" in this column indicates that the Profile
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > Purpose

Purpose

The SSDF provides a common language for describing secure software development practices
throughout the software development life cycle. This document augments the practices and
tasks defined in SSDF version 1.1 by adding recommendations, considerations, notes, and
informative references that are specific to generative AI and dual-use foundation model
development. These additions are documented in the form of an SSDF Community Profile
("Profile"), which is a baseline of SSDF practices and tasks that have been enhanced to address
a particular use case. An example of an addition is, "Secure code storage should include AI
models, model weights, pipelines, reward models, and any other AI model elements that need
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
Section 4.1.a of Executive Order (EO) 14110, Safe, Secure, and Trustworthy Development and > Scope

Scope

This Profile's scope is AI model development, which includes data sourcing for, designing,
training, fine-tuning, and evaluating AI models, as well as incorporating and integrating AI
models into other software. Consistent with SSDF version 1.1 and EO 14110, practices for the
deployment and operation of AI systems with AI models are out of scope. Similarly, while
cybersecurity practices for training data and other forms of data being used for AI model
development are in scope, the rest of the data governance and management life cycle is out of
scope.
Practices and tasks in this Profile do not distinguish between human-written and AI-generated
source code, because it is assumed that all source code should be evaluated for vulnerabilities
and other issues before use.