Has Your Software Supply Chain Already Been Compromised?

Software supply chain attacks have dominated headlines since the SolarWinds attack, closely followed by Log4j and numerous other incidents that continue to get media attention. However, in practice, software supply chain incidents do not tend to dominate daily security reports and alerts. This tendency leads some to write off the threat as industry buzz and fear-mongering, but the unfortunate truth is that threats to the most vulnerable part of the software supply chain—the open source ecosystem—are accelerating. And the odds are that if you are compromised via this entry point, it’s very likely that you don’t know.

Understanding the Attack Surface

Consider the current environment and how software development tends to work:

1. Developers write software on their workstations. During this process, they typically install, run and upgrade thousands of third-party software components, most of which are open source.
2. After some iteration, developers submit the work they’ve done for peer review. At this point, the work they’ve iterated on will be tested in the background. This process of automated testing and evaluation will similarly involve the installation and execution of thousands of third-party, open source components.
3. Finally, assuming the updates and changes are accepted, the new code will be merged in. Once “feature complete,” this set of changes, along with the others contributed by the rest of the team, will move into production. This build and release approach, yet again, will lead to the introduction of thousands of third-party, largely open source components and end up in the final application.

Each of those steps can be compromised in a software supply chain attack, and the compromises are often silent. This creates a black box of code that blocks visibility for the security organizations; source code goes in and software emerges, with very little oversight into how the proverbial sausage is made.

Under the hood, these black boxes store incredibly sensitive components: Production environment credentials, AWS keys, database secrets and more. This means that the impacts of undetected software supply chain breaches will often be felt far downstream, through data breaches, infrastructure compromises and other harmful outcomes.

The Software Development Process is Full of Security Blind Spots

Consider, for example, the case of ua-parser-js, an extremely popular JavaScript package. It is used by a massive number of organizations including some well-known names, and boasts tens of millions of weekly downloads. Roughly a year ago, the maintainer of this package was compromised and malware was inserted. This malware was primed to steal credentials from millions of consumers downstream. All users were subject to compromise, but the majority had no way of knowing until the malware was broadly reported.

This scenario is not unique. After a known breach is reported, real panic sets in for security teams. Companies are left to answer: How many software developers across those companies have installed a malicious version of that package? Have any sensitive company credentials been stolen? Which of those could result in a future breach? These questions challenge security teams to find ways to fix blind spots without impeding innovation.

Open Source Threats Are Not an Endpoint Problem

Open source malware is, by and large, very different from endpoint malware. While traditional endpoint, EDR and XDR products have evolved to combat malicious software arriving through conventional channels, they do nothing to block software supply chain threats from infiltrating and spreading via open source packages.

Your instinct might be to apply endpoint products to developer workstations and CI/CD infrastructures. However, in addition to being tricky to implement, those solutions are also not effective at preventing software supply chain threats. The behaviors, packaging and other indicators-of-compromise those solutions are designed to detect simply don’t apply in many cases to this new breed of attack. Enforcing the use of endpoint security products can also create even more friction between developers and security teams by slowing the development cycle.

Don’t Remediate, Alleviate

By now, you’re probably thinking, “This sounds exhausting; I don’t need more tools that give me more alerts to deal with.” So, rest assured, that is not what I am suggesting. Here are a few steps you can take to alleviate issues associated with software supply chain risks and address risks before they become an issue:

1. Avoid implementing tools and policies that create friction with your developers. It’s not that developers don’t care about security, but they will find ways around ‘solutions’ that get in the way of doing their jobs. Create open lines of communication, involve developers in decision-making and consider the adoption of tools and policies as a key success indicator.
2. Don’t believe all the hype. While software supply chain attacks are a real issue, the media buzz has resulted in some vendors making false claims on how to best address the threats. We already discussed the downfalls of taking an endpoint-only approach, but also be careful not to assume that SBOMs alone are good enough, or rely on application scanning once code is already in an application. This will not block threats and will only add more remediation to your workload as threats increase.
3. Embrace DevSecOps to shift further left. Look for ways to automate processes and enforce best practices at every stage of the development life cycle. Integrate solutions into the tools developers are already working in, rather than adding extra steps and environments into their workloads. Make security a seamless, consistent part of all builds.

I hope this advice helps you cut through all the industry noise around software supply chain security. Success will require maturing your AppSec program which will require effort and resources, but putting it off might make you the next headline.

Image source: max-bender-XIVDN9cxOVc-unsplash_770x513 (1)

Avatar photo

Aaron Bray

Aaron Bray is co-founder and CEO of Phylum, The Software Supply Chain Company. Prior to founding Phylum, Aaron spent the past 15 years working at the intersection of software development and cybersecurity across the DoD and large Fortune 500 enterprises.

aaron-bray has 1 posts and counting.See all posts by aaron-bray