What is the CISA Secure Software Development Attestation Form (SSDA)?

The Secure Software Development Attestation Form (SSDA) was developed by the Cybersecurity and Infrastructure Security Agency (CISA) to reinforce its Secure by Design principles and meet the Office of Management and Budget’s (OMB) requirements to improve the security of the federal government’s software supply chain.

The OMB issued OMB M-22-18 and then M-23-16 to meet the directives of Executive Order (EO) 14028. These memorandums require each federal agency to comply with the National Institute of Standards and Technology’s (NIST) Secure Software Development Framework (SSDF) when using third-party software on the agency’s information systems or otherwise affecting the agency’s information. In light of increasing cybersecurity threats, the attestation process aims to ensure that software used by the federal government adheres to the most rigorous security standards.

What are the benefits of using CISA’s security attestation form?

The primary benefits include enhanced security and trust in software supply chains, improved vulnerability management and strengthened compliance with federal cybersecurity requirements. By adhering to Secure by Design principles and maintaining transparency through the use of software bill of materials (SBOM), organizations can reduce the risk of supply chain attacks and enhance the overall security of their software products, ultimately building stronger trust with federal clients and the public.

What are the use cases of CISA SSDA?

CISA’s SSDA applies to any software developed after September 14, 2022, or earlier software that has undergone major version changes post this date. A company’s use of CISA’s SSDA is particularly relevant for organizations providing solutions to federal agencies, since these agencies must only use software producers who can attest to complying with the government-specified secure software development practices. The SSDA provides a federal agency with the means to ensure that software producers have been following a risk-based approach for secure development. 

Use cases include:

• Ensuring compliance for SaaS products and software with continuous updates.
• Demonstrating secure development practices for software that is part of critical infrastructure.
• Facilitating secure procurement processes for federal agencies by providing a clear record of security practices.

What are the best practices related to CISA SSDA?

To ensure rigorous security standards as outlined in the NIST SSDF, best practices may include:

• Develop secure environments that are isolated and protected through multi-factor authentication (MFA) and strict access controls.
• Maintain trusted source code supply chains using automated tools to verify third-party component integrity and maintain detailed documentation of all code sources.
• Regularly scan for vulnerabilities in both internal and external components and promptly address any discovered issues.
• Create and maintain a comprehensive SBOM for all software products to enhance transparency and accountability.

What are the identity security requirements for CISA SSDA?

Here are CISA SSDA attestations and the identity security strategies that organizations should take into consideration:

Attestation	Strategies
The environments where software is developed and built are secured by the following actions:	Separate and protect each environment involved in developing and building software. Log, monitor and audit trust relationships and access to both development environments and components. Enforce MFA and conditional access, ensuring proper lifecycle management, access certification and authentication. Encrypt sensitive data such as credentials, and rotate credentials to secure endpoints and cloud environments. Implement defensive cybersecurity practices, including continuous monitoring, session isolation, and automated responses to risky commands.
The software producer makes a good-faith effort to maintain trusted source code supply chains.	Employ automated tools or processes to address the security of internal code, third-party components and related vulnerabilities. Provision JIT (Just-in-Time) access with zero standing privileges to minimize the number of accounts with privileged access. Detect credential theft or misuse and automate responses. Automate the provisioning and de-provisioning of privileged accounts.
The software producer maintains provenance for internal code and third-party components incorporated into the software.	Use automated tools or processes to check for security vulnerabilities. Detect anomalous activity to systems or transaction records. Centrally monitor user behavior for forensics, audit and compliance. Detect and respond to risky and anomalous behavior.
The software producer employs automated tools or comparable processes that check for security vulnerabilities.	Institute a policy to address discovered vulnerabilities before product release. Centralized audit capabilities across all user sessions. Ability to discover privileged accounts and credentials. Centrally monitor, detect and respond to risky and anomalous behaviors.

What are the challenges of CISA SSDA?

Organizations face several challenges when preparing to meet the requirements in the CISA SSDA. Implementing secure development practices often demands significant investments in tools, training and process changes. Maintaining continuous compliance throughout the software lifecycle can be resource-intensive, and managing an accurate, up-to-date SBOM for all components, especially those from third parties, is complex and time-consuming. Additionally, aligning existing workflows with CISA SSDA requirements may require substantial modifications to current processes.

Learn more about CISA SSDA

• How to Secure Developer Access in the Cloud Without Compromising Their Velocity
• How Zero Standing Privileges Enable Secure and Seamless Cloud Development