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:
- May 2021: President Biden’s EO contains Section 4 Enhancing Software Supply Chain Security.
- February 2022: The National Institute of Standards and Technology (NIST) releases the Secure Software Development Framework (SSDF) v1.1
- September 2022: The Office of Management and Budget (OMB) releases memorandum M-22-18 “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” that requires Federal agencies to obtain a self-attestation from the software producer before using the software.
- April 2023: CISA Releases the Secure Software Self-Attestation Common Form noting that it’s responsible for developing and maintaining the form.
- May 2023: OMB releases memorandum M-23-16 “Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” that clarifies things like timelines and scope, including third-party components, open-source software, and contractor-developed software
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.
