Your real dependency is somebody's maintenance capacity, and it is rented
Serguey Asael Shinder3 min readThree items today, read together, are about the same thing: not what your software depends on, but who has time to maintain it.
Quarkus shipped an emergency release on both LTS streams. Two dozen CVEs. Three of them are Quarkus; eleven are Netty and eight are zstd-jni. No application team chose zstd-jni. It arrived.
Rust opened a funded full-time position for the Cargo team, and the announcement says why with unusual bluntness: some members left, and others "lost their dedicated funding for working on Cargo maintenance and had to scale down their involvement."
AWS introduced a 36-month support line for Spark on EMR.
Put those in order and the shape appears. The dependency you audited is not the one that will hurt you. The dependency nobody is paid to maintain is.
A dependency graph is a graph of obligations you did not enter into. Your build resolves Netty because Quarkus needs it, and the security posture of your HTTP boundary is now partly a function of how well-staffed the Netty project is. You can read the CVE list, but you cannot read the staffing. That is the part with no dashboard.
"LTS" is a claim about future capacity, not about code. AWS promising 36 months of critical fixes is a promise that someone will still be there to backport, with a qualifier worth rereading — critical and high severity, subject to availability. Quarkus's LTS stream is the same promise, and today it was honoured, at the cost of an unscheduled release on a Tuesday. Both are real. Both are people.
The work that funded maintainers do is the work volunteers correctly defer. Look at what Rust's new Cargo maintainer already did: moving compiler diagnostics onto annotate-snippets, years of effort, no user-visible feature when it landed, and the reason the Cargo linting system could be built at all. That is exactly the shape of task that never wins against a bug report on a Saturday.
So what follows, practically.
Count your transitive surface once, honestly. Not to remove it — you cannot — but to know it. If you had to name the five projects whose maintainer availability most affects your production security, could you? Most teams name their direct dependencies and are wrong.
Treat an emergency release as a signal about the tree, not just a patch. Today's told you that Netty's HTTP protocol handling had a bad month. That is worth knowing about every service you run that speaks HTTP through the JVM, not only the Quarkus one.
And when a vendor offers a long support window, price the qualifier. Three years of critical fixes is genuinely valuable and is not the same as three years of maintenance. The gap between those two sentences is where upgrade work you did not plan for lives.
The uncomfortable version, and I think it is the true one: most of the software your business runs on is maintained by people whose funding you do not control, whose names you do not know, and whose departure you will learn about from a CVE. The Rust post is unusual only because it says so out loud.