Agent Workflows for Dependency Upgrades and Security Patches

Software runs on other people's code now. Black Duck's 2025 OSSRA report puts open-source components in 97% of commercial codebases, and 81% of those codebases carry at least one high or critical vulnerability sitting in that open-source layer. The real trap is the direct dependency list, which usually looks fine on a quick scan but hides the danger elsewhere. It's the transitive layer underneath it, the packages your packages depend on, where most of the actual risk lives. A single JavaScript project can pull in more than 1,000 packages once you count those, and almost nobody's looking at them.

So this isn't an awareness problem. Security tools already tell teams what's broken. The bottleneck is what happens after the alert fires, and 85% of security pull requests go unmerged, not because nobody saw them, but because no team can route, triage, and fix that volume by hand. That gap between "flagged" and "fixed" is what this piece is about, and closing it is the whole job agent workflows exist to do.

How slow remediation translates into breach exposure

Attackers move fast. Defenders don't, and the numbers show exactly how much daylight sits between them. Industry averages put remediation of high and critical vulnerabilities somewhere between 43 and 55 days in 2025. Attackers weaponize a disclosed flaw in about 15 days. That gap, roughly a month, is where breaches actually happen.

Worse, the trend is moving the wrong direction. Veracode's 2025 numbers show average fix time climbing to 252 days, up 47% since 2020, even as the problem has grown more urgent over that same stretch. Edgescan's 2025 data shows mean time to remediate critical application vulnerabilities at 74.3 days, and that number balloons for complex enterprise stacks. Java and.NET shops are looking at 5 months and 10 days, mostly because compatibility testing and uptime requirements slow every step down.

Vulnerability exploitation now ranks as the second most common breach vector, responsible for 20% of all breaches, up 34% year over year. The median number of publicly tracked, known-exploited vulnerabilities organizations had to patch rose to 16 in 2025, up from 11 the year before. Nearly 50% more known, weaponized flaws landing on the same desks, with no more people hired to handle them.

Slow fix cycles don't just pile up technical debt. They open a window of a fairly predictable size, and attackers already know how to find it.

What rule-based update bots do and where their ceiling is

GitHub's Dependabot is the tool most engineers already know. It covers more than 30 package ecosystems and opens a pull request the moment it spots an outdated or vulnerable dependency. It's picked up real features over time. Grouped updates shipped in August 2023, a minimum package age check arrived in July 2025, and a default three-day cooldown period is set to land in July 2026, alongside malware alerts across eight ecosystems going GA that same month.

Renovate, built by Mend, plays the same game with more dials to turn. It supports more than 90 package managers across GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, and Forgejo. Its Dependency Dashboard (on by default with the config:recommended preset) gives teams one view of pending updates, and its scheduling options let you set update windows, cron-like timing, and automerge rules, so patch and minor versions merge on green CI while major versions wait for a human. Shared config presets let an organization standardize dependency policy across every repo it owns.

Renovate wins on control, especially in monorepos. Dependabot wins on setup speed, since its defaults already make sense out of the box. Both are free: Dependabot ships inside GitHub, and Renovate's hosted app costs nothing, with self-hosting available under the AGPL-3.0 license.

The ceiling demands blunt treatment. Renovate's maintainer, writing under the handle rarkins, said in January 2025 that "Renovate is not the right tool for transitive vulnerabilities." The feature that used to attempt transitive remediation doesn't exist anymore. A discussion proposing it reopened in 2026 and, as of this writing, still hasn't shipped.

The deeper issue lies elsewhere, beyond a missing feature. It's structural. A major version bump can break API calls, deprecate methods, or change type signatures across a codebase, and a rule-based bot has no way to diagnose any of that, let alone fix it. It opens the pull request. Whether the build breaks afterward is somebody else's problem. That handoff, right at the edge of what a bot can reason about, is exactly where agent workflows take over.

How an agent workflow picks up where the PR bot stops

Picture a relay race. Dependabot or Renovate runs the first leg: spot the vulnerable version, surface the alert, open the PR. A coding agent takes the baton from there, working out why the build failed, tracing that failure to its root, and proposing the actual code changes needed to fix it.

GitHub built this handoff directly into the platform. As of April 7, 2026, teams can assign a Dependabot alert straight to an AI coding agent (Copilot, Claude, or Codex) right from the alert page. The agent reads the security advisory, checks how the vulnerable package gets used in the repo, opens a draft pull request with a proposed fix, and tries to resolve whatever test failures the update caused. Teams can assign more than one agent to the same alert and compare the draft PRs side by side. Using this requires GitHub Code Security and a Copilot plan with coding agent access, and it's live on github.com.

Three things separate this from a rule-based bot. It fixes actual breaking changes when an update snaps the build or the test suite, instead of just flagging that it happened. It can downgrade a package once that package turns out to be compromised and no patched version exists yet. And it writes the kind of layered pull request a rule engine has no logic to produce at all.

The workflow shape, while it varies by implementation, generally moves from scanning and triage through code changes and a draft PR, into CI validation, and finally to merge and deployment.

What actually shifts is the human's job. Before, tooling found the alerts and engineers did most of the routing and fixing by hand. Now tooling finds the alerts, a human decides who owns the fix, an agent does the first pass, and a human reviews it before anything ships. The engineer moves from doing the work to checking the work, and GitHub says as much in its own documentation: AI-generated fixes aren't always right. Agents can miss edge cases, ship incomplete patches, or introduce new bugs. Review the PR. Check that tests actually pass. Skipping that step just because a machine typed the code is how things break later.

Multi-agent architectures and the feedback loop that handles complex upgrades

Some upgrades need more than one agent working in sequence, not because it looks impressive, but because a single pass can't hold the whole problem in its head. LADU, a framework described by Tawosi, Alamir, Liu, and Veloso (ASE 2025, arXiv:2510.03480), handles automated dependency upgrades in live Java codebases using three parts. These are a Summary Agent, a Control Agent, and a Code Agent. It pairs LLM reasoning with actual migration documentation to propose changes and check they don't break compatibility.

The loop is the interesting part. The project compiles, the tests run, and if something errors out, the logs go back to the Control Agent for another pass, an Automated Program Repair cycle: apply changes, compile, test, review the output, repeat, until the build actually passes clean. LADU reports 71.4% precision while burning fewer tokens than comparable approaches, which is the trade-off the whole field is chasing: get the fix right without spending a fortune in compute to get there.

That same loop pattern shows up elsewhere. Repair Agent (Bouzenia et al., 2025) runs an autonomous bug-repair pipeline that manages several repair tools at once through a dynamically updated prompt coordinated by a finite-state-machine layer, and it fixed 164 defects at low cost. NVIDIA's Agent Morpheus, part of a broader vulnerability-remediation workflow, reports a 9.3x speedup in vulnerability processing by pulling real-time data from OWASP and NVD through retrieval-augmented generation, which helps it separate real risk from false positives buried in tangled dependency trees. The same loop pattern supports pipelines that run end to end, from the moment a vulnerability gets flagged to a tested pull request sitting in review.

The loop is what ties all of this together: compile, test, log the failure, retry. That feedback cycle is what separates an agent workflow from a bot with a bigger vocabulary.

Evidence-based prioritization, how agents decide what to fix first

An agent that fires a PR for every advisory in the feed just rebuilds the alert-fatigue problem in better prose. Volume without triage is noise wearing a lab coat.

Reachability analysis is the actual fix, and it's the part most teams skip. It traces the call graph and checks whether the codebase ever invokes the vulnerable function in question, so automation focuses on dependencies carrying real exposure instead of every CVE that happens to mention an installed package name. That's the direct answer to the transitive-dependency problem from the opening: most of that risk is invisible to manual review, and reachability analysis is what makes it visible without flooding engineers with PRs for code paths nobody ever runs.

Upgrade impact analysis works the other side. It maps what a version bump actually touches before anyone merges it, so teams can tell an upgrade that'll hold from one that quietly breaks a downstream service three weeks later. And when no clean upgrade path exists, a backported patch can close the CVE without forcing a disruptive major-version jump, so a blocked upgrade doesn't have to mean the vulnerability just sits there indefinitely.

Endor Labs bundles versions of all three, with tooling that handles reachability filtering and upgrade impact analysis on one side and backporting on the other. Legacy systems and performance-critical paths stay the hardest cases no matter what tooling gets thrown at them. Undocumented dependencies in an old system break in ways no changelog ever predicted, and a patch that looks harmless in CI can quietly tank performance in production. Prioritization logic that only checks a CVE severity score misses both failure modes completely.

Production case study: Form3's Patch Pilot and the security model for agent-modified code

Form3 built a system called Patch Pilot, presented by Moritz Johner at AI Engineer World's Fair, aimed at dependency patching, with a specific eye on the supply-chain risks that show up once an agent starts touching production code.

The design splits work into two lanes. Deterministic tasks, the ones with one right answer and no judgment call needed, go to a deterministic orchestrator. Everything that needs actual reasoning goes to an LLM agent. Not every step in an upgrade pipeline gets better by having a language model guess at it, and Form3's architecture reflects that directly instead of routing everything through an agent by default.

That split rests on controls designed to limit unintended behavior. The agent's execution environment is kept isolated from production systems, and the deterministic-versus-agentic split itself caps how much autonomy the agent gets to the steps where it actually earns it.

The lesson underneath all three is that governance matters as much as capability, maybe more. An agent that can open pull requests, run test suites, and rewrite code across a repository is also an agent that, misconfigured or compromised, can push changes at that exact same scale. Even highly automated pipelines benefit from keeping a human at the merge gate for anything security-critical. Letting an agent work autonomously and letting it deploy autonomously are two different decisions, and the failure mode here is simple: treat them as one, and things go wrong.

Supply-chain risks that agent workflows introduce if not designed carefully

Agents don't just inherit the existing supply-chain risk. They stack a new layer on top of it. Endor Labs' State of Dependency Management research for 2025 found that across PyPI, npm, Maven, and NuGet, 49% of dependency versions imported by AI coding agents carried known vulnerabilities, and another 34% didn't exist at all: hallucinated package versions no registry has ever heard of.

That's not a one-off glitch, either. Kaspersky's 2025 research found leading language models recommended the wrong dependency version in 27% of cases, and a large share of hallucinated package names repeated consistently across separate queries, predictable enough for an attacker to plan around. That predictability is the entire basis of slopsquatting: watch what names AI coding assistants keep hallucinating, register those names on the real package registry, and wait. It doesn't take exploitation skill. It takes a free npm account and a little patience.

The volume of malicious packages published to open registries has grown sharply. An agent that installs and runs whatever it's told to install amplifies that exposure automatically, no malicious intent required on the agent's part. Prompt injection compounds it further: any changelog, README, or advisory the agent reads is a place an attacker can plant instructions, and every external source the agent consults widens that surface a bit more.

A survey of agentic security research (arXiv:2510.06445, Bouzenia et al.) makes the underlying point sharply: wrapping a language model in an agentic framework, giving it tools, memory, room to act on its own, measurably increases how exploitable it gets, because the safety training baked into the base model doesn't reliably survive the handoff to real autonomy. The failure modes aren't purely theoretical either. Legacy Java modernization projects fail in 73% of enterprise deployments, according to one industry guide, and that failure rate is part technical, part governance: teams that automate without the right controls in place run straight into those failure modes instead of the speed gains they were chasing.

None of this makes agent workflows unsafe by nature. It means the risks need deliberate design choices, not default settings left untouched.

What makes an agent dependency workflow safe and effective to operate at scale

Four decisions shape whether an agent workflow actually holds up in production, and skipping any one of them costs you later. It's a bet against the odds laid out above.

Tool selection and handoff boundaries come first. Decide explicitly which steps stay rule-based and which get handed to an agent, the way Form3 split deterministic work from agentic work rather than routing everything through a language model by default. Scheduling and grouping matter just as much: ship security patches the moment they land, batch minor versions on a routine cadence, and hold major versions for a human to actually look at. Test gating isn't optional. Nothing merges on a failing build, feature flags wrap anything risky, and rollback triggers stay armed. Agent sandboxing and prompt-injection defenses need to be built in from day one, not bolted on after something breaks.

Model-agnosticism matters more than it sounds like it should. A workflow locked to a single AI provider inherits every failure mode and every pricing decision that provider makes, whether anyone likes it or not. Teams that can swap models and run their own infrastructure keep control over cost, latency, and where their data actually lives, and that's a governance call as much as a technical one.

Before scaling any of this past a pilot, visibility into what the agent's actually doing has to come first: what it opened, what it changed, what it merged, and why. Speed isn't the metric that matters here. The workflow worth trusting is the one where every fix can be traced back to a decision somebody can actually explain.