The government has issued rules in a memo titled ‘M-22-18’ that will soon affect software producers and federal software supply chain Compliance. Here’s the short version:
Good news: The government wants to protect everyone from supply chain disruption and promote securing the software supply chain.
Bad news: Deadlines! New requirements, like providing attestations and artifacts.
Good news: That’s only if you sell software to the federal government.
Bad news: OK, but you ought to comply, anyway, since companies that meet the requirements will be more attractive business partners. You’ll either be one of them…or you won’t.
Good news: We are here to help make sense of all this.
Now for the long version.
The Main Requirement of the M-22-18 for Federal Software Supply Chain Security Compliance
On September 14, 2022, the Office of Management and Budget (OMB) issued Memorandum M-22-18 (the White House Memo) requiring federal agencies to comply with rules to ensure that third-party software they use meets secure software development practices. While the changes affect federal agencies and the companies providing software to them, industry-wide adoption by all software providers could help prevent the next massive cyberattack to the global supply chain.
The federal government’s efforts began with Executive Order (EO) 14028, Improving the Nation’s Cybersecurity (May 12, 2021). The EO was issued in response to the SolarWinds attack and other serious cyberattacks that affected the software supply chain and served as a reminder of the need to address vulnerabilities in using open source software and to take steps in securing the software supply chain. One of the EO’s aims: to “improve the security of software by establishing baseline security standards for development of software sold to the government.” The EO directed the National Institute of Standards and Technology (NIST) to issue guidance. The White House Memo now sets out the practices federal agencies must follow to comply with the resulting “NIST Guidance,” which assists in evaluating and mitigating software supply chain security risks.
The key requirement under the White House OMB Memo 22-18 states that Federal agencies “must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.” The White House Memo later adds that secure software development practices must have been used “throughout the software development lifecycle.” If you are a software producer, this new NIST attestation is one of your federal cybersecurity requirements.
The first set of requirements had the deadline of December 13, 2022, or 90 days after the date of the White House Memo.
Scope
Federal agencies:
- The White House Memo requires each federal “agency” to “comply with the NIST Guidance when using third-party software on the agency’s information systems or otherwise affecting the agency’s information.”
- An agency awarding a contract that may be used by other agencies must follow the OMB Memorandum M-22-18.
Software: Software is defined broadly. As a result, many organizations doing business with the federal government will be affected. Software “includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.” All of these products will require software attestation.
As of when: The White House Memo applies to federal agencies’ use of (a) software developed after September 14, 2022 and (b) existing software that is modified by “major version changes” after September 14, 2022.
Exclusions: The Requirements don't apply to “agency-developed software,” but agencies must use secure software development practices for agency-developed software.
What to do—if you Want to Provide Software to Federal Agencies
The White House OMB Memorandum 22-18 requires that before a federal agency uses software, the software producer must submit (1) a self-attestation of conforming to NIST Guidance and (2) potentially, “artifacts that demonstrate conformance to secure software development practices.”
First Requirement: Self-Attestation, and Exceptions:
Self-attestation, a minimum requirement. Agencies must obtain a self-attestation from the software producer before using all third-party software, including software renewals and major version changes (subject to exceptions). An agency may also require a third-party assessment due to the “criticality of the service or product that is being acquired.”* Self-attestation must include:
- The software producer's name;
- A description of which product or products the statement refers to; and
- A statement attesting that the software producer follows secure development practices and tasks that are itemized in the standard self-attestation form. Foundational practices for developing secure software are included in the NIST Secure Software Development Framework and the NIST Software Supply Chain Security Guidance.
Exception—documentation and mitigation. If a software producer cannot attest to one or more of the practices from the NIST Guidance, “the requesting agency shall require the software producer to identify those practices to which they cannot attest, document practices they have in place to mitigate those risks, and require a Plan of Action & Milestones (POA&M) to be developed.” If the agency is satisfied with the documentation, the agency may use the software.
Exception—valid third party assessments. Helpfully—especially where products incorporate open source software—a third-party assessment is acceptable instead of self-attestation, if provided by either a certified FedRAMP Third Party Assessor Organization (3PAO) or one approved by the agency, if the 3PAO uses the NIST Guidance as the assessment baseline.
Second Requirement: “Artifacts”
- Get ready to provide an SBOM. An agency can require a software producer to submit a Software Bill of Materials (SBOM). An SBOM is a “formal record containing the details and supply chain relationships of various components used in building software.”
- Provide defensible artifacts/evidence. An agency can require other artifacts, including evidence of participation in a vulnerability disclosure program. Under NIST, an artifact is simply “a piece of evidence,” and evidence is “grounds for belief or disbelief; data on which to base proof or to establish truth or falsehood.”
- Low-level artifacts are generated during software development and include, for example, threat models, log entries, source code files, source code vulnerability scan reports, testing results, telemetry, or risk-based mitigation decisions for a particular piece of software.
- High-level artifacts summarize secure software development practices derived from the low-level artifacts. An example: a publicly accessible document describing the methodology, procedures, and processes a software producer uses for its secure practices for software development.
Reliability of Attestations and Artifacts
Practices that enhance the security of the software supply chain include “employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code,” and “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them.”**
Therefore, an organization that relies on a data infrastructure based Compliance automation solution is better equipped to make an attestation and provide artifacts. Automated Compliance that provides a scalable constant stream of actionable, real-time data allows faster identification of vulnerabilities, thereby ensuring a more secure software development environment. In addition, such a Compliance system generates credible, trustworthy artifacts to show how software that is part of its product is protected. A judgment call can’t serve as evidence of a secure environment, and a screenshot is easily manipulated. But because an automated system of Compliance is designed to generate artifacts for use as reliable evidence in audits, that same system can yield reliable artifacts that evidence secure software development practices.
The Clock is Ticking
Some key deadlines under the White House Memo:
- By December 13, 2022, agencies must “inventory all software subject to the requirements of this memorandum, with a separate inventory for ‘critical software.’”
- By January 12, 2023, agencies must “develop a consistent process to communicate relevant requirements in this memorandum to vendors, and ensure attestation letters are collected in one central agency system.”
- By June 11, 2023, agencies must “collect attestation letters for ‘critical software’ subject to the requirements of this memorandum.”
- By September 14, 2023, agencies must “collect attestation letters for all software subject to the requirements of this memorandum.”
There are also deadlines for OMB, NIST, and the Cybersecurity and Infrastructure Security Agency.
How Big a Change?
Determining whether a particular organization has a lot of extra work in store to maintain federal software supply chain security Compliance in line with M-22-18 depends on whether they use automated Compliance tools. These tools make it easier to attest to, and show evidence of, secure software development practices. Organizations that provide software to government agencies should start closing any gaps that would prevent them from being able to continue.*** But other organizations should also adopt the White House Memo and the NIST Guidance, to better secure their own software development environment and the global software supply chain. The fact that the White House OMB Memorandum M-22-18 requires attestation and artifacts is a strong argument that these are best practices for any software producer because they are designed as a generic software supply chain security solution. Following these practices benefits businesses and their potential partners.
---------------
Further Explanations:
*In OMB memorandum M-21-30, NIST defines critical software as “any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:
• is designed to run with elevated privilege or manage privileges;
•has direct or privileged access to networking or computing resources;
• is designed to control access to data or operational technology;
• performs a function critical to trust; or
• operates outside of normal trust boundaries with privileged access.
The definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) that is purchased for, or deployed in, information systems and used for operational purposes.”
**https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ (Section 4(e)(iii) and (iv)).
***Congress is working to codify the requirements of the EO. On September 21, 2022, the Securing Open Source Software Act of 2022, S. 4913, was introduced in the Senate. In part, it would require the Director of the Cybersecurity and Infrastructure Security Agency to assess the risk of open source software components used by federal agencies and ensure federal cybersecurity requirements are met. The bill awaits approval by the Senate.
About the author
Contact us
