Almost two years ago, Executive Order 14028 – Improving the Nation’s Cybersecurity (EO) was issued requiring a host of actions be taken by the Federal Acquisition Regulation (FAR) Council, the National Institute of Standards and Technology (NIST), as well as the Office of Management and Budget (OMB). NIST completed one of those actions, which required it to identify “practices that enhance the security of the software supply chain,” when it released guidance on a secure software development framework and software supply chain security. In a recent memo, OMB (in accordance with the EO) requested all agencies comply with these NIST guidelines. Notably, the General Services Administration (GSA) is one of the first among the federal agencies to provide an update regarding specific actions it plans on taking to ensure only approved software is used under its contracts. Contractors already providing software under a GSA contract, or who are planning on doing so in the future, should become familiar with the four requirements listed below.
1. Minimum Requirements. Compliance with these guidelines will come in varying shapes and sizes, depending on which agency is procuring software. At a minimum, however, each agency is required to collect self-attestations from software producers when a government agency procures their software. This self-attestation will be a standard form and developed by the FAR Council. Such attestations will include, at a minimum, the software producer’s name, a description of the product(s), and a statement attesting that the software producer follows secure development practices (as identified by NIST).
These secure development practices derive primarily from two documents: NIST Special Publication 800-218 (SSDF) and the NIST Software Supply Chain Security Guidance. The former recommends a set of high-level, secure software development practices flexible to the security needs of individual software producers. The latter provides minimum guidelines that software producers will need to attest to, including: use of SSDF terminology, compliance with SSDF practices on an ongoing basis throughout a software’s lifecycle, and providing high-level artifacts to prove compliance with SSDF practices.
2. Existing Contracts that Include the Use of Software. For existing contracts that include the use of software, GSA IT will begin collecting attestations on June 12, 2023. If GSA previously approved a software, but no longer approves the software after updates to its GSA IT Standards Profile, any future period of performance cannot be exercised or issued and the requirement must be re-procured. The Profile, or current list of GSA-approved software, can be found in GSA’s Enterprise Architecture Analytics and Reporting (GEAR) tool. No software can be acquired until it has been through the IT Standards process.
While only individuals with access to the internal GSA server can access the Profile, you can submit an IT request for certain technology or software to become an approved standard. Specifically, the technology must undergo GSA’s security and Section 508 reviews, as well as receive Chief Technology approval after a formal review. If the software is being introduced to a production environment or for a known value in a GSA enterprise, the request can be submitted through the IT Service Desk. Also, if the feasibility or applicability of the product is not yet known or proven, a request for a pilot project, to explore usability, can be initiated through the IT Service Desk.
3. New Contracts that Include the Use of Software. For new GSA contracts with requirements procuring software, in performance of a contract with a Federal Risk and Authorization Management Program (FedRAMP) service provider, product, or solution, award may be made, and performance can begin, after ensuring the Profile is followed. In the event an apparently successful offeror offers pre-approved software, award may continue, and performance of the contract may start. However, if an apparently successful offeror plans to supply software not pre-approved, award may be made but performance cannot begin until said software is approved in accordance with the Profile.
In ensuring compliance with the Profile, GSA noted the security review may take significant time to adjudicate. The review will primarily entail collecting applicable attestations responsive to the minimum requirements, as released by the FAR Council in an upcoming rule. In the event GSA does not approve the software, the requirement must be re-solicited if the relevant acquisition team determines it is not in the best interest of the government to award to the next best-suited offeror.
4. GSA Recommends Offerors on GSA Contracts be Familiar with GSA IT Standards. Offerors on GSA contracts that deal with software should be familiar with the requirements of General Services Acquisition Manual (GSAM) 511.170. In short, subparagraph (d) of that provision requires offerors’ software products to be compliant with the Profile. Criteria GSA uses to determine whether a product is compliant with the Profile, and can thus become a GSA standard product, include whether an existing GSA IT product can meet the same requirements, whether the product is attached to an existing solution, the projected life cycle of the proposed product, and any other related practical considerations.
In the end, these “self-attestations” are necessary for any contractor looking to offer software on current and future contracts. Offering products that are already on GSA’s approved list (such as FedRAMP service providers, products, and solutions) will allow apparently successful offerors to begin contract performance much quicker than those offering unapproved software. With increasingly long lead times, contractors would be wise to avoid any other unnecessary delays, including those associated with the GSA IT review process. Note that for offerors on GSA-administered Indefinite Delivery Vehicles (FSS, GWACS, MACS), offerors are allowed to provide attestations regarding their software providing, but not required. GSA does anticipate, however, that such attestations be required at the master contract level, too.
An emphasis on cybersecurity in government contracting will continue to be a government-wide priority for the near future. New developments, including the release of the uniform self-attestations in mid-June, will keep those government contractors providing IT solutions and services busy learning and implementing compliance measures. If you have questions about the requirements for GSA’s software security practices and how to prepare for compliance with them, or any other secure software developments, please contact Cy Alba and Daniel Figuenick, the authors of this blog, or another member of PilieroMazza’s Government Contracts Group.
