In October 2025, the open source ecosystem hit a sobering milestone: 300,000 vulnerabilities. And with AI-driven code agents like CodeMender and Aardvark, that number will only grow faster. AI also accelerates exploitation, what used to be days or months, now might take minutes or hours.
The good news: fixes already exist.
The bad news: getting them into your stack is still a major challenge, and we are clearly losing the race.
Why Consuming Fixes Is Hard
Modern applications aren’t simple. They rely on complex dependency chains. A single vulnerable package can ripple across dozens of services.
Challenges include:
- Coordination headaches: Upgrades often require multiple maintainers to act in sync - rare in practice.
- Breaking changes: Traditional upgrades can cascade, breaking downstream services.
- Approval bottlenecks: Even GenAI-assisted upgrades need human testing and approvals.
- Because of all this, upgrades are not for free, and require substantial efforts, certainly if done on a regular basis.
Upgrade too frequently, and you risk instability. Delay, and vulnerabilities remain open to exploitation. As highlighted in When Exploits Take Minutes, Patching Can’t Take Months, attackers move fast - sometimes faster than patch cycles.
Remember: Complexity kills security. More dependencies, more services, more AI-generated code - more risk.
GenAI Doesn’t Solve Everything
Generative AI accelerates development, but approvals are still required.
Imagine 50 services relying on a single vulnerable package. Updating them manually - in many cases requires adopting your own application code to accommodate the changes - is slow, error-prone, and expensive.
The solution is clear: remediate vulnerabilities at the source package level, not individually across every service.
Real-World Example: A Lightweight, Repeatable Process
Traditionally, fixing a vulnerability across multiple microservices would require:
- Coordinating upgrades across 50 services, potentially modifying your own application code
- Testing for breaking changes, modifying your own code to accommodate & repeat until stable
- Managing cascading updates
- Waiting for approvals
With Resolved:
- A single replacement safely excludes the vulnerability across all services
- No breaking changes, no cascading upgrades
- Minimal impact: the drop-in replacement is a tiny patch on the original package - much less content than a full upgrade, reducing risk and surface area for errors
- Safe, repeatable, lightweight process, ready to use across your stack with minimal intervention
This turns weeks of work into a single, predictable action, allowing teams to focus on building features instead of chasing vulnerabilities.
Examples of Remediated Vulnerabilities
Here are vulnerabilities already addressed and ready to deploy safely:
- A highly exploited vulnerability in jQuery (CVE-2020-11022)
- A CISA KEV Vulnerability in spring-beans (CVE-2022-22965)
- A highly exploited vulnerability in mongoose (CVE-2024-53900)
- A CISA KEV vulnerability in grpc (CVE-2023-44487)
- A Critical Vulnerability in databind (CVE-2020-8840)
Fast. Easy. Safe. Resilient. That’s how Resolved keeps your stack secure without breaking anything.
Concluding Thoughts
The problem isn’t discovering fixes - it’s consuming them. With Resolved, you can patch vulnerabilities safely, predictably, and with minimal changes, even in an ecosystem where complexity often kills security.
