White-box vs black-box scans: how to choose a scan type in Cyberlop

A white-box scan in Cyberlop reads your application's source code from a Git repository and tests the running app at its URL. A black-box scan tests the live URL only, with no code, and needs proof that you own the target. You pick the type once, when you add the target. To get a grey-box style scan, you add login details to the scan profile.

Below you will see how white-box vs black-box scans differ in Cyberlop, which one to pick, what each needs, what each finds and how to add logins. No target yet? Start with Getting started.

What is the difference between white-box and black-box scans in Cyberlop?

The difference is what the scan can see. White-box testing works with the source code as well as the running app. Black-box testing works only from the outside, the way a visitor reaches your site. The Knowledge Hub defines both: white-box testing and black-box testing.

What a white-box scan does

A white-box scan clones the latest code from your repository when it launches, then tests the running app. Because it knows the code, a finding can point to a source file and line range, and the scan overview shows the commit and the lines of code analysed.

White-box is the type to use when the code is available, because it combines static analysis of the code with live testing of the app.

What a black-box scan does

A black-box scan tests the live URL only. There is no repository, so findings show an endpoint such as POST /search instead of a file and line, and the lines-of-code figure on the overview shows a dash. Black-box targets must have their ownership verified before a scan can run.

What a grey-box style scan is

The New target dialog shows two cards, White-box and Black-box. Grey-box testing is the middle path: the tester knows something about the inside, such as a set of credentials. The US government glossary describes it as a test method with "some knowledge of the internal structure and implementation detail" (NIST CSRC glossary, quoting CNSSI 4009-2022). In Cyberlop you reach it by adding authentication roles to a scan profile, so the scan can test the pages behind login.

White-box and black-box side by side

Which scan type should you choose?

Choose white-box whenever you can give Cyberlop the repository, because the scan can then use the code as well as the running app. Choose black-box when there is no code to share, or when you want to test the app as an outsider reaches it. The scan type belongs to the target, so decide before you add it.

Choose white-box when

• you own the repository and can reach it over HTTPS;
• you want findings your developers can open at a file and line;
• you are testing your own staging or development build before release.

Choose black-box when

• the code is not yours to share, or its repository has no HTTPS address;
• you want a view of the app from outside, as a visitor sees it;
• you can prove you own the target.

If your repository is private

A private repository needs a Git token. It can be a personal token (see Connect a repository) or one set for the organisation under Settings, as covered in Git access. SSH addresses such as git@… are not supported.

If the app is on a private network

If Cyberlop's cloud cannot reach the URL or the repository, run the scan on a self-hosted scan agent instead. See Self-hosted scan agents and private scanning.

What does each scan type need?

Both types need a target. They differ in two fields and one check. The table follows the order of the New target dialog; the full walkthrough is in Add a target.

Field reference for the New target dialog

The extra step for black-box: ownership

After you create a black-box target, its page shows an Ownership verification card. You confirm ownership with a DNS TXT record or with approval from Cyberlop staff. Once it is done, the card shows "Verified" and "Black-box scans can run." The steps are in Verify target ownership. Scan only applications you own or have permission to test.

What does each scan type find?

Both types look for the same ten vulnerability classes: Injection, Xss, Auth, Authz, Ssrf, Crypto, Config, Business-logic, Dependency and Secrets. If you tick none, the profile scans all of them. What changes is the evidence and the place a finding points to. The vulnerability classes guide covers each class.

Access control is the class most worth the extra effort. OWASP Top 10:2025 ranks Broken Access Control first. It reports that 100% of the applications tested had some form of it, with an average incidence rate of 3.74%. Flaws such as IDOR often need a signed-in account to find, which is why logins matter.

Exploitation matters too. The Verizon 2026 Data Breach Investigations Report found that 31% of breaches began with software vulnerabilities, a bigger share than stolen passwords. When the Run exploitation phase option is on, agents test and prove issues against the live target. When it is off, you get static source-code analysis only. See Exploitation phase before you run it against production.

How findings differ by type

To read these screens, see Read a finding and Scan detail page.

How do you add logins for a grey-box style scan?

You add one or more authentication roles to the scan profile. A role is a set of login details with a privilege level, so the scan can reach pages that a signed-out visitor cannot. With no role, the scan runs unauthenticated, and the app says: "No auth roles. Add a role to scan behind login, or leave empty for unauthenticated scanning."

1. Open Scan Profiles and click + New profile, or open your target and use + New profile to preselect it.
2. On the Scope section, pick the target, name the profile and choose your vulnerability classes.
3. Open the Authentication section and click + Add role.
4. Give the role a Name and a Privilege level: Unauthenticated, User, Elevated or Admin.
5. Tick one or more methods: Form, Header (token / API key) or OAuth 2.0.
6. Fill in the fields for each method (see the table below). Add AI guidance if the login needs hints.
7. Add a second role with a different privilege level if you want to check what one signed-in account can reach that it should not.
8. Click Preview YAML to validate, then Save.

Which login method should you use?

Use the method your app uses for its own sign-in. You can combine methods on one role, for example form plus header.

Form login tips

The Success condition tells the scan that sign-in worked. For example, set the type to Url Contains and the value to /dashboard. The Login flow takes one step per line, such as clicking "Sign in" and filling the username and password fields. If the account uses time-based codes, add the optional TOTP secret.

Header and OAuth tips

For a bearer token, use the header name Authorization and the value Bearer …. For OAuth, click Complete authentication to check that the app returns a token before you save.

Use test accounts, not real ones

Create dedicated accounts in a Dev or Staging environment and give them only the access you need, in line with least privilege. Cyberlop encrypts stored secrets and never shows them again once you save. When you edit the profile later, leave the fields blank to keep the stored value, or use Clear. See Authentication roles and Edit a scan profile.

How do you set up and run the scan you chose?

The route is the same for both types after the target exists: save a profile, press Scan, then read the results.

1. Choose the scan type using the table above.
2. Add the target with + New target and click Create target.
3. For black-box, complete ownership verification and wait for the Verified badge.
4. Create a scan profile and, if you want a grey-box style scan, add authentication roles.
5. Decide whether to keep Run exploitation phase ticked.
6. Click ▷ Scan. The scan starts at once and you can leave the page.
7. Follow it from Recent Scans. The app's own documentation says a typical scan of a small app takes roughly an hour.
8. Open the Findings tab and triage what you find.

The running steps are in Run a scan.

Can you change the scan type later?

Not by editing. You cannot edit a target, so the scan type, URL and repository stay fixed once it exists. To change them, delete the target and create it again. Deleting a target also deletes its profiles, schedules, scans and findings, so export what you need first. See Manage targets.

Common mistakes when choosing a scan type

Next step: add your first application in Add a target. Cyberlop reports what it actually exploited, as set out on the evidence page, and the How it works page shows the full path from scan to proof.