Getting started with Cyberlop: from sign-in to your first finding

Getting started with Cyberlop means going from your first sign-in to your first proven finding in six moves: add a target, create a scan profile, run the scan, open the findings, triage them and re-scan after a fix. Each section below names the buttons to press and links to the guide that goes deeper.

What do you need before your first scan?

You need an application you own or are authorised to test, the address of a running copy of it (staging is the safest choice) and, for white-box scanning, an HTTPS link to its Git repository. Cyberlop tests the running app at its URL. If you share the repository, it reads your source code as well, and it reports the vulnerabilities it could prove. Point it only at systems you have permission to test.

Table 1. Checklist before you start

Which scan type should you pick?

Pick white-box when you can share the repository, because findings then point to a file and line. Pick black-box when you only have a URL. Adding a login role to either gives you a grey-box style run that reaches signed-in pages.

Table 2. White-box and black-box in the New target dialog

Public repositories

Paste the HTTPS link and leave the branch as main unless you scan another branch. Cyberlop clones the repository when the scan launches.

Private repositories

Add a read-only Git token first. Your organisation can store one under Settings → Git Access, and each person can store a personal one under My Account. The token is only sent to the hosts you allow. The guides on connecting a repository and Git access cover both routes.

How do you add your first target?

A target is the application under test. Go to Targets in the sidebar, click + New target, fill in the dialog and click Create target.

1. Open Targets and click + New target.
2. Enter a Name and the Main URL.
3. Optionally list Backend / additional URLs, one per line.
4. Choose the Scan type: White-box or Black-box.
5. For white-box, enter the Repo URL (HTTPS) and Repo branch.
6. Choose the Environment and, if you wish, a Team.
7. Click Create target.

Table 3. New target fields

Two things to know about targets

Targets are immutable. To change a name, URL or repository, delete the target and create it again. Deleting a target also deletes its profiles, schedules, scans and findings, so get the details right the first time. The add a target guide goes field by field.

For a black-box target, the target page shows an Ownership verification card. Once it reads Verified, black-box scans can run. The route is a DNS TXT record or approval by Cyberlop staff; see verify target ownership.

How do you create a scan profile?

A scan profile is a reusable scan configuration that belongs to one target. It holds what to test, how to sign in and what to report. Open the target and click + New profile, which preselects the target, or use Scan Profiles → + New profile.

Table 4. The three profile sections

The steps

1. In Scope, give the profile a name. Leave Vulnerability classes empty to scan all classes: Injection, Xss, Auth, Authz, Ssrf, Crypto, Config, Business-logic, Dependency and Secrets.
2. Keep Run exploitation phase ticked if you want agents to prove issues against the live target. Untick it for source analysis only, with no live testing.
3. Leave Scan location on Cyberlop cloud (default) unless the app sits on a private network. Then choose a self-hosted scan agent.
4. In Authentication, click + Add role to scan behind a login. With no roles, the scan is unauthenticated.
5. In Reporting, add rules of engagement in plain words, for example to avoid destructive payloads in production. Detected personal data in these fields is redacted before analysis.
6. Click Preview YAML to see the generated configuration and catch validation errors, then click Save.

Use Auto Generate for application context

Application context tells the scanner what your app is, its stack, tenancy model and business-critical flows. After the first save, Auto Generate from Repo can fill the fields from the repository. Read the result and correct anything wrong. See application context.

Why add a login role at all?

Most of a real application sits behind sign-in, and that is where access mistakes live. Broken access control means one account reaches data or functions it should not. It tops the OWASP Top 10, and the 2021 edition found some form of it in 94% of the applications tested. A scan with no roles cannot do authenticated testing of those pages. Start with one role, then see authentication roles.

How do you run your first scan?

Click ▷ Scan on the profile row, on the target page or on the target row in Targets. The scan starts at once. It is durable, so you can close the page and come back.

Table 5. The five phases of a scan

Where do you follow it?

Open Recent Scans and click the row. The scan detail page has four tabs: Overview, Findings, Sitemap and Diff. The in-app documentation says a typical scan of a small app takes roughly an hour. Rate limits make a scan slower rather than failed. Press ⟳ Refresh to update the page.

On Overview, a white-box scan shows the commit that was scanned, lines of code, tokens consumed and a donut chart of findings by severity. See the run a scan and scan detail page guides.

How do you read your first findings?

Open the Findings tab of the scan, or Issues in the sidebar for findings across all scans. Each row shows severity, title, class, confidence, triage state and location. Click a row to open the issue dialog.

Table 6. The issue dialog

Severity, confidence and status are three different things

Severity is how bad the issue is: Critical, High, Medium, Low, Informational or Best Practice. Confidence is High, Medium or Low. Status says how well it was proven. Start with Critical and High findings marked Confirmed, then work down. Treat Likely and Unconfirmed items as leads to check, not as facts. See severity and confidence.

Where to start reading

Read Description first, then the reproduction steps on Evidence. Run the curl commands against your staging app to see the behaviour yourself. A white-box finding gives a source file and line range, which is where your engineer starts the fix. A black-box finding gives an endpoint. The read a finding guide goes through every field.

What do you do after the first finding?

Triage it, fix it and scan again. In the issue dialog, set Disposition, pick an Assignee, add Notes and click Update status.

Table 7. Dispositions

Issues persist per target. If a re-scan no longer finds an issue, it is marked Fixed. If it comes back, it becomes a regression rather than a new finding. The Diff tab lists New, Fixed and Regressed issues against the previous completed scan. For an executive copy, use ⤓ Download report on the scan, which offers Open issues only, Include fixed & accepted or Fixed issues only. Raw data leaves through Export JSON and Export CSV on Issues.

Where should you go next?

Table 8. Next guides

Next step: read Dashboard overview to see what to act on first. For the thinking behind proof-backed reporting, see how Cyberlop shows evidence and how it works.

What are the most common first-scan mistakes?

Table 9. Troubleshooting

Whatever went wrong, the safety rule stands: scan only applications you own or have written permission to test, and use staging for a first run.