The White House released a memo this week directing federal agencies to adopt guidelines from NIST for securing software used by the federal government and to attest to its security, a major step to shore up the security of federal systems.
The memo, M-22-18 (PDF document), published on Wednesday, is directed to the heads of executive departments and agencies and follows the Administration’s Executive Order 14028 for Improving the Nation’s Cybersecurity, released in May of 2021, which laid out new guidelines for securing software and empowers the Office of Management and Budget (OMB) to require agencies to comply with those guidelines.
The memo picks up where the EO left off, requiring federal agencies to comply with NIST guidance on software supply chain security, including NIST Special Publication 800-218 on developing a secure software development framework and subsequent NIST guidance on software supply chain security. It adds to a chorus of voices urging better management of the security of software used by the federal government and follows the release in early September of practice guidelines for software supply chain security by a panel of experts from the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA) and the Office for the Director of National Intelligence (ODNI).
Here's what the new memo means, practically, for software firms doing business with the government — and beyond.
[ Get a free SBOM and full supply chain risk analysis report ]
Software providers self-report on software supply chain security
Most important: the memorandum calls on federal agencies to obtain “self-attestation for all third party software, including software renewals and major version changes.” The memo applies to all new software purchases made after the issuance of the memorandum and to any software that receives a major version upgrade subsequent to the release of the Memorandum.
One category that is exempt is software developed by federal agencies. However, the Memorandum states that federal “agencies are expected to take appropriate steps to adopt and implement secure software development practices for agency-developed software.”
While the exact form of that attestation isn’t spelled out, agencies are encouraged to use a standard self-attestation form that “will be made available to agencies.” Furthermore, the Federal Acquisition Regulatory Council (FAR Council) will propose rulemaking that may standardize the self attestation form. Elsewhere, CISA is tasked with developing the self attestation form. Which will it be? Stay tuned!
It's worth noting: frameworks like the Department of Defense’s CMMC, require third party attestation of software security. The Biden Administration allows software publishers to “self attest” to the security of their wares and prove the existence of supply chain risk management controls. Third party assessments via a “Third Party Assessor Organization (3PAO) is also allowed, especially for open source software that might be part of a third party software application.
SBOM on deck (for now)
The new White House memo does not require software publishers to use — or federal agencies to require — the creation of a software bill of materials (SBOM) to validate their attestation. However, the language in the memo makes clear that SBOMs are the preferred method for demonstrating conformance with the NIST secure software development practices.
An SBOM “may be required” by an agency as part of solicitation requirements, the memo states, especially for software deemed “critical.” That SBOM must adhere to minimum requirements and one of the SBOM data formats defined in the NTIA SBOM requirements. Those state that SBOM must be accurate, presented in a standardized format, and include "known unknowns" for completeness. The Biden memo echoes that guidance, as well, instructing agencies to direct publishers to identify practices to which they cannot attest along with practices they have in place to mitigate those risks.
Other forms of attestation may also be required, including output from source code analysis and vulnerability scanning tools may be required in addition to or in lieu of an SBOM, as needed. Publishers may also need to show that they participate in a vulnerability disclosure program.
The clock is ticking for software providers working with the federal government
In addition to setting requirements for attesting to software security, the memorandum sets a schedule of deliverables for federal agencies. Within 90 days from the issuance of M-22-18, they must identify and inventory all software subject to the requirements of the memo and make a separate inventory of “critical software.”
Agencies have 120 days to develop a “consistent process” for communicating the new requirements to their vendors and establish a central agency system for holding attestation letters that are non-public.
Within 180 days of the issuance of the memo, agency CIOs need to have developed training plans for their agencies to review and validate attestation documents and other artifacts submitted by software vendors.
Within 270 days of the issuance of the memo, agencies need to have collected attestation letters for any critical software they have identified. Attestation letters for non critical software are due within 360 days of issuance of the memo.
Attestation is the easy part
Coupled with the 2021 Executive Order and the recently released Enduring Security Framework guidance, the memo reinforces the notion that federal agencies and contractors need to level-up their software security game…and fast.
But, as the saying goes: “The proof of the pudding is in the tasting.” In other words: the measure of the success of these programs and directives will be how strictly federal agencies and contractors adhere to them. Already, the memo contains lots of wiggle room, like language on “extensions” offered to agencies to comply with the requirements of the memo.
While that’s to be expected, serial extensions and can-kicking by Executive Branch agencies will undermine the effectiveness of the measures implemented by the memo and turn them into the federal cyber equivalent of “scofflaws.”
Finally, the memorandum’s focus on attestation highlights what, in some ways, is the easiest part for software publishers: standing by the security of their wares. The hard part, of course, is actually addressing security risks that exist in new and legacy code and actually raising the level of code security across product lines.
As we have previously written, the Enduring Security Framework (ESF) is a kind of roadmap for software vendors that do business with the federal government to do just that. It heavily references SSDF, SCVS and SLSA and is a de facto how-to guide for implementing a secure software development framework (SSDF) that many organizations will look to for navigating the EO and today's memo.
And the ESF makes clear that federal contractors and federal agencies need to develop proficiency in areas that, today and historically, they have not prioritized. Among those are:
- Binary scanning
- Final package validation
- SBOM generation
- SBOM component and publisher verification
- Management and mitigation of critical vulnerabilities
- Secrets enumeration
- Code verification
It is the investments that publishers make in those capabilities that will bear fruit in the form of more secure code that, in turn, can be assessed and verified by federal agencies that use it — using an SBOM or some other means.
