The Cybersecurity and Infrastructure Security Agency (CISA) on April 27 unveiled its draft Secure Software Self-Attestation Form, whose goal is to assure the federal government that the software it uses is securely developed.

Software producers will have to confirm their compliance with certain secure software practices based on the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-218 Secure Software Development Framework (SSDF). This should be done before their software is used by federal agencies.

Here’s a breakdown of what this entails.

Background

The executive order on improving the nation’s cybersecurity released May 12, 2021, calls on federal agencies to prioritize software supply chain security in their acquisitions. Following this directive, NIST published the SSDF to provide a set of fundamental, sound practices for secure software development.

Subsequently, on Sept. 14, 2022, the Office of Management and Budget (OMB) released a memorandum on strengthening the software supply chain through secure software development practices. This memo tasks CISA with creating a self-attestation form to be completed by software producers working with the federal government. By doing so, they confirm their adherence to the security practices outlined in the SSDF.

As part of that journey, CISA has released a draft of the self-attestation form based on the principles of the SSDF. This draft, created in close consultation with OMB, is currently open for comment.

The Requirements

CISA’s self-attestation form identifies the minimum criteria for meeting secure software development standards as per OMB’s memo. In addition to the self-attestation form, agencies may ask for additional documents, including a Software Bill of Materials (SBOM) in specific formats or documentation from a third-party assessor (3PAO).

If a certified FedRAMP or other approved 3PAO has already confirmed a software’s compliance with NIST guidance, the software producer might not have to submit an attestation. Nevertheless, they still need to provide the relevant documentation from the third party to show the verification process.

Who Needs to Sign the Form and What Do They Attest?

The software company CEO, or a representative from the company, has to sign the form. By signing, they confirm that their software was developed in accordance with the secure software development practices listed on the form. These rules cover four main aspects:

• The software is developed and built in secure environments.
• The software producer has made a good-faith effort to maintain trusted source code supply chains.
• The software producer employs automated tools or comparable processes to manage security vulnerabilities.
• They maintain data provenance for internal and third-party code incorporated into the software.

The form refers references specific parts of the SSDF that cover these four main areas and their sub-parts. This helps the software producer follow the practices and controls needed to meet the form’s requirements.

What Software is within the Scope of the Self-Attestation?

CISA specifies the following categories of software that require self-attestation:

• Software developed after Sept. 14, 2022;
• Existing software that undergoes major version changes after Sept. 14, 2022; and
• Software that experiences continuous changes to the software code, such as software-as-a-service (SaaS) offerings or products using continuous delivery/continuous deployment.

What Software is Outside the Scope of the Self-Attestation?

CISA also provides the categories of software products and components exempt from OMB’s memo and thus don’t require self-attestation:

• Software developed by federal agencies; and
• Software obtained directly by a federal agency that is freely available, such as freeware or open source software.

How to Provide Feedback on the Form

You have until June 26, 2023, to provide your comments on the Secure Software Development Common Self-Attestation Form. While CISA is requesting input on all aspects of the proposed common form, it’s especially interested in feedback in the following areas:

• The practical utility of the proposed collection of information, considering its implementation to meet the requirements of both the EO and the OMB guidance.
• The accuracy of the Department of Homeland Security’s (DHS) estimation of the burden associated with the proposed collection of information, as outlined in the draft form.
• Alternative ways for DHS to enhance the quality, utility, and clarity of the information to be collected; and
• How DHS could minimize the burden of the collection of information through appropriate automated means or electronic submissions.

You can submit your comments here.

Author:

Narpender Bawa is a Senior Director at REI running our Information Security Services