article.md

Mar 11: In Effort to Bolster Government Cybersecurity, Biden Administration Takes Step to Ensure Secure Dev

• Article link
• The actual software security attestation form which outlines minimum requirements

Today’s release of the secure software development attestation form reinforces secure-by-design principles advanced by CISA, Federal government partners, and international allies:

The referenced secure-by-design principles published by CISA

Note: the above includes 9 references to memory safe, which it regards as:

Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift

Additionally linking to a Nov 2022 NSA memory safety information sheet

Summary of the attestation form (by me)

TL;DR: zero mentions of memory safety or programming language.

The purpose of this form is to provide the Federal Government assurances that software used by agencies is securely developed.

Failure to provide any of the information requested may result in the agency no longer utilizing the software at issue. Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute.

This self-attestation form identifies the minimum secure software development requirements a software producer must meet, and attest to meeting, before software subject to the requirements [...] may be used by Federal agencies.

Software requires self-attestation if any of the conditions is met:

1. The software was developed after September 14, 2022;
2. The software was developed prior to September 14, 2022, but was modified by major version changes (e.g., using a semantic versioning [...]) after September 14, 2022; or
3. The producer delivers continuous changes to the software code (as is the case for software-as-a-service [...]).

Software products and components in the following categories are not in scope [...] and do not require a self-attestation:

1. Software developed by 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; or
4. Software that is freely obtained and publicly available.

Software producers who utilize third party components in their software are required to attest that they have taken specific steps [...] to minimize the risks of relying on such components in their products. Agency-specific instructions may be provided to the software producer outside of this common form.

Attestation

[...] I attest that, to the best of my knowledge, [software producer] presently makes consistent use of the following practices, derived from the secure software development framework (SSDF)

1. The software is developed and built in secure environments. Those environments are secured by the following actions, at a minimum: a) Separating and protecting each environment involved in developing and building software; b) Regularly logging, monitoring, and auditing [...] access to any software development and build environments [...] c) Enforcing multi-factor authentication [...] d) [...] minimize use of software that create undue risk within the environments used to develop and build software e) Encrypting sensitive data [...] f) Implementing defensive cybersecurity practices [...]
2. The software producer makes a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security [...]
3. The software producer maintains provenance for internal code and third-party components incorporated into the software to the greatest extent feasible;
4. The software producer employs automated tools or comparable processes that check for security vulnerabilities [...] prior to product, version, or update releases [...]