Skip to content

Add agentic workflow: Proactive Dependency Auto-Remediation for Dependabot PRs #23268

@Henry-Shan

Description

@Henry-Shan

Proactive Security Auto-Remediation Workflow

Problem

When Dependabot opens a PR for a dependency update (especially major versions or security patches), the update often introduces breaking API changes that cause CI to fail. These PRs then sit open, unmerged, and the security vulnerability remains unpatched — sometimes for weeks — until a human developer manually fixes the breakage.

An agentic workflow can close this gap by automatically detecting test failures on dependency update PRs, tracing them to breaking API changes, and refactoring the project code to adapt.

Use Case

  • Dependabot opens a PR bumping axios from 0.x to 1.x
  • CI fails because the API changed (e.g., axios.defaults.baseURL → different config pattern)
  • The agent reads the changelog, identifies the breaking change, refactors the call sites, commits the fix, and comments on the PR explaining what it did
  • A human reviewer can now review and merge a green PR instead of doing the migration themselves

Implementation Plan

Please implement a new agentic workflow file at .github/workflows/dependency-auto-remediation.md:

1. Frontmatter Configuration

---
description: |
  Intercepts dependency update PRs (e.g., Dependabot), runs the test suite,
  and automatically refactors project code to fix breaking API changes
  introduced by the updated dependency.

on:
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:

permissions:
  contents: write
  issues: read
  pull-requests: write
  checks: read

network: defaults

tools:
  github:
    lockdown: false
    min-integrity: none
  terminal:
    allowed-commands: ["npm", "yarn", "pytest", "go test", "cargo test", "npm run test", "make test"]

safe-outputs:
  mentions: true
  allowed-github-references: []
---

Key decisions:

  • Trigger: pull_request with opened and synchronize types, so it runs when Dependabot opens a PR and when new commits are pushed
  • Permissions: contents: write to commit fixes, pull-requests: write to comment on the PR
  • Terminal commands: Include common test runners across ecosystems (npm, yarn, pytest, go test, cargo test, make test)
  • No create-issue in safe-outputs since this agent modifies code and pushes to PRs directly

2. Agent Prompt (Markdown Body)

The prompt should instruct the agent to:

  1. Gate on PR author — Confirm the PR was created by dependabot[bot] or another known automated dependency tool. If not, exit gracefully with a comment like "Skipping: not a dependency update PR."

  2. Analyze the update — Read the PR diff to identify:

    • Which dependency is being updated
    • The old and new version numbers
    • Which files changed (e.g., package.json, go.mod, requirements.txt)
  3. Research breaking changes — Search for the changelog or release notes of the updated package to identify documented breaking API changes between the old and new versions.

  4. Detect the project's test runner — Inspect the repo for package.json (npm/yarn), go.mod (Go), requirements.txt/pyproject.toml (Python), Cargo.toml (Rust), or Makefile to determine the appropriate test command.

  5. Run the test suite — Execute tests using the terminal tool. Capture full output including error messages and stack traces.

  6. If tests pass — Leave a PR comment: "All tests pass with this dependency update. No breaking changes detected." Exit.

  7. If tests fail — Auto-remediate:

    • Parse error logs to identify failing test files and error messages
    • Trace failures to call sites of the updated dependency
    • Refactor the code to adapt to the new API
    • Re-run tests
    • Repeat (max 3 iterations) until tests pass or the agent determines the breakage is too complex for automated remediation
  8. Commit and report:

    • If fixed: Commit changes to the PR branch with a message like fix: adapt to <package>@<version> API changes
    • Leave a PR comment explaining:
      • What breaking changes were found
      • Which files were modified and why
      • A brief summary of the refactoring logic
    • If unable to fix: Leave a PR comment explaining what was tried, what failed, and suggest manual intervention areas
  9. Guardrails:

    • Never modify test files to make tests pass (fix the source code, not the tests)
    • Never remove or skip tests
    • Never modify the dependency version itself (that's Dependabot's job)
    • Limit code changes to files that directly import/use the updated dependency
    • Cap remediation attempts at 3 iterations to avoid infinite loops

3. Style Guidelines

  • PR comments should be analytical and concise
  • Explain the why behind each code change so reviewers can verify the logic
  • Use code blocks in comments to show before/after comparisons
  • If the agent cannot auto-fix, provide actionable guidance for the human developer

4. Testing Considerations

  • Test with a mock PR that bumps a package with known breaking changes
  • Verify the agent correctly skips non-Dependabot PRs
  • Verify the agent commits to the correct branch (the PR branch, not main)
  • Verify the guardrails (agent should refuse to modify test files)

5. Follow Guidelines

  • Use console formatting from pkg/console for any CLI output
  • Follow error message style guide: [what's wrong]. [what's expected]. [example]
  • Run make agent-finish before completing
  • Validate the compiled workflow output

Why This Matters

Security patches should not be blocked by API breakage. This workflow turns Dependabot from a "notification system" into an end-to-end remediation pipeline — aligned with gh-aw's goal of making agentic workflows handle real engineering tasks autonomously.

Labels

  • enhancement
  • workflow

Metadata

Metadata

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions