Exploit Validation
Overview
Exploit Validation proves whether an individual finding is actually exploitable by attacking a running target — without launching a full Pentest. When code review flags an injection point, or dependency analysis surfaces an exploitable CVE, Nullify can drive a focused exploitation agent against the deployed application, read the vulnerable source, reach the code path over real HTTP, and record the result as evidence.
Where a Pentest goes broad — mapping an application and hunting for anything exploitable — Exploit Validation goes narrow: one already-known finding, one verdict, backed by proof. It turns a theoretical "this looks reachable" into a confirmed "this was reproduced" (or a defensible "this could not be exploited").
Validation runs against the Web Services and Targets you register in your inventory, and it only runs when a policy you control says it should.
Exploit Validation reuses the same evidence-first exploitation engine as Pentests, scoped to a single finding. A validated finding carries the same reproduction evidence you would get from a full engagement.
How it works
A finding becomes a candidate. During Triage, a code-review (SAST) or dependency (SCA) finding is assessed as reachable and likely exploitable.
Policies decide whether to run. Nullify checks your Exploit Validation policies. If an enabled policy matches the finding — by finding source and validation window — and the finding isn't inside its revalidation cooldown, validation is started.
Targets are resolved. The finding's repository is matched to the Web Services named in the policy, and Nullify resolves the live target URLs to attack.
The agent attempts the exploit. A focused agent reads the vulnerable code, discovers the reaching endpoint, and sends bounded, real HTTP requests — using out-of-band callbacks where blind exploitation requires it. Credentials are used for authenticated access and are redacted from all logs and traces.
An outcome is recorded. The agent returns a verdict with proof. The result is written back onto the finding's triage — so a confirmed exploit moves the finding's exploitability verdict and priority — and appears as an attempt on the Exploit Validation page.
The Exploit Validation page holds both halves: the policies that govern validation, and the attempts that have run.
Outcomes
Every validation run is recorded as an attempt. While a run is underway the attempt shows as In progress; when it finishes it lands on one of these outcomes:
Confirmed
Nullify proved exploitability with a concrete HTTP response or an out-of-band callback. The finding is exploitable.
Not Exploitable
The correct reachable code path was exercised with the context it needed and the exploit still did not work — a strong negative signal.
Cannot Determine
Validation was blocked before a verdict could be reached (for example the target was unreachable, access was blocked, authentication was required, a rate limit or request budget was hit, or context was missing).
A Cannot Determine result is not a pass or a fail — it means the test setup, not the application, needs attention. The recorded reason (unreachable target, blocked access, auth required, budget exhausted, and so on) tells you what to fix so a re-run can reach a real verdict.
The attempts table lists each attempt's finding, source, outcome, confidence, any exploited CVE, and when it was validated — newest first.
Evidence
Every validated finding carries its exploit-validation report inline, on the finding itself: the outcome, Nullify's confidence, how long the run took, the endpoints it tested, a runnable reproduction script, and a written report covering the vulnerability, how it was exploited, the impact, and the fix — followed by the proof-of-exploit requests themselves.
Because the reproduction script is a plain shell script against your own environment, you can re-run Nullify's proof yourself — and re-run it after a fix to confirm the exploit no longer works.
Policies
Policies are how you control whether, when, and against what Exploit Validation runs. Validation attempts are live LLM-driven exploitation runs, so nothing fires until a policy you have configured matches a finding. A finding is validated only when at least one enabled policy matches it.
Each policy defines:
Name
A label for the policy.
Policy enabled
Turns the policy on or off. Disabled policies never start exploit validation.
Finding sources
Which sources the policy applies to — SAST (source-code vulnerabilities), SCA Dependencies (vulnerable open-source dependencies), or both. At least one is required.
Web services
Which registered Web Services validation may run against. At least one is required — this is how a finding's repository is mapped to a live target to attack. Pick existing services from your inventory, or create one inline.
Validation window
The days and local-time window in which new validations may begin — for example weekdays 09:00–17:00 in Australia/Sydney, or "all day" on the days you select.
Revalidation cooldown
How many days before the same finding can be validated again (default 30, minimum 7). Prevents the same finding from being re-attacked on every scan.
Two details worth knowing about the validation window: it gates when a validation may start, so a run already underway is allowed to finish rather than being cut off at the boundary; and an overnight window (one whose end time is earlier than its start) belongs to the day it starts on.
Findings are also held to a severity and exploitability floor, so low-severity or unlikely-to-be-exploitable findings aren't attacked. By default a finding must be High severity or above and assessed as Likely exploitable by Triage; where the controls are available you can tune both floors per policy.
When a finding is proposed for validation, Nullify keeps only the policies that are enabled and match on finding source, validation window, and those floors. If any match, it then checks the finding's most recent attempt against the cooldown, and resolves the matching web services to target URLs. If nothing matches — no enabled policy applies, the finding is inside its cooldown, or no matching policy has a web service for the finding's repository — validation is skipped and the reason is recorded.
How validation feeds triage
Exploit Validation closes the loop with Triage: a confirmed exploit is strong evidence that a finding is real and reachable, so it raises the finding's exploitability verdict and its priority. A Not Exploitable result biases the finding the other way. The validation outcome is folded into the finding's triage as evidence the model weighs — not a blunt override — so ranking still reflects the full picture (reachability, business context, and confidence) rather than the exploit result alone.
Where to find it
Everything lives on the Exploit Validation page in the web console, under Assessments. From there you can:
Create, edit, enable/disable, and delete validation policies.
Review every validation attempt, newest first, with its outcome and confidence.
Jump from an attempt straight to the finding it validated.
Each validated finding also shows its full exploit-validation report inline, in the finding's own detail view.
Running validation via the API
Exploit Validation is available through the Nullify API under the /dast/exploit-validation namespace — list attempts, manage policies, and request validation for a specific finding.
Exploit Validation vs Pentests
Scope
One known finding (from code review or dependencies)
A whole application
Goal
Prove or disprove a single finding's exploitability
Discover and exploit anything reachable
Trigger
Policy-driven, off the back of triage
On-demand
Depth
A focused attack on one code path
Endpoint mapping, fuzzing, and multi-stage exploit chains
Evidence
Reproduction proof for one finding
Request/response pairs and reproduced exploit chains across the app
Last updated