Self-attestation on software security: What development teams need to know

Software companies supplying the U.S. federal government must begin attesting to the security of critical software by June 11 — and more deadlines for attesting to the security of a wider range of software are approaching in the months ahead.

But what does it mean to self-attest? And what other government requirements are in store for software providers in the months and years ahead?

Here's a briefing on self-attestation to help you understand these new requirements that focus on the software supply chain.

See also: A timeline of federal guidance on software supply chain securityKey takeaways: Supply chain security risks addressed in new Gartner report

What is self-attestation all about?

As of June 11, 2023, software producers that sell critical software to U.S. federal agencies are required to provide those agencies with “attestation letters.” That’s according to the language of a memorandum by the Office of Management and Budget (OMB), M-22-18 (PDF), released in September 2022, that set specific deadlines for producers to attest to the cybersecurity of both critical and noncritical software sold or licensed to the federal government.

Critical software is defined in another OMB memo, M-21-30, as referring to so-called EO-Critical Software as defined by NIST, the National Institute of Standards and Technology, which refers to “any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:

• Is designed to run with elevated privilege or manage privileges;
• Has direct or privileged access to networking or computing resources;
• Is designed to control access to data or operational technology;
• Performs a function critical to trust; or,
• Operates outside of normal trust boundaries with privileged access."

As of September 13, 2023 — a year following publication of M-22-18 — federal agencies are instructed to collect attestation letters “for all software subject to the requirements of this memorandum,” critical or not.

As our team reported at the time, the OMB memo applies to all third-party software, including software renewals and major version changes, and to all new software purchases made after the issuance of the memorandum and to any software that receives a major version upgrade subsequent to the release of the memorandum.

What software is covered?

According to M-22-18, software sold or licensed to the federal government requires self-attestation by the software maker if it was developed after September 14, 2022, or modified by major version change after September 14, 2022 (e.g., from Version 2.5 to Version 3.0) or if it is software to which the producer delivers continuous changes to the software code (such as software-as-a-service products or other products using continuous delivery/continuous deployment).

Software products and components that do not require self-attestation under M-22-18 include software developed by federal agencies and software that is freely obtained (e.g., freeware and open-source software) directly by a federal agency.

What is self-attestation for software?

Self-attestation is what it sounds like: Software makers are attesting to the cybersecurity of the software they are selling or licensing to the federal government, without needing an independent, third-party assessment of the software’s security. The federal government is taking them at their word, so to speak. This is distinct from other government mandates. For example, frameworks such as the Department of Defense’s Cybersecurity Maturity Model Certification (CMMC) initially required third-party attestation of software security sold or licensed to the DOD.

By allowing software companies to self-attest to the security of their code — and prove the existence of supply chain risk management controls — the White House is erring on the side of efficiency and clearing the way for software suppliers to the federal government to document security controls and make security assurances.

It also removes the strong likelihood that bottlenecks would result if tens of thousands of software makers had been forced to turn to a limited number of third parties to obtain certifications. However, under the memorandum, third-party assessments via a “Third Party Assessor Organization (3PAO)” are also allowed, especially for open-source software that might be part of a third-party software application.

By allowing software companies to self-attest to the security of their code — and prove the existence of supply chain risk management controls — the White House is erring on the side of efficiency and clearing the way for software suppliers to the federal government to document security controls and make security assurances.

How does self-attestation work?

At the time that M-22-18 was released, the details of how self-attestation to federal agencies would work was an open question. The memorandum called for software makers to use a standardized government attestation form but noted that no such form existed. In April 2023, CISA (the Cybersecurity and Infrastructure Security Agency) released its Secure Software Attestation Common Form (PDF).

That form asks software makers to attest to a number of statements about the process they used to develop the software in question. Those include:

• That the software was “developed and built in secure environments"
• That the software producer made “a good-faith effort" to maintain trusted source code supply chains
• That the producer maintains provenance data for internal and third-party code incorporated into the software, scans for security vulnerabilities in the code, and so on

Forms must be completed and signed by the CEO of the software producer and submitted via email to the relevant federal agency using a naming convention spelled out in the standard form.

What about SBOMs?

Despite figuring prominently in discussions of federal software supply chain security and getting mentions in both Executive Order 14028 and Memorandum M-22-18, software bills of materials (SBOMs) are not required from software producers as part of the attestation process by default. However, CISA makes clear that producers may be asked by individual agencies to provide “additional attestation artifacts or documentation,” including SBOMs and documentation from third-party assessors, as a condition of the agency using the software in question.

Learn more about SBOMs Get a free SBOM and supply chain risk analysis

Agencies that opt to require additional artifacts or documentation beyond the self-attestation form can instruct the software producers that sell to them to maintain SBOMs or other requested elements needed for attestation among their own records, or to include them with the self-attestation form.

SBOMs submitted as part of the self-attestation process have to use a data format defined by the National Telecommunications and Information Administration (NTIA), which include SPDX, CycloneDX and SWID.