Agentic Remediation Just Got Bigger: Now Fixing Vulnerabilities in Your Dependencies, Not Just Your Code

CVEs are piling up faster than security teams can triage them, let alone fix them. AI-generated code has multiplied the volume of software shipping every day, and open-source dependencies make up most of any modern codebase. Every new package pulled in is a new door for a known vulnerability to walk through, and attackers are using AI to find and exploit those doors faster than defenders can respond. The longer it takes to determine what matters and get it fixed, the longer critical vulnerabilities remain exposed.

The find-it, fix-it model that AppSec has run on for two decades wasn't built for this. It assumes a backlog that gets worked down over time by humans. That assumption breaks the moment code generation outpaces code review, and it breaks completely when the vulnerable line isn't even in your own code, it's three layers deep in someone else's package. Finding the vulnerability is no longer enough. The real challenge is getting from finding to fix fast enough.

Legit's Agentic Remediation started by fixing what engineers wrote themselves, static analysis findings in first-party code. Today it takes on the other half of the problem: vulnerabilities introduced through dependencies. By taking those vulnerabilities all the way to a verified fix, the agent reduces the manual work between detection and remediation and helps teams close critical exposure faster. Same agent, same standard, a bigger surface.

From detection to a verified fix

Point at a vulnerable dependency and the agent works through the whole path from finding to fix:

• Understands the dependency. Identifies the vulnerable package, its current version, and whether it's declared directly or pulled in indirectly by something else in the tree.
• Finds the safest upgrade. Looks for the smallest version bump that resolves the issue, staying inside the current major version whenever it can to avoid unnecessary breaking changes.
• Applies the fix. Updates the dependency configuration and regenerates the lockfile, including checking for other copies of the vulnerable version still sitting deeper in the tree.
• Verifies it. Re-scans the dependency before and after the change.
• Opens a PR. The developer gets a ready-to-review pull request with the fix and the vulnerability details attached.

That verification step is the part worth sitting with. This isn't a suggestion engine telling a developer which version to install and hoping for the best. Every fix gets re-scanned to confirm the original vulnerability is actually gone and that the change didn't quietly introduce a new one. The agent doesn't open a PR until both of those hold true. What a developer receives isn't a recommendation, it's a change that's already been checked.

When the fix isn't a small bump

Not every vulnerability resolves inside the current major version. When the safe path crosses a major version boundary, the risk shifts from "is the vulnerability fixed" to "did this break the application," since major upgrades can carry breaking API changes.

Here the agent brings in an AI-assisted layer that looks at how the repository actually uses the package and evaluates the breaking changes that matter for that specific codebase. Where needed, it proposes the source code adaptations required to move to the new version, validated against the real repository and package information before anything goes into the PR.

This is where Legit draws a hard line worth being explicit about: the dependency fix itself is verified through re-scanning, the same as any other remediation. The code adaptation for a major version jump is AI-assessed. The PR makes that distinction visible, so a developer knows exactly what's been independently checked and what deserves a closer look before merging.

Part of a bigger cycle

This is Agentic Remediation doing what it was built to do, closing the gap between a finding and a safe, verified fix, without waiting on a human to work through a backlog one ticket at a time. First-party code and open-source dependencies are two sources of the same problem: vulnerabilities entering software faster than manual review can keep up. Fixing both, and feeding what's learned back into how code gets written in the first place, is how an AppSec program actually keeps pace with AI-speed development instead of chasing it.