Anyone Can Patch: Why "Just Upgrade" Is No Longer Enough

*Try it yourself: https://www.root.io/workshop/vibe-coding-a-backport

I've had the chance to present Anyone Can Patch at several events recently—including an OWASP evening in Boston and at VulnCon in Arizona this week. Each time, the same themes came up in the hallway after the talk: teams are drowning in CVE noise, they're scared of supply-chain malware, and they're tired of being told the only answer is to rip the band-aid off and upgrade everything on someone else's schedule.

This post is a short synthesis of that problem space—and an invitation to go deeper.

The supply chain stopped being "someone else's problem"

For a long time, we treated dependencies as free capability: add a package, ship faster, move on. Security was often framed as "the thing scanners nag us about," and remediation as "get to a newer version when we can."

That model is breaking down for a few converging reasons.

Malware and abuse are industrializing. It isn't only classic CVEs anymore. Compromised packages, maintainer pressure, typosquatting, and automated propagation mean the mechanism of delivery is often the same pipeline you use for legitimate work: registries, CI, auto-updates, and transitive pulls. When the channel you trust becomes the channel of attack, "trust upstream implicitly" stops being a strategy.

CVE volume is not your imagination. Disclosure rates have climbed for years, and tooling plus scrutiny across ecosystems means more issues surface in code that was always there—just unreported. On top of that, we're entering a phase where AI-assisted discovery (sometimes discussed under names like Mythos in the community) can accelerate finding and weaponizing issues. Whether you love or hate the framing, the operational reality is the same: more signal, faster exploitation timelines, and more pressure on teams that were already underwater.

"Upgrade to fix" doesn't match how software is actually run. Upgrades are not free. They drag in breaking changes, transitive upgrades, flaky tests, and calendar risk. Security wants closure; engineering wants stability. When those goals collide, the default answer—"just get current"—often means "accept unknown regression risk in exchange for a CVE checkbox." That trade is rational sometimes. It is not rational every time.

Pinning is necessary—but it isn't sufficient

One of the first things I emphasize in Anyone Can Patch is that pinning dependencies is table stakes. Reproducible builds, clear provenance, and a deliberate upgrade boundary all start with knowing exactly what you shipped.

Pinning is also uncomfortable because it freezes reality: you now own a specific graph of versions, and the world keeps moving. CVEs accumulate against those pins. Scanners keep screaming. Leadership asks for a date. Engineers ask for time.

So pinning answers: what are we running? It does not, by itself, answer: how do we remediate without blowing up the product?

That gap is where a lot of organizations stall.

Building from source is part of the puzzle—not the whole picture

Building from source (or otherwise controlling artifacts end-to-end) is a good hygiene move. It can reduce blind trust in prebuilt binaries and improve auditability.

But source does not remove the dependency problem. It shifts it.

You still consume upstream logic. You still inherit maintainers' priorities, their refactors, their release cadence, and their threat model—which is not identical to yours. Building from source without a patch and validation discipline can accidentally become "we compiled the vulnerability ourselves."

What teams need is not a single silver bullet. They need a system: inventory, pinning, policy, testing, and a way to apply minimal security changes when upgrades are not the right immediate move.

Backported patches: security without forced migration

Backporting is not exotic. Distros and serious operators have done it for a long time: take the security-relevant intent of a fix and apply it to the version you actually run, then validate.

What is newer is that the economics of doing this well—across languages and ecosystems, at scale—are finally starting to change. Agentic workflows and better tooling can make "research → apply fix → validate" a repeatable team habit, not a heroic one-off.

That's the core workflow behind Anyone Can Patch: treat patching like engineering, not like roulette. Understand the CVE, understand the upstream fix, reason about what belongs in your pinned line, prove it with tests and review, and keep the blast radius small.

Control, comprehension, and staged change

If there's a single takeaway I want engineering and security leaders to share, it's this: we need to control and understand the software we build—not in a philosophical sense, in an operational one.

That implies a few practices that sound boring until you don't have them:

• Know your graph. If you can't answer "what depends on what, at which exact versions," you can't reason about risk or blast radius.

• Plan upgrades. Treat upgrades as projects with budgets, test matrices, rollback, and sequencing—not as an ambient background radiation of semver churn.

• Stage remediation. Sometimes the right order is "patch in place, validate, buy time," then "schedule the upgrade that modernizes the stack." Sometimes the opposite. The point is to have options that don't all collapse into "latest or bust."

Scanners and SBOMs help you see. They do not, by themselves, give you agency when upstream velocity and your business constraints diverge.

Go deeper: the ebook

I turned a lot of this material—including framing, tradeoffs, and a hands-on mindset for dependency control and backported fixes—into an ebook aimed at practitioners who want a clearer map of the terrain than "install Dependabot and hope."

Read it here: https://www.root.io/workshop/vibe-coding-a-backport.

If you're responsible for shipping software in the real world—where deadlines, legacy, and transitive dependencies all exist at the same time—I wrote it for you.

Thanks to the communities hosting these conversations

Thanks to the organizers and attendees at OWASP Boston, VulnCon Arizona, and the other venues that hosted Anyone Can Patch recently. These problems are only solvable when security and engineering talk in the same room, with the same vocabulary, and with tooling that respects how software is actually built.

If this resonates, share it with someone who owns dependency risk in your org—and tell me what you disagree with. The best part of these events is always the hallway debate.