Most people find compliance a big ol’ snoozefest. It consumes time and resources that could be better allocated elsewhere. The language that regulatory bodies use is so “lawyered!” as to be nearly incomprehensible. For developers, the recent requirements around secure software attestations that start bringing the President’s “Executive Order on Improving the Nation’s Cybersecurity” (EO) to life. 

To give you the TL;DR, the Cybersecurity and Infrastructure Security Agency’s (CISA’s) Secure Software Self-Attestation Form is the first step to establish the minimum requirements that software companies need to meet. 

How did we get to the Secure Software Self-Attestation Form?

To understand how we got to this point, you need a brief overview of what’s been going on in the past few years. A brief timeline of software security initiatives looks like this:

The Anatomy of the Secure Software Self-Attestation Form

Although the form clocks in at 10 pages, you can skip several less important sections with the following summary:

  • The Privacy Act Statement: outlines the history of the EO and OMB memorandum, purpose as discussed in those documents, use-case which is to comply with those documents, and a disclosure that this is a mandatory requirement
  • Purpose of the form: discusses the EO and OMB memorandums requirements for Federal agencies to make sure their software developers follow NIST’s SSDF and provide documentation for any software develop after September 14, 2022
  • Filling out the form: explains that software company must complete all sections of the form and that the CEO or their designee must sign it
  • Additional information: directs agencies to fill in any blanks left by the software producer and require a plan of actions and milestones (POA&M) to mitigate any remaining risks, noting that agencies might ask software producers to provide a Software Bill of Materials (SBOM)

Once you get through the three pages of introductory material, you get to the real meat of the form. 

Minimum Attestation References

This chart aligns EO Section 4 subsections with related SSDF Practices and Tasks. At a minimum, software producers selling to the Federal government must self-attest to:

  • Separating and protecting development and build environments
  • Logging, monitoring, and auditing authorization and access to each environment and among components within each
  • Enforcing multi-factor authentication (MFA) across environments
  • Documenting risk assessment and mitigation controls for software products used within environments
  • Encryption sensitive data
  • Implementing cyber defense strategies, including continuous monitoring and incident response plans
  • Making good-faith efforts to maintain trusted source code supply chain by using automated tools or comparable processes and establishing third-party vulnerability management programs
  • Maintaining provenance data for internal and third-party code used
  • Using automate tools or comparable processes for ongoing security vulnerability monitoring prior to product, version, or update releases that include processes to remediate vulnerabilities prior to release and disclose vulnerabilities after release

What to expect

At the end of Section III, the form includes a “Burden Statement” that estimates that each response will take approximately 3 hours and 20 minutes that includes time to:

  • Review instructions
  • Search data sources
  • Gather and maintain the necessary data
  • Complete and review the collected information

Software companies should also note that Section III contains the following two boxes identifying whether they have attached either of the following to the self-attestation form:

  • Addendums and/or artifacts 
  • NIST Guidance assessment baseline verified by a FedRAMP Third Party Assessor Organization (3PAO) or other 3PAO approved by an appropriate agency official

Qwiet AI: Intelligent SBOMs for Self-Attestation Documentation

Qwiet AI’s Code Property Graphs (CPG) provide visibility into your source code’s fundamental components, identifying functional elements and data flow paths for a consolidated view of all code being scanned. With our intelligent Source Composition Analysis (SCA), you can prioritize your remediation activities with data that provides insight into open source code libraries containing vulnerabilities and whether attackers can exploit them within the context of your source code. Using our SBOM, you get an in-depth explanation of security issues associated with the identified packages so that you can mitigate threats and document activities, enabling you to provide timely and accurate self-attestation documentation. 

Take our preZero platform for a free spin or contact us today to see how Qwiet AI can help you reduce the time spent gathering and maintaining the data necessary for your Secure Software Self-Attestation Common Form. 

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit:


See for yourself – run a scan on your code right now