In May 2021, President Biden issued an Executive Order (EO) that will result in a monumental shift in supply chain security requirements for software developers and device manufacturers who sell to the Federal government. Per the EO’s directive, NIST recently published an initial definition of “critical software” — identifying the products that, in the initial phase of the EO’s implementation, will have to meet the technical requirements that will be issued under the EO. 

This is just the first step in the aggressive timeline established under the EO to bolster cybersecurity within our Federal agencies. But if you think this shift will apply only to organizations whose products fall into the initial definition of “critical software” or only those selling to the Federal government, think again.

Impact on the market

In the same way that California’s environmental rules for automobiles are adopted by other states and/or come to dictate industry standards, we anticipate that the technical requirements under the EO will be applied broadly across the software industry. 

Each software vendor will have to compete commercially alongside the companies that are directly subject to the EO’s rules. Failing to meet the increased security and transparency requirements that the EO will impose will, for many, translate into a competitive disadvantage in the marketplace. When other vendors offer a Software Bill of Materials (SBOM) for their products, along with transparency into their development and supply chain security processes, failing to match those security and transparency requirements will inevitably result in loss of sales for those who do not.

Furthermore, NIST directly states that any Federal agency may ask vendors to provide an attestation of product and supply chain security even if it is not on the EO-critical list. They suggest that agencies “leverage the EO-critical security measures defined in Section 4(e) [of the EO] as part of a procurement.” 

Other organizations are also likely to adopt the EO’s requirements as the model of best practices and may even make meeting them mandatory. As with the NIST Cybersecurity Framework and various technical cybersecurity standards, we anticipate that numerous companies will graft key requirements from the EO into their contract language, imposing the new standards for all their software acquisitions. We could even see these standards become prerequisites for obtaining cybersecurity insurance coverage or securing venture-backed funding.

We are already seeing sales cycles lengthening due to customer demand for transparency into product and supply chain security. Those companies that wait to adopt newly defined best practices until they become mandatory will quickly be outpaced by competitors and by the industry as a whole. 

Whose responsibility is it to handle product and supply chain security?

As the reality of this EO becomes more tangible, we are finding many organizations struggling to understand what must be done—and who, within each organization, should be responsible. 

One thing is certain: product and supply chain security for software and connected devices is a complex and difficult issue to manage. At the end of the day, supply chain risks should not be handled the same way as enterprise network risk, as the attack surface and attack vectors are not similar. Supply chain risk requires its own set of controls. It cannot be lumped together with cybersecurity controls; it requires a dedicated product team. In other words, not having a dedicated product security team, at this point, is a mistake. 

Having a dedicated Chief Product Security Officer (CPSO) with the ability to build out an effective team is often the most important first step in taking control of your product and supply chain security. It is important that there be someone in the organization with both the technical expertise to handle product and supply chain security as well as the decision-making power to make it a priority within the organization. This includes addressing supply chain initiatives that the EO, NIST, and customer demand will make necessary.

That being said, product risk is business risk, and company leadership as a whole should be making it a priority throughout the organization. In some cases, this may require a significant allocation of resources, but the cost of not acting is likely to be even greater.

Next steps for software vendors and device manufacturers

Our recommendation to all software vendors and device manufacturers is that they closely track the technical requirements emerging from the implementation of the EO, assess where these requirements are likely to land, and quickly establish a plan to meet those standards well before they become obligatory. In this, a CPSO needs to play a prominent role.  

Staying competitive —and, frankly, ensuring that your products and supply chains are secure — requires staying ahead of these requirements.