Your Dependency Graph Is a Liability You Haven’t Priced Yet

You have never sat down and calculated the cost of your dependencies. Not really.

I am guilty of this too. I have spent years treating `go.sum` and `package-lock.json` as infrastructure the kind of thing you commit and forget until something breaks loudly enough to wake you up. The problem is that the breakage is getting quieter and more deliberate.

John McBride wrote There is no secure software supply-chain and used the Gorilla web toolkit as his anchor. Gorilla was quietly archived after years of being embedded in production Go services everywhere. No CVE, no incident, no alarm. Just gone. The people responsible for maintaining code that thousands of systems depended on burned out and walked away. I have those in my stacks. You have them too. We just have not looked.

The instinct after reading something like that is to reach for tooling. Scan more aggressively. Automate the PRs. Trust the robot to keep the graph green.

Filippo Valsorda, who maintains cryptographic libraries for Go and who files the kind of advisories that keep security people awake at night, wrote Turn Dependabot Off. He describes filing an advisory for a vulnerability in a method that almost nobody calls, and watching Dependabot open thousands of PRs across the ecosystem — including one against a repository that does not even import the affected package. That is not security tooling. That is noise generation dressed as due diligence. His replacement is simpler and harder to argue with: `govulncheck` on a schedule, plus a test suite run against the latest dependencies. Signal-heavy, low ceremony.

But disabling Dependabot does not solve the upstream problem. It just makes you less reactive to one class of false alarm.

William Woodruff’s argument in We should all be using dependency cooldowns is that the window of a supply chain attack is usually short — days, not months. The axios compromise was live for four hours and hit packages with 100 million weekly downloads. A seven-day cooldown between publish and install blocks most of that class of attack for almost no cost. Empirically, it works.

Cal Paterson’s rebuttal in Dependency cooldowns turn you into a free-rider is the sharpest thing I have read on this topic in a while. He does not say cooldowns fail. He says they only work if someone else gets hit first. You benefit from their pain, their incident report, their three-day outage. Individually rational. Systematically broken. Classic tragedy of the commons, and the kind of argument that does not have a clean answer because he is right.

So: automated PRs create noise, cooldowns externalize the cost, and staying current by hand does not scale. Three approaches, three failure modes, no obvious synthesis.

Then there is the layer most people are not talking about yet.

Mark Seemann wrote Secret agentic AI and the scenario he describes has stayed with me since I read it. Adversarial actors set up shell companies running subsidized LLMs, fine-tuned to subtly introduce vulnerabilities into the code they generate. You use the tool, it produces plausible, clean, reviewable code, and somewhere in it is something that will matter later. The attack is upstream of the package registry entirely.

The threat is not that the model makes mistakes. The threat is that the model is working exactly as intended — by someone else.

Seemann’s point does not depend on LLMs being unreliable or non-deterministic. It works even if the model is perfect. That is what makes it sharp. SolarWinds did not fail because someone ran a bad scanner. It failed because a trusted build process was compromised by someone who understood exactly how trust works and where to stand inside it.

There is also a related shift happening at the contributor layer. dpc wrote I don’t want your PRs anymore, arguing that for a solo maintainer, LLM-generated code is now faster, more style-consistent, and carries less trust risk than a PR from an unknown contributor. The tradeoff that made open source contributions valuable has changed. If the code comes from an agent, you know exactly what model generated it. If it comes from a GitHub account with three commits and no history, you do not. I do not fully agree with this position but I understand why someone is making it.

All of this converges on the same problem: the dependency graph is a trust graph, and we price it like it is free.

It is not free. It is just that the cost arrives irregularly, at 2am, during an incident you did not anticipate, in a package you forgot you were using. The XZ Utils backdoor in 2024 was not a dependency scanner problem. It was a multi-year social engineering campaign against a burned-out maintainer. Filippo Valsorda has written about maintainer burnout as a supply chain risk, and he is correct — the human layer is exactly where the leverage is.

I do not have a clean framework to offer here. Govulncheck plus a cooldown plus careful agentic tooling selection is a better posture than Dependabot plus nothing. But none of it addresses the structural problem that McBride names clearly: security is a people problem, and we have systematically underfunded the people.

What I would ask you to do is open your dependency graph, pick five packages, and try to answer: who maintains this, when did they last commit, and would I know if they archived it tomorrow?

If you cannot answer that, you have not priced the liability. You have just chosen not to look at the invoice.