> 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/pentests/exploit-validation.md).
# Exploit Validation
## Overview
Exploit Validation proves whether an individual finding is *actually* exploitable by attacking a running target — without launching a full [Pentest](/capabilities/pentests.md). 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.
{% hint style="info" %}
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.
{% endhint %}
## How it works
1. **A finding becomes a candidate.** During [Triage](/capabilities/triage.md), a code-review (SAST) or dependency (SCA) finding is assessed as reachable and likely exploitable.
2. **Policies decide whether to run.** Nullify checks your Exploit Validation [policies](#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.
3. **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.
4. **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.
5. **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.
Validation policies and the attempts they produced
## 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:
| Outcome | Meaning |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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.
A confirmed validation on a finding: tested endpoints, reproduction script, and proof of exploit
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:
| Setting | What it controls |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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. |
Creating an exploit-validation policy
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](/capabilities/triage.md); 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](/capabilities/triage.md): 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](/api-reference/api-reference.md) under the `/dast/exploit-validation` namespace — list attempts, manage policies, and request validation for a specific finding.
## Exploit Validation vs Pentests
| Aspect | Exploit Validation | 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 |