> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Auto-Fix & Patches
> Automatically generate fix patches and pull requests for detected vulnerabilities
## How It Works
ZeroPath can automatically generate code fixes for detected vulnerabilities and open pull requests with the remediation. The system analyzes the vulnerability context, writes a targeted fix, and presents it for your review before any changes reach your codebase.
* **AI-generated patches** — fixes are generated by an AI agent that understands the vulnerability, the surrounding code, and the appropriate remediation pattern.
* **Human-in-the-loop** — by default, patches require explicit approval before a PR is created. You review the diff, approve it, and ZeroPath opens the PR.
* **Both SAST and SCA** — code-level vulnerabilities get code fixes; dependency vulnerabilities get version bumps with proper lockfile updates. Auto-fix PRs are supported for both SAST and SCA findings, so dependency vulnerability patches follow the same review-and-merge workflow as code fixes.
## Requesting a Patch
Open any finding in the ZeroPath dashboard.
Click **"Generate Patch"** on the issue detail view. ZeroPath generates a git diff targeting the vulnerability.
Review the proposed changes in the dashboard.
Click **"Approve Patch"** to create a PR, or use the **Adjust Patch** workflow to regenerate. When regenerating, you can provide free-form feedback (up to 4,000 characters) to guide the fix toward a specific approach, and optionally request multiple variants at once. ZeroPath generates up to three distinct patch candidates — each using a different fix strategy — and presents them for review. Select the candidate you want to promote; the others are discarded. See [Patch Variants](/docs/platform/scanner-settings#patch-variants) for details.
When enabled in scanner settings, patches are generated automatically for qualifying findings:
* **Full scan auto-patching** — after a full scan completes, patches are queued for findings above the configured score threshold. Only findings that have been explicitly confirmed by validation are eligible for auto-patching — findings with an unknown or inconclusive validation state are not patched, preventing unverified code changes from being proposed to your repository. This applies equally to SCA findings: a dependency finding must carry a **Confirmed** verdict (from reachability analysis or manual investigation) before a patch PR is opened, so dependency patches are subject to the same fail-closed gate as code fixes.
* **PR scan auto-patching** — during PR scanning, fix suggestions are generated and posted as inline code suggestions directly in your pull request. Apply them with one click in your VCS review UI. As with full scans, only confirmed findings are eligible for fix suggestions.
## Automatic Pull Requests
When you approve a patch (or when auto-PR generation is enabled), ZeroPath:
1. Creates a new branch from your repository's default branch.
2. Applies the fix as a commit with a descriptive message.
3. Opens a pull request with:
* A clear title describing the fix (e.g., *"Fix SQL injection in user authentication handler"*)
* A description structured in two sections: a **Fix** section with a one-sentence summary of what the patch does and a short bulleted list of the concrete changes, followed by a **Details** section with the vulnerability description, root cause, and patch implementation. Both sections use plain Markdown so the body renders correctly in your VCS and in the ZeroPath UI.
4. Links the PR back to the finding in ZeroPath for tracking.
### Requesting Follow-Up Changes on GitHub
After ZeroPath opens a GitHub patch PR, reviewers can request changes by
commenting on the PR with `@ZeroPath` and a concrete
description of the edit. If ZeroPath can verify that the current PR branch is
the patch branch it created, it commits the requested change to that same branch
and replies with a summary and commit reference.
```text PR comment theme={null}
@ZeroPath Please add a regression test for empty usernames
```
If the branch cannot be verified, the branch moved while the request was being
prepared, or the request is unsafe, ambiguous, impossible, or unrelated to the
patch, ZeroPath replies without pushing a commit. See [Bot
Commands](/docs/scanning/bot-commands#github-patch-pr-changes) for details.
**Supported VCS platforms for auto-PR:**
| Platform | Auto-PR Support |
| - | - |
| GitHub (Cloud & Enterprise) | Yes |
| GitLab (Cloud & Self-hosted) | Yes |
| Bitbucket (Cloud & Data Center) | Yes |
### PR Lifecycle Tracking
ZeroPath tracks the status of generated PRs:
* **Open** — PR has been created and is awaiting review.
* **Accepted** — PR was merged. The associated finding is automatically moved to **Resolved**.
* **Rejected** — PR was closed without merging.
## What Can Be Auto-Fixed
### Code Vulnerabilities (SAST)
The AI agent can generate fixes for most code-level security issues, including:
* SQL injection
* XSS
* Path traversal
* Command injection
* SSRF
* Insecure cryptography
* Missing authentication/authorization checks
* and more...
Some vulnerability types are **not auto-fixable** and will be marked as such:
* Hardcoded secrets (require manual rotation and migration to a secrets manager)
* Complex business logic issues (race conditions, multi-system authorization)
* Architectural issues where the root cause is outside the affected file
When a finding cannot be auto-fixed, ZeroPath now provides **remediation instructions** explaining why the fix could not be generated and what manual steps you should take to resolve the issue.
### Dependency Vulnerabilities (SCA)
For vulnerable dependencies, ZeroPath:
* Queries package registries for the latest non-vulnerable version.
* For **direct dependencies**: updates the version in your manifest file and regenerates the lockfile using the appropriate package manager.
* For **transitive dependencies**: updates the direct parent dependency that pulls in the vulnerable package.
Supported ecosystems for dependency patching:
* npm / Node.js
* Go modules
* Rust / Cargo
* Ruby / Bundler
* Python / Poetry
* Python / pip
* Maven / Gradle
* and more...
## Configuration
Patch generation settings follow org/tag/repo-level inheritance:
| Setting | Default | What It Controls |
| - | - | - |
| **PR scan auto-patching** | On | Generate fix suggestions for PR scan findings |
| **Full scan auto-patching** | Off | Auto-generate patches for qualifying full scan findings |
| **Full scan auto-PR creation** | Off | Automatically open PRs without human approval |
| **Full scan patch threshold** | 80 | Minimum priority score (0–100) for auto-patching |
| **Full scan PR threshold** | 80 | Minimum priority score for auto-PR creation |
| **PR title template** | — | Custom template for generated PR titles |
| **PR description template** | — | Custom template for generated PR descriptions |
| **Branch name format** | — | Custom template for fix branch names |
| **Commit message format** | — | Custom template for fix commit messages |
### Jira Ticket References in Templates
When a finding has a linked Jira ticket, you can reference it in your PR title, PR description, branch name, and commit message templates using the following placeholders:
| Placeholder | Substituted With |
| - | - |
| `{jira_id}` | The Jira issue key (e.g., `PROJ-123`) |
| `{jira_title}` | The Jira issue title |
| `{jira_url}` | The full URL to the Jira issue |
For example, a branch name template of `fix/{jira_id}/{vuln_class}` would produce a branch like `fix/PROJ-123/sql-injection` when the finding is linked to a Jira ticket. If no Jira ticket is linked, the placeholders are omitted and the template is filled with the available vulnerability context only.
### SCA-Specific Settings
| Setting | Default | What It Controls |
| - | - | - |
| **Auto-create direct dependency PRs** | Off | Auto-open PRs for direct dependency CVE fixes |
| **Direct dependency patch threshold** | 0 | Score threshold for direct dep auto-PR |
| **Auto-create transitive dependency PRs** | Off | Auto-open PRs for transitive dependency CVE fixes |
| **Transitive dependency patch threshold** | 0 | Score threshold for transitive dep auto-PR |
## Troubleshooting
### GitHub Actions Workflow Permission Error
If a patch modifies a GitHub Actions workflow file (under `.github/workflows/`), PR creation may fail with a permissions error. GitHub requires the **workflows** permission to create or update workflow files via API.
To resolve this:
* **Manually apply the patch** — copy the suggested changes and commit them yourself.
* **Have a repository administrator create the PR** — admins with sufficient permissions can push the workflow change.
* **Grant the workflows permission** — if your organization policy allows it, add the `workflows` permission to the ZeroPath GitHub App installation.
### Automatic Retry After PR Submission Failures
When a patch PR cannot be pushed — for example, because of a branch protection rule, a repository
ruleset that forbids creating refs, or a revoked installation token — ZeroPath records the failure
and retries automatically using an exponential backoff schedule. You do not need to re-approve the
patch; once the underlying VCS configuration issue is resolved, the next retry creates the PR.
Each submission attempt counts against a per-patch budget of five attempts. Retry intervals grow
with each failure (15 minutes, 1 hour, 4 hours, 12 hours) so a repeatedly failing patch does not
consume a worker slot every hour while it burns through its budget.
Certain failure reasons are classified as permanent and retire the submission immediately without
waiting for the budget to be exhausted:
* **Archived repository** — the repository is read-only and cannot accept new branches.
* **Missing push credentials** — the installation token was revoked or expired, or the integration
lacks push access.
* **Repository not linked** — no VCS integration is configured for the repository.
When a submission is retired for one of these reasons, the patch panel in the dashboard reflects
the specific cause so you can take corrective action. Transient failures — such as branch
protection rule violations or temporary service errors — are not classified as permanent and
continue retrying until the budget is spent.
### Repository Rule Violations
If your repository has branch protection rules that enforce commit message formats or branch naming patterns, PR creation may fail. Update your repository rules or adjust ZeroPath's PR branch name and commit message formats under **Settings → Remediation → Pull request templates** on the repository page (see [scanner settings](/docs/platform/scanner-settings)), then retry.
## Adoption Guide
1. **Start with on-demand patching** — click "Generate Patch" on individual findings to see the quality of generated fixes for your codebase.
2. **Enable PR scan suggestions** — turn on `prScanAutoPatching` to get fix suggestions as inline comments on your pull requests.
3. **Tune thresholds** — adjust the patch and PR thresholds to focus auto-patching on high-severity findings first.
4. **Enable full scan auto-patching** — once comfortable with patch quality, enable automatic patch generation for full scans.
5. **Consider auto-PR creation** — for teams with fast review cycles, enable auto-PR to get fix branches created automatically.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.