The Unacknowledged Risk of Authors

One of the largest (and most oft ignored) attack surfaces across the software supply chain is also one of the most obvious: package maintainers. While problems around maintainer account compromises are by no means a new issue, shockingly little has been done to really bring attention to this part of the problem space.

This sort of issue has now come to the forefront as authors are now actively being targeted in large-scale phishing campaigns.

Today we received reports of a phishing campaign targeting PyPI users. This is the first known phishing attack against PyPI.

We’re publishing the details here to raise awareness of what is likely an ongoing threat.August 24, 2022

The Attack Surface

So, what does this sort of risk vector even mean in terms of exposure? The unfortunate fact is that it creates a massive attack surface: While most organizations realize that users are frequently targeted across an enterprise, few, if any, realize that their entire upstream software supply chain is effectively vulnerable as well - and the majority of those who could be targeted are outside of their realm of control.

To make matters worse, this not only includes the thousands of package maintainers a typically project (not enterprise, but project) may rely on, but also includes a vast array of other artifacts as well - each package likely has a full suite of CI/CD infrastructure and testing tools, each component of which will in turn have authors and packages that it depends upon.

In essence, we now have tens of thousands of potential points of entry in our software supply chain: Not only do we have substantial risks around our internal employees - who we can at the very least train, and have some technical and administrative insight into, but we are also facing exposure through a massive network of third-party contributors - many of whom are likely hobbyists. On top of the covert issues surrounding account compromises and phishing campaigns, there are also further risks in these areas - how many maintainers are from areas facing geopolitical instability? How many are overtly employed by known nation-state-affiliated actors, or criminal organizations?

What This Means

What this really highlights is that reactive analysis is not nearly enough; as we are fundamentally trusting the operational security practices of thousands of unknown third parties from across the globe, manually inspecting and identifying issues in all of these assets we are intrinsically trusting is already a lost cause. From a more traditional vendor-risk-management perspective, this sort of thing would never pass muster - in fact, nearly all certification requirements (such as SOC2) would flag this sort of thing near-instantaneously during audit, yet there are no real controls - either technical or administrative - applied to this risk vector aside from simple vulnerability management.

This becomes increasingly important as release cycles become more rapid: Now, analysis of third-party packages is not a snapshot-in-time problem any longer - it has now become a continuous problem. Large enterprises may release hundreds or thousands of builds per day, with automation baked into every layer of every release; this means that a compromise resulting in malicious code being added to a popular package could easily result in at least dozens of compromises across an enterprise before anyone even realizes that there is an issue - if it is even caught at all.

Addressing the Problem

In order to get ahead of issues that emerge from this domain, we clearly need better guard rails around use of open-source assets. These controls absolutely must account for developer behavior, and proactively identify issues before they can make their way onto developer workstations, into build pipelines, and even into production.

This exact set of scenarios is essentially why we founded Phylum - to provide comprehensive, near-real-time protection against upstream software supply chain attacks. Register for a free account today to get in front of attacks before they become security incidents!