Skip to main content
Oliver hunts for real security problems in your app — a penetration test, or pentest — and shows you the proof for each one. You set the boundaries once — what to test, what’s off-limits, and what to sign in as — and Oliver tests as deeply as those allow.
Cyber is in beta. Find it under Cyber in the navigation menu.

​
Prerequisites

  • A domain you own, and the ability to add a DNS record for it.
  • Optional: a connected Git provider, if you want Oliver to read your source code.

​
Register your app

1

Open Cyber

Go to Cyber in the navigation menu and click Register your first app — or New app if you already have apps.
2

Describe the target

Enter an App name and a Target — a domain like example.com or an API base URL. CloudThinker suggests a matching OWASP framework (an industry-standard catalog of security risks): OWASP Web for a site, OWASP API for an API URL. Change it if the suggestion is wrong.
3

Create the app

Click Create app.Success state: the app overview opens with a Verify domain button. Verify the domain next — no pentest can run until you do.

​
Verify the domain

CloudThinker only tests sites you can prove you own. You do this once per domain, and every app on that domain reuses the proof.
1

Add the domain

Open Cyber → Settings. Under Verified domains, click Add domain (Manage domains once one exists) and enter the host in the Domain field.
2

Publish the TXT record

Copy the TXT name and TXT value, add them at your DNS provider, then click Check DNS. DNS propagation can take a few minutes, so retry if the first check fails.Success state: the domain badge reads Verified.
Verify domain dialog showing the TXT name and TXT value to publish

​
Set the boundaries

Open the app’s Settings tab. What you set here decides how much Oliver can find. Everything saves as you type — there’s no save button.
App Settings tab with domain verification, scope, context files, repositories, test identities, schedule, and default intensity

​
Attach a login

Attach two logins and Oliver can prove that one customer cannot read another’s data. Name them something like victim and attacker, and describe what each is allowed to see — that description is how Oliver knows which access is a bug.
Best for web apps. Sign in, open your browser’s developer tools, copy any request on the Network tab as cURL, and paste it in. Click Verify and attach — CloudThinker replays it to confirm the login works before saving.
Success state: the identity shows a Ready for testing chip.

​
How deep Oliver goes

The more you attach, the more Oliver can reach: nothing means black-box (only what a stranger sees), a login means gray-box (everything a signed-in user sees), a repository means white-box (the running app plus the code behind it). Oliver takes the deepest level available and shows it as an Access level badge in the run dialog. CloudThinker revalidates every stored identity before each run. If the credential for a gray-box or white-box run fails, that run fails instead of silently falling back to black-box; the schedule stays active and can use a new valid credential at its next occurrence.

​
Run the pentest

Click Run pentest. Everything lives in one dialog: Setup at the top repeats your target, framework, and scope — Edit setup › takes you back to fix a mistake before anything is sent. Most runs finish in a few minutes, and every run has a three-hour deadline.
Run pentest dialog with setup facts, intensity picker, access level badge, context, and schedule
Intensity decides how far Oliver goes:
Narrow Scope before running Full against anything you care about.
Access level shows how deep this run goes; Go deeper tells you what to add to unlock more. With a repository attached you also pick a Scan scope: Incremental prioritizes changes since your last successful run, Full sweeps the whole repository. Your first run is always Full. Then finish one of two ways:
  • Run now starts immediately and opens the workbench.
  • Schedule repeats it — Daily, Weekly, Monthly, No Repeat, or Custom — at a time you set, with an optional end date. Times keep the same local clock time year-round, so a run can land an hour off across a daylight saving change. Manage the schedule later from the app’s Settings tab.

​
Watch the run

The Timeline in the middle narrates each step as Oliver works. Confirmed findings appear on the right, leads that still need proof are labeled Needs verification, and past runs sit in Run history on the left.
Run workbench with run history, live timeline, and the findings rail
Stop run halts a run that’s doing something you didn’t expect. Confirm in the dialog: the run is cancelled and can’t be resumed, but every finding collected so far is kept. If the run finished just as you clicked, nothing is lost. When the run finishes, the full Report arrives and every confirmed finding lands in the app’s Findings tab — read the proof and work each one in Triage security findings.

​
Troubleshooting

The credential failed revalidation. Click Update login, remove the one marked Needs refresh, and add a new valid credential. The schedule stays active for its next run.
Your TXT record is missing, or DNS hasn’t caught up yet. Compare your DNS record against the TXT name and TXT value in the verify dialog, wait a few minutes, then click Check DNS again.
No Git provider is connected to your workspace yet. Click Connect provider, finish connecting, then reopen the dialog.
Incremental needs one successful run to compare against. Run a Full scan first; Incremental unlocks after it.

​
Next steps

Triage security findings

Read each finding’s proof, work the Kanban board, and export a PDF report

Cyber

See the workspace posture view and how the module fits together

Oliver

Meet the Security Engineer agent that runs your pentests and triages the findings

Connections

Connect the Git provider that unlocks white-box testing against your source