SSDF Attestation- CEO and COO Responsibilities
Author: Jason Weiss
SSDF attestation for anyone selling software to the Federal government is now one step closer to reality. On 15 November 2023, the Cybersecurity and Infrastructure Security Agency (CISA) published what is anticipated to be the final draft revision for the Secure Software Development Framework (SSDF) attestation form in the Federal Register. This form is intended to be collected by Federal procurement officials for anything the US Government purchases that contains software, defined to include firmware, embedded software, packaged software solutions, and even Software as a Service (SaaS) offerings running in a Cloud. The requirement for this attestation can be traced back to Executive Order on Improving the Nation’s Cybersecurity (EO 14028), signed by President Biden in May 2021.
There is a lot of significance to this form, especially for businesses that may not directly sell to the Federal government. Major defense contractors, for example, have already started to inform their supply chains that they will require this attestation and access to software bill of materials (SBOM) data. In fact, despite the lengthy journey for OMB and CISA to define this PDF form, both EO 14028 and the form make it clear that it is a requirement for all software produced after September 14th, 2022. Perhaps more importantly, the Federal government has doubled-down and insisted that this literally applies to all software, including the firmware behind that new microwave’s LED display in the breakroom even though there is no network or WiFi connectivity integrated into the device.
Who can attest?
The revised SSDF attestation form also stipulates that only the CEO or COO of the company may sign the attestation, and that the signatory must be an employee of the company being represented. This closed a previous loophole where an outsourced engineering director, for example, could have signed the attestation. The expectation from the Federal government is now clear: the C-Suite is in fact solely responsible for advocating for secure software development practices within their organization and for accepting the risk and consequences of misrepresenting their organization’s compliance with NIST SP 800-218, SSDF. When you factor in the recent criminal charges filed by the SEC against the CISO of SolarWinds, every business who creates any type of software should pause and reflect on the serious nature of this attestation.
CEO/COO Responsibility: The revised SSDF attestation mandates that only the CEO or COO can sign, underscoring their pivotal role in ensuring secure software development and compliance with NIST SP 800-218.
Open source projects are explicitly excluded in the guidance from requiring attestation, but that doesn’t mean that open source projects should ignore the descriptive guidance found within the 42 tasks defined by the SSDF. Perhaps counterintuitively, open source is well positioned to help reduce software supply chain security risk companies must manage from open source, commercial components, and custom developed software. The CNCF in-toto project, along with Witness and Archivista projects that were donated and voted into the CNCF as subprojects under in-toto at KubeCon NA 2023, provide significant assurances and reduce software supply chain risk. Let’s explore what that means.
Understanding the Depth of the Software Supply Chain
The software supply chain is defined by the sum of all activities that led to the creation of a software release. Examples of activities include the input files (source code), specific commands executed to manipulate or process those input files (such as invoking a software compiler), and all output files. The software supply chain far exceeds the minimum metadata that CISA expects to be published in an SBOM. As an analogy, the SBOM is like the list of ingredients found on the side of a peanut butter cookie mix. You know there is sugar and peanuts in the ingredients, but you don’t know anything about how they were processed. Who cleaned the peanuts, where were they cleaned, how were they shelled, at what temperature were they blanched, and were the peanuts roasted are all things that the ingredients panel on the box doesn’t disclose. While an SBOM is an important artifact in security the software supply chain, it only considers the last mile.
CEOs and COOs signing this SSDF attestation may be called upon to demonstrate their compliance with the SSDF. This is where in-toto, Witness, and Archivista complement the SBOM, and additionally, the Cloud native application guidance found in “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines” (NIST 800-204d), can help. Under SSDF PO.3, Implement Supporting Toolchains, it is necessary to protect and verify the state of every step that is chained together to transform (e.g. compile) or verify the state (e.g. linting) of the software before generating the final binary artifacts that are distributed into a production environment. Failure to ensure the integrity of all activities leading up to the creation of the SBOM and distribution of the final product leaves the software vulnerable to a supply chain attack. When these attacks occur, the attacker controls a step in the process and alters the intermediary artifacts, and by the time the SBOM is assembled it merely validates the integrity of the malware.
Protect your Software Supply Chain
In today’s software defined era, there are many affluent and highly capable C-Suite executives who have not had the opportunity to learn and appreciate the nuances of modern software development using continuous integration / continuous deployment pipeline (CI/CD pipeline) techniques. It is critical that software architects, software developers, engineering directors, and product managers are taking the necessary steps expected under the SSDF to protect the integrity of the software supply chain.
Open Source and Supply Chain Security: While open source projects are exempt from attestation, the SSDF's guidelines offer valuable insights for managing software supply chain risks, with projects like CNCF in-toto playing a crucial role.
If you’d like to learn more about how the Witness CNCF in-toto subproject can provide transparency and non-repudiation across the totality of your software development lifecycle, contact us to discuss your organization’s unique requirements. We’d be happy to listen and learn about your software process, and explore how we can help your organization both mitigate risk within your CI/CD pipeline and offer your C-Suite the assurances they expect ahead of signing a legally binding SSDF attestation.