Ship daily. Pentest each deploy. Introducing CloudThinker AppSec

The pentest report arrives on a Tuesday. It's thorough, and it describes a version of your app that was retired eleven releases ago. Since the testers signed off, the team has shipped a new invoices API, a tenant-switching feature and two dependency upgrades. None of that has been tested by anyone who thinks like an attacker, and none of it will be until the next engagement in six months.

An annual pentest can't keep up with code that changes hourly. CloudThinker AppSec is a pentest team that tests every release, proves each finding with a safe real exploit, then opens the fix as a merge request.

Today we're introducing AppSec, a new module from CloudThinker, which builds Frontier Investigation Agents. It turns application penetration testing from a point-in-time engagement you buy once or twice a year into continuous assurance that runs on every deploy. It's driven by a governed Security Agent, bounded by rules you set, and delivered as evidence and a patch instead of a PDF.

---

The problem: security coverage decays after every untested release

Manual application pentests are usually scheduled once or twice a year. The result is a point-in-time view of a system that no longer stands still. AI-assisted development has compressed the release cycle by three to five times, and every new route, dependency and deploy reshapes the attack surface the moment the last report was written.

The gap isn't a lack of testing. It's the untested time between a code change and the next scheduled assessment:

• Common cadence: once or twice a year. A strong report still describes the version that was tested, not every release that ships afterward.
• Every deploy changes risk. New code, routes and dependencies age static coverage immediately.
• Typical report lag: 2 to 4 weeks. Findings arrive after the engagement, then still need triage, reproduction and routing.
• Coverage goes stale after one deploy. One release past the tested snapshot, the report is already describing history.

---

Why today's options don't close it

Speed, depth and continuity rarely come together in one tool, and the reasons are structural.

Automated scanners are fast, continuous and strong at pattern detection. They match signatures against responses, so they can't tell a reachable bug from a theoretical one and their queues fill with noise that has no runtime proof. Auth flows and business logic, where tenant isolation bugs live, are mostly out of reach for a tool that doesn't know who's allowed to see what. And they stop at an alert that an engineer still has to investigate.

Human pentests are deep and contextual, and they're excellent at creative attack paths. Their limit is capacity: a skilled tester's time is scheduled in weeks, so they run when the calendar allows, not when the code changes. The tested snapshot ages after the next release, and remediation still lands on your team as a PDF.

CloudThinker AppSec complements both: continuous agentic testing, safe proof-of-concept validation, and remediation evidence routed into the workflow you already use.

---

What AppSec is

Continuous application pentesting, driven by a governed Security Agent. Three properties define it:

01Tests every release

CI/CD triggered

A merge or post-deploy webhook starts a fresh test against the approved target.

02Proves every finding

Proof-gated

Each candidate is confirmed with a safe proof-of-concept before it reaches your queue.

03Ships the fix

Patch, not a PDF

Evidence, code context and a suggested patch arrive as a merge request.

---

The assurance loop: Discover, Prove, Route, Retest

AppSec is a loop, not a scan. Every retest updates posture and creates an auditable record of what was found, changed and verified.

01Discover

Map the surface

Endpoints, roles and inputs, re-mapped on every deploy.

02Prove

Safe exploit

Each candidate is validated with a read-only proof-of-concept.

03Route

Owner and patch

Source context, severity, owner and a suggested fix for review.

04Retest

Close on proof

The exploit re-runs after the merge. The finding closes only when it fails.

1. Discover. Maps endpoints, roles and inputs, then re-tests on every deploy. No scheduling required.
2. Prove. Validates each candidate with a read-only exploit. Only proven, ranked findings surface.
3. Route. Adds source context, severity, owner and a suggested patch, ready for engineering review.
4. Retest. Re-runs the exploit once the fix merges, and closes the finding only when it can no longer reproduce.

One finding, end to end

Take the new invoices API from the opening. Discovery maps GET /api/invoices/{id}, notes that invoice IDs appear in responses to other calls, and that two test identities in different tenants can both reach the route. That's a candidate for broken object level authorization (BOLA), and there are three ways it could go:

1. Ownership is checked. A tenant A token asking for a tenant B invoice gets a 403 or 404. No finding.
2. Ownership is checked at the gateway only. The direct service route returns data, the public route doesn't. A finding, with a narrower blast radius.
3. Ownership isn't checked anywhere. The public route returns another tenant's invoice. A high-severity finding.

The proof is a single read, replayed with the scoped test identity. The shape of it:

# Tenant A's test token, tenant B's invoice ID (read-only, no state change)
curl -s -H "Authorization: Bearer $TENANT_A_TOKEN" \
  https://staging.example.com/api/invoices/inv_tenant_b_0042

The response comes back 200 with tenant B's invoice in the body. Reading three is confirmed, with no data changed:

The same finding arrives with a code-level remedy, opened as a merge request against the exact file and line:

Once the fix merges and deploys, the Retest step replays the same request. It now gets a 404, so the finding closes, and the record shows the proof, the patch and the failed replay side by side.

---

Specialist tests, one governed workflow

AppSec isn't a single monolithic scanner. A Security Agent orchestrator coordinates specialist tests and routes evidence across the surface:

• Code and web: SAST, DAST and attack-path chaining.
• Infrastructure: cloud, containers and configuration.
• Knowledge: data, APIs and business logic.
• Identity: IAM, tokens and credentials.

Each specialist is scoped to a clear part of the attack surface, and the orchestrator correlates their low-severity findings into the multi-stage attack paths a real pentester would chain. A verbose error message, an enumerable ID and a missing ownership check are three low findings on their own. Chained, they're one critical.

---

You stay in control

You choose the depth, scope, access and cadence of every run. Four dials govern how AppSec behaves:

• Intensity: Safe, Aggressive or Full. Controls whether the agent only reads, also writes test data, or exercises destructive paths. Safe is read-only with zero blast radius; Aggressive creates test records to reach deeper bugs; Full exercises destructive flows for maximum coverage.
• Scan scope: Incremental or Full. Test only what changed since the last run, or re-test the entire surface end to end.
• Access level: Black-box to White-box. Attach a scoped test identity, and optionally source, so the agent tests the way an insider attacker would.
• Schedule: On deploy, Daily or Weekly. Move from a one-off run to a recurring cadence that turns pentesting into continuous assurance.

Recommended defaults: run Safe on shared environments and Aggressive on dedicated staging; reserve Full for throwaway test environments. Pair Incremental on every deploy for speed with a Full scan weekly to catch drift and score posture. Gray-box is the sweet spot for most apps; use White-box for critical services where you want fixes drafted against real source.

---

Why aggressive stays safe

Safety is visible, scoped and auditable at every layer:

01Ownership

Verified targets

Only domains and targets you can prove you control are ever tested.

02Scope

Rules of Engagement

Hosts, paths, identities and allowed actions are explicit before a run.

03Execution

Isolated sandbox

Each task runs with strict egress policies, inside the scope it was granted.

04Access

Ephemeral

Scoped credentials are revocable, and task storage is destroyed after the run.

05Data

Guardrails

PII detection, schema enforcement and injection defenses bound every request.

06Oversight

Approval and audit

Actions are RBAC-gated, and every step lands in an exportable, tamper-evident trail.

No agent is installed inside your cluster. CI/CD triggers the run, approved connections provide context, and evidence flows back into your existing systems.

---

Where it lands

The point of AppSec isn't to replace human depth or scanner speed. It's to close the untested time between them.

The deeper difference is where the proof lives. A scanner hands you a hypothesis and a pentest report hands you a snapshot. AppSec hands you a reproduction that re-runs on the next deploy, so "fixed" means the exploit stopped working, not that someone closed a ticket.

---

How it fits your workflow

01Source and CI

Your pipeline

• GitHub and GitHub ActionsDiff and post-deploy trigger
• GitLab and GitLab CIDiff and post-deploy trigger

Reads the diff

02Testing

CloudThinker AppSec

• Security AgentCoordinates specialist tests
• Safe proof-of-conceptInside your Rules of Engagement
• Suggested patchAgainst the exact file and line

No agent in your cluster

03Targets

Verified scope

• AWS and Amazon EKSScoped test identity
• AzureScoped test identity
• Google CloudScoped test identity

Ownership verified

04Where the team works

Evidence

• SlackProof and owner
• Microsoft TeamsProof and owner
• JiraSLA and remediation

Plus email and Inbox

• Source and CI: GitHub, GitLab, GitHub Actions, GitLab CI. AppSec reads the diff and triggers after deployment.
• Targets and identity: AWS, Azure, GCP, Amazon EKS and APIs, with verified targets, scoped identities and explicit Rules of Engagement.
• Evidence and workflow: Slack, Microsoft Teams, Jira, email and the CloudThinker Inbox, carrying proof, owners, SLAs and suggested remediation.

---

Getting started

Start with one scoped run and expand only after the evidence earns trust:

1. Verify and scope. Verify ownership; define in-bounds hosts, paths, identities and allowed actions.
2. Run the first test. Trigger a sandboxed run against staging and review only proof-backed findings.
3. Approve the rules. Tune scope, credentials, severity policy and routing with security and engineering.
4. Add the CI/CD trigger. Fire after deployment and route evidence into Slack, Teams, Jira or the CloudThinker Inbox.

Some prompts to start the first run with, in plain language:

"Run a Safe, incremental test against staging for the routes changed in today's release, and show me only findings with a working proof."

"Check the invoices and tenant-switching endpoints for cross-tenant access using the two scoped test identities."

"For every open finding, draft the patch against the source and open it as a merge request for the owning team. Don't merge anything."

No agent is installed inside your cluster. Start with staging, keep human approval in the loop, and expand scope only after the evidence earns trust.

Ship daily. Pentest each deploy. Explore CloudThinker AppSec or talk to our team to see whether it's a fit for your stack.