Secure Software Development Attestation Form [Final]

[This post was previously published as Self-Attestation for M-22–18 and is now revised for the final form]

‍

Three years ago, Executive Order 14028 (“Improving the Nation’s Cybersecurity”) highlighted the importance of updating the Nation’s cyber hygiene.

‍

In September 2022, the Office of Management and Budget (OMB) made it actionable by rolling out memo M-22–18 (“Enhancing the Security of the Software Supply Chain through Secure Software Development Practices”).
M-22–18 outlines part of the EO14028 implementation plan for Federal agencies. M-23–16 added further clarifications to those requirements.

‍

Those memos, in turn, focuses on two artifacts to establish the security and maturity of a software producer’s development practices.

• A self-attestation form declaring the producer’s development practices
• Software Bill of Materials (SBOM) per product version declaring the composition of the software

‍

While the specification and requirements for SBOM have been well established with NTIA’s Minimum Elements for a Software Bill of Materials, the requirements for the self-attestation were finalized and released on March 8, 2024.

‍

The form leans heavily on Practices and Tasks specified in the NIST SP 800–218 (“Secure Software Development Framework”) revised to version 1.1 for the Executive Order.

‍

Interlynk has mapped out self-attestation requirements in an easy-to-follow format to help organizations get a head start.

‍

Who is impacted?

M-22–18/M-23–16 are two memos to the Federal agencies; therefore, the requirements only apply to software being sold to or used by them.

‍

All of the following types of software change require producers to submit the self-attestation form with the relevant agencies:

1. Software developed after September 14, 2022
2. Software going through a major revision after September 14, 2022
3. Continuously delivered software (e.g., software-as-a-service)

‍

Four carved-out exceptions are:

1. Software self-developed by the Federal agencies
2. Open-source software that is freely and directly obtained by a Federal Agency.
3. Third-party open source and proprietary components that are incorporated into the software end product used by the agency.
4. Software that is freely obtained and publicly available.

‍

Attestation Format

An attestation can apply to a single product version, multiple versions of the product, an entire product line, or the entire company.

‍

The attestation form can be completed online at this link: https://softwaresecurity.cisa.gov or via a local PDF download and email (the email will be determined per agency).

‍

Attestation Requirements

The self-attestation document references multiple sections of the Secure Software Development Framework (SSDF) and Executive Order 14028. Specifically, the self-attestation requires the declaration of the following:

• Security of the software development environment
• Trust in the software source code supply chain
• Automated tools and processes for trusting software supply chain
• Management of provenance data for internal and third-party code
• Policy, program, and automated processes for the management of the vulnerability in the software

Interlynk has mapped the requirements with the SSDF-referenced notional examples here.

This can serve as the reference guide for implementing the required controls.

‍

Getting Ready

Interlynk’s mission encompasses easy, obvious, and automated software disclosures, security controls, and requirements outlined in the EO14028 and M-22–18/M-23–16, incremental steps toward a more transparent and resilient software ecosystem. We are here to help any organization that needs support with clarity, guidance, or implementation of these controls.

‍

Reach out to us at hello@interlynk.io for a chat.

‍