One Year Out: What Biden’s EO Means for Software Devs

It has been just over a year since president Biden issued executive order 14028 (EO) to improve the nation’s cybersecurity posture. Despite the Log4j vulnerability and a worldwide increase in ransomware attacks, this EO signaled a major step in improving software security at federal agencies and establishing cybersecurity as a priority for the U.S. government. While the agencies tasked under this EO have made significant gains, it is important for industry to understand just how much progress has been made since its inception and what that progress means to the average producer of software.

To understand the effects of the EO, it is important to remember that president Biden does not have the authority to order any government agency to purchase specific software, nor does the president have the authority to require any governmental agency to procure specific software. Instead, the EO instructs heads of agencies to perform specific tasks that will ultimately define more stringent cybersecurity requirements to protect government offices. This doesn’t mean the EO solely applies to U.S. government contractors; if your company is anywhere in the software supply chain leading to a U.S. government purchase, then you need to pay attention to the EO and plan accordingly.

One of the first of those tasks was for the National Institute of Standards and Technology (NIST) to solicit input from the public and private industry surrounding the structure and management of software supply chains. That work resulted in an NIST publication on EO Critical Software in July 2021. That publication helped outline security measures for software use, including applying practices of least privilege, network segmentation and proper configuration. It also helped NIST to frame the Secure Software Development Framework (NIST sp800-218v1.1) (SSDF) published in February, which provides a set of fundamental secure software development practices.

This guidance, along with the definition of a software bill of materials (SBOM) by NTIA in November and the updated Cyber Security Guidance for Supply Chain Risk Management (NIST sp800-161r1) released in early May now form part of the risk-based framework that OMB instructed agencies to follow.

What it Means To Be “EO Compliant”

Before beginning any discussion about EO compliance, it’s important to recognize that until there are contract clauses defined—and those contract clauses are incorporated into contracts—there isn’t anything to comply with. That process is part of the Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation (DFAR) effort, and the proposed clauses haven’t been published yet. Despite this, we do know enough to start preparing for future compliance and creating processes that will allow for EO compliance.

The first step is to recognize whether your organization is a supplier within a supply chain of a U.S. government agency. In the context of the EO, that would mean any organization who creates, procures or embeds software into a component or assembly that is ultimately bought by a U.S. government agency. This includes open source software, low-code/no-code frameworks and DevSecOps tooling, to name just a few of the scenarios where U.S. government use might not be immediately apparent.

With that in mind, any provider of software within a supply chain should be prepared to answer questions about EO compliance if their software can be used in the U.S. government setting. For some, this could mean updating a few processes; for others, it may prompt a much larger set of changes in the development cycle. Those willing to change may be more likely to retain relationships or gain favor with government suppliers.

How Software Providers Can Be Proactive

There are three critical steps that can be performed today as part of preparing an organization for future EO compliance requirements. The first thing providers can do is generate a complete SBOM for their software in an NTIA compliance format and be prepared to attest to its accuracy. While it is not yet clear how the U.S. government will expect to receive an SBOM or what attestation format will be required, generating compliant SBOMs is one of the easiest tasks software producers will face as part of a post-EO world.

Next, providers should baseline existing software development practices with the objective of aligning with the SSDF (NIST sp800-218v1.1). The SSDF defines a set of tasks that NIST views as a minimum requirement to securely create software and manage the software creation process. If the government procurement requirements include an attestation of compliance to the SSDF, then software producers who already know how well-aligned they are to the SSDF will be that much closer to compliance.

Lastly, providers must implement controls related to open source governance. While an SBOM helps identify open source use and the SSDF includes tasks related to its use, neither specifically defines how any software producer is expected to govern their use of open source software. Open source software is fundamentally different from commercial software in many ways; the most important differentiator is that it is freely downloadable from the internet. This free access means that creators likely do not know who their consumers are and thus cannot proactively provide updates or security information. Open source governance processes can help to fill that gap.

Why It is Time to Embrace the EO

These first steps can help software providers address the initial requirements that have come out of Biden’s EO and those who get a jump on implementation will have a leg up against their competition. Starting now can save providers a major headache in the long run, as federal agencies seek an understanding of how much risk they bear when operating the software you produce.

The rapidly changing cybersecurity landscape was a key driver behind Biden’s EO. Threat actors are evolving their tactics to keep pace with improving cybersecurity postures and it is in everyone’s best interest—from the federal government to the private sector—to put an emphasis on security. An important place to start—regardless of where you are in any software supply chain—is by taking the steps necessary to demonstrate that you understand the risks inherent in operating software and are actively working to reduce those risks for your customers.