.CapabilityAutonomous Triage & Remediation
Triage and remediation are the back half of Nullify's find-to-fix loop: every validated finding is scored for reachability, exploitability, and business impact, then handed to autonomous remediation, which writes a root-cause fix, validates it against the build, and manages the pull request through review. Your team approves the merge.
What it does
- Scores every finding, continuously. Reachability, exploitability, business context and confidence — and re-triages automatically the moment code, dependencies or threat intel change.
- Separates severity from priority. Severity is the abstract risk level (URGENT down to NEGLIGIBLE). Priority is how urgently your team should act, based on what the affected service does, what data flows through it, and whether it's actually reachable.
- Screens out the noise before a human sees it. Unreachable code paths, test fixtures, benign configuration and duplicates get filtered at triage — and human overrides persist, feeding back into future scoring instead of being discarded.
- Fixes the root cause, not the symptom. Remediation writes a minimal-change plan and validates it against your build before a pull request ever opens.
- Manages the PR through review. Reads CI output and fixes failures, responds to reviewers, and rebases as main moves — routed through a reviewer cascade of authors, then CODEOWNERS, then the wider team. Your team approves the merge.
- Never merges on its own. Fix-PR throughput is deliberately capped at 3 open PRs per repository and 5 per remediation plan. Nullify drives the PR to a mergeable state; a human always makes the final call.
How it works
Triage and remediation are the last two stages of Nullify's find-to-fix loop, picking up once a finding has been validated with reproducible proof. Every finding is scored against reachability — is the vulnerable code actually reached, and is the asset reachable from the internet — exploitability, and business context: what the affected service does, what data it touches, how critical it is. That scoring produces a priority distinct from severity, and it isn't static: the moment code, a dependency, or threat intelligence changes, Nullify re-triages automatically, and any human override made on the original decision persists into the new score. What survives triage moves to remediation. Nullify writes a root-cause, minimal-change fix, then independently validates it against your build before a pull request opens. Once open, Nullify manages the pull request through review: reading CI output and fixing failures, responding to reviewer comments, and rebasing as main moves. Throughput stays capped at 3 open fix PRs per repository and 5 per remediation plan, by design — the goal is a short queue of pull requests actually worth reviewing, not a flood. Nullify never merges your code; a human always makes the final call.
Frequently asked questions
What's the difference between severity and priority?+
Severity is the abstract risk level of a finding on its own. Priority is how urgently your team should act on it, based on reachability, exploitability and what the affected service actually does. A high-severity flaw in dead code can carry low priority; a moderate-severity flaw in a reachable, business-critical path can outrank it.
Does Nullify ever merge code on its own?+
No. Nullify writes the fix, validates it against the build, opens the pull request, and manages it through CI and review; your team approves the merge. Fix-pull-request throughput is deliberately capped at three open pull requests per repository and five per remediation plan, so the queue stays reviewable.
What happens when the finding's underlying code or dependencies change?+
Nullify re-triages automatically whenever code, dependencies or threat intelligence change, rather than treating the original score as permanent. If you'd previously overridden a triage decision by hand, that override persists and feeds into the new score instead of being silently discarded.
How does remediation decide what the fix should be?+
It targets the root cause with a minimal-change plan, not the easiest patch. Before a pull request ever opens, an independent review validates that the fix actually resolves the issue against your build — the proof comes first, then the PR.
Who does the pull request go to?+
Nullify routes it through a reviewer cascade: first the code's original authors, then CODEOWNERS, then the wider team if neither responds — the same escalation path a human engineer would follow chasing a review.
Read the docs: Triage · Remediations · Related: Code Security · Exploit Validation
Automated to Merge-Ready. Human-Controlled at Merge.
Book a demo and watch Nullify triage a real finding and drive the fix to a mergeable pull request.
Book a live demo 