The Path to Software Attestation
Contractors will soon have to attest to the government that any software they provide to the Government is secure, based on the Government’s definition of secure. The path to software attestation requirements for contractors started in May 2021 when the White House issued Executive Order 14028, Improving the Nation’s Cybersecurity. That executive order, among other things, required Government agencies to develop requirements to assure any software a Government agency uses is secure.
The path continued in September 2022 when the Office of Management and Budget (“OMB”) issued a memo, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, directed at complying with the Executive Order requirements to shore up the Federal Government’s software security. OMB updated this memo in June 2023. While OMB took these steps, the FAR Council has been developing acquisition regulations which will require contractors who provide software to the Government to comply with the software security requirements spelled out in the OMB memos. Anticipate the FAR Council to get a new acquisition regulation out for comment at any moment.
The Federal Government took a giant leap down the path to a more secure software supply chain on March 11, when the Cybersecurity Information Security Agency (“CISA”) released a final version of the Secure Software Development Attestation Form. The form CISA developed for making the attestation about software can be completed and filed HERE electronically or in PDF. The OMB memos made clear that contractors providing software to the Federal Government will be required to complete and fill the form. When the FAR comes out it will have this requirement as well.
Once the forms start rolling in, the Government will maintain a repository of software artifacts and SBoMs that contractors may rely on to complete the self-attestation form when a contractor provides third party software to the Government and therefore, needs information about the third-parties’ software.
Get Ready to Attest
Given this, contractors providing software to the Federal Government are getting closer to the day when they will be required to file the software attestation form as part of providing the Government software.
The attestation is a self-certification which means software providers may complete the form themselves and need not have some type of external review or audit of the information provided in the attestation form.
However, if a contractor is providing a critical services or products, the Government reserves its right to have a third party assess the software’s security. Additionally, agencies may require contractors to provide additional information like software bills of materials or other software artifacts to confirm the software meets security standards. I predict we will likely see additional requirements from DoD.
The attestation form essentially requires contractors providing software to the Government to affirm to the Government that the software provided complies with certain software security standards defined in the attestation form which will most likely be in the forthcoming FAR.
Who Will Have to Attest to Secure Software
Three categories of software require a contractor to provide the self-attestation form:
- New software purchases,
- Major version upgrades to software, and
- Software where the code continuously changes such as when a contractor provides software-as-a-service products or other software which uses continuous delivery and deployment .
Contractors must include information in the self-attestation form for software it develops as well as for software it has obtained from another entity.
Contractors will not have to provide information in the attestation form on software or any components of the software if:
- A Federal Government agency developed the software
- The software is open source. That is the Government agency freely and directly obtained the software
- Third-party open source and proprietary components are incorporated into the software end product
- The software is freely obtained and publicly available.
If contractors develop software under a Government contract, it may be considered “agency-developed software” and may not require an attestation. This will largely depend on whether the Government customer is able to ensure that the contractor followed secure software development practices during the development lifecycle which will be for the most part measured against NIST SSDF SP 800-218. If a contractor’s Government customer is not sure if the software is “agency-developed” the Government customer must consult with the agency’s CIO for a determination.
What You Will Attest To
At the highest level, the information required by the attestation form is designed to show the Government that software provided meets secure software development requirements.
The form requires:
- Information on the software producer
- A description of the software, including version
- Confirmation that the software producer conformed to the secure software development framework, SSDF as defined by Secure Software Development Framework, SP 800- 218,
- The signature of the software producer’s CEO or the employee the CEO designated to sign the form
Contractors will have to complete the self-attestation form for software it developed if its software is an end product it provides to the Government. It will not have to provide self-attestation for third-party software components that are incorporated into the software end product it is providing. This is the case whether the third party software components are open-source and proprietary components. A component, whether open- source or proprietary, is considered to be a “third-party” component if it was developed by an entity other than the producer of the software end product into which it is incorporated.
For purposes of the attestation form, component means:
A software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities. A component has a clearly defined interface and conforms to a prescribed behavior common to all components within an architecture. See NIST SP 800-95, Guide to Secure Web Services.
What You Should Do Now
- Decide if you are required to file a self-attestation
- If you don’t think you are, then make a note to your file explaining exactly why you don’t have to complete the self-attestation. This note to your file should be based on the facts about your products in relation to the legal requirements for when an attestation form must be filed.
- If you are required to complete the form, then, review the self-attestation form and gather information to complete the form, including software bills of materials or other information you think the Government may ask for
- If it appears after reviewing the security requirements that you may not meet the requirements, then, document what requirements you can meet and see if your customer is willing to accept a Plan of Action and Milestones outlining when you will be able to make the certification.
- Appreciate that being on top of these requirements, may be a competitive advantage for you.
- Remember, any time you make a representation to the Government and the Government considers your representations to be material, providing inaccurate, incomplete or out of date information may be considered false, as the term false is used under the False Claims Act. This is the case even if your false statement is only because of a lack of due diligence or even a mistake. Read more on how this works here: The Defense Salon: False Claims Act
The software security attestation form is just one more requirement for contractors that takes time and money to execute along with the risk of providing inaccurate information. Keep the end game in mind – the Government’s need to secure its systems and information by using trustworthy software.
Tim Cook, Apple’s CEO: National security always matters, obviously. But the reality is that if you have an open door in your software for the good guys, the bad guys get in there, too.
