How to run a pentest scan in Cyberlop, and what happens next

To run a pentest scan in Cyberlop, click ▷ Scan on a scan profile, on a target or on a row in Recent Scans. The scan starts at once and runs as a durable five-phase workflow, so you can close the tab and come back. In white-box mode it reads your code, tests the running app, and tries to prove each finding.

What is a scan in Cyberlop, and what does it need?

A scan is one run of a scan profile against its target. It ends as Completed, Failed or Cancelled, and it records its cost, tokens consumed and, for white-box scans, lines of code. Findings from every scan on a target roll up into the Issues list, so one scan is a step in a history, not a one-off report.

Autonomous AI agents do the work. They read the repository, map the live app, look for weaknesses in parallel and then try to prove each one in a real browser. That proof step is why a Cyberlop finding comes with a request, a response and, where a person can see it, a screenshot. If you want the vocabulary first, read Key terms.

What should be ready before you click Scan?

You need a target, a profile on that target and, for the scan type you chose, the access it depends on. The table shows the difference.

What does white-box add?

The scan clones the latest code from the branch at launch, so merge or push what you want tested first. The scan page then shows the Commit it analysed, and findings point to a file and line. Steps for private repositories are in Connect a repository and Git access.

What does black-box change?

With no repository there is no source to read, so findings show an endpoint instead of a file and line, and Lines of code reads “—”. Confirm the target shows Verified first: Verify target ownership. Scan only applications you own or have permission to test. The white-box vs black-box guide helps you choose.

How do you run a pentest scan, step by step?

Run it from the profile row when you want a specific configuration. The steps are the same on every page that has a ▷ Scan button.

1. Open Scan Profiles and find the profile. If you have none, follow Create a scan profile first.
2. Check the row: Vuln classes (“All” means none are ticked), Auth roles and the target. Open the pencil icon if anything is wrong.
3. For a white-box target, check that the target page shows a repository and branch. For a black-box target, check the Ownership verification card says Verified.
4. Click the green ▷ Scan button on the row. The scan starts immediately.
5. Open Recent Scans. The new run appears at the top; click its row to open the scan detail page.
6. Watch the phase and counters, or leave. The run is durable, and ⟳ Refresh updates the page when you return.
7. When the result badge reads Completed, open the Findings tab and start triage.

Where can you start a scan?

There are four starting points. All of them launch a scan on the Cyberlop side; they differ only in how much choice you have.

Pipelines and calendars can start scans too: CI/CD integration calls the scan endpoint after a commit, and Schedule scans runs a profile on a cadence.

What happens after you click Scan?

The scan runs as a durable, crash-recoverable workflow in five phases, and each phase builds on the deliverables of the one before. Because the workflow is durable, closing the page does not stop it. The agents retry after rate limits and transient errors. The in-app documentation says that slows a scan down but does not fail it.

What are the five phases of a scan?

The phases are pre-recon, recon, vulnerability analysis, exploitation and reporting. The table says what each one does and what you can see afterwards.

Phase 3: eight specialists, one lane each

The specialists cover injection, XSS, authentication, access control (authorisation), SSRF, cryptography, configuration and business logic. Separate lanes keep the same weakness from turning up eight times. Which vulnerability classes a profile covers is set on the profile; Choose vulnerability classes explains the ten options.

Phase 4: proof, or analysis only

With Run exploitation phase ticked, agents prove issues against the live target, which is DAST style testing. Unticked, the scan is SAST only and skips this phase. Decide this before you launch, particularly for a production target; Exploitation phase covers the safety side.

Why does the choice of classes matter?

Access control deserves a place in most profiles. In the OWASP Top 10 for 2021, Broken Access Control sits at number one, and 94% of the applications in its data were checked for it. If you ticked classes and left Authz out, the scan will not look for it.

How do you follow a running scan?

Open Recent Scans, then click the row. The scan detail page shows the run status, live cost, token and lines-of-code counters, and tabs that fill with the sitemap and findings as the scan discovers them. The live view was not captured for this guide, so the layout while a scan is running may differ from the finished view.

How long does a scan take?

The in-app documentation says a typical scan of a small app takes roughly an hour. Rate limits can slow a scan down further. Plan for it to run in the background and check back rather than waiting on the page.

Which limits can hold a scan back?

Limits depend on your plan and are shown in Settings → Plan & usage, including how many scans can run at once. An online scan agent raises the concurrent-scan limit. If the included AI allowance runs out, scans on Cyberlop AI pause until next month, unless you connect your own key under Settings → AI Provider (see AI provider settings).

Where does the scan run, and where does your code go?

By default a scan runs in the Cyberlop cloud. Each scan clones the repository into an isolated workspace and wipes it from disk when the scan finishes. Nothing carries over between scans. Each organisation’s data lives in its own private database schema.

If the app sits on a private network, set the profile’s Scan location to a self-hosted agent. The agent connects out over HTTPS only, and your code and target stay on your network. Set one up in Self-hosted scan agents, and read the overview at private scanning.

What happens when the scan ends?

The result badge shows Completed, Failed or Cancelled, and the Overview tab shows the run details and a severity donut. Open Findings for the list, Diff to compare with the previous completed scan, and Download report for the PDF. Scan detail page walks through each tab.

Cancelling is available through the API (POST /api/scans/{id}/cancel, permission scan:cancel). The captured screens did not show a cancel button, so check the scan page in your own workspace. The Activity feed records every start and cancel.

Troubleshooting: why will a scan not start or not finish?

What mistakes do new users make?

• Launching from the Targets list when you meant to use a specific profile.
• Scanning an application you are not authorised to test. Do not do this.
• Leaving exploitation on for a production target without reading the safety guidance.
• Expecting a code change to be tested before you push it to the branch.
• Waiting on the page instead of reading Recent Scans later.

What should you do next?

Read the result page properly: Scan detail page is the next step. Then learn how to read a finding, and re-run the same profile after a fix so the scan comparison shows what closed. Re-running the exact exploit against the new code is what proves a fix. The full path from sign-in is in Getting started.

For the pipeline behind each phase, see how it works. To start scans from a pipeline, read about CI/CD and our integrations. For how security tests are planned and reported, see NIST SP 800-115 and the OWASP Web Security Testing Guide.