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: |
|
| The software producer makes a good-faith effort to maintain trusted source code supply chains. |
|
| The software producer maintains provenance for internal code and third-party components incorporated into the software. |
|
| The software producer employs automated tools or comparable processes that check for security vulnerabilities. |
|
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.
