Every security team has a folder of CVEs it knows about and can’t fix. Not because nobody assigned the ticket, but because the fix carries more operational risk than the vulnerability itself. A dependency bump pulls in a new major version, which breaks an internal API contract, which means a sprint of regression testing nobody budgeted for. A base image upgrade jumps from Debian 11 to 12, and half the build scripts choke on a package that no longer exists in the new repo. So the ticket sits. The vulnerability stays open. And the org quietly accepts risk it never meant to accept, because the alternative is worse in the short term.
This is the actual failure mode behind most unpatched CVEs in production — not negligence, but a cost-benefit calculation that keeps coming out in favor of “later.” It’s also the gap Aikido is now building directly into its platform through Aikido Libraries and Aikido Images.
Three bad options, and why teams keep picking the worst one
Historically, a team that finds a vulnerable open-source component has three paths. Upgrade to a patched version and risk breaking production. Migrate to a vendor’s hardened, locked-down replacement and take on new dependencies and workflows. Or do nothing and carry the exposure. None of these are good, which is why AppSec backlogs grow faster than they shrink almost everywhere.
Upgrading isn’t just “run npm update” — a version bump can drag in dozens of unrelated changes, depend on releases that don’t exist yet for older ecosystems, or introduce fresh vulnerabilities of its own. Teams that have lived through a bad Log4j-adjacent upgrade know this instinctively: the fix event is scarier than the exploit event.
The scale of the problem is documented independently of Aikido’s framing, not just asserted by it. VulnCheck’s 2025 tracking of known exploited vulnerabilities found that nearly 29% were exploited on or before the day their CVE was published — up from roughly 24% the year before, and part of a broader trend of exploitation outpacing disclosure that Mandiant, CrowdStrike, and Google’s Threat Intelligence Group have all reported independently in their own 2025-2026 datasets.
And Log4Shell, disclosed in December 2021, hasn’t gone away: Sonatype found roughly 13% of Log4j downloads in 2025 were still vulnerable, and Contrast Security reported around 12% of Java applications were still running exploitable versions three years after disclosure. Not because teams don’t know about it, but because ripping it out means touching code nobody wants to touch.
What actually changed: patch the version you’re already on
Aikido Libraries and Aikido Images take a narrower, more mechanical approach than “upgrade or migrate.” Instead of pushing you to a newer package or a different base image, Aikido backports the security fix into the exact version already pinned in your lockfile or Dockerfile. The package name stays the same. The version string stays essentially the same — Aikido appends a suffix (+aikido.1 for most ecosystems, a hyphenated variant for npm) so a patched starlette 0.27.0 becomes starlette 0.27.0+aikido.1. The public API doesn’t move. Nothing forces a rewrite.
For container images, the same logic applies at the OS layer. Aikido Images swap the base image tag for a hardened build on the same distro family and major version — Debian stays Debian, Alpine stays Alpine — instead of forcing a distro or major-version jump that would otherwise cascade through every downstream image that inherits from it.
This matters most for exactly the workloads security teams dread touching: legacy services on frameworks nobody actively maintains anymore, pinned transitive dependencies nobody controls directly, and anything past its official end-of-life where the vendor has stopped shipping fixes at all. For actively developed repos where a normal version bump is low-risk, a standard AutoFix upgrade is still the faster and more sensible path — Aikido’s own positioning is explicit that Libraries is for when the upgrade itself is the obstacle, not a universal replacement for normal dependency hygiene.
The mechanics: agents generate, humans verify, upstream gets the fix too
The patch generation is built on an agent pipeline inherited from Root — a system designed to produce large volumes of verified CVE patches rather than relying on manual backporting, which is the traditional (and unscalable) way distro maintainers have handled long-term support. Aikido states it ships more than 100 new patches a day across Libraries and Images, with a response SLA of under 48 hours for actively exploited or critical/high-severity CVEs and under seven days for medium-to-low severity ones. Every patch is described as human-verified before release, and each is scoped as a minimal, inspectable diff limited to the CVE fix — not a broader refactor bundled in under the same commit.
The part worth noting for anyone skeptical of vendor lock-in dressed up as security: Aikido says critical fixes for actively exploited vulnerabilities are also contributed back upstream, across ecosystems, rather than held exclusively for paying customers. Whether that commitment holds at scale over years is something only time and the open-source community will actually verify. It’s also worth being clear-eyed that the framing of competing hardened-image vendors as requiring full migration is Aikido’s own characterization, not an independently audited comparison — some competitors in this space also offer drop-in compatible tags rather than forcing a rebase. The distinction Aikido is drawing (patch-in-place vs. migrate) is real and matters operationally, but it’s fair to treat the specific competitive contrast as marketing framing rather than verified fact.
What this means for how teams actually operate
The practical shift is that “patch” and “upgrade” stop being the same action. A team can close a CVE today without opening the larger, riskier conversation about a framework migration or an OS version jump — and have that separate conversation on its own timeline, with its own testing budget, when it’s actually warranted. Protection is also continuous rather than one-time: once a repo or image is enrolled, new CVEs discovered later get folded into daily automated pull requests without anyone re-running the process.
None of this eliminates the underlying debt of running old software. A patched CVE on an unsupported framework is still technical debt, just debt that isn’t actively bleeding. But for security and platform teams measured on mean time to remediation rather than on how modern their stack looks, that distinction is the whole point — and it’s a more honest description of how CVE backlogs actually get cleared in real organizations than most vendor pitches admit.
