Routine vulnerability fixes are rarely difficult in isolation. The interruption that they cause is the problem: pick up the ticket, trace the dependency, update the package or image, regenerate files, run the checks, open the pull request, then return after deployment to close the loop.

That repeated handoff was a good candidate for automation with agentic pipelines. The goal was simple: start the day with a tested pull request instead of another ticket to pick up.

The problem with routine work

Security vulnerability patching is high-consequence but repeatable. Each routine update competes with planned work and creates a steady interruption tax across the sprint, even when the engineering decision is straightforward.

The workflow combines Jira Automation, a custom dispatcher and closer, Bitbucket Agentic Pipelines, Rovo Dev, and Atlassian Model Context Protocol (MCP) tools. Jira Automation schedules the work. The dispatcher finds and groups eligible tickets. Agentic Pipelines runs the coding agent inside the repository’s build environment, applies the code change, runs the checks, and opens the pull request. Engineers review the diff and decide whether to merge. After deployment, the closer verifies that the fix is live and updates the ticket.

In 3 months, an Atlassian team reported more than 120 vulnerabilities resolved and more than 55 agent-created pull requests merged. Ninety-five percent of those pull requests were merged on the first run, without rework or failed tests.

What surprised us was not that the agent could edit code. It was how much easier the work became to trust once the full job had a reviewable path and a clear stopping point.

Why vulnerability patching was a good place to start

The best candidates for agentic automation are not necessarily the biggest jobs. They are the jobs with a clear entry condition, repeatable decisions, deterministic checks, and an obvious definition of done.

Routine vulnerability remediation had all four:

1. A ticket described the affected package or image and the required safe version.
2. A limited set of fix patterns covered much of the work.
3. The repository’s build and test suite could verify the change.
4. A pull request gave an engineer a familiar control point before anything reached production.

That last point mattered. We did not ask the agent to decide whether a change should ship. We asked it to prepare the change and the evidence an engineer needed to make that decision.

How the whole flow works

We separated the core automation into a dispatcher, a coding agent, and a closer. Each job has a narrow purpose and its own permissions. Jira Automation starts the workflow, while the existing delivery system and engineers remain responsible for merge and deployment.

Component	Responsibility
Jira Automation	Starts the scheduled workflow
Custom dispatcher (Agentic Pipeline)	Applies eligibility and grouping rules, then starts Coding Agents in parallel for the batches.
Coding Agent (Agentic Pipeline)	Updates the repository, runs the checks, creates a branch, and opens a pull request
Existing CI/CD and engineers	Govern review, merge, and deployment
Custom closer (Agentic Pipeline)	Verifies the deployed commit and updates the Jira ticket

1. The dispatcher finds work worth automating

The dispatcher is scheduled to start automatically before the working day. The dispatcher searches for vulnerability tickets inside the configured patch window, then makes four decisions:

• Is the ticket eligible for an automated fix?
• Does it share an underlying dependency change with another ticket?
• Which tickets should be grouped into one run?
• Which items need human judgment instead?

Every ticket receives an explicit outcome. It is dispatched, grouped with related work, or left for manual handling. Nothing disappears into an agent run with no record of what happened.

2. The coding agent prepares the pull request

For every eligible batch, the dispatcher starts an Agentic Pipelines run. The coding agent receives the ticket context, checks out the repository, and follows codebase-specific instructions stored beside the code.

Those instructions describe the real decision tree an engineer would use. A direct dependency may need a version bump. A transitive dependency may require its parent to be upgraded. A platform-managed package may need to be flagged rather than changed. A base image follows a different path again.

The agent applies the appropriate change, regenerates generated files when needed, and runs the full build and test suite. If the checks fail or the fix falls outside the encoded patterns, the run stops and reports why. If they pass, the agent creates a branch and opens a pull request.

The pipeline definition, prompt, and reusable skill are all versioned in the repository. A simplified definition looks like this:

definitions:
  agents:
    vulnerability-fixer:
      provider: rovodev
      prompt: "!.rovodev/prompts/vulnerability-fixer.md"

pipelines:
  custom:
    fix-vulnerability:
      - step:
          name: Apply fix and open pull request
          auth:
            system:
              scopes:
                - write:repository:bitbucket
                - read:pullrequest:bitbucket
                - write:pullrequest:bitbucket
          script:
            - agent: vulnerability-fixer

This configuration makes the agent part of the same delivery system as the build. It has the repository checkout, the build tools, and only the Bitbucket permissions required for that step.

For more details on the implementation visit this post.

3. The closer verifies that the fix is live

Opening a pull request is not the end of vulnerability remediation. The ticket should move only when the fix has actually been deployed.

After deployment, the closer checks that the matching pull request was merged and that the deployed build contains the expected commit. Only then does it transition the ticket for scanner verification. If the evidence is incomplete, the item stays open.

The closer can run repeatedly without duplicating actions or closing the same work twice.

How this improved our dev-loop

Engineers moved from scanning vulnerability tickets and finding sprint capacity to fix them, tracking vulnerable dependencies or images, making changes and running checks, opening PRs, and manually updating tickets to a simpler agentic workflow. Agentic pipelines now handle everything from investigation to implementation and testing, PR creation, deployment verification, and ticket updates, leaving engineers to review the change and approve the PR when satisfied.

The work did not become invisible. It became easier to inspect where engineering judgment mattered most.

What are the learnings, and how you can apply it

The first prompt was not the finished system. Reliability came from tightening the workflow after real runs and treating prompts and skills as production assets.

These practices made the biggest difference:

Make the instructions specific to the codebase: Store the dependency patterns, file locations, build commands, and known exceptions the agent will actually encounter. Generic instructions produce generic fixes.

Keep verification deterministic and human-controlled: The agent can prepare a change, but the existing build, tests, branch protections, and required reviews still decide whether it is safe to merge. Model output should not become a release gate by itself.

Fail safely and make reruns harmless. When the build fails, the dependency pattern is unfamiliar, or deployment evidence is missing, stop with a clear handoff. Use tickets, labels, branches, pull requests, and deployment state to prevent repeated runs from duplicating work.

Keep access narrow and attributable. Grant write scopes only to the steps that need them, and use dedicated provider credentials where required. This makes automated work easier to recognise and audit without weakening existing human controls.

To apply the pattern, start with one repeatable job in one repository that already has reliable checks. Define the eligibility rules and manual exceptions, encode the codebase knowledge in a repository-owned prompt or skill, and use first-run failures to improve the instructions.

Vulnerability patching is just one example. The same pattern can work for dependency maintenance, stale feature flags, documentation updates, and flaky-test fixes.

Try it now with Bitbucket Agentic Pipelines

Agentic Pipelines is currently in beta for Bitbucket Cloud. You can run agents with Rovo Dev as the Atlassian-managed provider, or use Claude Code or Codex with your own provider account.

For Rovo Dev, you need a paid Bitbucket Cloud account with Pipelines enabled and a paid Rovo Dev Standard subscription. Agentic steps use normal Pipelines build minutes and the selected provider’s model usage.

Choose one repeatable repository task with reliable checks and a clear human review point. Start with the Agentic Pipelines overview, follow the step-by-step guide, and review the authentication and security guidance before granting write access.

If you use Claude Code or Codex, review the third-party agent provider guidance to understand data handling, provider terms, cost, and responsibility for agent output.

Pick one bounded task. Automate it. Then share what worked, what didn’t, and what you would automate next in the Agentic Pipelines discussion on Atlassian Community.