> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/capabilities/remediations.md). # Remediations > **Maturity: GA** — The cited infrastructure configures autofix tasks (`sast/iac/ecs.tf`, `sca/iac/`) and drafts pull requests through the connected git provider. ## Overview Nullify doesn't just find and rank vulnerabilities — it fixes them. For code vulnerabilities, dependency issues, cloud misconfigurations, and validated pentest findings, Nullify drafts production-ready fixes, opens pull requests that match your codebase's style, and shepherds each one until it's ready for a developer to merge. Leaked secrets are not autofixed — credential findings route to manual rotation and a tracking ticket. The bar it holds itself to: the vulnerability is genuinely closed, existing functionality is preserved, and no new vulnerability is introduced. ## How a fix is produced Only findings that have been [triaged](/capabilities/triage.md) as real and worth fixing become fix candidates — Nullify doesn't open PRs for noise. From there, it works like a careful engineer rather than a find-and-replace bot: 1. **Locate and plan.** Nullify finds the code responsible and writes a minimal-change plan that targets the root cause, not just the symptom. 2. **Edit.** It applies the change, matching your surrounding error handling, logging, and style conventions. 3. **Independent review.** A separate reviewing step checks that the fix actually addresses the root cause, preserves behavior, and stays minimal. If it doesn't, the fix loops back for revision. 4. **Validate it.** Nullify attempts the scanner, build, test, and exploit checks available to that workflow. Review the recorded validation and any unavailable checks before accepting the change. Successful workflows open a draft pull request for further CI and human review. Generated code is a proposed fix, not a guarantee that all security or functional checks passed. ## The pull request lifecycle Opening the PR is the start of Nullify's work, not the end. It keeps iterating the way a diligent author would: * **Reads CI and fixes it.** When CI fails, Nullify reads the actual failure logs and pushes corrective commits, within a bounded effort budget. * **Responds to reviewers.** When a developer leaves a review comment, Nullify reads the diff and the discussion and responds inline — updating the code or explaining the change. * **Handles conflicts.** If the branch falls behind, Nullify rebases it. * **Promotes when green.** Once CI is passing, Nullify promotes the PR from draft to ready-for-review and assigns the right reviewer. Nullify never merges your code — a human always makes the final call. Review the current CI result and any unresolved limitations before merging. ### Ask Nullify on the PR Reply in the PR thread — or **`@mention`** Nullify — to ask why a change is needed, request a different approach, or get more context. Nullify reads the diff and the discussion and responds inline, which is the fastest way to get a fix review-ready and merged. On pull requests Nullify didn't open, `@mention` it so it knows the comment is for it. ## Choosing the reviewer Nullify assigns each fix PR to the person most likely to be able to review it well, using a ranked ownership cascade: 1. **The authors of the changed code** — the people whose recent commits touched the lines being modified (automated/bot accounts excluded). 2. **Code owners** — the owners defined in your CODEOWNERS file for the affected paths. 3. **The owning team** — falling back to the team that owns the repository or finding. Nullify selects at most **3 reviewers** for an autofix PR. ## Pull Request Limits Manager campaign planning applies fixed selection limits: * **3 open Nullify fix PRs per repository** at any time. * **5 new fix PRs per remediation plan.** Once a fix PR merges or closes, the next queued fix can open. These are campaign-plan limits, not a global throttle on ad hoc dashboard, API, or CLI requests. ## Working with developers ### Status Updates * Posts to existing Slack threads. * Updates Jira tickets with PR links. * Sends notifications when a review is needed. * Escalates stalled PRs to team leads. ### Manual Fallback When an automated fix isn't appropriate, Nullify provides detailed fix guidance, creates a ticket with reproduction steps, tags the appropriate owner, and preserves the context for future learning. ## Where remediation fits Remediation is driven by [Security Program Management](/capabilities/program-management.md), which decides what to fix and when, and reads from the [Context Engine](/capabilities/context-engine.md) for ownership and business context. When a fix needs a human decision Nullify can't make alone, it raises an [action item](/capabilities/working-with-nullify.md). ## Cached fixes and manual retries A cached patch may be reused only when its recorded source checksums still match the current checkout. Drift can cause a fresh agent run, so a previous diff is not a guarantee of the next result. Locally supplied caches can be trusted on first use; inspect the proposed change and resulting validation evidence. Where the dashboard offers **Force auto-fix** for a finding marked not autofixable, use it as an explicit retry request. It does not guarantee a safe patch or successful PR. Follow status and activity and review any new failure reason. Dependency remediation includes supported container base-image updates. Pentest findings also have an autofix lifecycle. See the [Dependency Analysis](/api-reference/api-reference/dependency-analysis.md), [Code Review](/api-reference/api-reference/code-review.md), and [Pentests](/api-reference/api-reference/pentester.md) APIs for the available start and polling operations.