Can Biden’s Executive Order Secure the Software Supply Chain?

Conformity. Attestation. Artifacts.

If you want to sell products powered by software to the federal government, you need to get familiar with those terms. You’d also better be prepared to comply with what they require.

Because if you don’t, federal agencies will eventually be banned from buying from you, by executive order (EO) of President Biden.

Don’t panic. You will have some time — likely years — to get ready. More on that later.

But don’t delay either. Those three words are at the core of the section of Biden’s May 2021 EO on improving cybersecurity that is devoted to the software supply chain.

In brief, its goal is to ban U.S. government agencies from buying any software product that doesn’t include detailed, credible information on who made the components, where they came from, whether they were built and tested in conformance with specified quality and security standards, and how updates and patches for any exploitable defects will be provided and for how long.

Yes, that’s in brief. The National Institute of Standards and Technology (NIST) goes into much more detail in response to Biden’s EO with Software Supply Chain Security Guidance, issued Feb. 4, 2022.

And for anyone who cares about the risks to government, business, and individuals from software that is not secure — which should be everybody — the directives should be welcome.

Indeed, virtually every private and public sector organization depends on software. A lot of software. And if it’s not secure, your organization is at risk. Unpatched vulnerabilities can lead to trouble ranging from annoyance to disaster — hijacking of systems, data leaks (and therefore theft of sensitive data), denial-of-service attacks, system crashes, theft of everything from identity to financial data and intellectual property, millions in ransomware payments, critical infrastructure damaged or shut down, and more.

And the threat of such disasters is increasing. The research firm Gartner, in a report titled “Top Trends in Cybersecurity 2022,” called the digital supply chain one of the top two current attack vectors. “Vulnerabilities that are deeply embedded in the digital supply chain are often extremely difficult to detect, and thousands of applications or devices may be simultaneously impacted,” the report said.

To minimize the risk of those disasters, which is the intent of the Biden EO, organizations need to use software components that meet rigorous security standards, keep track of them, and keep them up to date.

The ways to do this are no great mystery — they’re well established. To keep track of it requires a software Bill of Materials (SBOM). As has been said thousands of times at security conferences, you can’t protect something you don’t know you have. And if you don’t protect it, you can’t trust it to protect you.

Supply chain tracking is not a revolutionary concept either. For generations we have taken for granted that supply chain information for just about every product in the physical world is accessible when necessary.

If contaminated lettuce shows up in grocery stores, we soon hear on the news which farms it came from and to throw it out if you bought lettuce between certain dates from certain stores.

Same for malfunctioning airbags, brakes, seatbelts, or any other component in cars. If there’s a problem, the auto manufacturer knows which vehicles to recall, and which vendor made the flawed product.

The same ought to be true of software products. In a connected world, software is behind just about everything, from factory operations to bookkeeping, human resources, communication, finance, critical infrastructure, home security, appliances, and yes, government. The list could go on and on.

Why isn’t it already mainstream?

Because it’s complicated. Very complicated. Creating and maintaining an SBOM for an organization of any size can be a massive undertaking, since the software components used to build applications, customer interfaces, networks, and other digital infrastructure in most cases rely on other components, called dependencies.

That means the stuff you know you’re using is relying on other stuff you may not know you’re using. Those dependencies can go multiple levels deep and exponentially increase the number of components that need to be tracked so they can be updated when necessary.

Tim Mackey, principal security strategist within the Synopsys Cybersecurity Research Center, has used a simple Slack application with an Instagram interface as an example.

In a recent webinar, he noted that the app included eight declared dependencies, one of which originated from Slack itself, called Bolt.

But Bolt has 15 dependencies of its own. And one of those, called Express, has another 30. “When you peel back the onion on this, Slack/Bolt actually has 133 separate components in it,” Mackey said.

That’s 16 times the eight declared or “visible” dependencies of just one component of one app. And given that most organizations have hundreds to thousands of apps, it’s clear how complex and unwieldy tracking a software supply chain can be.

Fortunately, there are numerous resources available to help create and maintain what would be an impossible manual task. They include automated tools and detailed advice from government and private sector associations.

Among them, the National Telecommunications and Information Administration within the Department of Commerce has a section of its website devoted to everything an organization needs to understand an SBOM, including an extensive Q&A.

And the federal Cyber Information Security Agency hosted a virtual conference titled SBOM-a-Rama on Dec. 15 and 16, 2021, in which SBOMs were described as “a key building block in software security and software supply chain risk management.”

But besides keeping track of software, the EO calls for federal agencies to buy only quality software products, or in other words, products that comply with those three key words mentioned earlier – conformity, attestation, and artifact.

According to the NIST definitions:

Conformity is a “demonstration that specified requirements are fulfilled,” including “a demonstration that the software producer has followed secure software development practices.”

Attestation is the “issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.”

Artifact is “a piece of evidence (that provides) grounds for belief or disbelief; data on which to base proof or to establish truth or falsehood. Artifacts provide records of secure software development practices.”

Those requirements amount to a very tall order for any organization that isn’t already building security into its software with secure software development practices and maintaining an SBOM.

So how much time, realistically, will both federal agencies and vendors have to get ready?

Don’t hold your breath, even though EO deadlines are looming. The federal Office of Management and Budget (OMB), if it meets its deadline, will be issuing guidance within a week or two on requirements for federal agencies to comply with the EO’s software procurement requirements.

But Emile Monette, director of government contracts and value chain security at Synopsys, said that guidance, even if it’s issued on time, won’t result in anything enforceable until a Federal Acquisition Regulation (FAR) rule is issued.

Indeed, the EO itself says the deadline for OMB to make recommendations to the FAR Council (which will issue the rule) on “contract language” for government procurement of software products isn’t until a year after the EO — May 12, 2022.

And after that, there is no deadline for the FAR Council to act. The EO simply says that the council “shall review the recommendations and, as appropriate and consistent with applicable law, amend the FAR” to create a “final rule.”

That, Monette said, can take years. Besides the fact that every proposed “final rule” requires a comment period of at least 60 days, “lots of other variables can also affect the process — political pressure from either end of Pennsylvania Avenue, new statutes, new EOs, small-p political pressure from OMB or the other agencies, the volume and content of public comments received, a ‘reopening’ of the comment period, and just the passage of time between original publication date and the occurrence of some superseding event in the world,” he said.

“In general, the FAR rulemaking process is assumed to be 24 months if there are no hiccups. But realistically, it’s rare that a substantive rule gets through that quickly and unscathed.”

“OMB has not communicated anything publicly on the topic,” he added. “And the OMB guidance will most likely only be directives to the agencies as to how they implement the NIST requirements — which contracts, waiver process, timelines, etc. Without a FAR rule in place, the government has no way to require contractors to meet the conformance and attestation requirements, or any others.”

Beyond all that, the law of unintended consequences could come into play. What if, after the rule is established, a government agency can’t get software products it needs because there aren’t qualified vendors available?

Monette said that possibility will likely be addressed in OMB recommendations, which would allow waivers or a Plan of Actions and Milestones process.

It could still create a problem, though, “because it might cause certain software developers to exit the federal market if the cost to make their products compliant is too high,” he said.

Finally, there is no way to conduct an overhaul of this magnitude to the biggest and most complicated organization in the country quickly.

“Just think about the software used by the VA [Veterans Administration],” Mackey said. “You’ve got everything from medical devices, implantable devices, and EMR [electronic medical records] software to fleet management software for transport vans and the software in the vans themselves. All of those are under some form of government contract, so just imagine trying to apply this to the VA and then the rest of our government infrastructure.”

Still, while it may be a slow train, it’s moving. Any company that wants to sell to the feds needs to prepare for its arrival. Now would be a good time to start.

Click here to find more Synopsys content about securing your software supply chain.