Application context in Cyberlop: fill the ten fields and use Auto Generate from Repo

Application context is a set of ten text fields in the Reporting section of a Cyberlop scan profile where you describe the app being tested: what it does, what it is built with, what data it holds and how its tenants and trust boundaries work. To fill it in, open a saved profile, click ✦ Auto Generate from Repo to draft the fields from the repository, then correct each one by hand and click Save.

What is application context in a Cyberlop scan profile?

Application context is the part of a scan profile that tells the scan what your application is before it starts testing. It sits below the report filters in the Reporting section and holds ten free-text boxes: Overview, Tech stack, Frameworks, Sensitive data types, Trust boundaries, Tenancy model, Business-critical flows, Third-party integrations, Known endpoints, API spec reference.

None of the ten boxes is marked as required, and a profile with all of them empty still validates. The only error you will see when previewing is a missing name. The fields exist so you can hand the scan facts you already know instead of making it work them out. They are optional, and they are the cheapest way to improve a profile.

Why does application context improve scan results?

Context helps because a scan that knows your attack surface and how the app is meant to behave can tell a real flaw from normal behaviour. The in-app documentation says the first phase reads the repository and builds an architectural baseline of frameworks, entry points, data flows, trust boundaries, the authentication model and sensitive operations. Your context fields cover the same ground in your own words, and the app states that this text is sent to the AI engine after PII redaction.

What the scan cannot see for itself

Code shows what an app does. It does not show what your business considers dangerous. Three examples:

• A refund endpoint looks like any other endpoint until someone says refunds are the money flow.
• A tenant_id column is only a column until someone says each customer must never see another customer's rows (see tenant isolation).
• A field called notes could be harmless or could hold health data.

Your answers turn those guesses into stated facts. That matters most for flaws that depend on meaning, such as business-logic flaws and broken access control. They are common partly because an app's own rules are rarely written down where a tester can read them.

Why this matters for access control

Access control sits at number one in the OWASP Top 10. In the 2021 edition, 94% of the applications OWASP's contributors tested had some form of it, at an average incidence of 3.81%. In the 2025 edition, every application tested had some form of it, with an average incidence of 3.74% across 1,839,701 recorded occurrences. The OWASP API Security Top 10 puts Broken Object Level Authorization first for 2023 and rates its prevalence as widespread. A tester can only find these flaws if it knows who is supposed to own what. That is the job of the Tenancy model and Trust boundaries boxes.

Where context helps most

The gain is largest for authorisation and business-logic testing, and smallest for classes such as missing security headers, which look the same in every app. With only ten minutes, fill in Sensitive data types, Tenancy model and Business-critical flows.

Where context cannot help

Context does not replace logins. For tests behind a login, see Authentication roles. Context also does not change scope; use Focus and avoid rules for that.

How do you fill in application context?

You fill it in from the Reporting section of the profile form, either while creating a profile or while editing one. The ten boxes behave the same way in both cases.

1. Go to Scan Profiles and click + New profile, or open an existing profile with the pencil icon.
2. On a new profile, choose the target and enter a name in Scope. Save the profile once if you want to use auto-generation.
3. Switch to the Reporting section ("Report filters, context & engagement") and scroll below the report filters to Application context.
4. Click ✦ Auto Generate from Repo to draft the fields from the repository, or type into the boxes yourself.
5. Read every box and correct anything wrong or missing, using the field table below.
6. Click Preview YAML. The form validates and shows the generated configuration. A red message such as name: String must contain at least 1 character(s) means a required field is empty.
7. Click Save, then start a scan as described in Run a scan.

The profile's target is fixed after creation, so context belongs to one target. Put the facts of that application in it, not facts about your company in general. If you have not made a profile yet, start with Create a scan profile.

Application context field reference

The form shows no length limit or format rule, so write short, plain sentences. Describe the app. Do not paste secrets, real customer records or keys; the PII section below explains why.

What does good application context look like?

Good context is specific, short and true. It names the thing, says why it matters, and leaves out anything the code already makes obvious. Compare the weak and strong versions below.

Weak and strong wording

State the rule, not just the feature

A rule gives the scan something to test against. "Refunds are limited to the original charge" can be checked and found false. "The app handles refunds" cannot.

Describe roles in context, create them in Authentication

Writing "support staff can read tickets but not billing" in the context helps, but it does not create a login. Add a matching role under Authentication so the scan can reach those screens. See Authentication roles for the privilege levels and Form login authentication for the form-login fields. Described rules plus real test accounts are what let the scan check what each signed-in account can reach that it should not.

How does Auto Generate from Repo work?

✦ Auto Generate from Repo drafts the application context fields from the profile's repository, so you start from a filled form instead of ten empty boxes. It is disabled on a new profile with the tooltip "Save the profile first, then generate from its repo", and it is enabled once the profile has been saved.

1. Make sure the target has a repository. A target without one shows "No repository configured — add a Git repository URL to run a scan." See Connect a repository and Git access for HTTPS URLs and tokens.
2. Fill in the profile name and save it once.
3. Open the profile again with the pencil icon, switch to Reporting and click ✦ Auto Generate from Repo.
4. Read every generated box. Fix wrong claims and add what only your team knows.
5. Click Preview YAML, then Save.

This guide does not show the text the button produces, because it varies with your repository. Treat the output as a first draft that someone on your team signs off, not as an answer.

What the repository can and cannot tell you

What happens to personal data in application context?

The app redacts detected PII in application context before it is sent to the AI engine. A note under the section says: "Detected PII is automatically redacted before this context is sent to the AI engine." For report guidance and rules of engagement, the app lists emails, phone numbers, SSNs and payment cards as redacted, and keeps IPs and URLs so the scan can use them.

Redaction is a safety net. Write about kinds of data, not real values: "customer email addresses", not an actual address. If text you wrote comes back changed, you probably typed something that looked like personal data. See PII for the general idea and Reporting rules for the fields next to this one.

Does application context matter for black-box scans?

Yes, but you write it yourself. Auto-generation reads a repository, and a black-box target has none, so type the fields by hand. A white-box scan reads your code while it tests the running app, so it already learns a lot, and your context adds the business meaning. Read White-box vs black-box scans to choose between scan types.

A short context is fine for a first scan. Afterwards, open the Sitemap tab and check whether the endpoints you listed under Known endpoints appear (see Scan sitemap). If they do not, correct the context or the focus rules and scan again.

Troubleshooting: why is my application context not helping?

Most problems come from an empty or vague box, or from text that redaction changed. Match your symptom in the table.

Common mistakes

• Pasting real customer data, keys or passwords into the boxes.
• Generating once, never reading it, and never updating it as the app changes.
• Writing marketing copy in Overview instead of what the app does.
• Treating context as a limit on scope. It informs the scan; Avoid rules limit it.
• Describing roles in context but never adding them under Authentication.

What is the next step after application context?

Next step: see how to change a saved profile safely in Edit a scan profile. Then run the scan and read the results in Read a finding. When the app changes, update the context along with the code.