The exploitation phase: on or off, and safe in production

The exploitation phase is the step where a Cyberlop scan tries each suspected flaw against your running app and keeps the proof: real requests, a real browser and captured evidence. It is the Run exploitation phase checkbox on a scan profile, ticked by default. Leave it on to prove findings live, which is a DAST scan. Untick it for source-code analysis only, which is SAST. This guide explains the choice, what proof looks like and how to run it safely against production.

What is the exploitation phase?

The exploitation phase is phase four of Cyberlop's five-phase scan: pre-recon, recon, vulnerability analysis, exploitation and reporting. Earlier phases read the code and map the app and produce hypotheses. This phase takes each hypothesis and tries to demonstrate it against the live target.

The checkbox sits in the Scope section of the profile form, under the vulnerability classes. A (?) icon next to it explains the setting in the app's own words: with the box ticked, "the agents actively test and prove vulnerabilities against the live target (real HTTP requests, browser, captured evidence)". With it unticked, you get "static source-code analysis with no live testing".

What is the difference between on and off?

On is DAST: the scan sends traffic to your running app. Off is SAST: the scan only reads code. The table sets them side by side.

Table 1. Exploitation phase on and off

Where can you see the setting after you save?

Open the target page. The Scan profiles card has an Exploit column that shows Enabled for every profile with the phase on. It is a fast way to check which profiles will send live traffic before anyone presses Scan.

What does "proving" a finding mean?

Proving a finding means the scan actually triggered the weakness and kept the evidence. For each hypothesis, an exploitation agent drives a browser, tries to reproduce the flaw safely and records the request, the response, the payload and, where relevant, a screenshot. A proof of concept like this lets an engineer repeat the result instead of arguing about whether it is real.

Open any proven finding from Issues and choose the Evidence tab. Read it top to bottom.

Table 2. What the Evidence tab holds

How are findings graded?

The documentation says findings are graded confirmed, likely or unconfirmed "based on how strongly they were proven". The Summary tab shows this as Status. Status answers "how well was it proven?". It is separate from severity ("how bad is it?") and confidence. Read severity and confidence before you rank work, and how to read a finding for the full dialog.

Why does proof change how you prioritise?

An unproven finding costs time, because someone has to decide whether it is a false positive. A proven one is quicker to fix, because the curl steps show exactly what to repeat. Speed matters. In the 2025 Verizon Data Breach Investigations Report, as summarised by Tenable, 2025, exploiting a vulnerability ranked among the top ways in for 20% of breaches, up 34% on the previous report.

When should you leave it on, and when turn it off?

Leave it on for most profiles, which is why it is the default. Turn it off when live traffic is not acceptable or not possible, or when you want a quick code-only pass. The off setting is described as source-code analysis, so it fits targets that have a repository; a black-box target has none.

Table 3. Choosing a setting

How do you switch the phase on or off?

1. Open Scan Profiles and click + New profile, or open a target and use + New profile on its Scan profiles card. To change an existing profile, click its pencil icon or Edit.
2. In Scope, pick the target and name the profile.
3. Choose the vulnerability classes. Leave them all empty to cover every class.
4. Find Run exploitation phase. Keep it ticked to prove findings live, or untick it for static analysis only.
5. Choose the Scan location: Cyberlop cloud (default) or one of your own scan agents.
6. Click Preview YAML to check the generated configuration, then Save.

The full form is covered in create a scan profile, and changing a saved one in edit a scan profile. A profile's target cannot be changed after creation; the checkbox can.

Is it safe to run the exploitation phase against production?

It can be, if you plan it, but it is never free of risk. Cyberlop's documentation says the agents attempt to demonstrate issues "safely", yet a proving scan sends real requests to a running system. Treat it like any production change and agree it with the people who run the system first. The safest default is to prove findings on Staging and keep production for a narrower, planned run.

Only register and scan applications you own or are authorised to test. For black-box targets, ownership must be verified first.

Which controls do you have?

The profile gives you several levers. Some are hard scope settings and one is plain-language guidance, so use them together.

Table 4. Controls that reduce risk

How do you write useful rules of engagement?

Be specific and short. The field's own placeholder suggests the kind of rule to write: "avoid destructive payloads in prod". Add what matters to your app, for example "do not place real orders" or "do not email real customers". Detected PII such as emails, phone numbers and payment cards is redacted before analysis, so describe behaviour, not people. See reporting rules. Rules of engagement steer the agents, but they do not replace an avoid rule for anything that must never be touched.

How do avoid rules keep a scan away from sensitive areas?

Under Scope rules, click + Add rule beneath Avoid rules and pick a type: Url Path, Subdomain, Domain, Method, Header, Parameter or Code Path. Use them for paths that send money, messages or deletions. Details and pitfalls are in focus and avoid rules.

Which accounts should the scan use?

Give each role the least access a test needs (least privilege), and prefer accounts that hold test data. Authentication roles explains the privilege levels. A scan that proves an IDOR will read a real record, so make sure the account cannot reach real customers' data.

What is a sensible order for a first production run?

1. Run the profile on a staging copy with the exploitation phase on, and read the findings.
2. Fix or triage what you find, then re-scan so staging is quiet.
3. Create a separate production profile with narrow classes, avoid rules and written rules of engagement.
4. Tell the people who watch production, and pick a quiet hour. A schedule uses your organisation's timezone from Settings → Organization.
5. Start the scan from the profile row, then follow it in Recent Scans.
6. Check Activity afterwards: it records scan starts and cancellations. See the activity feed.

If the app cannot be reached from the internet, run the scan from inside your network with a private scan agent, so your code and target stay on your side.

What do you get when the phase is off?

You get findings from reading the code, each tied to a location in the source. The Evidence tab is built from live testing, so do not expect captured requests, responses or screenshots for those findings. The scan still follows the other phases and the report is filtered by your reporting rules.

An off scan therefore gives early feedback, but it is a weak basis for claiming that a flaw is exploitable. Many teams run both: code-only on every change, proving scans on a schedule. Compare white-box and black-box testing in white-box vs black-box scans.

What are the most common mistakes?

Common mistakes and fixes

Table 5. Mistakes with the exploitation phase

What should you do next?

Next step: narrow the blast radius with focus and avoid rules. Then run a scan and triage the findings. Prove each fix by re-running the exploit, as fixed and regressed issues explains. For the bigger picture, see how it works and what the evidence looks like. Standards for planning tests include NIST SP 800-115 and the OWASP Web Security Testing Guide.