> 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

## Overview

Nullify doesn't just find and rank vulnerabilities — it fixes them. For code vulnerabilities, dependency issues, leaked secrets, 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. 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. **Prove it.** Before any PR opens, the fix is verified — the original scanner is re-run to confirm the finding is gone, and the change is exercised (build, tests, and, where a runnable exploit exists, re-running that exploit to confirm it no longer works while the feature's own tests still pass). A fix that closes the vulnerability but breaks functionality is rejected.

Only after surviving that does Nullify open a pull request — as a **draft** first.

## 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. Its job is to hand you a PR that's already green, already reviewed against its own bar, and already in front of the right person.

### 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.

Reviewer assignment is capped to a sensible number of people so a PR isn't spread across half the org.

## Pull Request Limits

To avoid overwhelming developers, autofix applies fixed, platform-managed limits rather than per-repository configuration:

* **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 limits are built-in platform behaviour and are not configurable per repository.

## 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).