On May 12, the Biden Administration published an executive order that is expected to have a major impact on America’s approach to cybersecurity. The executive order, which was released following a series of security incidents (including the massive SolarWinds breach and Colonial Pipeline cyberattack), includes guidance designed to improve the federal government’s defenses against cyber threats.

The executive order outlines elevated security standards that the federal government — and private vendors that work with the federal government — will be required to meet. These new requirements cover seven dimensions of cybersecurity:

  • Removing barriers to the sharing of threat information
  • Modernizing the federal government’s cybersecurity
  • Improving software supply chain security
  • Establishing a government-run Cyber Safety Review Board
  • Standardizing government responses to cybersecurity vulnerabilities and incidents
  • Enhancing vulnerability and issue detection across government networks
  • Improving investigation and remediation capabilities

At FOSSA, we specialize in helping organizations manage risk that comes with the use of open source software, which is part of the software supply chain for the vast majority of modern applications. With that as a backdrop, it’s only natural that we use this blog to highlight some of our top takeaways related to the executive order’s provisions on software supply chain security.

Related: How to Comply with Biden Administration Cybersecurity Executive Order

1. SBOMs Will Become Mandatory

Strengthening software supply chain security is best accomplished when we know what individual software components — and the relationship between different software components — are in a given product. It’s no surprise, then, that the executive order specifically highlights the need for manufacturers to publish SBOMs (software bill of materials) either to accompany each product individually or as part of a public website.

In mid-July, 2021, the U.S. government released the minimum required elements of an SBOM. There are three categories of required elements: data fields, automation support, and practices and processes.

  • Data fields: Descriptive information about each software component
  • Automation support: The ability to auto-generate SBOMs in both human- and machine-readable formats
  • Practices and processes: How and when SBOMs should be generated and distributed

2. Don’t Overlook Open Source Provenance

Open source software is part of the supply chain for the vast majority of today’s applications. (In fact, more than 90% of modern applications use at least some open source.) As a result, many organizations now use tools that scan open source libraries for known vulnerabilities and provide remediation guidance to address any security issues. But there’s another element to open source vulnerability management that goes beyond scanning and remediation: OSS provenance and quality.

The executive order section on open source provenance reads as follows:

Organizations should “(ensure) and (attest), to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.”

In other words, organizations will in some form or fashion be required to address several key questions about the OSS components in their products, such as:

  • Have we verified the integrity of the components, even if they’re from trusted sources?
  • Is there enough adoption and contributions from the open source community to give enterprises confidence that they can depend on the libraries long term?

These aren’t always easy questions to answer, of course, but it’s always wise to steer clear of trusting a package just because it’s used in other software products. Avoid auto-upgrades and always verify packages, even ones from trusted sources. Other best practices include checking their SHA-1 and other checksums for problems between what a program says it is and what it really is.

3. Automation Will Be Key

Modern applications are built with dozens upon dozens of different software components. This sheer volume of code makes detecting and remediating vulnerabilities via manual processes quite impractical. And while the executive order doesn’t require organizations to use automated tools to find and fix security issues per se, it does offer a blueprint for when and how organizations will need to check for vulnerabilities — something that will be much easier to do with automated capabilities. Specifically, the executive order notes that organizations should employ:

  • Automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
  • Automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;

Fortunately, there are a variety of effective tools available to organizations that will enable compliance with these provisions. For example, software composition analysis checks for and helps remediate vulnerabilities in open source code.

4. Software Supply Chain Security Includes Secure Development Environments

When we think about software supply chains, there may be a tendency to focus mostly on the third-party components we’re pulling into our build. After all, the average application uses a staggering 147 different open source components.

But, given that software supply chains really do include anything that impacts the software, the executive order also rightfully includes guidance on maintaining secure development environments. Specifically, it highlights several best practices organizations should follow, including:

  • Using administratively separate build environments
  • Auditing trust relationships;
  • Establishing multi-factor, risk-based authentication and conditional access across the enterprise
  • Documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software
  • Employing encryption for data

More specific guidance on how organizations can comply with these directives is forthcoming, but it certainly wouldn’t hurt for teams to start assessing their current development environments and planning any needed tooling or process upgrades.

5. The Executive Order Was Only a First Step

The Biden Administration executive order represents a necessary and important first step on America’s journey to strengthening its cyber defenses, but it really is just that: a first step. Over the next calendar year, the government will provide more specifics on the steps organizations will need to take to comply with these new regulations.

In addition to what we mentioned earlier (that minimal requirements for a software bill of materials will be published around mid-July), here are some of the key dates/milestones to track.

  • Within 30 days (by mid-June, 2021): The government will gather input from the public and private sectors on “standards, tools, and best practices” to enable compliance with the guidance laid out in the executive order
  • Within 180 days (by mid-November, 2021): The government will publish “preliminary guidelines” that spell out how organizations can meet the order’s requirements
  • Within 90 days of the issuance of preliminary guidelines (by mid-February, 2022): The government will issue additional guidance around how organizations can comply with the executive order

You can view the full executive order text here to see the complete timeline and all key milestones.

6. The Executive Order Will Impact Private Transactions, Too

Although the scope of the executive order is mostly limited to the federal government and vendors that do business with the federal government, its provisions are also relevant to organizations that sell exclusively into the private sector. This is the case for several reasons.

First and foremost, cybersecurity is obviously a top priority for private organizations — the financial and reputational costs of a breach are massive. As a result, we’d expect to see private organizations adopt some of these elevated standards when they make purchasing decisions. For example, a buyer may insist that a manufacturer provide it with a software bill of materials before finalizing a deal.

Additionally, the new Cyber Safety Review Board (outlined in the fifth section of the executive order), will have some degree of oversight over the private sector. Although we’ll learn more specifics in the coming months, it appears the Review Board will function in a similar fashion to how the National Transportation Safety Board (NTSB) operates within the aviation industry, with the authority to investigate and report on cyber incidents.

Cybersecurity Executive Order: The Bottom Line

In light of today’s increasingly complex cyber threat landscape, this new executive order represents an important step in the federal government’s work to modernize its cybersecurity infrastructure. When it comes to preventing software supply chain attacks, it’s clear that the ability to accurately and comprehensively understand the different software components in a given application will be a table stakes capability to enable compliance with several key provisions.

For information on how FOSSA can help your organization get a head start on compliance, check out our page How to Comply with the Biden Administration's Cybersecurity Executive Order.