Vibe App Scanner: turning checks into useful findings

Vibe App Scanner is a Thunkle-owned security product. This is an engineering case study about how findings become useful to someone fixing an application—not a client audit, a disclosure of an unresolved issue or an independent certification of the scanner.

Visit Vibe App Scanner to see the product. For contextual source review and authorized tests of your own application, Thunkle's paid security audit is a separate service.

A scan needs more than a list of warnings

A developer must be able to distinguish an exposed credential from public configuration, understand where a finding came from and decide whether the proposed change fits the application.

That creates a product requirement: a finding needs evidence, impact and remediation, not simply a red label. Useful automation reduces repetitive investigation while leaving room to validate what a result means for the product.

Separate the request from the scanning work

The repository separates the web interface, API and background scan processor. Shared scanner code supplies the checks, while queued work handles the longer-running processing.

This separation lets the product represent a scan as work with a lifecycle rather than one browser request. It also provides a common place to dispatch checks. The documented rerun path uses the same worker scanner dispatch as ordinary scans, reducing the chance that a second execution path silently uses different logic.

The presence of a queue is not, by itself, a reliability guarantee. The important design question is how the same job contract is used consistently across normal work and reruns.

Public configuration is not automatically a secret

The secret-scanning implementation includes checks for known public-key patterns and contextual handling before treating a match as a credential exposure.

This matters for technologies such as Supabase and Firebase, where some identifiers are intended to appear in client applications. Hiding a publishable key does not establish that the underlying data permissions are correct; finding that key is not enough to claim a breach.

The Supabase key guide explains the distinction. The relevant question is what authority a value grants and whether it reached an unintended audience.

Remediation needs conditions, not just commands

The repository's remediation guidance distinguishes the recommended change from checks to make before applying it. A proposed browser policy can affect features that the application legitimately uses.

For example, a cookie or cross-origin policy change needs to account for the app's sign-in and integration flows. A fix that removes the warning but breaks login is not a finished outcome.

That is why a developer should read the evidence, understand the affected workflow and run appropriate regression checks. Automation can identify important gaps; applying a recommendation still requires context.

Findings must remain connected to evidence

The scanner's finding structure includes severity, description, remediation and evidence. Those fields serve different readers: an owner deciding priority, a developer locating the behaviour and a reviewer checking the change.

A severity label without a reproducible explanation leaves too much work for the recipient. Equally, an observed configuration difference should not be presented as confirmed data exposure without supporting evidence.

Our illustrative audit report shows how a human-reviewed finding can state the business rule, demonstrate the observed result and define the re-test.

The boundary between a tool and an engagement

A scanner can examine its supported surfaces and report what it observes. A paid audit defines the application's intended permissions, the agreed access and the workflows to validate. These are complementary uses of evidence, not a claim that automated tools cannot find authorization problems.

A two-account test, for example, needs the expected sharing policy. Two people seeing the same record can be correct in a shared workspace and wrong across unrelated customers. The product rule determines the expected result.

What this case study establishes

The account is grounded in the repository's API/worker structure, shared scan dispatch, secret-context checks and remediation guidance. It makes no new claims about detection accuracy, customer counts or reduction in security incidents. It is not a comprehensive review of the product.

If your app handles private data, payments or staff privileges, request a developer-led audit. We agree the test scope and deliver evidence-backed findings, remediation guidance and a free re-review of agreed fixes. Implementation is scoped separately, and no audit can guarantee the absence of every vulnerability.