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, proves it works, and manages the pull request to merge. A human always makes the final call.
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 proves it works — an independent review validates the fix against your build before a pull request ever opens. Once open, Nullify manages the PR the way an engineer would: reading CI output and fixing failures, responding to reviewer comments, 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.
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.
No. Nullify writes the fix, proves it works, opens the pull request, and manages it through CI and review — but the merge is always a human decision. Fix-PR throughput is also deliberately capped, at 3 open PRs per repository and 5 per remediation plan, so the queue stays something a team can actually review.
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.
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.
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
Book a demo and watch Nullify triage a real finding and drive the fix to a mergeable pull request.
Book a Demo