The National Cybersecurity Strategy released by the Biden Administration 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 cant 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 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 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 . 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 , organizations should follow three critical principles to improve the quality and security of their supply chains: Source parts from fewer and better suppliers Use only the highest quality parts; dont pass defects downstream 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, dont 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 Demings 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 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 dont 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 , almost . 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