The National Cybersecurity Strategy released by the Biden Administration this week includes key recommendations that significantly mitigate software supply chain risks. Specifically, the White House recommends making software providers liable for insecure software. Until now, the U.S. government has never taken such a bold stance on liability for software products at this level.

The strategy recognizes that even advanced security programs can’t prevent all vulnerabilities. To account for this, a series of “Safe Harbors” based on reasonable standards and best practices will be defined. If followed, these would allow organizations to avoid liability.

This includes having greater organizational accountability for the software supply chain and creating products that are “secure from the start” and “secure by design.” In practical terms, for organizations trying to get ahead of these recommendations, this means increased scrutiny, responsibility, and liability attached to their software supply chains.

While open source software makes up as much as 80% of modern applications, many organizations have no process or policy for open source consumption. The result is software supply chains plagued by low-quality parts in the form of vulnerable open source.

To better understand the impact of low-quality parts on software supply chains, a good place to start is with lessons from W. Edwards Deming. Deming is widely known for helping shape post-world-war-II manufacturing in Japan. Many of the management techniques he developed serve as a foundation for modern supply chain theory. Based on Deming’s work, organizations should follow three critical principles to improve the quality and security of their supply chains:

  1. Source parts from fewer and better suppliers

  2. Use only the highest quality parts; don’t pass defects downstream

  3. Continuously track the location of every part

That guidance directly applies to software supply chains. First, reduce suppliers (open source projects) and only use the highest quality parts (open source components). Second, don’t have ten web frameworks; instead, use one across the codebase. And finally, use the best project vetted with criteria like how actively it is maintained, how often vulnerable versions have been discovered, and how long it takes to release a fix.

The good news is that this problem can be solved today, resulting in a measurable risk reduction and increased efficiencies for software development teams. Bringing together the guidance from the new National Security Strategy with Deming’s principles, here are three things software development organizations should do to minimize their exposure to software liability.

Acknowledge Organizational Responsibility

Utilizing the principles from Deming mentioned earlier, open source projects represent traditional suppliers seen in manufacturing, with open source components representing the parts. Similar to traditional manufacturing, not all suppliers or parts are of equal quality. And the same can be said for open source projects and components.

In research conducted by Sonatype for the 2022 State of their Software Supply Chain Report, they identified that 96% of components downloaded with a vulnerability had a non-vulnerable version available at the time of download. This means that of all components downloaded with a known vulnerability, only 4% did not have an available fix. Put another way, organizations could have downloaded a non-vulnerable component 96% of the time but chose not to.

This is a problem that can be solved today. Software organizations must acknowledge their responsibility to their customers to use the highest quality open source components. As central tenets of that responsibility, enterprises must create a software supply chain that prioritizes the secure ingestion of open source components, focuses on the developer experience, and builds upon policy-based foundations and best practices. However, acknowledging organizational responsibility also requires attention to the consumption of open source software.

Improve Open Source Consumption

At the core of the White House strategy is an intention to prevent the introduction of vulnerabilities into a software supply chain. This is the first place organizations should focus. Unfortunately, most teams don’t have processes to vet or make decisions about the suppliers or parts used in the software products they develop.

A real-world example of this exists in the log4shell vulnerability. In the same report mentioned above, research showed that nearly a year after the disclosure of the log4shell vulnerability, almost 30% of all Log4J downloads were of a vulnerable version. This comes down to empowerment and explicitly building an approach to open source consumption that prioritizes the developer experience.

There are several ways to achieve this. First, organizations should ensure developers can access version data, known vulnerabilities, project health, and update metrics for open source projects and components. Next, they should provide developers with alternatives and recommendations when known vulnerabilities are present. And finally, they should develop cross-functional — Security and Software Development — open source consumption strategies to address open source software issues before products are shipped actively.

However, these only address selecting the highest quality parts from the fewest and best suppliers; vulnerabilities still occur. Organizations must also focus on active component management to successfully achieve the goals and recommendations being put forward.

Establish Software Recall Capabilities

Making applications secure from the start and secure by design solves the “96% problem” attributed to the consumption of vulnerable open source. For what remains, organizations should focus on Deming’s third principle: Continuously track every part’s location.

Almost all modern manufacturing industries have tackled this challenge with the ability to recall products. For example, the Takata airbag recall demonstrates the effectiveness of this approach. After identifying a defect in the airbags, various auto manufacturers traced the part directly to each impacted vehicle.

Compare that to software development teams today. When the log4shell vulnerability was disclosed at the end of 2022, teams scrambled to understand which applications were exposed. Unprepared development teams needed to scan their code base manually across hundreds, and even thousands, of applications. This created weeks and months of unplanned technical debt.

Despite this, many vulnerable products were still available while that research took place. Without the processes, best practices, or tools to track where the defective framework was used, teams were unaware of which applications were impacted.

In contrast, implementing recall capabilities for software products provides the same protection to the end user as a recall for an automobile. The impacted applications are quickly identified and removed if necessary until a fix is available. While this could potentially mean downtime for an application, this wasn’t the case for log4shell and certainly not for most vulnerabilities. Often a fix or stop-gap measures are provided as part of the vulnerability disclosure process.

After years of a market-led approach, increased software liability for organizations is here. While open source software has become a scapegoat, going forward, organizations can expect to be held responsible for the parts they consume and the insecure software they release. But by following some basic principles that Deming used to address auto manufacturing safety, and new White House guidelines, software providers have a solid blueprint to help them do their part to keep the software supply chain secure.