Security1 publisher2 min readPublished
Legit Security expands remediation agent to patch open-source dependency vulnerabilities
Legit Security's remediation agent now fixes vulnerable open-source dependencies, transitive ones included, as well as first-party code. Its proof of a fix is a scanner re-run, so build and behavior checks stay with the team that merges the pull request.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Until this release, the agent fixed only static analysis findings in code written by a company's own engineers.
- For a dependency fix it updates the configuration and regenerates the lockfile, including other copies of the vulnerable version elsewhere in the tree.
- Each fix is re-scanned before and after the change, and only then does the agent open a ready-to-review pull request carrying the vulnerability details.
- Source code changes proposed for major-version upgrades are AI-assessed, not independently verified, and the company says the pull request flags them.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- cost Breakage from an automated bump still has to be caught by the customer's own CI and reviewers, so the customer keeps paying review time on every merged fix.
- exposure Teams that merge major-version pull requests on the strength of the scan alone ship AI-written application code that no independent check has covered.
- precedent A pull request that separates scanner-verified changes from model-assessed ones gives buyers a disclosure format to expect from other vendors' remediation agents.
Legit Security's release is defensive tooling and discloses no vulnerability, so an attacker's options this week are the same as last week's [2]. The company's case for it is speed. It said the hard part is now "getting from finding to fix fast enough" [10]. It also said AI-generated code has multiplied the volume of software shipping daily, while attackers use AI to find and exploit flaws faster than defenders can respond [11].
Version selection is conservative. The agent identifies the vulnerable package, its current version and whether it is a direct or transitive dependency [3]. It then picks the smallest version bump that resolves the issue, staying inside the current major version where possible to avoid breaking changes [4]. Legit says transitive findings are where backlog work by human teams falls furthest behind, because the vulnerable code sits several layers deep in a third-party package [12].
In this release, "verified" means the scanner agrees. A clean second scan shows the scanner no longer flags the dependency. Whether the application still compiles and passes its tests is left to the reviewer and the team's CI [1]. As reported, the announcement does not name supported package ecosystems, describe a build or test step, say how the agent treats a parent package that pins the vulnerable version, or include fix rates or customer results [13].
Major versions add a second layer. When a fix crosses that boundary, the agent evaluates how the specific repository uses the package and proposes changes to the repository's source code, validated against real repository and package data [8]. A major-version pull request is therefore two review jobs: a dependency bump the scanner has cleared, and AI-written edits to the team's own code that only the model has assessed [9].
For teams carrying a transitive backlog, the lockfile and re-scan steps are now a reasonable thing to require of any vendor selling automated fixes [5][6]. A guarantee that the bump does not break the build is a separate request [1]. The evidence that the workflow runs as described is Legit's own account, as reported by Help Net Security [1].
What to watch
- Whether Legit publishes which package ecosystems the agent covers and how it handles a transitive package pinned by its parent.
- Customer merge or rejection rates for the agent's dependency pull requests, the first evidence beyond the vendor's own description.
- Whether the verification step expands to run the repository's build and test suite before a pull request opens.