Software Acquisition Guide: Supplier Response Web Tool

Software Name:

  1. Basic Info
  2. Governance and Attestations
  3. Software Supply Chain
  4. Secure Software Development
  5. Secure Software Deployment
  6. Vulnerability Management
  7. Optional Details
  8. Response Summary
Basic Info

Instructions

This questionnaire is organized into five sections. Detailed guidance on the usage of this questionnaire can be found in the companion document titled "Software Acquisition Guide for Government Enterprise Consumers: Software Assurance in the Cyber-Supply Chain Risk Management (C-SCRM) Lifecycle." To get started, please enter the basic information. A red asterisk (*) indicates a required field.

Note: No data is saved on this website. Information can only be imported or exported on your own device. Please export your data to your computer or print your results prior to closing this page.

Disclaimer: The Cybersecurity and Infrastructure Security Agency (CISA) pulled the content for this tool directly from the Information and Communications Technology Supply Chain Risk Management Task Force’s "Software Acquisition Guide for Government Enterprise Consumers: Software Assurance in the Cyber-Supply Chain Risk Management (C-SCRM) Lifecycle," which was previously published in August 2024.

Basic Information

Already have a Software Acquisition Guide? Import my guide

To ensure proper version control, please name your Software Acquisition Guide.

Response Status

0% Complete

Questions skipped:

0/58 Controls

0/316 Tasks

Governance and Attestations

Instructions:

Answer the Governance (GOV) questions below to determine the relevant Control and Task questions required in the subsequent sections.

For most of these questions, a simple ‘Yes’ or ‘No’ is required. A ‘Yes’ response to the question enables a series of CONTROLs in other sections to be skipped. The exceptions to this are the last CONTROLs of this section.

A red asterisk (*) indicates a required field.

CONTROL.GOV.01 Does the supplier provide a CISA Secure Software Development Attestation Form, or equivalent such as the GSA 7700 Secure Software Development Attestation Form, without need for a POA&M, signed by the supplier's designated employee (Chief Executive Officer or designee that can bind the supplier)?
CONTROL.GOV.02 Does the Supplier maintain provenance data for internal and third-party components?
CONTROL.GOV.03 Has the supplier's product(s) or product line employed automated tools or comparable processes including, but not limited to, log management and patch management to maintain integrity of software supply chains and to check for and mitigate security-relevant vulnerabilities in binary, source code, development, and build systems?
CONTROL.GOV.04 Has all the software (including third-party and open source) to be delivered undergone rigorous code analysis and multi-level testing according to the supplier's documented testing procedures? Foremost in this testing is the identification of code weaknesses and software vulnerabilities, including those listed in the DHS CISA Known Exploited Vulnerabilities (KEV) Catalog with vulnerable components either patched, rebuilt, or otherwise mitigated.
CONTROL.GOV.05 Does the supplier use industry standards or frameworks for implementing vulnerability scanning and vulnerability management, and to communicate mitigation status for any unpatched vulnerabilities using machine-readable formats, such as a Common Security Advisory Framework (CSAF) Security Advisory, a NIST defined VDR, or a VEX document, for the current version of the application and all future versions and updates?
CONTROL.GOV.06 Does the supplier use a secure by default approach for software deployment processes?
CONTROL.GOV.07 Does the supplier use secure by design tactics ensuring that their product been developed and built in secure environments using community or industry recognized frameworks, certified against those applicable standards, and tested in an environment following zero-trust principles?
CONTROL.GOV.08 Prior to incorporating any third-party components in its software components, products or services provided to customers, does the software supplier require third-party software suppliers to produce a software bill of materials (SBOMs), to establish a vulnerability disclosure policy, and to follow “NIST Guidance” as specified in OMB M-22-18?
CONTROL.GOV.09 Does the supplier provide a machine-readable SBOM meeting minimum requirements defined by National Telecommunications Information Administration (NTIA) or successor guidance as published by CISA that covers all software components of the product being delivered to the customer organization?
CONTROL.GOV.10 Does the supplier define and enforce policies controlling the use of open source libraries and software, AI generated code, and AI powered toolchains?
CONTROL.GOV.11 For the products or services being provided, has the supplier received a successful third-party FedRAMP High or Moderate Baseline certification?
CONTROL.GOV.12 Does the supplier have protections and verification methods in place with third-party suppliers (for software, network, and cloud services) for products or services provided to the customer that are commensurate with contractually specified government protection levels and trust relationships?
CONTROL.GOV.13 Does the software supplier establish and resource a Cyber Supply Chain Risk Management (C-SCRM) Program that includes attack and risk modeling and incident management and response?
CONTROL.GOV.14 Does the software supplier provide role-based SDLC-related training and have qualified personnel and/or automated processes that contribute to all parts of the SDLC, including secure architecture, development, testing, and threat modeling?
CONTROL.GOV.15 Does the supplier have and enforce defined policies for software security requirements, including securely storing all forms of code (for source code, executable code, binaries, and configuration-as-code), release artifacts, and associated integrity verification information for each release?
CONTROL.GOV.16 Does the supplier have policies and procedures that ensure the maximum use of software modules providing standardized implementations of security features and services or the reuse of well-secured software components developed in-house following SDLC processes?
CONTROL.GOV.17 Does the supplier have policies and procedures to use built-in checks and protections supported by programming languages or environments, both compiled and interpreted during development and in the software shipped/distributed?
CONTROL.GOV.18 Do software supplier's procurement, outsourcing, and contractual agreements, such as Service Level Agreements (SLAs), stipulate that their sub-suppliers and/or service providers follow secure SDLC practices, scan for undocumented, unused, or obsolete functions, and notify the software supplier of identified vulnerabilities or security incidents?
CONTROL.GOV.19 Does the supplier provide license terms that permit the using enterprise, agency, organization, or a trusted third party to scan the delivered software relative to provenance and security?

Response Status

0% Complete

Questions skipped:

0/58 Controls

0/316 Tasks

Software Supply Chain

Software is increasingly composed of, or reliant upon, libraries created by third-party development teams. These libraries might be open source, commercial, or third-party contracted, and each team may create their libraries using any combination of open source, commercial, or third-party contracted libraries. The lack of visibility into the design, development, and implementation decisions made by third-party teams poses risk to all software.

Instructions:

Answer the CONTROL questions related to the software supplier's Supply Chain (SC). Select the appropriate “Yes”, “No”, “Partial”, or “N/A” response. Click Read More to get more information about the “Yes”, “No”, “Partial”, and “N/A” response criteria.

Yes - The supplier believes they have appropriate controls in place to meet the expectations of the CONTROL question, and they are prepared to provide supporting documentation if requested. The supporting TASK questions do not need to be answered; however, the TASK questions may be reviewed to determine full compliance with the expectations of a Yes answer to the CONTROL question.

No - Implies that the supplier believes they do not have appropriate controls in place to meet the expectations of the CONTROL question. The TASK questions can be used to determine whether the supplier lacks the appropriate controls or can indicated that they partially comply with the requirement.

Partial - The supplier complies with some of the requirements indicated in the CONTROL question. If the supplier indicates Partial compliance, use the TASK questions to identify the areas in which they comply and the areas that are potential recommendations for improvement or represent factors to consider in comparing the security posture of competing suppliers.

N/A - Indicates the supplier believes that in the operational context of their software, the CONTROL question does not apply. They may be required to indicate why.

A red asterisk (*) indicates a required field.

CONTROL.SC.01 Does the supplier have policies and procedures to validate the development of software used, including all libraries, and with the exception of Integrated Development Environment (IDE), compiler, build, packaging, and Continuous Integration/Continuous Delivery (CI/CD) tools, occurs using supplier employees or vetted contract employees?
Please answer the following Task questions:
TASK.SC.01.01 Were sub-contractors or contracted development teams used in the creation of the software?
TASK.SC.01.02 Does the product include or depend upon Commercial off-the-shelf/Government off-the-shelf (COTS/GOTS) or commercial libraries?
TASK.SC.01.03 Does the product include or depend upon open source libraries?
TASK.SC.01.04 Does the product include or depend upon AI generated source code or libraries?
CONTROL.SC.02 Does the supplier create a validated SBOM in an NTIA or CISA approved machine-readable format with NTIA or CISA defined minimum fields for all releases of the software, including updates?
Please answer the following Task questions:
TASK.SC.02.01 Does the supplier document its SBOM creation processes?
TASK.SC.02.02 Does the supplier publish its SBOM in an accessible location?
TASK.SC.02.03 Is the SBOM provided in an NTIA or CISA approved machine-readable format?
TASK.SC.02.04 Does the supplier provide a conformance or attestation to ensure the SBOM is accurate and complete?
CONTROL.SC.03 Does the supplier perform cyber risk management on outsourced, or third-party contracted, software development?
Please answer the following Task questions:
TASK.SC.03.01 Does the supplier review any differences in the IDE, compiler, build, packaging, and CI/CD tools used by a contractor relative to those used by internal development teams?
TASK.SC.03.02 Are contractors permitted to sub-contract for contracted work?
TASK.SC.03.03 Are periodic threat models performed as part of a contractor risk management effort?
CONTROL.SC.04 Does the supplier have a defined policy and process for open source governance as typically established by an Open Source Program Office (OSPO)?
Please answer the following Task questions:
TASK.SC.04.01 Is there a defined review process for any new usage of an open source component prior to its first usage in the software?
TASK.SC.04.02 Is there a process to identify and remediate known vulnerabilities in open source components as minimally disclosed in the National Vulnerability Database (NVD)?
TASK.SC.04.03 Is there a process to identify abandoned, unmaintained, obsolete, or compromised open source libraries?
TASK.SC.04.04 Is there a process to perform ongoing security testing on open source libraries used within the software?
CONTROL.SC.05 Does the software supplier establish and resource a C-SCRM Program?
Please answer the following Task questions:
TASK.SC.05.01 Does the software supplier obtain executive leadership support for C-SCRM?
TASK.SC.05.02 Does the software supplier have established C-SCRM policies across enterprise-levels?
TASK.SC.05.03 Does the software supplier have an established C-SCRM governance structure?
TASK.SC.05.04 Does the software supplier have well-documented, consistent, and validated C-SCRM processes?
TASK.SC.05.05 Does the software supplier establish a C-SCRM threat awareness program?
TASK.SC.05.06 Does the software supplier have a quality and reliability program?
TASK.SC.05.07 Does the software supplier integrate C-SCRM into acquisition/procurement policies?
TASK.SC.05.08 Does the software supplier determine impact levels and categorize/assess its systems according to those impact levels (e.g., FIPS 199 impact levels)?
TASK.SC.05.09 Does the software supplier have defined, explicit roles for C-SCRM?
TASK.SC.05.10 Does the software supplier have adequate and dedicated C-SCRM resources?
TASK.SC.05.11 Does the software supplier have a defined C-SCRM control baseline?
TASK.SC.05.12 Does the software supplier have C-SCRM internal checks and balances to assure compliance?
TASK.SC.05.13 Does the software supplier have a supplier management program?
CONTROL.SC.06 Does the software supplier have and enforce policies covering the usage of AI generated code (e.g., ChatGPT or GitHub CoPilot) or code otherwise generated by a third-party tool or service (e.g. Low-Code or No-Code) within its software supply chain?
Please answer the following Task questions:
TASK.SC.06.01 Does the supplier include a review for AI generated code as part of its vendor selection process?
TASK.SC.06.02 Does the supplier perform a risk assessment to determine the impact of AI generated code on the security functions within the software under review?
TASK.SC.06.03 Does the supplier validate the software license implications covering the usage of AI generated code?
TASK.SC.06.04 Does the supplier review the usage of AI or cloud powered developer tools?
TASK.SC.06.05 Does the supplier use automated tooling to identify where AI or cloud generated code is used within the software?
TASK.SC.06.06 Does the supplier maintain an approved list of AI code generation implementations?
TASK.SC.06.07 Does the supplier perform ongoing periodic reviews for data leakage associated with AI or cloud generated code?
CONTROL.SC.07 Does the software supplier acquire and maintain current well-secured, vetted software components (e.g., software libraries, modules, middleware) from commercial, open source, and other third-party developers for use by the organization's software throughout the lifespan of the software?
Please answer the following Task questions:
TASK.SC.07.01 Does the software supplier review and evaluate third-party software components and their security aspects in the context of their expected use?
TASK.SC.07.02 If a third-party component is to be used in a substantially different way than when initially approved for use, does the software supplier perform the review and evaluation again with that new context in mind?
TASK.SC.07.03 Does the software supplier determine secure configurations for software components, and make these available (e.g., as configuration-as-code) so developers can readily use the configurations?
TASK.SC.07.04 Does the software supplier implement processes to update deployed software components to newer versions?
TASK.SC.07.05 Does the supplier update process include retaining older versions of software components until all transitions from those versions have been completed successfully?
CONTROL.SC.08 Does the software supplier obtain and manage provenance information (e.g., SBOM, source composition analysis, binary software composition analysis) for each software component?
Please answer the following Task questions:
TASK.SC.08.01 Does the software supplier analyze provenance information to better assess the risk that the component may introduce?
TASK.SC.08.02 Does the software supplier verify, safeguard, and maintain provenance data for all components of each software release (e.g., in a SBOM)?
TASK.SC.08.03 Does the software supplier make the software component provenance data available to the organization's operations and response teams to aid them in mitigating software vulnerabilities?
TASK.SC.08.04 Does the software supplier protect the integrity of provenance data, and provide a way for recipients to verify provenance data integrity?
TASK.SC.08.05 Does the software supplier establish one or more software repositories to host sanctioned and vetted open source components?
TASK.SC.08.06 Does the supplier maintain a list of organization approved commercial software components and component versions along with their provenance data?
TASK.SC.08.07 Does the software supplier designate that only organization approved components be included in software to be developed?
TASK.SC.08.08 Does the software supplier update the provenance information every time any of the software's components are updated?
TASK.SC.08.09 If the vendor cannot determine the integrity or provenance of acquired binaries, do they verify the source code's integrity, security, and provenance, and rebuild the binaries from source code?
TASK.SC.08.10 Does the software supplier make the software component provenance data available to software acquirers in accordance with the organization's policies?
TASK.SC.08.11 For commercial and cloud software, does the supplier include provenance attributes such as supplier ownership or control, or Data Universal Numbering System (DUNS) verification?

Response Status

0% Complete

Questions skipped:

0/58 Controls

0/316 Tasks

Secure Software Development

Software development teams are expected to deliver software that is well designed, implemented, and tested. Such designs are commonly referred to as “secure by design.” Ensuring that these activities occur on a consistent and reliable basis requires a set of controls over how software development teams function and the various criteria used to release, maintain, and update that software. This section is based on and aligned with NIST’s SSDF, SP800-218 v1.1. If an alternative framework is used by the supplier, the SSDF includes a reference column for each task that may prove valuable.

Instructions:

Answer the CONTROL questions related to the software supplier's Supply Chain (SC). Select the appropriate “Yes”, “No”, “Partial”, or “N/A” response. Click Read More to get more information about the “Yes”, “No”, “Partial”, and “N/A” response criteria.

Yes - The supplier believes they have appropriate controls in place to meet the expectations of the CONTROL question, and they are prepared to provide supporting documentation if requested. The supporting TASK questions do not need to be answered; however, the TASK questions may be reviewed to determine full compliance with the expectations of a Yes answer to the CONTROL question.

No - Implies that the supplier believes they do not have appropriate controls in place to meet the expectations of the CONTROL question. The TASK questions can be used to determine whether the supplier lacks the appropriate controls or can indicated that they partially comply with the requirement.

Partial - The supplier complies with some of the requirements indicated in the CONTROL question. If the supplier indicates Partial compliance, use the TASK questions to identify the areas in which they comply and the areas that are potential recommendations for improvement or represent factors to consider in comparing the security posture of competing suppliers.

N/A - Indicates the supplier believes that in the operational context of their software, the CONTROL question does not apply. They may be required to indicate why.

A red asterisk (*) indicates a required field.

CONTROL.DEV.01 Does the software supplier identify, document, and maintain all security requirements for the organization's software development infrastructures and processes?
Please answer the following Task questions:
TASK.DEV.01.01 Does the software supplier have defined policies for establishing and maintaining secure software development infrastructures and the component elements of those infrastructures (such as build and staging systems) throughout the SDLC?
TASK.DEV.01.02 Does the software supplier have defined policies for establishing and maintaining secure software development infrastructure and processes throughout the SDLC?
TASK.DEV.01.03 Does the software supplier review and update security requirements at least annually?
TASK.DEV.01.04 Does the software supplier review and update security requirements if a major software development security incident occurs?
CONTROL.DEV.02 Does the software supplier identify, document, and maintain all security requirements for organization-developed software to meet?
Please answer the following Task questions:
TASK.DEV.02.01 Does the software supplier have defined policies that specify risk-based software architecture and design requirements (e.g., modular code, security component separation)?
TASK.DEV.02.02 Does the software supplier have defined policies specifying the organization's software security requirements?
TASK.DEV.02.03 Does the software supplier perform risk assessments of applicable technology stacks?
TASK.DEV.02.04 Does the software supplier have defined policies specifying what needs to be archived for each software release?
TASK.DEV.02.05 Does the supplier maintain the security requirements over time?
TASK.DEV.02.06 Does the software supplier ensure that its policies cover the entire software life cycle?
TASK.DEV.02.07 Does the supplier specify how long archives need to be retained based on the SDLC model, software end-of-life, and other factors?
TASK.DEV.02.08 Does the supplier notify users of the impending end of software support and the date of software end-of-life?
TASK.DEV.02.09 Does the software supplier have established processes for handling requirement exception requests?
TASK.DEV.02.10 For any exceptions, does the supplier have a process to periodically review all approved exceptions?
CONTROL.DEV.03 Does the software supplier communicate security acceptance criteria to all third parties who will provide commercial software components to the organization for reuse by the organization's own software?
Please answer the following Task questions:
TASK.DEV.03.01 Does the software supplier have a defined set of core security requirements for third-party software components?
TASK.DEV.03.02 Does the supplier incorporate security requirements in all acquisition documents, software contracts, and other agreements with third parties?
TASK.DEV.03.03 Does the software supplier have defined security related criteria for selecting software from its sources?
TASK.DEV.03.04 Does the software supplier require its suppliers (third parties) to attest that their software complies with the organization's security requirements?'
TASK.DEV.03.05 Does the software supplier require its suppliers (third parties) to supply provenance data and integrity verification mechanisms for all components of their software?
TASK.DEV.03.06 Does the software supplier have exception processes to address risk when its security requirements related to acquired third party software components are not met by that supplier/source?
TASK.DEV.03.07 For exceptions to security requirements, does the supplier have a process to periodically review all exceptions to requirements?
TASK.DEV.03.08 Does the supplier require a vulnerability disclosure program and/or product security incident response capabilities from its sources?
CONTROL.DEV.04 Does the software supplier create and maintain new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC?
Please answer the following Task questions:
TASK.DEV.04.01 Does the software supplier integrate security roles into the software development team?
TASK.DEV.04.02 Does the software supplier have defined SDLC related roles and responsibilities for all members of the software development team?
TASK.DEV.04.03 Does the software supplier have defined roles and responsibilities for other cybersecurity staff and points of contact associated with the SDLC (e.g., security champions, project managers and leads, senior management, software testers, software assurance leads and staff, product owners)?
TASK.DEV.04.04 Does the software supplier conduct an annual review of all roles and responsibilities?
TASK.DEV.04.05 Does the software supplier educate impacted individuals on impending changes to roles and responsibilities?
TASK.DEV.04.06 Does the software supplier use tools and processes to promote communication and engagement among individuals with SDLC-related roles and responsibilities?
TASK.DEV.04.07 Does the software supplier designate a group of individuals or a team as the code owner for each project?
CONTROL.DEV.05 Does the software supplier provide periodically updated role-based, SDLC-related training for all personnel with responsibilities that contribute to secure architecture, development, testing, and threat modeling?
Please answer the following Task questions:
TASK.DEV.05.01 Does the software supplier periodically review role-based training and update the training as needed?
TASK.DEV.05.02 Does the software supplier periodically review personnel proficiency against their assigned role to determine whether additional training or training updates are needed?
TASK.DEV.05.03 Does the software supplier document the desired outcomes of training for each role?
TASK.DEV.05.04 Does the software supplier define the type of training or curriculum required to achieve the desired outcome for each role?
TASK.DEV.05.05 Does the software supplier acquire or create training for each role?
TASK.DEV.05.06 Does the software supplier measure outcome performance to identify areas where changes to training may be beneficial?
CONTROL.DEV.06 Does the software supplier obtain upper management or authorizing official commitment to secure development practices, and convey that commitment to all with SDLC-related roles and responsibilities?
Please answer the following Task questions:
TASK.DEV.06.01 Does the software supplier appoint a single leader or leadership team to be responsible for the entire secure software development process?
TASK.DEV.06.02 Does the software supplier management (at all levels) incorporate secure development support into their communications with personnel (in particular, those with development-related roles and responsibilities)?
TASK.DEV.06.03 Does leadership of the secure software development process include accountability for releasing software to production and delegating responsibilities as appropriate?
TASK.DEV.06.04 Does the software supplier educate management personnel on the importance of secure development to the organization?
TASK.DEV.06.05 Does the software supplier educate all personnel with development-related roles and responsibilities on upper management's commitment to secure development and the importance of secure development to the organization?
CONTROL.DEV.07 Does the software supplier define categories (e.g., IDE, compiler, build, and CI/CD tools) within toolchains, and specify the mandatory tools or tool types to be used for each category?
Please answer the following Task questions:
TASK.DEV.07.01 Does the software supplier identify security tools to integrate into the software developers' toolchain?
TASK.DEV.07.02 Does the software supplier provide information (e.g., settings) that can be used to rebuild the software?
TASK.DEV.07.03 Does the software supplier evaluate tools' capabilities to create immutable (signed) records/logs for auditability within the toolchain?
TASK.DEV.07.04 Does the software supplier use automated technology for toolchain management and orchestration?
CONTROL.DEV.08 Does the software supplier follow NIST recommended security practices to deploy, operate, and maintain tools and toolchains?
Please answer the following Task questions:
TASK.DEV.08.01 Does the software supplier include cybersecurity considerations or assessments in its evaluation, selection, and acquisition of its tools?
TASK.DEV.08.02 Does the software supplier use code-based configuration for development toolchains (e.g., pipelines-as-code, toolchains-as-code)?
TASK.DEV.08.03 Does the software supplier implement software development technologies and processes needed for reproducible builds?
TASK.DEV.08.04 Does the software supplier update, upgrade, or replace software development tools as needed to address tool vulnerabilities or add new tool capabilities?
TASK.DEV.08.05 Does the software supplier continuously monitor tools and tool logs for potential operational and security issues, including policy violations and anomalous behavior?
CONTROL.DEV.09 Does the software supplier configure tools to generate artifacts of their compliance with secure software development practices as defined by the organization?
Please answer the following Task questions:
TASK.DEV.09.01 Does the software supplier use automated workflow 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?
TASK.DEV.09.02 Does the software supplier determine how often the collected information should be audited, and implement the necessary processes?
TASK.DEV.09.03 Does the software supplier establish and enforce security and retention policies for software development artifact data?
TASK.DEV.09.04 Does the software supplier assign responsibility for creating and managing any needed artifacts that tools cannot generate?
TASK.DEV.09.05 Does the supplier encrypt build-related artifacts at rest and in transit?
CONTROL.DEV.10 Does the software supplier define, gather, and use software security criteria and measures throughout the SDLC?
Please answer the following Task questions:
TASK.DEV.10.01 Does the software supplier ensure that the software development security criteria adequately indicate how effectively security risk is being managed?
TASK.DEV.10.02 Does the software supplier define key performance indicators (KPIs), key risk indicators (KRIs), vulnerability severity scores, and other measures for software security?
TASK.DEV.10.03 Does the software supplier review the artifacts generated as part of the software development workflow system to determine if they meet the criteria?
TASK.DEV.10.04 Does the software supplier use the software development toolchain to automatically gather information that informs security decision-making?
TASK.DEV.10.05 Does the software supplier deploy additional tools if needed to support the generation and collection of information supporting the criteria?
TASK.DEV.10.06 Does the software supplier automate decision-making processes using the security criteria, and periodically review these processes?
TASK.DEV.10.07 Does the software supplier only allow authorized personnel to access the gathered information?
TASK.DEV.10.08 Does the software supplier prevent any alteration or deletion of the gathered information?
CONTROL.DEV.11 Does the software supplier separate and protect each environment used in a phase of software development (build system, staging, and production)?
Please answer the following Task questions:
TASK.DEV.11.01 Does the software supplier use multi-factor, risk-based authentication, and conditional access for each environment?
TASK.DEV.11.02 Does the software supplier use network segmentation and access controls consistent with zero-trust principles to separate each environment from others and from production environments, and to separate components from each other within each non-production environment?
TASK.DEV.11.03 Does the software supplier enforce authentication and tightly restrict connections entering and exiting each software development environment, including minimizing access to the internet to only what is necessary?
TASK.DEV.11.04 Does the software supplier minimize direct human access to toolchain systems such as build services?
TASK.DEV.11.05 Does the software supplier continuously monitor and audit all access attempts and all use of privileged access?
TASK.DEV.11.06 Does the software supplier isolate the use of production environment software and services from non-production environments?
TASK.DEV.11.07 Does the software supplier regularly log, monitor, and audit trust relationships for authorization and access between the environments and between the components within each environment?
TASK.DEV.11.08 Does the software supplier 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?
TASK.DEV.11.09 Does the software supplier configure security controls and other tools involved in separating and protecting the environments to generate artifacts for their activities?
TASK.DEV.11.10 Does the software supplier continuously monitor all software deployed in each environment for new vulnerabilities?
TASK.DEV.11.11 Does the software supplier follow a risk-based approach to respond to vulnerabilities?
CONTROL.DEV.12 Does the software supplier secure its development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach?
Please answer the following Task questions:
TASK.DEV.12.01 Does the software supplier configure each development endpoint based on approved hardening guides, checklists, etc.?
TASK.DEV.12.02 Does the software supplier 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?
TASK.DEV.12.03 Does the software supplier continuously monitor the security posture of all development endpoints, including monitoring and auditing all use of privileged access?
TASK.DEV.12.04 Does the software supplier configure security controls and other tools involved in securing and hardening development endpoints to generate artifacts for their activities?
TASK.DEV.12.05 Does the software supplier require multi-factor authentication (MFA) for all access to development endpoints and development resources?
TASK.DEV.12.06 Does the software supplier provide dedicated development endpoints on non-production networks for performing all development-related tasks?
TASK.DEV.12.07 Does the software supplier also provide separate endpoints on production networks for non-development related tasks, such as system administration tasks?
TASK.DEV.12.08 Does the software supplier follow a zero-trust architecture to configure each development endpoint?
CONTROL.DEV.13 Does the software supplier have defined policies for securely storing all forms of code (including source code, executable code, and configuration-as-code), release artifacts, and associated integrity verification information for each release?
Please answer the following Task questions:
TASK.DEV.13.01 Does the software supplier store all source code and configuration-as-code in a version controlled code repository to track all changes?
TASK.DEV.13.02 Does the software supplier use commit signing for code repositories?
TASK.DEV.13.03 Does the software supplier have the code owner review and approve all changes made to the code by others?
TASK.DEV.13.04 Does the software supplier use code signing to help protect the integrity of executables?
TASK.DEV.13.05 Does the software supplier use cryptography (e.g., cryptographic hashes) to help protect file integrity?
TASK.DEV.13.06 Does the software supplier securely store the necessary files and supporting data (e.g., integrity verification information) to be retained for each software release (e.g., by keeping it in a separate location from the release files or by signing the data)?
TASK.DEV.13.07 Does the software supplier store all forms of code and associated integrity verification information for each release based on the principle of least privilege (including read-only access for release files) so that only authorized personnel, tools, services, etc. have access?
TASK.DEV.13.08 Does the supplier automatically revoke access to development and/or release repositories when an authorized user is no longer an active member of the development team associated with the repository?
TASK.DEV.13.09 Does the software supplier securely archive the necessary files and supporting data (e.g., integrity verification information) to be retained for each software release?
TASK.DEV.13.10 Does the supplier periodically review source code and integrity verification information access logs for attempted access and compare such access to the list of authorized accounts?
CONTROL.DEV.14 Does the software supplier make software authenticity and integrity verification information available to software acquirers?
Please answer the following Task questions:
TASK.DEV.14.01 Does the software supplier post cryptographic hashes for release files on a well-secured website?
TASK.DEV.14.02 Does the software supplier use an established certificate authority or trusted signing keys for code signing so that consumers' operating systems or other tools and services can confirm the validity of signatures before use?
TASK.DEV.14.03 Does the software supplier periodically review the code signing processes, including signing keys renewal, rotation, revocation, and protection?
CONTROL.DEV.15 Does the software supplier use forms of risk modeling-such as threat modeling, attack modeling, or attack surface mapping-to help assess the security risk for the software?
Please answer the following Task questions:
TASK.DEV.15.01 Does the software supplier train the development team how to use a risk-based approach to communicate the risks and determine how to address them, including implementing mitigations?
TASK.DEV.15.02 Does the software supplier apply additional rigor in performing assessments for high-risk areas, such as protecting sensitive data and safeguarding identification, authentication, and access control including credential management?
TASK.DEV.15.03 Does the software supplier review vulnerability reports and statistics for previous software versions to inform the security risk assessment?
TASK.DEV.15.04 Does the software supplier use data classification methods to identify and characterize each type of data that the software will interact with?
CONTROL.DEV.16 Does the software supplier track and maintain the software's security requirements, risks, and design decisions?
Please answer the following Task questions:
TASK.DEV.16.01 Does the software supplier record the response to each identified risk, including mitigations performed, the rationale for any approved exceptions to the security requirements, and any mitigation additions to the software's security requirements?
TASK.DEV.16.02 Does the software supplier 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?
TASK.DEV.16.03 Does the software supplier periodically re-evaluate all approved exceptions to the security requirements and implement changes as needed?
CONTROL.DEV.17 Does the software supplier take advantage of modules providing standardized implementations of security features and services where appropriate instead of creating customized implementations of security features and services?
Please answer the following Task questions:
TASK.DEV.17.01 Does the software supplier maintain one or more software repositories of modules for supporting standardized security features and services?
TASK.DEV.17.02 Does the software supplier 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?
TASK.DEV.17.03 Does the software supplier define criteria for which security features and services must be supported by software to be developed?
CONTROL.DEV.18 Does the software supplier have qualified personnel and/or automated processes to review alignment between the software design and security requirements?
Please answer the following Task questions:
TASK.DEV.18.01 Does the software supplier review the software design to confirm that it addresses applicable security requirements?
TASK.DEV.18.02 Does the software supplier review the risk models created during software design to determine if they appear to adequately identify the risks?
TASK.DEV.18.03 Does the software supplier review the software design to confirm that it satisfactorily addresses the risks identified by the risk models?
TASK.DEV.18.04 Does the software supplier have the software architect correct failures to meet the requirements?
TASK.DEV.18.05 Does the software supplier change the design and/or the risk response strategy if the security requirements cannot be met?
TASK.DEV.18.06 Does the software supplier record the findings of design reviews to serve as artifacts?
CONTROL.DEV.19 Does the software supplier create, maintain, and reuse well-secured software components developed in-house following SDLC processes to meet shared internal software development?
Please answer the following Task questions:
TASK.DEV.19.01 Does the software supplier follow organization-established security practices for secure software development when creating and maintaining software components?
TASK.DEV.19.02 Does the software supplier maintain one or more software repositories for these components?
TASK.DEV.19.03 Does the software supplier promote the use of preexisting and vetted software components?
TASK.DEV.19.04 Does the software supplier maintain vetted software components?
TASK.DEV.19.05 Does the software supplier promote the creation of reusable components by their internal software development teams?
CONTROL.DEV.20 Does the software supplier verify that third-party software components, including open source and commercial components, comply with the requirements, as defined by the supplier for the software, throughout the lifecycle of the component in the application?
Please answer the following Task questions:
TASK.DEV.20.01 Does the supplier review component patches and updates for functional changes that might impact runtime requirements for the software?
TASK.DEV.20.02 If a component patch or update implements changes to security functions, does the supplier perform a threat analysis to determine if those changes impact other security functions or the ability to perform forensic analysis on the software?
TASK.DEV.20.03 Does the supplier define a policy handling end-of-life and end-of-support conditions for third-party components?
CONTROL.DEV.21 Prior to component usage, does the software supplier check whether there are publicly known vulnerabilities in the software modules and services that they (or their component sources) have not yet fixed?
Please answer the following Task questions:
TASK.DEV.21.01 Does the supplier identify where their software suppliers publish vulnerability information?
TASK.DEV.21.02 If a component or module supplier publishes their vulnerability information in a location other than the NVD, does the supplier have a process to automatically process that vulnerability data source?
TASK.DEV.21.03 If a software service provider discloses a vulnerability, does the supplier perform a risk-based review of all points of usage for that software supplier to determine the impact of the vulnerability on the software?
CONTROL.DEV.22 Does the software supplier build into the toolchain automatic detection of known vulnerabilities in software components?
Please answer the following Task questions:
TASK.DEV.22.01 Does the software supplier use existing results from commercial services for vetting the software modules and services?
TASK.DEV.22.02 Does the software supplier ensure that each software component is still actively maintained and has not reached end-of-life (this should include ensuring no new vulnerabilities have been found in the software being remediated)?
TASK.DEV.22.03 Does the software supplier determine a plan of action for each software component that is no longer being maintained or that will not be available in the near future?
TASK.DEV.22.04 Does the software supplier confirm the integrity of software components through digital signatures or other mechanisms?
TASK.DEV.22.05 Does the software supplier review, analyze, and/or test code?
CONTROL.DEV.23 Does the software supplier follow all secure coding practices that are appropriate to the development languages and environment to meet the organization's requirements?
Please answer the following Task questions:
TASK.DEV.23.01 Does the software supplier follow secure coding practices to validate all inputs?
TASK.DEV.23.02 Does the software supplier validate and properly encode all outputs?
TASK.DEV.23.03 Does the software supplier follow secure coding practices to avoid using known unsafe functions and calls?
TASK.DEV.23.04 Does the software supplier follow secure coding practices to detect and handle errors?
TASK.DEV.23.05 Does the software supplier follow secure coding practices to provide logging and tracing capabilities?
TASK.DEV.23.06 Does the software supplier use development environments with automated features that encourage or require the use of secure coding practices?
TASK.DEV.23.07 Does the software supplier employ just-in-time training in its secure coding practices?
TASK.DEV.23.08 Does the software supplier follow procedures for manually ensuring compliance with secure coding practices when automated methods are insufficient or unavailable?
TASK.DEV.23.09 Does the software supplier use tools (e.g., linters, formatters) to standardize the style and formatting of the source code?
TASK.DEV.23.10 Does the software supplier check for other vulnerabilities that are common to the development languages and environment it uses?
TASK.DEV.23.11 Does the software supplier have the developer review their own human-readable code to complement (not replace) code review performed by other people or tools?
CONTROL.DEV.24 Does the software supplier use compiler, interpreter, and build tools that offer features to improve executable security?
Please answer the following Task questions:
TASK.DEV.24.01 Does the software supplier use up-to-date versions of compiler, interpreter, and build tools?
TASK.DEV.24.02 Does the software supplier follow change management processes when deploying or updating compiler, interpreter, and build tools and audit all unexpected changes to tools?
TASK.DEV.24.03 Does the software supplier regularly validate the authenticity and integrity of compiler, interpreter, and build tools?
CONTROL.DEV.25 Does the software supplier determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations?
Please answer the following Task questions:
TASK.DEV.25.01 Does the software supplier determine and implement optimum compiler, interpreter, and build tool feature configurations for the build tools based on its risk strategy and security policies?
TASK.DEV.25.02 Does the software supplier enable compiler features that produce warnings for poorly secured code during the compilation process?
TASK.DEV.25.03 Does the software supplier implement the “clean build” concept, where all compiler warnings are treated as errors and eliminated except those clearly determined to be false positives or irrelevant?
TASK.DEV.25.04 Does the software supplier perform all builds in a dedicated, highly controlled build environment?
TASK.DEV.25.05 Does the software supplier enable compiler features that randomize or obfuscate execution characteristics (such as memory location usage) that would otherwise be predictable and thus potentially exploitable?
TASK.DEV.25.06 Does the software supplier test to ensure that the features are working as expected and are not inadvertently causing any operational issues or other problems?
TASK.DEV.25.07 Does the software supplier make the approved tool configurations available as configuration-as-code so developers can readily use them?
TASK.DEV.25.08 Does the software supplier continuously verify that the approved configurations are being used?
CONTROL.DEV.26 Does the software supplier have established policies and procedures to determine when and how to perform code reviews, code analysis, and/or testing methodologies?
Please answer the following Task questions:
TASK.DEV.26.01 Does the software supplier mandate the organization's policies or guidelines for when code review (human looking at code) vs. code analysis (using tools to find coding issues) vs. testing should be performed, and how it should be conducted for all code whether developed in-house or via third party?
TASK.DEV.26.02 Does the software supplier prescribe code review, analysis methods, and/or testing methods based on the stage of the software?
TASK.DEV.26.03 Does the software supplier perform the code review code analysis and/or testing based on the organization's secure coding standards?
TASK.DEV.26.04 Does the software supplier perform peer review of code, and review any existing code review, analysis, or testing results as part of the peer review?
TASK.DEV.26.05 Does the software supplier use peer reviewing tools that facilitate the peer review process, and document all discussions and feedback?
TASK.DEV.26.06 Does the software supplier use a static analysis tool to automatically check code for vulnerabilities and compliance with the organization's secure coding standards with a human reviewing the issues reported by the tool?
TASK.DEV.26.07 Does the software supplier use review checklists to verify that the code complies with the requirements?
TASK.DEV.26.08 Does the software supplier use expert reviewers to check code for backdoors and other malicious content?
TASK.DEV.26.09 Does the software supplier use automated tools to identify and verify unsafe software practices on a continuous basis as human-readable code is checked into the code repository?
TASK.DEV.26.10 Does the software supplier identify and document the root causes of discovered issues?
TASK.DEV.26.11 Does the software supplier record, triage, and address all discovered issues and recommended remediations in the development team's workflow or issue tracking system?
TASK.DEV.26.12 Does the software supplier follow up to capture metrics on error rates, remediation time, and resolution types to ensure issues are properly resolved?
TASK.DEV.26.13 Does the software supplier document lessons learned from code review and analysis and make the lessons available to developers?
CONTROL.DEV.27 Does the software supplier determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing?
CONTROL.DEV.28 Does the software supplier have a rigorous testing process that includes functional and dynamic testing, documenting of test results to include functional and dynamic types of testing, recording, and triaging all discovered issues in a workflow or issue tracking system?
Please answer the following Task questions:
TASK.DEV.28.01 Does the vendor's testers follow the organization's policies or guidelines for when code testing should be performed and how it should be conducted (e.g., within a sandboxed environment)?
TASK.DEV.28.02 Does the software supplier ensure that its policies and guidelines for code testing are followed for third-party executable code and reusable executable code modules written in-house?
TASK.DEV.28.03 Does the software supplier perform robust functional testing of security features?
TASK.DEV.28.04 Does the software supplier integrate dynamic vulnerability testing into the project's automated test suite?
TASK.DEV.28.05 Does the software supplier incorporate tests for previously reported vulnerabilities into the project's test suite to ensure that errors are not reintroduced?
TASK.DEV.28.06 Does the software supplier take into consideration the infrastructures and technology stacks the software will be used with when developing test plans in production?
TASK.DEV.28.07 Does the software supplier use fuzz testing tools to find issues with input handling?
TASK.DEV.28.08 Does the software supplier review, analyze, and/or test the software's code to identify or confirm the presence of previously undetected vulnerabilities?
TASK.DEV.28.09 Does the software supplier configure the toolchain to perform automated code analysis and testing on a regular or continuous basis for all supported releases?
TASK.DEV.28.10 Does the software supplier use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios?
TASK.DEV.28.11 Does the software supplier identify and record the root causes of discovered issues?
TASK.DEV.28.12 Does the software supplier document lessons learned from code testing with lessons provided to developers?
TASK.DEV.28.13 Does the software supplier use source code, design records, and other resources when developing test plans?
TASK.DEV.28.14 Does the software supplier 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?
CONTROL.DEV.29 Does the software supplier implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators?
Please answer the following Task questions:
TASK.DEV.29.01 Does the software supplier verify that the approved configuration is in place for the software?
TASK.DEV.29.02 Does the software supplier document each setting's purpose, options, default value, security relevance, potential operational impact, and relationships with other settings?
TASK.DEV.29.03 Does the software supplier use authoritative programmatic technical mechanisms to record how each setting can be implemented and assessed by software administrators?
TASK.DEV.29.04 Does the software supplier store the default configuration in a usable format? If so, does the software supplier follow change control practices for modifying it (e.g., configuration-as-code)?
CONTROL.DEV.30 Does the software supplier use a vulnerability disclosure program that gathers information on potential vulnerabilities in the software and its third-party components?
Please answer the following Task questions:
TASK.DEV.30.01 Does the software supplier monitor vulnerability databases, security mailing lists, and other sources of vulnerability reports through manual or automated means?
TASK.DEV.30.02 Does the software supplier use threat intelligence sources to better understand how vulnerabilities in general are being exploited?
TASK.DEV.30.03 Does the software supplier investigate all credible vulnerability reports?
TASK.DEV.30.04 Does the software supplier automatically review provenance and software composition data for all software components to identify any new vulnerabilities they have?

Response Status

0% Complete

Questions skipped:

0/58 Controls

0/316 Tasks

Secure Software Deployment

This section focuses on those aspects of the software supply chain that relate to secure deployment practices implemented by software suppliers and software consumers, such as federal agencies. Responses are provided by parties with ownership for risk management activities pertaining to the secure deployment of software within their respective environments and are intended to ensure that best practices for secure deployment of software are being applied.

Instructions:

Answer the CONTROL questions related to the software supplier's Supply Chain (SC). Select the appropriate “Yes”, “No”, “Partial”, or “N/A” response. Click Read More to get more information about the “Yes”, “No”, “Partial”, and “N/A” response criteria.

Yes - The supplier believes they have appropriate controls in place to meet the expectations of the CONTROL question, and they are prepared to provide supporting documentation if requested. The supporting TASK questions do not need to be answered; however, the TASK questions may be reviewed to determine full compliance with the expectations of a Yes answer to the CONTROL question.

No - Implies that the supplier believes they do not have appropriate controls in place to meet the expectations of the CONTROL question. The TASK questions can be used to determine whether the supplier lacks the appropriate controls or can indicated that they partially comply with the requirement.

Partial - The supplier complies with some of the requirements indicated in the CONTROL question. If the supplier indicates Partial compliance, use the TASK questions to identify the areas in which they comply and the areas that are potential recommendations for improvement or represent factors to consider in comparing the security posture of competing suppliers.

N/A - Indicates the supplier believes that in the operational context of their software, the CONTROL question does not apply. They may be required to indicate why.

A red asterisk (*) indicates a required field.

CONTROL.DEP.01 Has the software supplier implemented multi-factor authentication (MFA) for all login access to accounts for both local and remote access?
Please answer the following Task questions:
TASK.DEP.01.01 Do all user interactive administrative and privileged functions within the product require MFA?
TASK.DEP.01.02 Is MFA required for local account access?
TASK.DEP.01.03 Is MFA required for all user accounts by default?
TASK.DEP.01.04 If the product supports application program interface (API) access, is MFA required for any user to generate an API access token?
TASK.DEP.01.05 Does the supplier employ toolsets that are verifier impersonation-resistant for authenticating login access?
CONTROL.DEP.02 Does the software supplier's organization maintain updated cybersecurity incident response plans related to operating the software and development of the software?
Please answer the following Task questions:
TASK.DEP.02.01 Does the supplier provide details of the cybersecurity incident response communication process for its customers?
TASK.DEP.02.02 Does the supplier provide details of patch or other mitigation steps required as part of a cybersecurity incident or vulnerability response process?
TASK.DEP.02.03 Does the supplier communicate the occurrence of a cybersecurity incident to its customers?
TASK.DEP.02.04 Does the supplier have a Business Continuity Plan that is regularly exercised?
TASK.DEP.02.05 For SaaS or cloud-based services, does the supplier provide written SLAs related to restoration of service because of an incident?
TASK.DEP.02.06 For SaaS or cloud-based services, are all backups of the software supplier's systems that are necessary for operations regularly checked/exercised for restoration?
CONTROL.DEP.03 Does the software supplier follow best practices for log management as defined in NIST SP800-92 or OMB M-21-31?
Please answer the following Task questions:
TASK.DEP.03.01 Does the product support centralized logging?
TASK.DEP.03.02 Does the product generate log files in a consistent manner supporting automated analysis for unexpected events?
TASK.DEP.03.03 Does the product support policy-based configuration of log content?
TASK.DEP.03.04 If the product is deployed in a distributed manner, does the product synchronize timestamps between components of the product?
TASK.DEP.03.05 If the software supplier provides a SaaS solution, does the software supplier meet Event Logging Tier 1 (EL1) for low assurance environments?
TASK.DEP.03.06 If the software supplier provides a SaaS solution, does the supplier have a plan to meet higher logging tier levels consistent with the timelines outlined in M-21-31?
TASK.DEP.03.07 If the software supplier provides a SaaS solution, is the software supplier monitoring log activity on a regular basis for anomalous or suspicious events?
TASK.DEP.03.08 If the software supplier provides a SaaS solution, does the supplier retain log information consistent with the retention timelines outlined in M-21-31?
CONTROL.DEP.04 Does the supplier have a defined patch process for all software, tools, and systems used in the delivery of the software?
Please answer the following Task questions:
TASK.DEP.04.01 Does the patch process focus on response to vulnerabilities in a timely manner to reduce the cyberattack susceptibility window timeframe?
TASK.DEP.04.02 Does the software supplier maintain a patch history for all software, tools, and systems used in the delivery of the software?
TASK.DEP.04.03 Does the software supplier maintain a log of when patches are applied to all software, tools, and systems used in the delivery of the software?
TASK.DEP.04.04 If the supplier provides a SaaS solution, does the software supplier provide a documented SLA for patch application?
CONTROL.DEP.05 Does the supplier require its suppliers to have a process in place, such as scanning, to address undocumented or obsolete code or functions that might allow unauthorized access or use of the software product, or cause the software product to behave outside of the specified requirements or in an unreliable manner?
Please answer the following Task questions:
TASK.DEP.05.01 Does the software supplier require sub-suppliers to have a process to account for hidden functions and vulnerable features embedded in the code, describing their purpose and their impact on the integrity and reliability of software product?
TASK.DEP.05.02 Does the software supplier require sub-suppliers to have hidden functions removed or (as a minimum as part of security hardening procedures) addressed (e.g., as part of the failure modes and effects analysis of the software) to prevent any unauthorized access or degradation of the reliability of the software?
CONTROL.DEP.06 Does the supplier have protections in place between software supplier's network and cloud service providers, including protections associated with contractually specified government protection levels and personnel background checks if applicable?
Please answer the following Task questions:
TASK.DEP.06.01 If the supplier has connectivity to a government system requiring special protection levels, does the supplier have established policies in place requiring background checks and screening for personnel and requisite information handling procedures (including clearance levels and formal access approvals) appropriate to the protection level associated with the interconnected government system?
TASK.DEP.06.02 Does the supplier enforce the screening and formal access approval process for its personnel and subcontractors (including service providers) that have access to the government system requiring special protection levels?
TASK.DEP.06.03 Does the software supplier convey cloud security requirements to sub-suppliers and sub-contractors?
CONTROL.DEP.07 Does the software supplier's product support hardened security configurations that enforce the principles of least privilege, separation of duties, and least functionality?
Please answer the following Task questions:
TASK.DEP.07.01 Is hardened security configuration implemented as default, out-of-box behavior in the software supplier's product?
TASK.DEP.07.02 Does the software supplier provide accessible documentation on hardening the security configurations?
CONTROL.DEP.08 Does the software supplier have methods to verify the trust relationship between a product supplier and the party identified within a digital signature for a product installation package?
Please answer the following Task questions:
TASK.DEP.08.01 Does every party in the supply chain ensure that software received from their suppliers is validated, trusted, and authorized by an electronic certificate?
TASK.DEP.08.02 Does the supplier verify that the certification used to sign any software from each supplier is authorized by their supplier?
TASK.DEP.08.03 Does the supplier provide a means to verify that their certificate should be used to sign this software?
TASK.DEP.08.04 Does the software supplier restrict access to code signing certificates?
TASK.DEP.08.05 Does the supplier audit the use of their code signing certificates?
CONTROL.DEP.09 Do the binary packages distributed by the software supplier implement cryptographic signatures to ensure they are not manipulated or tainted?
Please answer the following Task questions:
TASK.DEP.09.01 Do the signatures also provide means to assure authenticity and ownership of the publisher for each individual component in the distribution?
TASK.DEP.09.02 Do the binary packages distributed by the software supplier implement verification of the integrity of the individual components in the distribution (e.g., Hash files representing checksum, cryptographically signed packages, and individual components included in the distribution and listed in the SBOM)?
TASK.DEP.09.03 Do software updates and upgrades verify the authenticity and ownership of the individual components included in the distribution through cryptographic signatures prior to installing the binary files (e.g., Trusted boot, Verified boot, or Secure boot)?
TASK.DEP.09.04 Are the binary packages distributed by the software supplier cryptographically signed using a valid public certificate authority for code signing so that consumers' operating systems or other tools and services can confirm the validity of signatures before use?
CONTROL.DEP.10 Does the software supplier certify their software against applicable standards and maintain that certification?
Please answer the following Task questions:
TASK.DEP.10.01 If the software supplier provides a SaaS solution, is the supplier's service examined by an accredited third-party certified to audit data protection and cybersecurity controls such as against the Association of International Certified Professional Accountants SOC 2 Trust Services Criteria for service organizations?
TASK.DEP.10.02 Is the software provided by the supplier certified against Common Criteria Protection Profile Tracks?
TASK.DEP.10.03 Is the software provided by the supplier certified against any U.S. federal government approved products list?
TASK.DEP.10.04 Does the software supplier follow an industry standard or framework such as NIST Risk Management Framework (RMF) for supplier's internal or third-party cloud deployments, as applicable?
TASK.DEP.10.05 Does the software supplier use a third-party auditing function or certifier?
CONTROL.DEP.11 Does the supplier provide detailed deployment guidance for the software?
Please answer the following Task questions:
TASK.DEP.11.01 Does the provided deployment guidance, and any associated deployment scripts or installers, follow secure by default principles?
TASK.DEP.11.02 Does the supplier document the expected network configuration, including any requirements for network isolation?
TASK.DEP.11.03 If the software is deployable in a distributed manner, including via the use of containers, are interdependencies between components in distributed systems documented?
TASK.DEP.11.04 If the software requires the use of a service provider, are service provider configuration requirements documented?
TASK.DEP.11.05 If the software requires the use of user downloaded components (e.g., a mobile application), are the deployment requirements for the product documented, including any required security configuration of the user device?
CONTROL.DEP.12 If the software requires the use of a service provider, does the supplier perform any pre-installation integrity or validation checks to ensure that the software continues to meet deployment or acceptance criteria associated with an authority to operate?
Please answer the following Task questions:
TASK.DEP.12.01 Does the supplier require vulnerability scanning of all software prior to installation?
TASK.DEP.12.02 Does the supplier have a process in place to identify and mitigate any inadvertent or inappropriate alterations of the software package that is delivered to consumers for installation?
TASK.DEP.12.03 Does the supplier perform a pre-installation review of configuration requirements to ensure that any deployment dependencies meet deployment or acceptance criteria associated with an authority to operate?

Response Status

0% Complete

Questions skipped:

0/58 Controls

0/316 Tasks

Vulnerability Management

Software suppliers are expected to monitor their software products for vulnerabilities following “NIST Guidance” as specified in OMB M-22-18, coordinated vulnerability disclosure standards and processes, and other on-going methods. Software suppliers issue security advisories to identify the list of products in their product catalog that are affected whenever a new vulnerability is reported. Customers use these security advisories to evaluate risk within their ecosystems and take mitigating action based on guidance provided in the security advisory. Ideally, a software supplier will provide their security advisories in both human-readable and machine-readable forms.

Instructions:

Answer the CONTROL questions related to the software supplier's Supply Chain (SC). Select the appropriate “Yes”, “No”, “Partial”, or “N/A” response. Click Read More to get more information about the “Yes”, “No”, “Partial”, and “N/A” response criteria.

Yes - The supplier believes they have appropriate controls in place to meet the expectations of the CONTROL question, and they are prepared to provide supporting documentation if requested. The supporting TASK questions do not need to be answered; however, the TASK questions may be reviewed to determine full compliance with the expectations of a Yes answer to the CONTROL question.

No - Implies that the supplier believes they do not have appropriate controls in place to meet the expectations of the CONTROL question. The TASK questions can be used to determine whether the supplier lacks the appropriate controls or can indicated that they partially comply with the requirement.

Partial - The supplier complies with some of the requirements indicated in the CONTROL question. If the supplier indicates Partial compliance, use the TASK questions to identify the areas in which they comply and the areas that are potential recommendations for improvement or represent factors to consider in comparing the security posture of competing suppliers.

N/A - Indicates the supplier believes that in the operational context of their software, the CONTROL question does not apply. They may be required to indicate why.

A red asterisk (*) indicates a required field.

CONTROL.VULN.01 Does the supplier provide a NIST-defined vulnerability disclosure report for the current version of the product and all future versions, including updates?
Please answer the following Task questions:
TASK.VULN.01.01 Are software operators expected to directly update individual components from suppliers providing patches for the identified vulnerability or update the product directly from the supplier?
TASK.VULN.01.02 Does the supplier provide mitigation guidance following "NIST Guidance" per OMB memo M-22-18?
TASK.VULN.01.03 Does the mitigation guidance allow software operators to effectively remove or reduce the vulnerability risk?
TASK.VULN.01.04 Does the supplier include descriptions of mitigations performed by the supplier to address vulnerabilities?
TASK.VULN.01.05 Does the supplier have established remediation time thresholds for levels of severity/criticality in software vulnerabilities?
TASK.VULN.01.06 Do acceptance teams implement a trust but verify model where the product is analyzed by a software composition analysis or risk assessment tool capable of performing a binary analysis?
CONTROL.VULN.02 Does the supplier scan for and mitigate potential vulnerabilities at the component level within the product?
Please answer the following Task questions:
TASK.VULN.02.01 Has the supplier ensured these processes operate on an ongoing basis and, at a minimum, prior to product, version, or update releases?
TASK.VULN.02.02 Has the supplier remediated or mitigated material security relevant vulnerabilities prior to product release?
CONTROL.VULN.03 Does the software supplier provide a notification process for vulnerability disclosures?
Please answer the following Task questions:
TASK.VULN.03.01 Does vulnerability notification occur in advance of patch availability or only upon release of a patch?
TASK.VULN.03.02 Does vulnerability notification include mitigation options?
TASK.VULN.03.03 Does vulnerability notification include root cause and/or impact analysis via a Common Weakness Enumeration (CWE)?
TASK.VULN.03.04 Does the supplier provide both a human-readable and machine-readable security advisory, such as CSAF formatted Security Advisory (profile 4)?
CONTROL.VULN.04 Does the supplier have documented policies or procedures for internal identification and management of vulnerabilities within their networks and enterprise systems?
Please answer the following Task questions:
TASK.VULN.04.01 Are automated mechanisms employed to detect and notify authorized personnel of the presence of unauthorized software on networks and enterprise systems?
TASK.VULN.04.02 Are automated mechanisms employed to compare the results of vulnerability scans over time to determine trends in networks and enterprise systems vulnerabilities and mitigation/flaw remediation activities?
TASK.VULN.04.03 Does the supplier discern and document what information associated with the networks and enterprise systems is discoverable publicly over the internet?
TASK.VULN.04.04 Does the supplier employ vulnerability scanning tools and techniques that promote interoperability among tools and vulnerability management automation?
TASK.VULN.04.05 Does the supplier have established remediation time thresholds for levels of severity/criticality in networks and enterprise systems?
CONTROL.VULN.05 Does the supplier employ vulnerability scanning procedures that maximize the breadth and depth of coverage within their own digital ecosystem, especially software development and build environments (i.e., networks and enterprise system components scanned, and vulnerabilities checked)?
Please answer the following Task questions:
TASK.VULN.05.01 Does the supplier analyze vulnerability scan reports regularly (at least weekly)?
TASK.VULN.05.02 Does the supplier employ vulnerability scanning tools that include the capability to update the list of cyber vulnerabilities scanned?
TASK.VULN.05.03 Does the supplier update the list of vulnerabilities scanned regularly (at least weekly) and when new vulnerabilities are identified and reported?
TASK.VULN.05.04 Does the supplier include privileged access authorization to networks and enterprise systems for selected vulnerability scanning activities to facilitate more thorough scanning?
TASK.VULN.05.05 "Does the supplier perform security testing to determine the level of difficulty in circumventing the security controls of the networks and enterprise systems? Note: Testing methods include penetration testing, malicious user testing, and independent verification and validation."
CONTROL.VULN.06 Does the software supplier have a policy and program to monitor for vulnerabilities within the supplier's running ecosystem and remediate such security-relevant vulnerabilities?
Please answer the following Task questions:
TASK.VULN.06.01 Has the supplier ensured these processes operate on an ongoing basis and, at a minimum, prior to product, version, or update releases?
TASK.VULN.06.02 Has the supplier remediated or mitigated material security relevant vulnerabilities prior to product release?
CONTROL.VULN.07 Does the supplier implement industry standards or frameworks for vulnerability management?
Please answer the following Task questions:
TASK.VULN.07.01 Does the software supplier have an intrusion detection and monitoring system in place to detect unauthorized activities?
TASK.VULN.07.02 Does the software supplier's organization maintain updated indicators of compromise?
TASK.VULN.07.03 Does the supplier's organization scan for vulnerabilities in externally obtained software (e.g., pen testing of enterprise and non-enterprise software)?
TASK.VULN.07.04 Does the supplier conduct threat hunting exercises and pen testing on a reasonable cadence?
CONTROL.VULN.08 Does the supplier implement a documented process to resolve and disclose identified vulnerabilities in a software product?
Please answer the following Task questions:
TASK.VULN.08.01 Does the supplier have a reasonable policy and process to disclose security-relevant vulnerabilities?
TASK.VULN.08.02 Does the software supplier have processes to ensure sub-suppliers disclose vulnerabilities?

Optional Details

This section provides an optional space to record contact information for those assisting with the completion of your Software Acquisition Guide. Please note that no information is stored on our servers. If you find this unnecessary, feel free to skip to the next section.

Created By

Primary Point of Contact

Up to 5 supporting Point of Contacts (POC) may be added.

POC 1

Clear

Add any additional notes or comments supporting the completion of your Software Acquisition Guide below

Response Summary

The below tabs provide a summary of the responses provided. Review all responses to ensure accuracy. Once finalized, an authorized representative may sign and approve the Response Summary.

This Response Summary can be used to initiate and structure discussions with cybersecurity staff and enterprise risk owners to describe, assess, and measure suppliers' security practices relative to the software life cycle.

The format of the Software Acquisition Guide is intended to gather an initial and consistent baseline to assess the cybersecurity development practices used by a software supplier in the software supply chain associated with the software being assessed. Additional follow-up questions for the supplier, including supporting documentation, may be warranted.

Show Skipped Questions:

Basic Info

Software Name:
Supplier Name:
Start Date:
Complete Date:

Governance and Attestations

CONTROL.GOV.01
Does the supplier provide a CISA Secure Software Development Attestation Form, or equivalent such as the GSA 7700 Secure Software Development Attestation Form, without need for a POA&M, signed by the supplier's designated employee (Chief Executive Officer or designee that can bind the supplier)?
Skipped
CONTROL.GOV.02
Does the Supplier maintain provenance data for internal and third-party components?
Skipped
CONTROL.GOV.03
Has the supplier's product(s) or product line employed automated tools or comparable processes including, but not limited to, log management and patch management to maintain integrity of software supply chains and to check for and mitigate security-relevant vulnerabilities in binary, source code, development, and build systems?
Skipped
CONTROL.GOV.04
Has all the software (including third-party and open source) to be delivered undergone rigorous code analysis and multi-level testing according to the supplier's documented testing procedures? Foremost in this testing is the identification of code weaknesses and software vulnerabilities, including those listed in the DHS CISA Known Exploited Vulnerabilities (KEV) Catalog with vulnerable components either patched, rebuilt, or otherwise mitigated.
Skipped
CONTROL.GOV.05
Does the supplier use industry standards or frameworks for implementing vulnerability scanning and vulnerability management, and to communicate mitigation status for any unpatched vulnerabilities using machine-readable formats, such as a Common Security Advisory Framework (CSAF) Security Advisory, a NIST defined VDR, or a VEX document, for the current version of the application and all future versions and updates?
Skipped
CONTROL.GOV.06
Does the supplier use a secure by default approach for software deployment processes?
Skipped
CONTROL.GOV.07
Does the supplier use secure by design tactics ensuring that their product been developed and built in secure environments using community or industry recognized frameworks, certified against those applicable standards, and tested in an environment following zero-trust principles?
Skipped
CONTROL.GOV.08
Prior to incorporating any third-party components in its software components, products or services provided to customers, does the software supplier require third-party software suppliers to produce a software bill of materials (SBOMs), to establish a vulnerability disclosure policy, and to follow “NIST Guidance” as specified in OMB M-22-18?
Skipped
CONTROL.GOV.09
Does the supplier provide a machine-readable SBOM meeting minimum requirements defined by National Telecommunications Information Administration (NTIA) or successor guidance as published by CISA that covers all software components of the product being delivered to the customer organization?
Skipped
CONTROL.GOV.10
Does the supplier define and enforce policies controlling the use of open source libraries and software, AI generated code, and AI powered toolchains?
Skipped
CONTROL.GOV.11
For the products or services being provided, has the supplier received a successful third-party FedRAMP High or Moderate Baseline certification?
Skipped
CONTROL.GOV.12
Does the supplier have protections and verification methods in place with third-party suppliers (for software, network, and cloud services) for products or services provided to the customer that are commensurate with contractually specified government protection levels and trust relationships?
Skipped
CONTROL.GOV.13
Does the software supplier establish and resource a Cyber Supply Chain Risk Management (C-SCRM) Program that includes attack and risk modeling and incident management and response?
Skipped
CONTROL.GOV.14
Does the software supplier provide role-based SDLC-related training and have qualified personnel and/or automated processes that contribute to all parts of the SDLC, including secure architecture, development, testing, and threat modeling?
Skipped
CONTROL.GOV.15
Does the supplier have and enforce defined policies for software security requirements, including securely storing all forms of code (for source code, executable code, binaries, and configuration-as-code), release artifacts, and associated integrity verification information for each release?
Skipped
CONTROL.GOV.16
Does the supplier have policies and procedures that ensure the maximum use of software modules providing standardized implementations of security features and services or the reuse of well-secured software components developed in-house following SDLC processes?
Skipped
CONTROL.GOV.17
Does the supplier have policies and procedures to use built-in checks and protections supported by programming languages or environments, both compiled and interpreted during development and in the software shipped/distributed?
Skipped
CONTROL.GOV.18
Do software supplier's procurement, outsourcing, and contractual agreements, such as Service Level Agreements (SLAs), stipulate that their sub-suppliers and/or service providers follow secure SDLC practices, scan for undocumented, unused, or obsolete functions, and notify the software supplier of identified vulnerabilities or security incidents?
Skipped
CONTROL.GOV.19
Does the supplier provide license terms that permit the using enterprise, agency, organization, or a trusted third party to scan the delivered software relative to provenance and security?
Skipped

Software Supply Chain

CONTROL.SC.01
Does the supplier have policies and procedures to validate the development of software used, including all libraries, and with the exception of Integrated Development Environment (IDE), compiler, build, packaging, and Continuous Integration/Continuous Delivery (CI/CD) tools, occurs using supplier employees or vetted contract employees?
Skipped
TASK.SC.01.01
Were sub-contractors or contracted development teams used in the creation of the software?
Skipped
TASK.SC.01.02
Does the product include or depend upon Commercial off-the-shelf/Government off-the-shelf (COTS/GOTS) or commercial libraries?
Skipped
TASK.SC.01.03
Does the product include or depend upon open source libraries?
Skipped
TASK.SC.01.04
Does the product include or depend upon AI generated source code or libraries?
Skipped
CONTROL.SC.02
Does the supplier create a validated SBOM in an NTIA or CISA approved machine-readable format with NTIA or CISA defined minimum fields for all releases of the software, including updates?
Skipped
TASK.SC.02.01
Does the supplier document its SBOM creation processes?
Skipped
TASK.SC.02.02
Does the supplier publish its SBOM in an accessible location?
Skipped
TASK.SC.02.03
Is the SBOM provided in an NTIA or CISA approved machine-readable format?
Skipped
TASK.SC.02.04
Does the supplier provide a conformance or attestation to ensure the SBOM is accurate and complete?
Skipped
CONTROL.SC.03
Does the supplier perform cyber risk management on outsourced, or third-party contracted, software development?
Skipped
TASK.SC.03.01
Does the supplier review any differences in the IDE, compiler, build, packaging, and CI/CD tools used by a contractor relative to those used by internal development teams?
Skipped
TASK.SC.03.02
Are contractors permitted to sub-contract for contracted work?
Skipped
TASK.SC.03.03
Are periodic threat models performed as part of a contractor risk management effort?
Skipped
CONTROL.SC.04
Does the supplier have a defined policy and process for open source governance as typically established by an Open Source Program Office (OSPO)?
Skipped
TASK.SC.04.01
Is there a defined review process for any new usage of an open source component prior to its first usage in the software?
Skipped
TASK.SC.04.02
Is there a process to identify and remediate known vulnerabilities in open source components as minimally disclosed in the National Vulnerability Database (NVD)?
Skipped
TASK.SC.04.03
Is there a process to identify abandoned, unmaintained, obsolete, or compromised open source libraries?
Skipped
TASK.SC.04.04
Is there a process to perform ongoing security testing on open source libraries used within the software?
Skipped
CONTROL.SC.05
Does the software supplier establish and resource a C-SCRM Program?
Skipped
TASK.SC.05.01
Does the software supplier obtain executive leadership support for C-SCRM?
Skipped
TASK.SC.05.02
Does the software supplier have established C-SCRM policies across enterprise-levels?
Skipped
TASK.SC.05.03
Does the software supplier have an established C-SCRM governance structure?
Skipped
TASK.SC.05.04
Does the software supplier have well-documented, consistent, and validated C-SCRM processes?
Skipped
TASK.SC.05.05
Does the software supplier establish a C-SCRM threat awareness program?
Skipped
TASK.SC.05.06
Does the software supplier have a quality and reliability program?
Skipped
TASK.SC.05.07
Does the software supplier integrate C-SCRM into acquisition/procurement policies?
Skipped
TASK.SC.05.08
Does the software supplier determine impact levels and categorize/assess its systems according to those impact levels (e.g., FIPS 199 impact levels)?
Skipped
TASK.SC.05.09
Does the software supplier have defined, explicit roles for C-SCRM?
Skipped
TASK.SC.05.10
Does the software supplier have adequate and dedicated C-SCRM resources?
Skipped
TASK.SC.05.11
Does the software supplier have a defined C-SCRM control baseline?
Skipped
TASK.SC.05.12
Does the software supplier have C-SCRM internal checks and balances to assure compliance?
Skipped
TASK.SC.05.13
Does the software supplier have a supplier management program?
Skipped
CONTROL.SC.06
Does the software supplier have and enforce policies covering the usage of AI generated code (e.g., ChatGPT or GitHub CoPilot) or code otherwise generated by a third-party tool or service (e.g. Low-Code or No-Code) within its software supply chain?
Skipped
TASK.SC.06.01
Does the supplier include a review for AI generated code as part of its vendor selection process?
Skipped
TASK.SC.06.02
Does the supplier perform a risk assessment to determine the impact of AI generated code on the security functions within the software under review?
Skipped
TASK.SC.06.03
Does the supplier validate the software license implications covering the usage of AI generated code?
Skipped
TASK.SC.06.04
Does the supplier review the usage of AI or cloud powered developer tools?
Skipped
TASK.SC.06.05
Does the supplier use automated tooling to identify where AI or cloud generated code is used within the software?
Skipped
TASK.SC.06.06
Does the supplier maintain an approved list of AI code generation implementations?
Skipped
TASK.SC.06.07
Does the supplier perform ongoing periodic reviews for data leakage associated with AI or cloud generated code?
Skipped
CONTROL.SC.07
Does the software supplier acquire and maintain current well-secured, vetted software components (e.g., software libraries, modules, middleware) from commercial, open source, and other third-party developers for use by the organization's software throughout the lifespan of the software?
Skipped
TASK.SC.07.01
Does the software supplier review and evaluate third-party software components and their security aspects in the context of their expected use?
Skipped
TASK.SC.07.02
If a third-party component is to be used in a substantially different way than when initially approved for use, does the software supplier perform the review and evaluation again with that new context in mind?
Skipped
TASK.SC.07.03
Does the software supplier determine secure configurations for software components, and make these available (e.g., as configuration-as-code) so developers can readily use the configurations?
Skipped
TASK.SC.07.04
Does the software supplier implement processes to update deployed software components to newer versions?
Skipped
TASK.SC.07.05
Does the supplier update process include retaining older versions of software components until all transitions from those versions have been completed successfully?
Skipped
CONTROL.SC.08
Does the software supplier obtain and manage provenance information (e.g., SBOM, source composition analysis, binary software composition analysis) for each software component?
Skipped
TASK.SC.08.01
Does the software supplier analyze provenance information to better assess the risk that the component may introduce?
Skipped
TASK.SC.08.02
Does the software supplier verify, safeguard, and maintain provenance data for all components of each software release (e.g., in a SBOM)?
Skipped
TASK.SC.08.03
Does the software supplier make the software component provenance data available to the organization's operations and response teams to aid them in mitigating software vulnerabilities?
Skipped
TASK.SC.08.04
Does the software supplier protect the integrity of provenance data, and provide a way for recipients to verify provenance data integrity?
Skipped
TASK.SC.08.05
Does the software supplier establish one or more software repositories to host sanctioned and vetted open source components?
Skipped
TASK.SC.08.06
Does the supplier maintain a list of organization approved commercial software components and component versions along with their provenance data?
Skipped
TASK.SC.08.07
Does the software supplier designate that only organization approved components be included in software to be developed?
Skipped
TASK.SC.08.08
Does the software supplier update the provenance information every time any of the software's components are updated?
Skipped
TASK.SC.08.09
If the vendor cannot determine the integrity or provenance of acquired binaries, do they verify the source code's integrity, security, and provenance, and rebuild the binaries from source code?
Skipped
TASK.SC.08.10
Does the software supplier make the software component provenance data available to software acquirers in accordance with the organization's policies?
Skipped
TASK.SC.08.11
For commercial and cloud software, does the supplier include provenance attributes such as supplier ownership or control, or Data Universal Numbering System (DUNS) verification?
Skipped

Secure Software Development

CONTROL.DEV.01
Does the software supplier identify, document, and maintain all security requirements for the organization's software development infrastructures and processes?
Skipped
TASK.DEV.01.01
Does the software supplier have defined policies for establishing and maintaining secure software development infrastructures and the component elements of those infrastructures (such as build and staging systems) throughout the SDLC?
Skipped
TASK.DEV.01.02
Does the software supplier have defined policies for establishing and maintaining secure software development infrastructure and processes throughout the SDLC?
Skipped
TASK.DEV.01.03
Does the software supplier review and update security requirements at least annually?
Skipped
TASK.DEV.01.04
Does the software supplier review and update security requirements if a major software development security incident occurs?
Skipped
CONTROL.DEV.02
Does the software supplier identify, document, and maintain all security requirements for organization-developed software to meet?
Skipped
TASK.DEV.02.01
Does the software supplier have defined policies that specify risk-based software architecture and design requirements (e.g., modular code, security component separation)?
Skipped
TASK.DEV.02.02
Does the software supplier have defined policies specifying the organization's software security requirements?
Skipped
TASK.DEV.02.03
Does the software supplier perform risk assessments of applicable technology stacks?
Skipped
TASK.DEV.02.04
Does the software supplier have defined policies specifying what needs to be archived for each software release?
Skipped
TASK.DEV.02.05
Does the supplier maintain the security requirements over time?
Skipped
TASK.DEV.02.06
Does the software supplier ensure that its policies cover the entire software life cycle?
Skipped
TASK.DEV.02.07
Does the supplier specify how long archives need to be retained based on the SDLC model, software end-of-life, and other factors?
Skipped
TASK.DEV.02.08
Does the supplier notify users of the impending end of software support and the date of software end-of-life?
Skipped
TASK.DEV.02.09
Does the software supplier have established processes for handling requirement exception requests?
Skipped
TASK.DEV.02.10
For any exceptions, does the supplier have a process to periodically review all approved exceptions?
Skipped
CONTROL.DEV.03
Does the software supplier communicate security acceptance criteria to all third parties who will provide commercial software components to the organization for reuse by the organization's own software?
Skipped
TASK.DEV.03.01
Does the software supplier have a defined set of core security requirements for third-party software components?
Skipped
TASK.DEV.03.02
Does the supplier incorporate security requirements in all acquisition documents, software contracts, and other agreements with third parties?
Skipped
TASK.DEV.03.03
Does the software supplier have defined security related criteria for selecting software from its sources?
Skipped
TASK.DEV.03.04
Does the software supplier require its suppliers (third parties) to attest that their software complies with the organization's security requirements?'
Skipped
TASK.DEV.03.05
Does the software supplier require its suppliers (third parties) to supply provenance data and integrity verification mechanisms for all components of their software?
Skipped
TASK.DEV.03.06
Does the software supplier have exception processes to address risk when its security requirements related to acquired third party software components are not met by that supplier/source?
Skipped
TASK.DEV.03.07
For exceptions to security requirements, does the supplier have a process to periodically review all exceptions to requirements?
Skipped
TASK.DEV.03.08
Does the supplier require a vulnerability disclosure program and/or product security incident response capabilities from its sources?
Skipped
CONTROL.DEV.04
Does the software supplier create and maintain new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC?
Skipped
TASK.DEV.04.01
Does the software supplier integrate security roles into the software development team?
Skipped
TASK.DEV.04.02
Does the software supplier have defined SDLC related roles and responsibilities for all members of the software development team?
Skipped
TASK.DEV.04.03
Does the software supplier have defined roles and responsibilities for other cybersecurity staff and points of contact associated with the SDLC (e.g., security champions, project managers and leads, senior management, software testers, software assurance leads and staff, product owners)?
Skipped
TASK.DEV.04.04
Does the software supplier conduct an annual review of all roles and responsibilities?
Skipped
TASK.DEV.04.05
Does the software supplier educate impacted individuals on impending changes to roles and responsibilities?
Skipped
TASK.DEV.04.06
Does the software supplier use tools and processes to promote communication and engagement among individuals with SDLC-related roles and responsibilities?
Skipped
TASK.DEV.04.07
Does the software supplier designate a group of individuals or a team as the code owner for each project?
Skipped
CONTROL.DEV.05
Does the software supplier provide periodically updated role-based, SDLC-related training for all personnel with responsibilities that contribute to secure architecture, development, testing, and threat modeling?
Skipped
TASK.DEV.05.01
Does the software supplier periodically review role-based training and update the training as needed?
Skipped
TASK.DEV.05.02
Does the software supplier periodically review personnel proficiency against their assigned role to determine whether additional training or training updates are needed?
Skipped
TASK.DEV.05.03
Does the software supplier document the desired outcomes of training for each role?
Skipped
TASK.DEV.05.04
Does the software supplier define the type of training or curriculum required to achieve the desired outcome for each role?
Skipped
TASK.DEV.05.05
Does the software supplier acquire or create training for each role?
Skipped
TASK.DEV.05.06
Does the software supplier measure outcome performance to identify areas where changes to training may be beneficial?
Skipped
CONTROL.DEV.06
Does the software supplier obtain upper management or authorizing official commitment to secure development practices, and convey that commitment to all with SDLC-related roles and responsibilities?
Skipped
TASK.DEV.06.01
Does the software supplier appoint a single leader or leadership team to be responsible for the entire secure software development process?
Skipped
TASK.DEV.06.02
Does the software supplier management (at all levels) incorporate secure development support into their communications with personnel (in particular, those with development-related roles and responsibilities)?
Skipped
TASK.DEV.06.03
Does leadership of the secure software development process include accountability for releasing software to production and delegating responsibilities as appropriate?
Skipped
TASK.DEV.06.04
Does the software supplier educate management personnel on the importance of secure development to the organization?
Skipped
TASK.DEV.06.05
Does the software supplier educate all personnel with development-related roles and responsibilities on upper management's commitment to secure development and the importance of secure development to the organization?
Skipped
CONTROL.DEV.07
Does the software supplier define categories (e.g., IDE, compiler, build, and CI/CD tools) within toolchains, and specify the mandatory tools or tool types to be used for each category?
Skipped
TASK.DEV.07.01
Does the software supplier identify security tools to integrate into the software developers' toolchain?
Skipped
TASK.DEV.07.02
Does the software supplier provide information (e.g., settings) that can be used to rebuild the software?
Skipped
TASK.DEV.07.03
Does the software supplier evaluate tools' capabilities to create immutable (signed) records/logs for auditability within the toolchain?
Skipped
TASK.DEV.07.04
Does the software supplier use automated technology for toolchain management and orchestration?
Skipped
CONTROL.DEV.08
Does the software supplier follow NIST recommended security practices to deploy, operate, and maintain tools and toolchains?
Skipped
TASK.DEV.08.01
Does the software supplier include cybersecurity considerations or assessments in its evaluation, selection, and acquisition of its tools?
Skipped
TASK.DEV.08.02
Does the software supplier use code-based configuration for development toolchains (e.g., pipelines-as-code, toolchains-as-code)?
Skipped
TASK.DEV.08.03
Does the software supplier implement software development technologies and processes needed for reproducible builds?
Skipped
TASK.DEV.08.04
Does the software supplier update, upgrade, or replace software development tools as needed to address tool vulnerabilities or add new tool capabilities?
Skipped
TASK.DEV.08.05
Does the software supplier continuously monitor tools and tool logs for potential operational and security issues, including policy violations and anomalous behavior?
Skipped
CONTROL.DEV.09
Does the software supplier configure tools to generate artifacts of their compliance with secure software development practices as defined by the organization?
Skipped
TASK.DEV.09.01
Does the software supplier use automated workflow 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?
Skipped
TASK.DEV.09.02
Does the software supplier determine how often the collected information should be audited, and implement the necessary processes?
Skipped
TASK.DEV.09.03
Does the software supplier establish and enforce security and retention policies for software development artifact data?
Skipped
TASK.DEV.09.04
Does the software supplier assign responsibility for creating and managing any needed artifacts that tools cannot generate?
Skipped
TASK.DEV.09.05
Does the supplier encrypt build-related artifacts at rest and in transit?
Skipped
CONTROL.DEV.10
Does the software supplier define, gather, and use software security criteria and measures throughout the SDLC?
Skipped
TASK.DEV.10.01
Does the software supplier ensure that the software development security criteria adequately indicate how effectively security risk is being managed?
Skipped
TASK.DEV.10.02
Does the software supplier define key performance indicators (KPIs), key risk indicators (KRIs), vulnerability severity scores, and other measures for software security?
Skipped
TASK.DEV.10.03
Does the software supplier review the artifacts generated as part of the software development workflow system to determine if they meet the criteria?
Skipped
TASK.DEV.10.04
Does the software supplier use the software development toolchain to automatically gather information that informs security decision-making?
Skipped
TASK.DEV.10.05
Does the software supplier deploy additional tools if needed to support the generation and collection of information supporting the criteria?
Skipped
TASK.DEV.10.06
Does the software supplier automate decision-making processes using the security criteria, and periodically review these processes?
Skipped
TASK.DEV.10.07
Does the software supplier only allow authorized personnel to access the gathered information?
Skipped
TASK.DEV.10.08
Does the software supplier prevent any alteration or deletion of the gathered information?
Skipped
CONTROL.DEV.11
Does the software supplier separate and protect each environment used in a phase of software development (build system, staging, and production)?
Skipped
TASK.DEV.11.01
Does the software supplier use multi-factor, risk-based authentication, and conditional access for each environment?
Skipped
TASK.DEV.11.02
Does the software supplier use network segmentation and access controls consistent with zero-trust principles to separate each environment from others and from production environments, and to separate components from each other within each non-production environment?
Skipped
TASK.DEV.11.03
Does the software supplier enforce authentication and tightly restrict connections entering and exiting each software development environment, including minimizing access to the internet to only what is necessary?
Skipped
TASK.DEV.11.04
Does the software supplier minimize direct human access to toolchain systems such as build services?
Skipped
TASK.DEV.11.05
Does the software supplier continuously monitor and audit all access attempts and all use of privileged access?
Skipped
TASK.DEV.11.06
Does the software supplier isolate the use of production environment software and services from non-production environments?
Skipped
TASK.DEV.11.07
Does the software supplier regularly log, monitor, and audit trust relationships for authorization and access between the environments and between the components within each environment?
Skipped
TASK.DEV.11.08
Does the software supplier 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?
Skipped
TASK.DEV.11.09
Does the software supplier configure security controls and other tools involved in separating and protecting the environments to generate artifacts for their activities?
Skipped
TASK.DEV.11.10
Does the software supplier continuously monitor all software deployed in each environment for new vulnerabilities?
Skipped
TASK.DEV.11.11
Does the software supplier follow a risk-based approach to respond to vulnerabilities?
Skipped
CONTROL.DEV.12
Does the software supplier secure its development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach?
Skipped
TASK.DEV.12.01
Does the software supplier configure each development endpoint based on approved hardening guides, checklists, etc.?
Skipped
TASK.DEV.12.02
Does the software supplier 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?
Skipped
TASK.DEV.12.03
Does the software supplier continuously monitor the security posture of all development endpoints, including monitoring and auditing all use of privileged access?
Skipped
TASK.DEV.12.04
Does the software supplier configure security controls and other tools involved in securing and hardening development endpoints to generate artifacts for their activities?
Skipped
TASK.DEV.12.05
Does the software supplier require multi-factor authentication (MFA) for all access to development endpoints and development resources?
Skipped
TASK.DEV.12.06
Does the software supplier provide dedicated development endpoints on non-production networks for performing all development-related tasks?
Skipped
TASK.DEV.12.07
Does the software supplier also provide separate endpoints on production networks for non-development related tasks, such as system administration tasks?
Skipped
TASK.DEV.12.08
Does the software supplier follow a zero-trust architecture to configure each development endpoint?
Skipped
CONTROL.DEV.13
Does the software supplier have defined policies for securely storing all forms of code (including source code, executable code, and configuration-as-code), release artifacts, and associated integrity verification information for each release?
Skipped
TASK.DEV.13.01
Does the software supplier store all source code and configuration-as-code in a version controlled code repository to track all changes?
Skipped
TASK.DEV.13.02
Does the software supplier use commit signing for code repositories?
Skipped
TASK.DEV.13.03
Does the software supplier have the code owner review and approve all changes made to the code by others?
Skipped
TASK.DEV.13.04
Does the software supplier use code signing to help protect the integrity of executables?
Skipped
TASK.DEV.13.05
Does the software supplier use cryptography (e.g., cryptographic hashes) to help protect file integrity?
Skipped
TASK.DEV.13.06
Does the software supplier securely store the necessary files and supporting data (e.g., integrity verification information) to be retained for each software release (e.g., by keeping it in a separate location from the release files or by signing the data)?
Skipped
TASK.DEV.13.07
Does the software supplier store all forms of code and associated integrity verification information for each release based on the principle of least privilege (including read-only access for release files) so that only authorized personnel, tools, services, etc. have access?
Skipped
TASK.DEV.13.08
Does the supplier automatically revoke access to development and/or release repositories when an authorized user is no longer an active member of the development team associated with the repository?
Skipped
TASK.DEV.13.09
Does the software supplier securely archive the necessary files and supporting data (e.g., integrity verification information) to be retained for each software release?
Skipped
TASK.DEV.13.10
Does the supplier periodically review source code and integrity verification information access logs for attempted access and compare such access to the list of authorized accounts?
Skipped
CONTROL.DEV.14
Does the software supplier make software authenticity and integrity verification information available to software acquirers?
Skipped
TASK.DEV.14.01
Does the software supplier post cryptographic hashes for release files on a well-secured website?
Skipped
TASK.DEV.14.02
Does the software supplier use an established certificate authority or trusted signing keys for code signing so that consumers' operating systems or other tools and services can confirm the validity of signatures before use?
Skipped
TASK.DEV.14.03
Does the software supplier periodically review the code signing processes, including signing keys renewal, rotation, revocation, and protection?
Skipped
CONTROL.DEV.15
Does the software supplier use forms of risk modeling-such as threat modeling, attack modeling, or attack surface mapping-to help assess the security risk for the software?
Skipped
TASK.DEV.15.01
Does the software supplier train the development team how to use a risk-based approach to communicate the risks and determine how to address them, including implementing mitigations?
Skipped
TASK.DEV.15.02
Does the software supplier apply additional rigor in performing assessments for high-risk areas, such as protecting sensitive data and safeguarding identification, authentication, and access control including credential management?
Skipped
TASK.DEV.15.03
Does the software supplier review vulnerability reports and statistics for previous software versions to inform the security risk assessment?
Skipped
TASK.DEV.15.04
Does the software supplier use data classification methods to identify and characterize each type of data that the software will interact with?
Skipped
CONTROL.DEV.16
Does the software supplier track and maintain the software's security requirements, risks, and design decisions?
Skipped
TASK.DEV.16.01
Does the software supplier record the response to each identified risk, including mitigations performed, the rationale for any approved exceptions to the security requirements, and any mitigation additions to the software's security requirements?
Skipped
TASK.DEV.16.02
Does the software supplier 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?
Skipped
TASK.DEV.16.03
Does the software supplier periodically re-evaluate all approved exceptions to the security requirements and implement changes as needed?
Skipped
CONTROL.DEV.17
Does the software supplier take advantage of modules providing standardized implementations of security features and services where appropriate instead of creating customized implementations of security features and services?
Skipped
TASK.DEV.17.01
Does the software supplier maintain one or more software repositories of modules for supporting standardized security features and services?
Skipped
TASK.DEV.17.02
Does the software supplier 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?
Skipped
TASK.DEV.17.03
Does the software supplier define criteria for which security features and services must be supported by software to be developed?
Skipped
CONTROL.DEV.18
Does the software supplier have qualified personnel and/or automated processes to review alignment between the software design and security requirements?
Skipped
TASK.DEV.18.01
Does the software supplier review the software design to confirm that it addresses applicable security requirements?
Skipped
TASK.DEV.18.02
Does the software supplier review the risk models created during software design to determine if they appear to adequately identify the risks?
Skipped
TASK.DEV.18.03
Does the software supplier review the software design to confirm that it satisfactorily addresses the risks identified by the risk models?
Skipped
TASK.DEV.18.04
Does the software supplier have the software architect correct failures to meet the requirements?
Skipped
TASK.DEV.18.05
Does the software supplier change the design and/or the risk response strategy if the security requirements cannot be met?
Skipped
TASK.DEV.18.06
Does the software supplier record the findings of design reviews to serve as artifacts?
Skipped
CONTROL.DEV.19
Does the software supplier create, maintain, and reuse well-secured software components developed in-house following SDLC processes to meet shared internal software development?
Skipped
TASK.DEV.19.01
Does the software supplier follow organization-established security practices for secure software development when creating and maintaining software components?
Skipped
TASK.DEV.19.02
Does the software supplier maintain one or more software repositories for these components?
Skipped
TASK.DEV.19.03
Does the software supplier promote the use of preexisting and vetted software components?
Skipped
TASK.DEV.19.04
Does the software supplier maintain vetted software components?
Skipped
TASK.DEV.19.05
Does the software supplier promote the creation of reusable components by their internal software development teams?
Skipped
CONTROL.DEV.20
Does the software supplier verify that third-party software components, including open source and commercial components, comply with the requirements, as defined by the supplier for the software, throughout the lifecycle of the component in the application?
Skipped
TASK.DEV.20.01
Does the supplier review component patches and updates for functional changes that might impact runtime requirements for the software?
Skipped
TASK.DEV.20.02
If a component patch or update implements changes to security functions, does the supplier perform a threat analysis to determine if those changes impact other security functions or the ability to perform forensic analysis on the software?
Skipped
TASK.DEV.20.03
Does the supplier define a policy handling end-of-life and end-of-support conditions for third-party components?
Skipped
CONTROL.DEV.21
Prior to component usage, does the software supplier check whether there are publicly known vulnerabilities in the software modules and services that they (or their component sources) have not yet fixed?
Skipped
TASK.DEV.21.01
Does the supplier identify where their software suppliers publish vulnerability information?
Skipped
TASK.DEV.21.02
If a component or module supplier publishes their vulnerability information in a location other than the NVD, does the supplier have a process to automatically process that vulnerability data source?
Skipped
TASK.DEV.21.03
If a software service provider discloses a vulnerability, does the supplier perform a risk-based review of all points of usage for that software supplier to determine the impact of the vulnerability on the software?
Skipped
CONTROL.DEV.22
Does the software supplier build into the toolchain automatic detection of known vulnerabilities in software components?
Skipped
TASK.DEV.22.01
Does the software supplier use existing results from commercial services for vetting the software modules and services?
Skipped
TASK.DEV.22.02
Does the software supplier ensure that each software component is still actively maintained and has not reached end-of-life (this should include ensuring no new vulnerabilities have been found in the software being remediated)?
Skipped
TASK.DEV.22.03
Does the software supplier determine a plan of action for each software component that is no longer being maintained or that will not be available in the near future?
Skipped
TASK.DEV.22.04
Does the software supplier confirm the integrity of software components through digital signatures or other mechanisms?
Skipped
TASK.DEV.22.05
Does the software supplier review, analyze, and/or test code?
Skipped
CONTROL.DEV.23
Does the software supplier follow all secure coding practices that are appropriate to the development languages and environment to meet the organization's requirements?
Skipped
TASK.DEV.23.01
Does the software supplier follow secure coding practices to validate all inputs?
Skipped
TASK.DEV.23.02
Does the software supplier validate and properly encode all outputs?
Skipped
TASK.DEV.23.03
Does the software supplier follow secure coding practices to avoid using known unsafe functions and calls?
Skipped
TASK.DEV.23.04
Does the software supplier follow secure coding practices to detect and handle errors?
Skipped
TASK.DEV.23.05
Does the software supplier follow secure coding practices to provide logging and tracing capabilities?
Skipped
TASK.DEV.23.06
Does the software supplier use development environments with automated features that encourage or require the use of secure coding practices?
Skipped
TASK.DEV.23.07
Does the software supplier employ just-in-time training in its secure coding practices?
Skipped
TASK.DEV.23.08
Does the software supplier follow procedures for manually ensuring compliance with secure coding practices when automated methods are insufficient or unavailable?
Skipped
TASK.DEV.23.09
Does the software supplier use tools (e.g., linters, formatters) to standardize the style and formatting of the source code?
Skipped
TASK.DEV.23.10
Does the software supplier check for other vulnerabilities that are common to the development languages and environment it uses?
Skipped
TASK.DEV.23.11
Does the software supplier have the developer review their own human-readable code to complement (not replace) code review performed by other people or tools?
Skipped
CONTROL.DEV.24
Does the software supplier use compiler, interpreter, and build tools that offer features to improve executable security?
Skipped
TASK.DEV.24.01
Does the software supplier use up-to-date versions of compiler, interpreter, and build tools?
Skipped
TASK.DEV.24.02
Does the software supplier follow change management processes when deploying or updating compiler, interpreter, and build tools and audit all unexpected changes to tools?
Skipped
TASK.DEV.24.03
Does the software supplier regularly validate the authenticity and integrity of compiler, interpreter, and build tools?
Skipped
CONTROL.DEV.25
Does the software supplier determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations?
Skipped
TASK.DEV.25.01
Does the software supplier determine and implement optimum compiler, interpreter, and build tool feature configurations for the build tools based on its risk strategy and security policies?
Skipped
TASK.DEV.25.02
Does the software supplier enable compiler features that produce warnings for poorly secured code during the compilation process?
Skipped
TASK.DEV.25.03
Does the software supplier implement the “clean build” concept, where all compiler warnings are treated as errors and eliminated except those clearly determined to be false positives or irrelevant?
Skipped
TASK.DEV.25.04
Does the software supplier perform all builds in a dedicated, highly controlled build environment?
Skipped
TASK.DEV.25.05
Does the software supplier enable compiler features that randomize or obfuscate execution characteristics (such as memory location usage) that would otherwise be predictable and thus potentially exploitable?
Skipped
TASK.DEV.25.06
Does the software supplier test to ensure that the features are working as expected and are not inadvertently causing any operational issues or other problems?
Skipped
TASK.DEV.25.07
Does the software supplier make the approved tool configurations available as configuration-as-code so developers can readily use them?
Skipped
TASK.DEV.25.08
Does the software supplier continuously verify that the approved configurations are being used?
Skipped
CONTROL.DEV.26
Does the software supplier have established policies and procedures to determine when and how to perform code reviews, code analysis, and/or testing methodologies?
Skipped
TASK.DEV.26.01
Does the software supplier mandate the organization's policies or guidelines for when code review (human looking at code) vs. code analysis (using tools to find coding issues) vs. testing should be performed, and how it should be conducted for all code whether developed in-house or via third party?
Skipped
TASK.DEV.26.02
Does the software supplier prescribe code review, analysis methods, and/or testing methods based on the stage of the software?
Skipped
TASK.DEV.26.03
Does the software supplier perform the code review code analysis and/or testing based on the organization's secure coding standards?
Skipped
TASK.DEV.26.04
Does the software supplier perform peer review of code, and review any existing code review, analysis, or testing results as part of the peer review?
Skipped
TASK.DEV.26.05
Does the software supplier use peer reviewing tools that facilitate the peer review process, and document all discussions and feedback?
Skipped
TASK.DEV.26.06
Does the software supplier use a static analysis tool to automatically check code for vulnerabilities and compliance with the organization's secure coding standards with a human reviewing the issues reported by the tool?
Skipped
TASK.DEV.26.07
Does the software supplier use review checklists to verify that the code complies with the requirements?
Skipped
TASK.DEV.26.08
Does the software supplier use expert reviewers to check code for backdoors and other malicious content?
Skipped
TASK.DEV.26.09
Does the software supplier use automated tools to identify and verify unsafe software practices on a continuous basis as human-readable code is checked into the code repository?
Skipped
TASK.DEV.26.10
Does the software supplier identify and document the root causes of discovered issues?
Skipped
TASK.DEV.26.11
Does the software supplier record, triage, and address all discovered issues and recommended remediations in the development team's workflow or issue tracking system?
Skipped
TASK.DEV.26.12
Does the software supplier follow up to capture metrics on error rates, remediation time, and resolution types to ensure issues are properly resolved?
Skipped
TASK.DEV.26.13
Does the software supplier document lessons learned from code review and analysis and make the lessons available to developers?
Skipped
CONTROL.DEV.27
Does the software supplier determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing?
Skipped
CONTROL.DEV.28
Does the software supplier have a rigorous testing process that includes functional and dynamic testing, documenting of test results to include functional and dynamic types of testing, recording, and triaging all discovered issues in a workflow or issue tracking system?
Skipped
TASK.DEV.28.01
Does the vendor's testers follow the organization's policies or guidelines for when code testing should be performed and how it should be conducted (e.g., within a sandboxed environment)?
Skipped
TASK.DEV.28.02
Does the software supplier ensure that its policies and guidelines for code testing are followed for third-party executable code and reusable executable code modules written in-house?
Skipped
TASK.DEV.28.03
Does the software supplier perform robust functional testing of security features?
Skipped
TASK.DEV.28.04
Does the software supplier integrate dynamic vulnerability testing into the project's automated test suite?
Skipped
TASK.DEV.28.05
Does the software supplier incorporate tests for previously reported vulnerabilities into the project's test suite to ensure that errors are not reintroduced?
Skipped
TASK.DEV.28.06
Does the software supplier take into consideration the infrastructures and technology stacks the software will be used with when developing test plans in production?
Skipped
TASK.DEV.28.07
Does the software supplier use fuzz testing tools to find issues with input handling?
Skipped
TASK.DEV.28.08
Does the software supplier review, analyze, and/or test the software's code to identify or confirm the presence of previously undetected vulnerabilities?
Skipped
TASK.DEV.28.09
Does the software supplier configure the toolchain to perform automated code analysis and testing on a regular or continuous basis for all supported releases?
Skipped
TASK.DEV.28.10
Does the software supplier use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios?
Skipped
TASK.DEV.28.11
Does the software supplier identify and record the root causes of discovered issues?
Skipped
TASK.DEV.28.12
Does the software supplier document lessons learned from code testing with lessons provided to developers?
Skipped
TASK.DEV.28.13
Does the software supplier use source code, design records, and other resources when developing test plans?
Skipped
TASK.DEV.28.14
Does the software supplier 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?
Skipped
CONTROL.DEV.29
Does the software supplier implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators?
Skipped
TASK.DEV.29.01
Does the software supplier verify that the approved configuration is in place for the software?
Skipped
TASK.DEV.29.02
Does the software supplier document each setting's purpose, options, default value, security relevance, potential operational impact, and relationships with other settings?
Skipped
TASK.DEV.29.03
Does the software supplier use authoritative programmatic technical mechanisms to record how each setting can be implemented and assessed by software administrators?
Skipped
TASK.DEV.29.04
Does the software supplier store the default configuration in a usable format? If so, does the software supplier follow change control practices for modifying it (e.g., configuration-as-code)?
Skipped
CONTROL.DEV.30
Does the software supplier use a vulnerability disclosure program that gathers information on potential vulnerabilities in the software and its third-party components?
Skipped
TASK.DEV.30.01
Does the software supplier monitor vulnerability databases, security mailing lists, and other sources of vulnerability reports through manual or automated means?
Skipped
TASK.DEV.30.02
Does the software supplier use threat intelligence sources to better understand how vulnerabilities in general are being exploited?
Skipped
TASK.DEV.30.03
Does the software supplier investigate all credible vulnerability reports?
Skipped
TASK.DEV.30.04
Does the software supplier automatically review provenance and software composition data for all software components to identify any new vulnerabilities they have?
Skipped

Secure Software Deployment

CONTROL.DEP.01
Has the software supplier implemented multi-factor authentication (MFA) for all login access to accounts for both local and remote access?
Skipped
TASK.DEP.01.01
Do all user interactive administrative and privileged functions within the product require MFA?
Skipped
TASK.DEP.01.02
Is MFA required for local account access?
Skipped
TASK.DEP.01.03
Is MFA required for all user accounts by default?
Skipped
TASK.DEP.01.04
If the product supports application program interface (API) access, is MFA required for any user to generate an API access token?
Skipped
TASK.DEP.01.05
Does the supplier employ toolsets that are verifier impersonation-resistant for authenticating login access?
Skipped
CONTROL.DEP.02
Does the software supplier's organization maintain updated cybersecurity incident response plans related to operating the software and development of the software?
Skipped
TASK.DEP.02.01
Does the supplier provide details of the cybersecurity incident response communication process for its customers?
Skipped
TASK.DEP.02.02
Does the supplier provide details of patch or other mitigation steps required as part of a cybersecurity incident or vulnerability response process?
Skipped
TASK.DEP.02.03
Does the supplier communicate the occurrence of a cybersecurity incident to its customers?
Skipped
TASK.DEP.02.04
Does the supplier have a Business Continuity Plan that is regularly exercised?
Skipped
TASK.DEP.02.05
For SaaS or cloud-based services, does the supplier provide written SLAs related to restoration of service because of an incident?
Skipped
TASK.DEP.02.06
For SaaS or cloud-based services, are all backups of the software supplier's systems that are necessary for operations regularly checked/exercised for restoration?
Skipped
CONTROL.DEP.03
Does the software supplier follow best practices for log management as defined in NIST SP800-92 or OMB M-21-31?
Skipped
TASK.DEP.03.01
Does the product support centralized logging?
Skipped
TASK.DEP.03.02
Does the product generate log files in a consistent manner supporting automated analysis for unexpected events?
Skipped
TASK.DEP.03.03
Does the product support policy-based configuration of log content?
Skipped
TASK.DEP.03.04
If the product is deployed in a distributed manner, does the product synchronize timestamps between components of the product?
Skipped
TASK.DEP.03.05
If the software supplier provides a SaaS solution, does the software supplier meet Event Logging Tier 1 (EL1) for low assurance environments?
Skipped
TASK.DEP.03.06
If the software supplier provides a SaaS solution, does the supplier have a plan to meet higher logging tier levels consistent with the timelines outlined in M-21-31?
Skipped
TASK.DEP.03.07
If the software supplier provides a SaaS solution, is the software supplier monitoring log activity on a regular basis for anomalous or suspicious events?
Skipped
TASK.DEP.03.08
If the software supplier provides a SaaS solution, does the supplier retain log information consistent with the retention timelines outlined in M-21-31?
Skipped
CONTROL.DEP.04
Does the supplier have a defined patch process for all software, tools, and systems used in the delivery of the software?
Skipped
TASK.DEP.04.01
Does the patch process focus on response to vulnerabilities in a timely manner to reduce the cyberattack susceptibility window timeframe?
Skipped
TASK.DEP.04.02
Does the software supplier maintain a patch history for all software, tools, and systems used in the delivery of the software?
Skipped
TASK.DEP.04.03
Does the software supplier maintain a log of when patches are applied to all software, tools, and systems used in the delivery of the software?
Skipped
TASK.DEP.04.04
If the supplier provides a SaaS solution, does the software supplier provide a documented SLA for patch application?
Skipped
CONTROL.DEP.05
Does the supplier require its suppliers to have a process in place, such as scanning, to address undocumented or obsolete code or functions that might allow unauthorized access or use of the software product, or cause the software product to behave outside of the specified requirements or in an unreliable manner?
Skipped
TASK.DEP.05.01
Does the software supplier require sub-suppliers to have a process to account for hidden functions and vulnerable features embedded in the code, describing their purpose and their impact on the integrity and reliability of software product?
Skipped
TASK.DEP.05.02
Does the software supplier require sub-suppliers to have hidden functions removed or (as a minimum as part of security hardening procedures) addressed (e.g., as part of the failure modes and effects analysis of the software) to prevent any unauthorized access or degradation of the reliability of the software?
Skipped
CONTROL.DEP.06
Does the supplier have protections in place between software supplier's network and cloud service providers, including protections associated with contractually specified government protection levels and personnel background checks if applicable?
Skipped
TASK.DEP.06.01
If the supplier has connectivity to a government system requiring special protection levels, does the supplier have established policies in place requiring background checks and screening for personnel and requisite information handling procedures (including clearance levels and formal access approvals) appropriate to the protection level associated with the interconnected government system?
Skipped
TASK.DEP.06.02
Does the supplier enforce the screening and formal access approval process for its personnel and subcontractors (including service providers) that have access to the government system requiring special protection levels?
Skipped
TASK.DEP.06.03
Does the software supplier convey cloud security requirements to sub-suppliers and sub-contractors?
Skipped
CONTROL.DEP.07
Does the software supplier's product support hardened security configurations that enforce the principles of least privilege, separation of duties, and least functionality?
Skipped
TASK.DEP.07.01
Is hardened security configuration implemented as default, out-of-box behavior in the software supplier's product?
Skipped
TASK.DEP.07.02
Does the software supplier provide accessible documentation on hardening the security configurations?
Skipped
CONTROL.DEP.08
Does the software supplier have methods to verify the trust relationship between a product supplier and the party identified within a digital signature for a product installation package?
Skipped
TASK.DEP.08.01
Does every party in the supply chain ensure that software received from their suppliers is validated, trusted, and authorized by an electronic certificate?
Skipped
TASK.DEP.08.02
Does the supplier verify that the certification used to sign any software from each supplier is authorized by their supplier?
Skipped
TASK.DEP.08.03
Does the supplier provide a means to verify that their certificate should be used to sign this software?
Skipped
TASK.DEP.08.04
Does the software supplier restrict access to code signing certificates?
Skipped
TASK.DEP.08.05
Does the supplier audit the use of their code signing certificates?
Skipped
CONTROL.DEP.09
Do the binary packages distributed by the software supplier implement cryptographic signatures to ensure they are not manipulated or tainted?
Skipped
TASK.DEP.09.01
Do the signatures also provide means to assure authenticity and ownership of the publisher for each individual component in the distribution?
Skipped
TASK.DEP.09.02
Do the binary packages distributed by the software supplier implement verification of the integrity of the individual components in the distribution (e.g., Hash files representing checksum, cryptographically signed packages, and individual components included in the distribution and listed in the SBOM)?
Skipped
TASK.DEP.09.03
Do software updates and upgrades verify the authenticity and ownership of the individual components included in the distribution through cryptographic signatures prior to installing the binary files (e.g., Trusted boot, Verified boot, or Secure boot)?
Skipped
TASK.DEP.09.04
Are the binary packages distributed by the software supplier cryptographically signed using a valid public certificate authority for code signing so that consumers' operating systems or other tools and services can confirm the validity of signatures before use?
Skipped
CONTROL.DEP.10
Does the software supplier certify their software against applicable standards and maintain that certification?
Skipped
TASK.DEP.10.01
If the software supplier provides a SaaS solution, is the supplier's service examined by an accredited third-party certified to audit data protection and cybersecurity controls such as against the Association of International Certified Professional Accountants SOC 2 Trust Services Criteria for service organizations?
Skipped
TASK.DEP.10.02
Is the software provided by the supplier certified against Common Criteria Protection Profile Tracks?
Skipped
TASK.DEP.10.03
Is the software provided by the supplier certified against any U.S. federal government approved products list?
Skipped
TASK.DEP.10.04
Does the software supplier follow an industry standard or framework such as NIST Risk Management Framework (RMF) for supplier's internal or third-party cloud deployments, as applicable?
Skipped
TASK.DEP.10.05
Does the software supplier use a third-party auditing function or certifier?
Skipped
CONTROL.DEP.11
Does the supplier provide detailed deployment guidance for the software?
Skipped
TASK.DEP.11.01
Does the provided deployment guidance, and any associated deployment scripts or installers, follow secure by default principles?
Skipped
TASK.DEP.11.02
Does the supplier document the expected network configuration, including any requirements for network isolation?
Skipped
TASK.DEP.11.03
If the software is deployable in a distributed manner, including via the use of containers, are interdependencies between components in distributed systems documented?
Skipped
TASK.DEP.11.04
If the software requires the use of a service provider, are service provider configuration requirements documented?
Skipped
TASK.DEP.11.05
If the software requires the use of user downloaded components (e.g., a mobile application), are the deployment requirements for the product documented, including any required security configuration of the user device?
Skipped
CONTROL.DEP.12
If the software requires the use of a service provider, does the supplier perform any pre-installation integrity or validation checks to ensure that the software continues to meet deployment or acceptance criteria associated with an authority to operate?
Skipped
TASK.DEP.12.01
Does the supplier require vulnerability scanning of all software prior to installation?
Skipped
TASK.DEP.12.02
Does the supplier have a process in place to identify and mitigate any inadvertent or inappropriate alterations of the software package that is delivered to consumers for installation?
Skipped
TASK.DEP.12.03
Does the supplier perform a pre-installation review of configuration requirements to ensure that any deployment dependencies meet deployment or acceptance criteria associated with an authority to operate?
Skipped

Vulnerability Management

CONTROL.VULN.01
Does the supplier provide a NIST-defined vulnerability disclosure report for the current version of the product and all future versions, including updates?
Skipped
TASK.VULN.01.01
Are software operators expected to directly update individual components from suppliers providing patches for the identified vulnerability or update the product directly from the supplier?
Skipped
TASK.VULN.01.02
Does the supplier provide mitigation guidance following "NIST Guidance" per OMB memo M-22-18?
Skipped
TASK.VULN.01.03
Does the mitigation guidance allow software operators to effectively remove or reduce the vulnerability risk?
Skipped
TASK.VULN.01.04
Does the supplier include descriptions of mitigations performed by the supplier to address vulnerabilities?
Skipped
TASK.VULN.01.05
Does the supplier have established remediation time thresholds for levels of severity/criticality in software vulnerabilities?
Skipped
TASK.VULN.01.06
Do acceptance teams implement a trust but verify model where the product is analyzed by a software composition analysis or risk assessment tool capable of performing a binary analysis?
Skipped
CONTROL.VULN.02
Does the supplier scan for and mitigate potential vulnerabilities at the component level within the product?
Skipped
TASK.VULN.02.01
Has the supplier ensured these processes operate on an ongoing basis and, at a minimum, prior to product, version, or update releases?
Skipped
TASK.VULN.02.02
Has the supplier remediated or mitigated material security relevant vulnerabilities prior to product release?
Skipped
CONTROL.VULN.03
Does the software supplier provide a notification process for vulnerability disclosures?
Skipped
TASK.VULN.03.01
Does vulnerability notification occur in advance of patch availability or only upon release of a patch?
Skipped
TASK.VULN.03.02
Does vulnerability notification include mitigation options?
Skipped
TASK.VULN.03.03
Does vulnerability notification include root cause and/or impact analysis via a Common Weakness Enumeration (CWE)?
Skipped
TASK.VULN.03.04
Does the supplier provide both a human-readable and machine-readable security advisory, such as CSAF formatted Security Advisory (profile 4)?
Skipped
CONTROL.VULN.04
Does the supplier have documented policies or procedures for internal identification and management of vulnerabilities within their networks and enterprise systems?
Skipped
TASK.VULN.04.01
Are automated mechanisms employed to detect and notify authorized personnel of the presence of unauthorized software on networks and enterprise systems?
Skipped
TASK.VULN.04.02
Are automated mechanisms employed to compare the results of vulnerability scans over time to determine trends in networks and enterprise systems vulnerabilities and mitigation/flaw remediation activities?
Skipped
TASK.VULN.04.03
Does the supplier discern and document what information associated with the networks and enterprise systems is discoverable publicly over the internet?
Skipped
TASK.VULN.04.04
Does the supplier employ vulnerability scanning tools and techniques that promote interoperability among tools and vulnerability management automation?
Skipped
TASK.VULN.04.05
Does the supplier have established remediation time thresholds for levels of severity/criticality in networks and enterprise systems?
Skipped
CONTROL.VULN.05
Does the supplier employ vulnerability scanning procedures that maximize the breadth and depth of coverage within their own digital ecosystem, especially software development and build environments (i.e., networks and enterprise system components scanned, and vulnerabilities checked)?
Skipped
TASK.VULN.05.01
Does the supplier analyze vulnerability scan reports regularly (at least weekly)?
Skipped
TASK.VULN.05.02
Does the supplier employ vulnerability scanning tools that include the capability to update the list of cyber vulnerabilities scanned?
Skipped
TASK.VULN.05.03
Does the supplier update the list of vulnerabilities scanned regularly (at least weekly) and when new vulnerabilities are identified and reported?
Skipped
TASK.VULN.05.04
Does the supplier include privileged access authorization to networks and enterprise systems for selected vulnerability scanning activities to facilitate more thorough scanning?
Skipped
TASK.VULN.05.05
"Does the supplier perform security testing to determine the level of difficulty in circumventing the security controls of the networks and enterprise systems? Note: Testing methods include penetration testing, malicious user testing, and independent verification and validation."
Skipped
CONTROL.VULN.06
Does the software supplier have a policy and program to monitor for vulnerabilities within the supplier's running ecosystem and remediate such security-relevant vulnerabilities?
Skipped
TASK.VULN.06.01
Has the supplier ensured these processes operate on an ongoing basis and, at a minimum, prior to product, version, or update releases?
Skipped
TASK.VULN.06.02
Has the supplier remediated or mitigated material security relevant vulnerabilities prior to product release?
Skipped
CONTROL.VULN.07
Does the supplier implement industry standards or frameworks for vulnerability management?
Skipped
TASK.VULN.07.01
Does the software supplier have an intrusion detection and monitoring system in place to detect unauthorized activities?
Skipped
TASK.VULN.07.02
Does the software supplier's organization maintain updated indicators of compromise?
Skipped
TASK.VULN.07.03
Does the supplier's organization scan for vulnerabilities in externally obtained software (e.g., pen testing of enterprise and non-enterprise software)?
Skipped
TASK.VULN.07.04
Does the supplier conduct threat hunting exercises and pen testing on a reasonable cadence?
Skipped
CONTROL.VULN.08
Does the supplier implement a documented process to resolve and disclose identified vulnerabilities in a software product?
Skipped
TASK.VULN.08.01
Does the supplier have a reasonable policy and process to disclose security-relevant vulnerabilities?
Skipped
TASK.VULN.08.02
Does the software supplier have processes to ensure sub-suppliers disclose vulnerabilities?
Skipped

Optional Details

Created By:

First Name:
Last Name:
Email:
Phone Number:

Primary Point of Contact:

First Name:
Last Name:
Email:
Phone Number:

Additional Supporting Point of Contacts:

POC 1:
First Name:
Last Name:
Email:
Phone Number:
POC 2:
First Name:
Last Name:
Email:
Phone Number:
POC 3:
First Name:
Last Name:
Email:
Phone Number:
POC 4:
First Name:
Last Name:
Email:
Phone Number:
POC 5:
First Name:
Last Name:
Email:
Phone Number:
Additional Notes or Comments:
Print

Print and Sign

Once all questions have been answered and reviewed, you can print this summary and have an authorized representative sign and approve it. "Skipped" questions will only print if the visibility is turned on using the above toggle.
Note: Any question with an explicit negative response (i.e., the question wasn't skipped (exempt) due to a prior affirmative answer and an explicit "No" was provided) may require a POA&M.

Need help? Visit the Software Acquisition Guide Resource Page. resources