Cyber

Hacks you before hackers do. Cyber is the Frontier Investigation Agent for application security. It attacks a web application or API you own, audits the source code behind it, and keeps the evidence that proves each problem it finds. A scanner lists what might be wrong. Cyber proves it: a pentest finding is an attack it reproduced, with the requests and responses behind it, and a source finding carries the verification that decided it. A check it couldn’t run, such as a protected page with no test user, is marked limited rather than clean.

How it works

Cyber tests two surfaces. A pentest attacks the running app; a Code Audit reads the source behind it. A pentest run goes like this:

Stage	What happens
1. Register the app	You add an App: one application URL plus what to test, Web application or API. That choice sets which OWASP categories the coverage report measures.
2. Prove ownership	You publish a DNS TXT record for the domain. Cyber won’t run against a domain until it shows Verified.
3. Set the boundaries	You add optional test users, a repository, and API docs, then include or exclude paths and pick an intensity.
4. Attack	CloudThinker explores the app, tries attacks within scope, and records each request and response. You watch the run live and can stop it.
5. Prove and fix	Each finding carries its evidence. You triage it, open a fix pull request with the agent, and reverify or rerun to confirm the fix.

A Code Audit skips steps 1 to 3: you pick a connected repository and branch, and the audit scans the code, investigates what it finds, and verifies each candidate against the commit it pinned. It then follows that branch, re-auditing it on a schedule or on every push, and watches the branch’s dependencies for new library advisories. Click Cyber in the sidebar to open the overview: your apps, their latest results, and recent activity. The sidebar lists your pentest Apps and, under them, the Repositories Code Audit follows.

The Cyber overview page with recent activity.

Safety model

Cyber sends real attack traffic, so every run is fenced in by settings you control: the target, the paths it may touch, the test users it signs in as, and how hard it pushes.

Control	What it protects
Domain ownership	Runs are blocked until a DNS TXT record proves you control the domain. Only a workspace admin can claim and verify a domain.
Scope	Include and Exclude path rules. Excluded paths stay off-limits.
Intensity	How hard the run pushes, from Safe to Deep dive. See the intensity table.
Test users	Dedicated accounts you create for testing. Cyber signs in as them, never as your real users. A scheduled run signs in only with a Long-lived token user, so without one it can’t test or recheck anything behind the login. See Add test users.
Stop run	Cancels a run at any point. Findings already saved stay available. A stopped run doesn’t produce a run report.

Aggressive (the UI’s Recommended level) sends writes that create and edit test data. Full and Deep dive can permanently change or delete data inside the saved scope. Point anything above Safe at staging with test accounts, not production.

Before your first run

Settle these with your platform team before you launch, so the run isn’t blocked or paged on.

Question	Answer
Who can launch a run?	Workspace Admins and Developers. Viewers can only look. Any role that can run can pick any intensity, so limit who holds those roles. See Roles.
Where does the traffic come from?	CloudThinker’s cloud, not your network. This guide doesn’t list source IP ranges or an identifying header. If your WAF or IDS will block or alert on attack traffic, contact us for the current details first.
Can it test an internal or VPN-only app?	No. The target must be a domain name that CloudThinker can reach. IP addresses, CIDR ranges and `localhost` aren’t accepted as targets.
How long does a run take?	It depends on app size and intensity. Every run stops at three hours at most.
Does a run cost credits?	Yes. Every Cyber run uses credits, and Deep dive uses the most. A manual Deep dive run can take a credit limit. See Usage.
What data does Cyber keep?	The requests, responses, and screenshots that prove each finding, stored as evidence. Passwords, tokens, cookies, and keys are replaced with placeholders, but other response data is kept, so use test accounts with no real customer data. See Data protection.
Can I limit the request rate?	No. There’s no rate setting. To reduce load, narrow the scope or use a lower intensity.
Do I need permission beyond DNS proof?	Yes, if you don’t own the hosting. DNS proves you control the domain, not that you may attack the infrastructure under it. Check your hosting or cloud provider’s pentest policy and get written approval for third-party assets.

What you can do

Capability	What you get	Learn more
Run a first pentest	A Safe run against a few paths of a staging app, start to findings	Cyber quickstart
Follow a walkthrough	A scoped pentest on a staging app with two test users, the proof behind one finding, and a retest that confirms the fix	Pentest a staging app with Cyber
Configure and schedule pentests	Test users, scope, intensity, and recurring runs	Run a pentest
Go deep on complex flows	Deep dive mode for connected attack paths and business logic	Deep dive pentest
Triage findings	Table and board views, proof per finding, dismiss, fix, and retest	Triage findings
Share results	A PDF of selected findings or a run’s assessment document	Cyber reports
Test logins behind CAPTCHA	Test keys or a bypass for password logins	Handle CAPTCHA logins
Audit source code	A repository branch scanned, investigated and verified, then followed across commits	Run a Code Audit
Watch your dependencies	Library inventory per branch, advisory evidence, and impact on your own code	Monitor library vulnerabilities
Fix a problem	Cause, check and fix for common Cyber problems	Cyber troubleshooting

Key concepts

Term	Meaning
App	One saved target: a URL, its framework, access settings, findings, and run history
Access level	Set by what you provide. Black-box is public access only, Gray-box adds test users, White-box adds a repository, with or without test users.
Confirmed	A finding whose attack reproduced, with evidence attached
Needs verification	A candidate Cyber couldn’t prove yet. Treat it as a lead, not a vulnerability.
Stale	An app whose last completed scan is more than 30 days old
Tracked branch	One repository branch Code Audit follows across audits, keeping its findings and its library inventory

Get started

Cyber quickstart

Run your first pentest against a staging app

Run a pentest

Set up test users, scope, intensity, and schedules

Triage findings

Read the proof, fix, and retest

Run a Code Audit

Audit a repository branch and follow it across commits

Get started

Run tests

Results

Help

How it works

Safety model

Before your first run

What you can do

Key concepts

Get started

Cyber quickstart

Run a pentest

Triage findings

Run a Code Audit

​How it works

​Safety model

​Before your first run

​What you can do

​Key concepts

​Get started

Cyber quickstart

Run a pentest

Triage findings

Run a Code Audit

How it works

Safety model

Before your first run

What you can do

Key concepts

Get started