How to create a scan profile in Cyberlop: Scope, Authentication, Reporting

To create a scan profile in Cyberlop, go to Scan Profiles, click + New profile, choose the target and name the profile. Then complete three sections: Scope, Authentication and Reporting. Click Preview YAML to validate, then Save. A scan profile is a reusable scan configuration that belongs to one target.

What is a scan profile in Cyberlop?

A scan profile is a reusable scan configuration that belongs to one target. It records what to test (scope), how to sign in (authentication roles) and how to write up the results (reporting rules). Every scan is one run of a profile, so you cannot start a scan without one. The wider vocabulary sits in Key terms.

One target can carry several profiles, such as a quick check on the classes you changed this sprint or a full audit before a release, and each profile keeps its own scope, roles and reporting rules.

A profile records the scope and the rules of engagement up front. NIST SP 800-115 is the standard reference for planning and running technical security tests. A profile is where Cyberlop records those planning decisions.

What do you need before you create a scan profile?

You need an existing target, permission to create profiles, and, if you want to test behind a sign-in, credentials for a test account. Create the target first with Add a target.

Pre-flight checklist

1. A target. The profile picker lists your targets by name and URL. If it is empty, add one first.
2. Authorisation. Only configure scans for apps you own or are authorised to test.
3. A test account, if needed. Use a dedicated account on a Dev or Staging copy, not a real customer login.
4. A decision on exploitation. Leaving it on proves findings against the live app; read Exploitation phase first if the target is production.

Where to start from

There are two entry points. From the sidebar, go to Scan Profiles → + New profile and choose the target yourself. Or open a target and click + New profile on its Scan profiles card, which adds the target to the address and preselects it.

How do you create a scan profile, step by step?

The New scan profile page is one full page, not a dialog. A switcher on the left holds three sections, and one footer holds Preview YAML and Save. Cancel sits at the top right.

1. Open Scan Profiles and click + New profile, or start from a target's Scan profiles card.
2. In Scope, pick the Target and type a Name.
3. Add Tags if you want them, then tick any Vulnerability classes to narrow the scan.
4. Keep or untick Run exploitation phase and choose the Scan location.
5. Optionally add Focus rules and Avoid rules.
6. In Authentication, click + Add role for each login the scan should use. Leave it empty for an unauthenticated scan.
7. In Reporting, set the minimum severity and confidence, then add report guidance and rules of engagement. Fill in any application context fields you already know.
8. Click Preview YAML to see the generated configuration and any validation error.
9. Click Save.

What goes in the Scope section?

In Scope you choose the target and the vulnerability classes, decide whether the exploitation phase runs, set where the scan runs and add focus and avoid rules. Main and backend URLs belong to the target, not the profile.

Scope field reference

Vulnerability classes: all or narrow?

With no class ticked, the profile covers all ten. That is the right default for a first scan. Narrow the list when you want a faster, focused run, for example only Authz and Business-logic after a change to checkout. Choose vulnerability classes explains each class.

Exploitation on or off

The field's tooltip calls this a DAST scan. The agents test the live target and prove vulnerabilities with real HTTP requests, a browser and captured evidence. Unticked, you get SAST only: static analysis of source code and no live testing. See DAST and SAST for the terms, and Exploitation phase for safety on production.

Scan location

Pick an internal agent when the app sits on a network the Cyberlop cloud cannot reach, such as a staging environment behind your firewall. Agents are managed in Settings → Scan Agents; see Self-hosted scan agents.

Focus and avoid rules

Each rule row has a Description, a Type, a Value and a bin icon. Focus rules steer the scan towards an area, such as a path prefix. Avoid rules keep it away from something, such as a logout route or a header. The empty state reads "No rules." Details and pitfalls are in Focus and avoid rules.

How do you set up authentication in a scan profile?

Authentication is where you add the login roles the scan can use. A role has a name, a privilege level and one or more methods. With no roles, the page says "No auth roles. Add a role to scan behind login, or leave empty for unauthenticated scanning."

The parts of your app that matter most usually sit behind a sign-in, so a scan without a role never reaches them. A second, lower-privileged account also lets it check what one signed-in account can reach that it should not. The background term is authenticated testing. Use test accounts with the least access that still reaches the screens you care about (least privilege).

Role fields

Form login

The form block asks for a Login type (FORM, SSO, API or BASIC), Login URL, Username, Password and an optional TOTP secret. Then set a Success condition (Url Contains, Url Equals Exactly, Element Present or Text Contains) with a value such as /dashboard. The Login flow box takes one step per line, for example Fill #email with username. The TOTP secret is for accounts that use a time-based code, as defined in RFC 6238, which recommends a default time step of 30 seconds. See Form login authentication.

Header: token or API key

Click + Add header and enter a name such as Authorization and a value such as Bearer .... Use it for an API key or bearer token. Add AI guidance if the token should be sent as-is. See Header and token authentication.

OAuth 2.0 client credentials

Cyberlop mints a token through the client credentials flow and injects it as a header at scan time. Enter Token URL, Client ID, Client secret, Scope (optional), Header name (default Authorization) and Header prefix (default Bearer ). Then click Complete authentication to confirm a token is issued; it stays disabled until the fields are filled. The grant itself is defined in RFC 6749, section 4.4. See OAuth client credentials and the background on OAuth.

Stored secrets are encrypted at rest and never shown again.

What goes in the Reporting section?

Reporting sets the minimum severity and confidence that reach the report, adds guidance and rules of engagement, and holds the application context.

Reporting field reference

Severity and confidence filters

Unsure? Leave both on "No minimum" for the first scan and tighten later. Filtering on confidence can hide a real issue; see severity vs confidence and Reporting rules.

Application context and Auto Generate from Repo

The context fields tell the scan about your stack, data, tenancy model and business-critical flows. On a new profile the Auto Generate from Repo button is disabled with the tooltip "Save the profile first, then generate from its repo". Save once, edit the profile, then use it to fill the fields from the repository. See Application context.

Detected personal data in these free-text fields is redacted before analysis, but do not paste real customer data.

How do you validate and save a scan profile?

Click Preview YAML to see the generated configuration and to validate the form, then click Save. Validation errors appear in a red banner. With an empty name the banner reads "name: String must contain at least 1 character(s)".

1. Click Preview YAML and read the configuration it shows.
2. Fix anything the banner reports, usually a missing name or an incomplete role.
3. Click Save. The profile appears in Scan Profiles and on its target's Scan profiles card.
4. Click ▷ Scan on its row when you are ready; see Run a scan.

The list has Name, Target, Tags, Vuln classes, Auth roles and Actions (Scan, edit, delete) columns. Search it by name, target or tag. Later changes, including secrets that stay blank to keep their stored value, are covered in Edit a scan profile.

Which profile settings suit which goal?

Start broad, then make narrower profiles for repeat work.

Name each profile after its purpose and use tags for team or release, because several small profiles are easier to read and to schedule than one profile that tries to do everything.

What are the common mistakes and how do you fix them?

Most problems trace back to the target, the credentials or filters set too tight. The table maps each symptom to a fix.

A profile that looks right but finds little

Ask three questions. Did you tick only a few classes? Does an avoid rule exclude the area you care about? Did the scan have a role to sign in with? Without a role it reaches only what is public.

Credentials you cannot see

Stored secrets are never shown again. Enter the new value if a login stops working; a blank field keeps the old one.

What should you do next?

Next step: decide which classes to cover in Choose vulnerability classes. You can then run a scan, or return to Getting started for the full path from target to first finding.

Work only on apps you own or are authorised to test. See Security for how credentials are protected.