The Biden administration has taken another step forward in its strong push to improve national cybersecurity, this time addressing the software supply chain with new requirements. In keeping with the terms previously presented in Executive Order 14028, the Office of Management and Budget (OMB) has issued a new memorandum that sets a year-long framework for vendors to provide assurances of secure software development.
Within one year, software producers will be required to produce a Software Bill of Materials (SBOM) or equivalent document guaranteeing secure software development practices. The time limit is reduced to 270 days for “critical software.”
Supply chain software the focus of new OMB orders
Calling it a necessity to deliver a “secure government experience,” the OMB instructions issued to federal agencies to ensure that nothing but secure software is in place. This means, primarily, an accounting of the components of everything used in the software supply chain; the main mechanism being a SBOM.
A number of recent events have demonstrated the need for something like a SBOM to truly secure software, but none more than the Log4j vulnerability that cropped up in late 2021. An easily exploited vulnerability in a software component broadly used in all sorts of applications highlighted the need for a quick and simple way to locate each of these components for patching or remediation when such an issue appears.
The order also mandates that secure software development standards are in place going forward, and that all federal agencies and their software supply chain are in compliance with these standards. The memo orders the National Institute of Standards and Technology (NIST) to immediately prepare guidance that these parties will be directed to comply with, which will be drawn from the NIST Secure Software Development Framework (SSDF) SP 800-218 and the existing NIST Software Supply Chain Security Guidance.
The memo is comprehensive, applying these secure software standards to any third-party programs or apps used on agency systems or “otherwise affecting the agency’s information” (or software that vendors with access to these systems make use of). Agencies will be responsible for implementing software supply chain standards with the organizations they contract with. Software that is developed internally by agencies is excepted from these requirements, but the memo “expects appropriate steps” to implement secure software development practices.
While agencies must implement, they will not bear the full burden of inspecting; software vendors are being given a year (or 270 days in some “critical” cases) to self-attest that these secure software development practices are in place. At minimum these self-attestation statements will require a description of the product, and a statement that an itemized list of secure software practices has been followed in development (on a standardized form to be developed within 120 days). If the software is determined to be critical enough, a SBOM or equivalent documentation will also be required (behaving with standards established in the National Telecommunications and Information Administration report “The Minimum Elements for a Software Bill of Materials” or successor guidance prepared by CISA) . A third-party assessment may also be required depending on risk level.
Vendors will have 365 days to prepare the necessary statements; those requiring SBOMs will have 270 days. Participation in a vulnerability disclosure program may also be required, depending upon individual agency determinations. Agencies are required to inventory their software within 90 days and note critical applications, and develop a process communicating for requirements to vendors within 120 days.
Attacks on supply chain, critical infrastructure prompt secure software push
The government has very limited ability to dictate “secure software” terms to private companies, but hopes that pressure on government contractors in the software supply chain (which include tech’s biggest names such as Microsoft and Oracle) will in turn translate into more secure products across the general landscape.
But some cybersecurity analysts are not convinced that this approach will actually lead to more secure software, or at least see it as a process that could take years to unfold. While critical software will have to be supported with documentation, and some software will be subject to review by a certified FedRAMP assessor (or one appointed by the agency), the bulk of the federal software supply chain will only be subject to the most basic self -attestation requirements.
Some analysts point to a similar set of terms that have been in place for defense contractors since 2015. Sharp criticism of these terms eventually gave way to lawsuits that courts began deciding in favor of the government in 2019, as contractors simply overstated or even falsely stated their capability and readiness. These terms may follow a similar pattern, with years of continued breaches before the government turns up the heat and increases its auditing practices. In the case of defense contractors, the successful use of the False Claims Act in court (which can subject contractors to millions of dollars in fines in the worst cases) may be a planned element of this strategy given that there is now legal precedent.
Eric Noonan, CEO of CyberSheath, had particularly harsh words for the memorandum: “This memo could’ve been written by China, lobbyists or both. First, yes, this is a step forward in that the government is requiring some level of assurance from their suppliers relative to meeting cybersecurity minimums. But allowing for self-attestation ensures we will repeat the sins of the past. We need look no further than the recent whistleblower case where defense contracting giant Aerojet Rocketdyne self-tested to meeting cybersecurity standards on federal contracts. The case just settled last month for $9 million and I doubt Aerojet’s settled believing their self-attestation to meeting cybersecurity standards was accurate … Most states don’t allow Americans to self attest to the vehicle inspection of their cars but we are going to allow Multi billion dollar international corporations to self attest to their Cybersecurity? The damage done to national security because we allow agencies and companies to self attest is long. We’ve had the Target data breach, we’ve had the Office of Personnel Management breach, the Equifax breach, the Colonial Pipeline hack, I could go on. The link between successful data breaches impacting national security and self attestation is irrefutable.”
And Mark Stamford, CEO and Founder of OccamSec, questioned whether government had simply set itself up to eternally play catch-up with threats: “The problem here is who sets the standards? If we need to use software build using secure development process, who is setting that? And how do we enforce it? And what about organizations that can’t comply (ie small businesses) is this going to lead to the usual suspects being acceptable and everyone else not? This will have a long term, net negative effect on our nations’ security.
When you publish a standard, everyone knows what your defenses are, and you then have a roadmap on how to plot your attack. Standards for secure software development works if you address all the ways in which software can be developed, given the multitude of programming environments; Are we going to set specific coding requirements? Or broad strokes? Again, how are we going to keep this up to date?” added Stamford. “What we need really is a more dynamic approach which is constantly re-assessing how the risk posture has changed following a new threat/vulnerability/other – without this we will have standards set, which get updated everyone once in a while, but always playing catch up.”
The secure software push continues prior efforts by the Biden administration to improve general cybersecurity readiness in the country, following orders for federal agencies to adopt a “zero trust” approach to network security and creating new requirements for utility and critical infrastructure companies.