Endor Labs Uses AI to Generate Targeted Fixes for Open Source Vulnerabilities

Endor Labs is aiming to shorten the path from finding an open source vulnerability to changing the code that exposes an application to it. Its AURI Fix for Open Source tool assesses reachable vulnerabilities in context and can propose a targeted code change, a dependency update or a patch. The practical question for engineering teams is whether those generated fixes are small enough to review quickly and well documented enough to trust.

That approach addresses a familiar bottleneck: vulnerability scanners can produce more findings than development teams have time to investigate and resolve. Endor Labs principal product manager Joe Harrington argues that AI-assisted discovery is increasing the volume of findings, while AI tools can also help attackers exploit weaknesses faster. He cites a mean time to exploitation of 39 days, which he says continues to fall. In that setting, adding more findings without improving remediation risks leaving teams with a larger queue rather than safer software.

Start with whether the flaw is reachable

AURI evaluates reachability, exploitability, severity and deployment context. Those checks are intended to distinguish a vulnerable component that is actually exposed through an application from one that is present but poses no practical risk in that environment. The tool can document findings it considers non-risky, giving teams context for why they may not need to make a change.

When a dependency upgrade is compatible with the application, the agent looks for what Endor Labs calls the minimum safe package version and opens a pull request. That can avoid a larger upgrade than the fix requires, though teams still need to assess the change against their own compatibility requirements and release process.

Some vulnerabilities are exposed through the way an application uses a dependency, rather than through a defect that can be resolved by updating that dependency. In those cases, engineers can use a command-line interface to invoke the Endor Labs policy engine and create a pull request for review. They can also assign the AURI agent to triage findings, choose a remediation method and apply the proposed fix.

Endor Labs says its generated changes typically involve about 10 lines of code. Small patches can make review more manageable, but line count alone doesn't establish that a fix is correct. Reviewers still need to understand what behavior the change prevents, whether it affects other code paths and how it will be tested in the application.

When an upgrade isn't enough

Updating a package can be difficult when an application pins a specific version or depends on an older interface. If an API change would create compatibility problems, or an upstream release contains no available fix, AURI can apply a backported patch or a zero-day patch. These options give teams a way to address exposure without waiting for a compatible upstream release, while adding another change that developers need to evaluate and maintain.

Replacing a dependency is another possible route. For code that is no longer maintained or has repeatedly been vulnerable, Endor Labs offers a scoring tool to help teams identify an alternative open source package. A replacement can reduce reliance on a problematic component, but it also brings migration work: teams must check how the candidate fits their application and account for any changes in behavior or interfaces.

Each fix comes with a VEX report. Harrington says the report explains why the vulnerability is no longer exploitable and supplies evidence for suppressing the finding. That record matters because remediation tools have to do more than produce code: teams also need to show why a scanner result no longer applies. Futurum Group vice president and software lifecycle engineering practice lead Mitch Ashley described the shift as moving remediation into application code. He sees the durability of the VEX evidence, including how it stands up to audit, as a key test of whether teams will trust agents to make these changes.

What Endor Labs' figures suggest

Endor Labs researchers assessed 264,643 reachable vulnerabilities in enterprise codebases. The company reports that fewer than 10% could be resolved by upgrading or patching the dependency, while 82% could be mitigated with a small application change that leaves the dependency untouched. Those figures help explain why a workflow focused only on package updates can miss many practical fixes. They describe Endor Labs' assessment, however, and don't establish that the same split will apply to every organization's codebase.

The design pairs deterministic analysis from the company's static application security testing and software composition analysis tools with AI-generated code. The analysis narrows the problem; the model proposes a change suited to the application context. That division of work may help contain the uncertainty inherent in generated code, but it still leaves teams responsible for reviewing and validating each pull request.

For engineering leaders, the value will depend on the entire remediation loop: how accurately the tool judges reachability, whether the proposed change preserves application behavior, and how much reviewer effort each fix saves. The report attached to a change may also help teams keep vulnerability records useful after a finding is resolved. AURI's central bet is that targeted application edits can close gaps that dependency upgrades leave open. Its next measure will be how reliably those edits hold up in real codebases and review workflows.