ComplianceForge News & Announcements

Secure Software Development Attestation Forms

Secure Software Development Attestation Forms

ComplianceForge Support ComplianceForge Support
3 minute read

Listen to article
Audio generated by DropInBlog's Blog Voice AIâ„¢ may have slight pronunciation nuances. Learn more

Can you tell the difference in these secure software development attestation forms? There isn't one - they all require attestation against Executive Order 14028 (EO 14028) requirements.

Secure Software Development Attestation Form

EO 14028 Compliance

The CISA Secure Software Development Attestation Form contains the same attestation requirements as the NASA Secure Software Development Attestation Form and the US Department of Transportation (DOT) Attestation Form. Even the General Services Administration (GSA) has its own software attestation form. All require attestation for Secure Software Development Practices (SSDP) from EO 14028.

EO 14028 Requirements

The following application security controls are applicable to EO 14028, Sec. 4. Enhancing Software Supply Chain Security.:

  • (A) using administratively separate build environments.
  • (D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software.
  • (E) employing encryption for data.
  • (F)(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section.
  • (F)(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code.
  • (F)(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.
  • (F)(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated.
  • (F)(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis.
  • (F)(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.
  • (F)(viii) participating in a vulnerability disclosure program that includes a reporting and disclosure process.
  • (F)(ix) attesting to conformity with secure software development practices.
  • (F)(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

Are you willing to sign this off on behalf of your organization?

"On behalf of the above-specified company, 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), in developing the software identified in... [EO 14028]"

To legitimately attest, this requires an organization to have clear evidence of due diligence and due care of its development practices. This is both at the organization level and for its developers.

« Back to Blog