The long-awaited Secure Software Development Attestation Form was published on March 18, 2024 by the Cybersecurity and Infrastructure Agency (CISA). This is a continuation of the trend toward modernization of cybersecurity compliance that the US government has been marching toward since the turn of the millennium.
This initiative is rooted in the cybersecurity challenges highlighted by Executive Order 14028, including the SolarWinds attack and the Colonial Pipeline ransomware attack, which clearly demonstrated the need for a coordinated national response to the emerging threats of a complex software supply chain.
The Secure Software Development Attestation Form is the newest, and likely not the final, step towards a more secure software supply chain for both the United States and the world at large. We will take you through the details of what this form means for your organization and how to best approach it.
While the SSDF and the new Secure Software Development Attestation Form are important compliance milestones in their own right, they are typically intermediate steps on the way to more rigorous compliance standards such as FedRAMP or continuous Authority to Operate (cATO). Regardless of your end destination, we will guide you through how to approach this step and all of the steps that come after.
Overview of the Secure Software Development Attestation Form
The Secure Software Development Attestation Form is part of a broader effort derived from the Cybersecurity EO 14028 (formally called “Improving the Nation's Cybersecurity). As a result of this EO, the Office of Management and Budget (OMB) issued two memorandums, M-22-18 “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” and M-23-16 “Update to Memorandum M-22-18”.
These memos require the Federal agencies to obtain self-attestation forms from software suppliers. Software suppliers have to attest to complying with a subset of the Secure Software Development Framework (SSDF).
Before the publication of the Secure Software Development Attestation Form, the SSDF was a software development best practices standard published by the National Institute of Standards and Technology (NIST) based on industry best practices like OWASP's BSIMM and SAMM. A useful resource for organizations that valued security intrinsically and wanted to run secure software development without any external incentives like formal compliance requirements.
Now, the Secure Software Development Attestation Form requires software providers to self-attest to having met a subset of the SSDF best practices. There are a number of implications to this transition from secure software development as being an aspiration standard to a compliance standard that we will cover below. The most important thing to keep in mind is that while the Attestation Form doesn't require a software provider to be formally certified before they can transaction with a federal agency like FedRAMP does, there are retroactive punishments that can be applied in cases of non-compliance.
Who/What is Affected?
Who is Affected?
- Software providers to federal agencies:
- Federal service integrators
- Independent software vendor
- Cloud service providers
- Federal agencies and DoD programs who use any of the above software providers
What is Included
- New software: Any software developed after September 14, 2022
- Major updates to existing software: A major version change after September 14, 2022
- Software-as-a-Service (SaaS)
What is Excluded
- First-party software: Software developed in-house by federal agencies. SSDF is still considered a best practice but does not require self-attestation.
- Free and open-source software (FOSS): Even though FOSS components and end-user products are excluded from self-attestation the SSDF requires that specific controls are in place to protect against software supply chain security breaches.
Anchore is the leading open-source software supply chain security platform and helps numerous DoD programs achieve cATO. Anchore Federal offers:
Key Requirements of the Attestation Form
There are two high-level requirements for meeting compliance with the Secure Software Development Attestation Form;
- Meet the technical requirements of the form
- Note: NIST SSDF has 19 categories and 42 total requirements. The self-attestation form has 4 which are a subset of the full SSDF. See below for a breakdown of all 4 requirements.
- Self-attest to compliance with the subset of SSDF
- Sign and return the form.
Timeline
The timeline for compliance with the SSDF self-attestation form involves two critical dates: for critical software, compliance is required by early June, and for all other software in scope, by early September. Precise dates are not available yet due to ambiguity from CISA in their public communications.
Implications
Now that CISA has published the final version of the Secure Software Development Attestation Form there are a number of implications to this transition. One is economical and the other is potentially criminal.
The economic penalty of not self-attesting to secure software development practices via the form is that any federal agencies that you're currently working with won't be able to pay you any more and any future agencies you want to work with will ask to see your form before procurement. Sign the form or miss out on this revenue.
The second penalty is a bit scarier from an individual perspective. An officer of the company has to sign the attestation form to state that they are responsible for attesting to the fact that all of the form's requirements have been met. Here is the relevant quote from the form:
"Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute."
It is also important to realize that this isn't an unenforceable threat. There is evidence that the DOJ Civil Cyber Fraud Initiative is trying to crack down on government contractors failing to meet cybersecurity requirements. They are bringing False Claims Act investigations and enforcement actions. This will likely weigh heavily on both the individual that signs the form and who is chosen at the organization to sign the form.
Challenges and Considerations
Do I still have to sign if I have a 3PAO do the technical assessment?
No. As long as the 3PAO is FedRAMP-certified.
What if I can't comply in time?
You can draft a plan of action and milestones (POAM) to fill the gap while you are addressing the gaps between your current system and the system required by the attestation form. If the agency is satisfied with the POAM then they can continue to use your software. But they have to request either an extension of the deadline from OMB or a waiver in order to do that.
Can only the CEO and COO sign the form?
The wording in the draft form that was published required either the CEO or COO but new language was added to the final form that allows for a different company employee to sign the attestation form.
Full Requirements of Secure Software Development Attestation Form
- Software is developed and built in secure environments
- Isolation and hardening of development and build environments
- Authorization and access monitoring, logging and auditing
- Multi-factor authentication
- Catalog of software components
- Encrypt sensitive data
- Continuous monitoring of cybersecurity alerts and incidents
- Maintain trusted source code supply chains
- Make a good-faith effort to maintain trusted software supply chains by employing automated tools to address the security supply chain and manage related vulnerabilities
- Maintain provenance for 1st- and 3rd-party components
- Employ automated tools for security vulnerabilities
- Continuous scanning for vulnerabilities
- Operate a vulnerability remediation policy
- Operate a vulnerability disclosure program
How Anchore Can Help
Anchore Enterprise is a software supply chain security platform and can address many of the requirements of the Secure Software Development Attestation Form. By utilizing the platform, you can ensure that whoever is required to sign the attestation form has a battle-tested software platform to back-up their signature.
Software is developed and built in secure environments
Catalog of software components (i.e., an SBOM)
Anchore Enterprise includes a software component scanner that can make a full inventory of all software and the 3rd party components that are integrated into the end-user software by generating a software bill of materials (SBOM).
Continuous monitoring of cybersecurity alerts and incidents
Anchore Enterprise includes a vulnerability scanner that can uncover vulnerabilities in all software components and alert on vulnerabilities as they are found and feed these alerts into an incident management system that allows for teams to manage and remediate any critical discoveries.
Maintain trusted source code supply chains
This requirement is a bit nebulous but Anchore Enterprise is able to meet the requirement of providing an "automated tool to address the security of internal code and third-party components and manage related vulnerabilities''. Anchore Enterprise includes a vulnerability scanner that can scan the entire catalog of software components and a management interface for the vulnerabilities that are discovered.
Employ automated tools for security vulnerabilities
Continuous scanning for vulnerabilities
Anchore Enterprise includes a vulnerability scanner that can be integrated into all stages of the CI/CD pipeline and allow for scanning for vulnerabilities across all build environments.
Operate a vulnerability remediation policy
Anchore Enterprise includes remediation recommendations that will utilize the results of a vulnerability scanner to provide feedback to developers on how to best resolve a security vulnerability.
Operate a vulnerability disclosure program
Anchore Enterprise includes an API that can be consumed by a vulnerability disclosure application or process. All of the vulnerability metadata can be collected from the API in order to populate the required vulnerability metadata for the disclosure.
Conclusion
Cybersecurity compliance modernization is a journey not a destination. The Secure Software Development Attestation Form is the next step in that journey for secure software development. This stop was focused on transforming the preceding SSDF standard from a recommendation into a requirement with a soft gate. Given the overall trend of cybersecurity modernization that was kickstarted with FISMA in 2002, it would be prudent to assume that this attestation form is an intermediate step before the requirements become a hard gate where compliance will have to be demonstrated as a prerequisite to utilizing the software.
Anchore is committed to keeping you up-to-date on the latest with these changes. If you're interested to learn more about how Anchore Federal can help you achieve compliance with the Secure Software Development Attestation Form follow the link. Also, we have two webinars that go into more depth on how to achieve SSDF compliance that will expand your knowledge on this deeply technical topic, links below:
