ezesecops/rmf-ato-core huggingface dataset:
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.3 > PW.3.3

PW.3.3: Include adversarial samples in the training and testing data to improve attack prevention. [Not part of SSDF 1.1] Medium R1: Use a process and corresponding controls to test the adversarial samples and put appropriate guardrails on training and testing use. OWASP: LLM03-6, LLM05-7 Adv ML 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.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.4 > PW.4.1

PW.4.1: 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's software. Medium C1: Consider using an existing AI model instead of creating a new one. OWASP: LLM05
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.4 > PW.4.2

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. Low No additions to SSDF 1.1
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.4 > PW.4.4

PW.4.4: Verify that acquired commercial, open-source, and all other third-party software components comply with the High R1: Verify the integrity, provenance, and security of an existing AI model or any other acquired AI components - including training, testing, fine-tuning, and aligning datasets; OWASP: LLM05-2, LLM05-6 Adv ML Practice Task Priority Recommendations [R], Considerations [C], and Notes [N] Specific to AI Model Development Informative References requirements, as defined by the organization, throughout their life cycles. reward models; adaptation layers; and configuration parameters - before using them. R2: Scan and thoroughly test acquired AI models and their components for vulnerabilities and malicious content before use. Create Source Code by Adhering to Secure Coding Practices (PW.5): Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.5 > PW.5.1

PW.5.1: Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization's requirements. High R1: Expand secure coding practices to include AI technology-specific considerations. R2: Code the handling of inputs (including prompts and user data) and outputs carefully. All inputs and outputs should be logged, analyzed, and validated within the context of the AI model, and those with issues should be sanitized or dropped. R3: Encode inputs and outputs to prevent the execution of unauthorized code. AI RMF: Manage 1.2, 1.3, 1.4 OWASP: LLM01, LLM02, LLM04-1, LLM06, LLM07, LLM09-9, 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.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.6 > PW.6.1

PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security. Low C1: Consider using secure model serialization mechanisms that reduce or eliminate vectors for the introduction of malicious content.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.6 > PW.6.2

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. Low C1: Consider capturing compiler, interpreter, and build tool versions and features as part of the provenance tracking. 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.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.7 > PW.7.1

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. Medium R1: Code review and analysis policies or guidelines should include code for AI models and other related components. C1: Consider performing scans of AI model code in addition to testing the AI models.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.7 > PW.7.2

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 High R1: Scan all AI models for malware, vulnerabilities, backdoors, and other security issues in accordance with the organization's code review and analysis policies or guidelines. AI RMF: Measure 2.3, 2.7; Manage 1.1, 1.2, 1.3, 1.4 Practice Task Priority Recommendations [R], Considerations [C], and Notes [N] Specific to AI Model Development Informative References development team's workflow or issue tracking system. OWASP: LLM03-7d, LLM07-4 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.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > PW > PW.8 > PW.8.1

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. High R1: Include AI models in code testing policies and guidelines. Several forms of code testing can be used for AI models, including unit testing, integration testing, penetration testing, red teaming, use case testing, and adversarial testing. C1: Consider automating tests within a development pipeline as part of regression testing where possible.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. High R1: Test all AI models for vulnerabilities in accordance with the organization's code testing policies or guidelines. R2: Retest AI models when they are retrained or new data sources are added. AI RMF: Measure 2.2, 2.3, 2.7; Manage 1.1, 1.2, 1.3, 1.4 OWASP: LLM03-7d, LLM05-7, LLM07-4 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 Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium No additions to SSDF 1.1 AI RMF: Measure 2.7
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium N1: Documenting settings can be performed earlier in the process, such as when defining a secure baseline (see PW.9.1). AI RMF: Measure 2.7; Manage 1.2, 1.3, 1.4 Respond to Vulnerabilities (RV) Identify and Confirm Vulnerabilities on an Ongoing Basis (RV.1): Help ensure that vulnerabilities are identified more quickly so
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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 High R1: Log, monitor, and analyze all inputs and outputs for AI models to detect possible security and performance issues (see PO.5.3). AI RMF: Govern 4.3, 5.1, 6.1, 6.2; Practice Task Priority Recommendations [R], Considerations [C], and Notes [N] Specific to AI Model Development Informative References that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers. and third-party components that the software uses, and investigate all credible reports. R2: Make the users of AI models aware of mechanisms for reporting potential security and performance issues. N1: In this context, "users" refers to AI system producers and acquirers who are using an AI model. R3: Monitor vulnerability and incident databases for information on AI-related concerns, including the machine learning frameworks and libraries used to build AI models. Measure 1.2, 2.4, 2.5, 2.7, 3.1, 3.2, 3.3; Manage 4.1 OWASP: LLM03-7a, LLM09, LLM10
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium R1: Scan and test AI models frequently to identify previously undetected vulnerabilities. R2: Rely mainly on automation for ongoing scanning and testing, and involve a human-inthe-loop as needed. R3: Conduct periodic audits of AI models. AI RMF: Govern 4.3; Measure 1.3, 2.4, 2.7, 3.1; Manage 4.1 OWASP: LLM03-7b, LLM03-7d
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium R1: Include AI model vulnerabilities in organization vulnerability disclosure and remediation policies. R2: Make users of AI models aware of their inherent limitations and how to report any cybersecurity problems that they encounter. AI RMF: Govern 4.3, 5.1, 6.1; Measure 3.1, 3.3; Manage 4.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.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium N1: This may include deep analysis of generative AI and dual-use foundation model input and output to detect deviations from normal behavior. AI RMF: Govern 4.3, 5.1, 6.1; Measure 2.7, 3.1; Manage 1.2, 2.3, 4.1 Adv ML
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > RV > RV.2 > RV.2.2

RV.2.2: Plan and implement risk responses for vulnerabilities. High R1: Risk responses for AI models should consider the time and expenses that may be associated with rebuilding them. AI RMF: Govern 5.1, 5.2, 6.1; Measure 3.3; Practice Task Priority Recommendations [R], Considerations [C], and Notes [N] Specific to AI Model Development Informative References R2: Establish and implement criteria and processes for when to stop using an AI model and when to roll back to a previous version and its components. C1: Consider being prepared to stop using an AI model at any time and to continue operations through other means until the AI model's risks are sufficiently addressed. Manage 1.3, 2.1, 2.3, 2.4, 4.1 Analyze Vulnerabilities to Identify Their Root Causes (RV.3): Help reduce the frequency of vulnerabilities in the future.
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
SSDF Practices > RV > RV.3 > RV.3.1

RV.3.1: Analyze identified vulnerabilities to determine their root causes. Medium N1: The ability to review training, testing, fine-tuning, and aligning data after the fact can help identify some root causes. AI RMF: Govern 5.1, 6.1; Measure 2.7, 3.1; Manage 2.3, 4.1
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium No additions to SSDF 1.1 AI RMF: Govern 5.1, 6.1; Measure 2.7, 3.1; Manage 4.1, 4.3
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium No additions to SSDF 1.1 AI RMF: Govern 5.1, 5.2, 6.1; Measure 2.7, 3.1; Manage 4.1, 4.2, 4.3
Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
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. Medium No additions to SSDF 1.1 AI RMF: Govern 5.2, 6.1; Measure 2.7, 3.1; Manage 4.2, 4.3
Guide for Conducting Risk Assessments
CHAPTER 1 > 1.1 PURPOSE AND APPLICABILITY

1.1 PURPOSE AND APPLICABILITY

The purpose of Special Publication 800-30 is to provide guidance for conducting risk assessments
of federal information systems and organizations, amplifying the guidance in Special Publication
800-39. Risk assessments, carried out at all three tiers in the risk management hierarchy, are part
of an overall risk management process-providing senior leaders/executives with the information
needed to determine appropriate courses of action in response to identified risks. In particular,
this document provides guidance for carrying out each of the steps in the risk assessment process
(i.e., preparing for the assessment, conducting the assessment, communicating the results of the
assessment, and maintaining the assessment) and how risk assessments and other organizational
risk management processes complement and inform each other. Special Publication 800-30 also
provides guidance to organizations on identifying specific risk factors to monitor on an ongoing
basis, so that organizations can determine whether risks have increased to unacceptable levels
(i.e., exceeding organizational risk tolerance) and different courses of action should be taken.
This publication satisfies the requirements of FISMA and meets or exceeds the information
security requirements established for executive agencies9 by the Office of Management and
Budget (OMB) in Circular A-130, Appendix III, Security of Federal Automated Information
Resources. The guidelines in this publication are applicable to all federal information systems
other than those systems designated as national security systems as defined in 44 U.S.C., Section
3542. The guidelines have been broadly developed from a technical perspective to complement
similar guidelines for national security systems and may be used for such systems with the
approval of appropriate federal officials exercising policy authority over such systems. State,
local, and tribal governments, as well as private sector organizations are encouraged to consider
using these guidelines, as appropriate.
Guide for Conducting Risk Assessments
CHAPTER 1 > 1.2 TARGET AUDIENCE

1.2 TARGET AUDIENCE

This publication is intended to serve a diverse group of risk management professionals including:
•
Individuals with oversight responsibilities for risk management (e.g., heads of agencies, chief
executive officers, chief operating officers, risk executive [function]);
•
Individuals with responsibilities for conducting organizational missions/business functions
(e.g., mission/business owners, information owners/stewards, authorizing officials);
•
Individuals with responsibilities for acquiring information technology products, services, or
information systems (e.g., acquisition officials, procurement officers, contracting officers);
•
Individuals with information system/security design, development, and implementation
responsibilities (e.g., program managers, enterprise architects, information security architects,
information system/security engineers, information systems integrators);
•
Individuals with information security oversight, management, and operational responsibilities
(e.g., chief information officers, senior information security officers,10 information security
managers, information system owners, common control providers); and
9 An executive agency is: (i) an executive department specified in 5 U.S.C., Section 101; (ii) a military department
specified in 5 U.S.C., Section 102; (iii) an independent establishment as defined in 5 U.S.C., Section 104(1); and (iv) a
wholly owned government corporation fully subject to the provisions of 31 U.S.C., Chapter 91. In this publication, the
term executive agency is synonymous with the term federal agency.
10 At the agency level, this position is known as the Senior Agency Information Security Officer. Organizations may
also refer to this position as the Chief Information Security Officer.
Guide for Conducting Risk Assessments
CHAPTER 1 > 1.3 RELATED PUBLICATIONS

1.3 RELATED PUBLICATIONS

The risk assessment approach described in this publication is supported by a series of security
standards and guidelines necessary for managing information security risk. In addition to this
publication, the Special Publications developed by the Joint Task Force Transformation Initiative
supporting the unified information security framework for the federal government include:
•
Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and
Information System View;11
•
Special Publication 800-37, Guide for Applying the Risk Management Framework to Federal
Information Systems: A Security Life Cycle Approach;
•
Special Publication 800-53, Recommended Security Controls for Federal Information
Systems and Organizations; and
•
Special Publication 800-53A, Guide for Assessing the Security Controls in Federal
Information Systems and Organizations: Building Effective Security Assessment Plans.
The concepts and principles associated with the risk assessment processes and approaches
contained in this publication are intended to be similar to and consistent with the processes and
approaches described in International Organization for Standardization (ISO) and International
Electrotechnical Commission (IEC) standards. Extending the concepts and principles of these
international standards for the federal government and its contractors and promoting the reuse of
risk assessment results, reduces the burden on organizations that must conform to ISO/IEC and
NIST standards.
Guide for Conducting Risk Assessments
CHAPTER TWO > 2.1 RISK MANAGEMENT PROCESS

2.1 RISK MANAGEMENT PROCESS

Risk assessment is a key component of a holistic, organization-wide risk management process as
defined in NIST Special Publication 800-39, Managing Information Security Risk: Organization,
Mission, and Information System View. Risk management processes include: (i) framing risk; (ii)
assessing risk; (iii) responding to risk; and (iv) monitoring risk. Figure 1 illustrates the four steps
in the risk management process-including the risk assessment step and the information and
communications flows necessary to make the process work effectively.13
FIGURE 1: RISK ASSESSMENT WITHIN THE RISK MANAGEMENT PROCESS
The first component of risk management addresses how organizations frame risk or establish a
risk context-that is, describing the environment in which risk-based decisions are made. The
purpose of the risk framing component is to produce a risk management strategy that addresses
how organizations intend to assess risk, respond to risk, and monitor risk-making explicit and
12 NIST Special Publication 800-39 provides guidance on the three tiers in the risk management hierarchy including
Tier 1 (organization), Tier 2 (mission/business process), and Tier 3 (information system).
13 Many of the outputs from the risk framing step provide essential inputs to the risk assessment step and the associated
risk assessment process. These include, for example, the risk management strategy, organizational risk tolerance, risk
assessment methodology, assumptions, constraints, and mission/business priorities.
T
Information and
Communications Flows
Information and
Communications Flows
FRAME
ASSESS
RESPOND
MONITOR