The uptick in high profile supply chain related attacks through the early months of 2026 have led to a lot of conversations about securing your supply chain. Overall this is great, it has been an overlooked area of security for quite a long time, and package manager ecosystems have definitely not been resourced appropriately to address the risks they pose to the global software supply chain. But one “solution” I’ve seen people bring up time and time again is that you would be protected if you just built the dependencies from source. Or you would be protected if you use our product that builds the dependencies from source. This seems to be a great example of capitalism’s ability to capitalize on fear, uncertainty and doubt.
Building a project from source improves your security in one specific way - it allows you to verify the exact source code going into your project. I don’t want to understate the importance of this - it is extremely valuable to know exactly what source code is going into your project.
But hash-based dependency lock files also allow you to verify the Editor's Note: this is considerably less true for opaque dependencies like DLLs or other pre-compiled software artifacts - but most discussions I've seen recently are around javascript, python, and other languages that distribute source. - without needing to manage your own build, deploy, and hosting pipelines for every one of your dependencies.
One might go on to argue that building from source allows you to verify the build environment so you can trust it. This is true, and again, a very valuable thing to know about the code supporting your projects.
OIDC-based package publishing workflows also allow you to verify the build environment. Albeit to a lesser degree, sure - the workflow that published a package could be deleted or force-pushed to have the history overwritten. But it gives a useful, largely unadopted mitigant to some classes of supply chain problems.
One might go on to say “We sign all of our software builds and our downstream only trusts signed dependencies.” Awesome work. Very cool. Much wow. Integrity verification of your software supply chain is critical.
But one question - Where are you keeping those signing keys? Who is responsible for signing every single dependency that goes into your build? Is it your automated toolchain for managing hundreds or thousands of dependencies? Oh those keys are available from any workflow in your toolchain? Congratulations, you’ve taken the scenic route to the same supply chain compromise.
There are market incentives for companies to create their own source of trust for organizations, such that you fetch your dependencies from SupplyGuard LLC, and trust that SupplyGuard is safe and secure. SupplyGuard can position itself well to attempt to proactively identify and mitigate security issues before they arise.
But when your supply chain grows to hundreds, or thousands of dependencies, you start to have a bit of a problem. You either have to start fetching your dependencies directly from upstream because SupplyGuard can’t provide everything you need, or SupplyGuard needs to scale to support it’s thousands of customers, all of whom need their own dependency trees covered.
If you go directly to the upstream, you’ve mitigated some of the attack surface, but you’ve inherently gone directly to the upstream for less popular dependencies, which are far less likely to have robust security built into their build process.
If you instead rely on SupplyGuard to fetch it all, SupplyGuard now has a scaling problem and has to automate the fetching and downloading of source for every supported version of every dependency of every customer. Sure there will be a lot of overlap, but there is also a very long tail. Anything short of automating this will leave customers complaining.
Automating the fetching of the upstream dependencies and rebuilding them in a “controlled” environment immediately reduces how much one should trust the resulting output. An attacker in the supply chain could publish some binary artifact directly to a package repository, sure. But they are equally as capable to publish some malicious source code into the package repository, and now your automated “secure” dependency manager has once again taken the scenic route to a supply chain compromise.
This raises an interesting idea, though - if I were SupplyGuard, I might think to myself “In order to reduce the risk for our customers, we will automatically scan all the source we download to look for security problems, thereby providing an extra layer of trust.” Sure enough, I could run semgrep across every dependency I build and maybe if I get a certain number of issues of a certain severity, I hold off on building. But now, as SupplyGuard, am I going to go submit upstream patches to fix all of this software? Probably not. How do I programmatically determine the difference between software that is vulnerable and software that is malicious?
I do not want to spend this entire piece constructing and attacking hypotheticals. What I am trying to call out is that at the end of the day, the software supply chain ecosystem is inherently built on trust. You can shuffle that trust around all you want in the world’s most complicated game of 3 card monte, but you still need to be able to place your trust somewhere.
To handle your scale problems, you need automation.
To automate, you need to create automatic trust systems.
Short of actually reviewing every dependency before build, you are going to have to place your trust somewhere.
Whether that trust is placed in John from Wyoming who has painstakingly managed that one open source dependency 6 layers deep in your dependency tree, or in a company who is profiting off of John’s work by repackaging it and adding a “Norton Secured” badge to it, or in your own ability to build, maintain, and scale your supply chain infrastructure, is up to you. But you’re still making that trust decision.
I would argue that the only economical choice is to support the open source developers you’ve built your business on, and maybe thinking carefully about whether you’re actually getting any additional trust out of any extra systems you bolt on top.
New posts in your inbox when they're published. No spam, unsubscribe any time.