In the ever-evolving landscape of cybersecurity, software supply chain security has fast become a critical concern for public and private organizations worldwide. And with good reason, as crippling high-profile attacks of recent years have shown just how vulnerable entities are and the level of damage they can cause.  In this blog post, we explore the journey of software supply chain security, from its humble beginnings to its current status as an essential component of modern software development, and take a historic look at Software Bills of Materials (SBOMs) and the significant role they can play in delivering a new era of application security.

 

The Old Days: Blissful Ignorance

Before the now-infamous Log4Shell vulnerability rocked the industry, little attention was paid to the potential risks lurking in the complex web of dependencies that modern software relies on. Software supply chain security rarely crossed the minds of most developers and security professionals and  SBOMs were in their infancy, primarily used for obscure niche activities like license compliance. Even the term “software supply chain” was unknown to most practitioners, and those who had heard of the concept mostly associated it with DevOps practices, such as build pipeline automation. .

This period of relative blissful ignorance left many organizations vulnerable to attacks that exploited weaknesses in the software supply chain, setting the stage for a rude awakening.

 

From Log4shell to XZ Utils: Awakening to Vulnerability

In 2021, Log4Shell – a serious vulnerability that made it possible for malicious code to be inserted in software by threat actors – served as a wake-up call for application developers and security teams. This critical flaw in the widely used Log4j library exposed countless systems to potential exploitation. To make matters worse, most security teams couldn’t even tell what applications were affected without spending a huge amount of time and effort re-scanning all of their software assets. 

In the aftermath, SBOMs gained recognition as valuable tools for security teams, allowing the concept of software supply chain security to take root and  transcend “the chasm” of the technology adoption curve.

Despite the increased awareness, however, many organizations struggled to see an immediate return on investment in SBOM management. For example, although SBOMs provided increased visibility, they did not solve the problem. Furthermore, they actually made the problem seem worse, since organizations were now more aware of how much open source they are using and how many unpatched vulnerabilities existed in their applications. 

The magnitude of the problem meant that simply “patching faster” wasn’t going to be enough. In addition, the relative rarity of large-scale zero-day events made it challenging to justify significant spend on supply chain security initiatives.

 

 

The Technology Adoption Curve

At this stage, SBOMs and related supply chain security measures found themselves in the early majority phase of the technology adoption curve. While no longer considered cutting-edge, these practices had yet to demonstrate their full potential in preventing and mitigating security incidents.

 

The Next Wave: Holistic Supply Chain Security

The March 2024 compromise of the XZ Utils project suddenly highlighted the shortcomings of current software supply chain tooling. Organizations realized that it’s not enough to simply know what’s in your software, or even to have comprehensive insight into its known vulnerabilities. To get to the next level, security teams need to get proactive and start vetting the open source building blocks of their applications. 

In this emerging model, the SBOM is merely the starting point, not the end unto itself. The factual information in the SBOM becomes a roadmap, and the next generation of tools will use these clues along with massive datasets about the open source ecosystem to produce new insights that were previously hidden. In other words, instead of the whack-a-mole-patch-everything approach of old, we can use SBOMs to zero in on the most dire threats in the software supply chain and come up with real, actionable solutions.

In the case of XZ these tools could have highlighted many warning signs about the project. Case in point, there was a longtime single maintainer for a project that, while relatively low-profile, is crucial to the operation of other extremely vital tools, such as systemd. Then, suddenly, a new maintainer emerged who had virtually no traceable footprint outside of this single project. As it turns out, this suspicious pattern resulted from a sleeper agent who played a long game to inject a backdoor into this component, making a long-theorized nightmare scenario very, very real. In this case, disaster was averted by a combination of extreme diligence on the part of a curious engineer and a huge dose of good luck. But can we count on that next time?

Instead of hoping to get lucky, a more robust approach requires:

• A shift toward securing the entire software supply chain, not just individual components.
• The emergence of next-generation tools that leverage SBOMs as a foundation for deeper analysis and insights.
• The integration of artificial intelligence and machine learning to process vast datasets and uncover hidden patterns and potential threats.

These advanced tools are still in the early-adopter stage, positioned to the left of “the chasm” on the technology adoption curve. However, they represent a significant leap forward in our ability to secure software supply chains.

 

The Future of Software Supply Chain Security

The problems confronting software supply chains today are ones that require next-generation tooling. To outmaneuver threat actors, organizations must have a way to thoroughly analyze their SBOMs, map out all the different components in their environment, surface actionable current threats, automate remediation, as well as highlight the potential future threats – not just in terms of who is contributing to your software, and what misdeeds they’re up to. With this approach, security teams and application developers spend less time chasing false alarms and more time on hardening their infrastructure and outsmarting would-be attackers. 

As we look further into the future, all these trends will continue. We’ll see more and more automation in security assessments and risk mitigation, as there is no way for humans to keep up. Industry standards and government regulations will become more explicit as best practices become more widely recognized. Organizations that embrace these advanced tools and practices will be better positioned to defend against sophisticated supply chain attacks and maintain the integrity of their software ecosystems.