Skip to main content
Oliver hunts for real security problems in your app 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.
App Pentesting is in beta. Find it under App Pentesting 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 App Pentesting

Go to App Pentesting from the navigation menu, then click Register your first app. If you already have apps, click New app instead.
App Pentesting landing page with the Register your first app call to action
2

Describe the target

Enter an App name and a Target — a domain like example.com or an API base URL like https://api.example.com/v1. CloudThinker suggests an OWASP framework from the target: OWASP Web for a site, OWASP API for an API URL. Change it if the suggestion is wrong.
New app dialog with App name, Target, and OWASP framework fields
3

Create the app

Click Create app.Success state: the app overview opens and shows No pentests yet, with a Verify domain button. Verify the domain next — you can’t run a pentest until you do.
App overview showing the No pentests yet setup hero

​
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 App Pentesting → Settings. Under Verified domains, click Add domain — or Manage domains if you have verified one before — and enter the host in the Domain field.
Verified domains section with the add domain dialog open
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 the most valuable thing of all: that one customer cannot read another’s data. Name them something like victim and attacker, and describe what each is allowed to see — their role, their team, the records they own. That description is how Oliver knows which access is a bug.
Best for web apps. Sign in, open your browser’s developer tools, find any request on the Network tab, copy it 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. You don’t choose this — Oliver takes the deepest level available and shows it as an Access level badge in the run dialog. One catch: browser sessions expire. An app with only a session tests as gray-box when you click Run now, but drops to black-box on a schedule, because the session dies before the scheduled run fires. Attach a long-lived token or a repository to keep the depth.

​
Run the pentest

Click Run pentest. Everything lives in one dialog. Setup at the top repeats your target, framework, and scope so you can catch a mistake before anything is sent — Edit setup › takes you back to fix it. Most runs finish in a few minutes and stop at 30.
Run pentest dialog with setup facts, intensity picker, access level badge, context, and schedule
Intensity decides how far Oliver goes — and how much it can change:
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. If you attached a repository, you also pick a Scan scope: Incremental checks only what changed since your last run, Full checks everything. 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 use your local time and keep the same clock time year-round, so a run can land an hour off across a daylight saving change.

​
Read the results

Watch the run happen. The Timeline in the middle narrates each step as Oliver works, findings appear on the right the moment they’re confirmed, and past runs sit in Run history on the left. The full Report arrives when the run finishes.
Run workbench with run history, live timeline, and the findings rail
Four tabs hold the results:
Overview tab with OWASP Web Top 10 coverage, findings by severity, and the CWE mapping list
Open any finding to see the proof. Summary says what’s wrong, Attack path shows exactly how Oliver got in, Safe PoC is the request you can replay yourself, and Remediation says how to fix it — Create PR with agent turns that fix into a pull request. A progress bar tracks the finding from Needs triage to Verified fixed. That last step isn’t yours to click: the next scan re-tests it and confirms the fix for you.
Findings table with search, severity and status filters, and columns for affected surface, OWASP category, severity, and status
Finding detail with the triage rail, summary, attack path, safe PoC, and remediation

​
Troubleshooting

Your session expired. Rather than quietly testing as a logged-out visitor and reporting less than it should, Oliver stops. Click Update login, remove the one marked Needs refresh, and add a fresh one. If this keeps happening, attach a long-lived token instead — those don’t expire.
Your TXT record is missing, or DNS hasn’t caught up yet. Compare the record at your DNS provider 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 compares against your last successful run, so you need one first. Run a Full scan, and Incremental becomes available after it.

​
Next steps

Oliver

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

Code Review

Catch the same classes of vulnerability on every pull request, before they ship

Security

Harden workspace access itself with MFA, SSO, and single-purpose API keys

Connections

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