You're almost out of time on an SLA on a critical dependency vulnerability, but you have no room in the current sprint for the manual testing needed to make sure you don't break production. Missing the remediation deadline itself is a finding in your next SOC 2 or ISO 27001 report, but the risk of exploitation is also growing with advancing AI models. You are left with two bad choices: slow down product development to patch this vulnerability or explain to your security team and other stakeholders why you broke an important SLA.
If the above scenario sounds familiar you aren't alone. Organizations are falling further behind in the race to close known vulnerabilities and meet their security SLAs. A study by Verizon, released in 2026, shows that vulnerability exploitation is the number 1 cause of confirmed breaches, overtaking stolen credentials for the first time in the report's nearly 20 year history.
Remediation continues to lose ground due to an explosion in identified vulnerabilities. From the same Verizon report: only 26% of known exploited vulnerabilities (KEVs) were fully remediated in 2025, down from 38% the year before, while the median remediation time grew to 43 days, up from 32 the year prior. The Verizon report attributes this to organizations having 50% more critical vulnerabilities to patch.
Why does this keep happening
It's not crazy to expect that, as the importance of vulnerabilities increases, more resources would pour into the problem and the fixes would keep up. But, if you are working in this space, you know that this just hasn't been the case. There are two primary reasons why this problem is getting worse instead of better:
- A huge portion of dependencies are essentially unmaintained, but buried too deeply in production systems to just tear out or easily move to a newer major version. Think
log4j. - SLA policies, and compliance programs don't care whether there is an active maintainer.
What teams do today: the stages of SLA grief
When time runs out, most engineering teams cycle through a predictable loop of bad options. It looks a lot like the classic Kübler-Ross grief model.
Denial: Most teams start off by waiting for an upstream patch, but there is no guarantee when, if ever, the maintainer will patch the vulnerability. Some maintainers fix within days or less, while others don't. This problem is exacerbated for widely used, but effectively unmaintained packages with effectively no owner. Waiting just burns down your SLA clock, without fixing the vulnerability.
Anger: Rip out and replace the problematic dependency. It looks like a real fix, and it probably is for today. But when the new package version takes a CVE next month and another the month after that, you are stuck in a cycle of replacement that costs your team real time on building the product. It's rarely the act of replacing the package version itself that really costs you, it's all the adjacent work to comply with dependency audits, verify API compatibility, and run tests to make sure you don't break critical application functions in production.
Bargaining: As the SLA clock ticks down you decide to file for an exception. This buys you more time to find a solution, but it doesn't solve the underlying problem. The ticket is off your dashboard for today, but you know it will come back around. Worse, it will surface as a finding the next time an auditor or a customer security team looks at the remediation log. One time probably is survivable, but when you build up a pattern of exceptions, this can be worse than a single missed SLA deadline.
Depression: The final option is to backport the security patch yourself. This option is a real solution, if you can dedicate the time to understand the CVE, isolate the fix, and cherry-pick it into the existing codebase. The downside is that you now own this patch and all future patches on this library moving forward. It's a resource commitment that likely diverts away from your team's core mission.
The fix: Aikido Libraries
If we followed the metaphor to the end, the final stage would be acceptance. Giving up and taking the compliance hit, or risking a break. Don't accept it. Aikido Libraries breaks this cycle.
Aikido Libraries delivers patched versions of your vulnerable dependencies. The package name and public API stay put. The only change is a suffix marking the patch and a pin to Aikido's registry.
Every patch starts from the maintainer's own fix. Aikido lifts the upstream security change, applies it to the version you run. Adjustments are only made where the older runtime needs it. Each one is tested automatically, then reviewed by a person, and ships as a diff you can read in full before you merge.
The patch transparency matters for trust. You aren't getting Aikido's proprietary fix for the vulnerability, but the maintainer's fix adapted to your version, with the full diff, if you want to inspect it.
Let's look at a concrete example. The library version jsonwebtoken 8.5.1 has a CVE-2022-23529 rated as High. The Aikido Libraries version becomes jsonwebtoken 8.5.1-aikido.5 and backports the security fixes from jsonwebtoken 9.0.0 onto 8.5.1. The change is additions: new key-validation files, one carrying a compatibility shim for the older Node runtime. Upgrading to 9.0.0 for the same fix would have meant a major release that dropped older Node support and changed how verify() handles unsigned tokens.
The Aikido Libraries catalog currently has more than 9,000 secure libraries across JavaScript, Python, Java, .NET, PHP, Go, and Ruby. We are also shipping 50-100 new patches each day. For enrolled repositories we ship patched secure libraries within 48 hours for known exploited vulnerabilities and within 7 days for Critical and High CVEs.
Turn it on once
Aikido Libraries works two ways. For a single package, it is an option in the existing AutoFix menu: close a CVE without upgrading, one PR at a time. For a repo, activation pins your dependencies and ships a daily AutoFix PR for CVEs disclosed after you turn it on. You can activate it for a single important repo, or your entire codebase from the Aikido UI.
None of this locks you to the secured build. Upgrade whenever you want the newer API or features, and you'll still get the CVE fixes that ship with it. Closing the CVE and changing the version stop being the same decision.
Meet your SLAs every time
Point Aikido at a repo and it returns your first merge-ready PR against a real CVE in a few minutes. Explore the catalog to see which of your dependencies are covered, or protect a repo to get your first patch.
