.png)
4 weeks ago
1
DISCLAIMER: This post is not meant to be xenophobic or highlight individual maintainers as risky or dangerous, this article is meant to help open a dialogue to the possibility that the software you run in production today might be “blocked” tomorrow. I doubt the data from this post will be used as an enforcement mechanism, but it is an easy avenue to highlight the potential impact.
Geopolitically, the past year has been heavily centered on tariffs and reworking physical supply chains around the world. Which leads to the question: What happens when tariffs and geopolitical tensions begin to impact the digital world? As recently as Saturday October 10th, 2025; threats of export controls on “critical software” are being discussed as a possibility. With the hope that these possibilities are merely ideas that don’t pan out. The minimum we should do as a community is begin to have discussions around what the implications of such a move and direction could mean for the software development community at large.
This post will dive into some high level data analysis of the email domains used on common open source repos (NPM, PyPi) as a proxy for understanding where software comes from. The patterns derived from this analysis offer an indirect measurement for risks in a potential future with rising geopolitical tensions. Additionally, this post will identify gaps in existing frameworks, draw parallels to other industries (e.g “substantial transformation” for international trade, KYC in banking), in the hopes of bringing this topic to the community for feedback and suggestions and further dialogue on the topic.
Data Analysis:
DISCLAIMER #2: The email address of a maintainer is not a direct indicator of 1) the country of origin 2) the country of the maintainer and 3) if the maintainer has permissions to modify the package; however, this is the best publicly available data I can put together and is used as a point of conversation. I focused on China and Russia for this post, given the tensions with the US as of late.
To kick off the investigation, I pulled the metadata of every package on PyPi and NPM, and extracted the maintainer email addresses.
NPM Analysis
The below table outlines the top 20 most commonly used email address domains of maintainers. The attached list provides a breakdown of the domains used by ~1 million NPM maintainers. Nearly 50% of maintainers make use of gmail.com (shocking, I know /s). What I did find interesting, is that #2 and #3 making up <just> 12.65% of all maintainers, using Chinese email address (qq.com and 163.com). In a similar vein, #12 and #13 are associated with .ru domains and <1% of maintainers.
Now, just looking at total number of maintainers using these email domains isn’t a good indicator of the breadth or depth of impact of a geopolitical software supply chain shock, but they are a good starting point.
For example, pay-exchange.tech is the 11th most popular email domain on NPM, and guess what? I just bought it for $25.19, woohoo!
Fortunately, every single one of the packages is associated with empty code packages used with spam, SEO stuffing attacks, or other suspicious content. (NPM team, please email me at [email protected] so we can clean up the spam packages :)).
Here’s a breakdown of packages on pay-exchange.tech
Total packages: 9,782
Total weekly downloads: 42,835
Average downloads per package: 4
Full Extract Here:
Despite a majority of these likely being NPM crawlers downloading the packages versus actual users installing these packages, 43k downloads per week isn’t world ending, it’s still large enough not to ignore.
The main point I’m calling out here is — if I can this quickly purchase the domain associated with nearly 10k software packages, imagine what a nationstate could do in a similar style?
Purchasing expired domain names to perform an account takeover of maintainers is a known problem — but what happens when a countries views the software supply chain (and associated email of a maintainer) as a pressure point or as a mechanism to control the software supply chain?
PyPi Email Domain Distribution
DISCLAIMER #3: The below analysis does not factor in linked, dev, and child dependencies which may include or rely on the below listed packages.
Here’s a summary of impact from the most common Chinese and Russian based emails:
China (qq.com/163.com/126.com/foxmail.com):
NPM
- Total unique packages: 523,888
- Estimated Weekly Downloads: ~43.5M
PyPi:
- Total monthly downloads: 18,683,456
- Daily: 418,848 | Weekly: 4,095,633 | Monthly: 18,683,456
- Average: 875 downloads per package per month
Russia: (mail.ru/yandex.ru)
NPM:
- Total unique packages: 18,889
- Estimated Weekly Downloads: ~190,000
PyPi:
- Total monthly downloads: 6,025,835
- Daily: 120,025 | Weekly: 1,554,164 | Monthly: 6,025,835
- Average 2,678 downloads per package per month
Risks to future software supply chains
Below are some high level notes on security, availability, and financial concerns and risks.
Security
- Account takeovers due to expired domains is a known problem, one that doesn’t have a great solution. To the above point, what happens when the domain takeover is due to geopolitical reasons or due to national importance/security?
- There is a well documented history of nationstates planting vulnerabilities and backdoors in software across the globe, will we see a continued rise in this over the next decade?
- There is an ever growing prevalence of supply chain attacks in recent memory such as Shai-Hulud, Chalk, Debug, and xz-utils of note, which impacted hundreds of millions of Node installations.
Availability
- What happens if you are producing code and your access to the NPM repository (or similar repository) is cut off?
- What happens if countries adopt their own region locked registries for open source? Just like region migration on cloud, will you be ready? How will the world handle version drift and feature parity?
- What if you need a bug fix and the package maintainer is no longer allowed to provide code for your dependency?
Financial
- What happens when / if code imported from other countries becomes subject to tariffs? Is there a world which “free and open source” is not longer “free”?
- Is there a world which a maintainer is now subject to taxation / tariffs?
Existing Frameworks / Parallels to Other Industries
CISA SBOM (Software Bill of Materials)
Fortunately, CISA SBOM calls for an Author and a Supplier — unfortunately, both fields are a bit ambiguous and do not call for a country of origin. Is there opportunity here for improvement? Should this be an item of importance going forward?
Author:
Supplier:
CISA SBOM Guidance on Supplier (cisa.gov)
Parallels to Physical Supply Chains:
Country of Origin / Substantial Transformation (International Trade Administration)
Tariffs are tricky to apply in a global supply chain — for example, there maybe be an import tariff on steel; but there are multiple steps along the way to make steel, that may involve several countries along the way. In the case of physical goods, the country of origin is determined based on the “substantial transformation”.
This is not a science nor a perfect way of solving where / when to tariff, but it does prevent countries from slapping a sticker on a finished product to call it a “substantial transformation” (at least when that does happen, it’s generally a violation of international trade). A valid “substantial transformation” would need to be more meaningful, such as the final refinement of ore prior to it being cooled and molded.
Can the concept of “substantial transformation” be applied to software? Is adding a test case a substantial transformation? Is adding a comment the equivalent of adding a sticker? Where is the line on what constitutes a substantial transformation? Determining Origin on physical goods is of utmost importance in global trade — is there room in the industry to adopt a similar model? Will we be forced to?
Determining Origin (trade.gov)
Parallels to KYC
Banking has a internationally recognized process known as KYC (Know your customer). The concept of KYC put simply, requires banks to perform due diligence on customers and transactions to flag and/or prevent those which may be highly regulated, illegal, or sanctioned. After years of observing the open source community, the idea likely sends shivers down the spines of many; but it may be a reality we must face in the near future — KYM (Know your Maintainer) or you may need to say No to your maintainer.
If you are interested in learning more, please send a note to [email protected] I’m always looking to collaborate, share ideas, and build cool things 🙂
Appendix:
For a quick and easy way to inspect the maintainers of a package in NPM you can run the following:
npm owner ls <package-name>If you don’t have a command line handy, I built a free and easy to use service (https://meldsecurity.com/npm) that does quick look ups of maintainers from the NPM website. You can lookup a package(s) or have it parse your package.json directly (WE DO NOT SAVE ANYTHING, IT IS A STATIC HTML PAGE, FEEL FREE TO SAVE SOURCE AND RUN LOCALLY)
(here’s a screenshot before I implemented dark mode :D)
