THE FIRST 60 SECONDS: TIME-TO-FIRST-CRITICAL ON AI-BUILT APPS

This is a detection-floor catalog. The numbers per finding class below are reproducible wall-clock measurements against live deliberately vulnerable scenarios on the gapbench public benchmark — you can time the curl commands at the top of this page and observe the same floors. The detection floor is the latency lower bound: an attacker tooling up a similar probe is bounded by the same physics.

If your reaction is “that’s fast”, the unsettling implication is that an attacker is not slower.

Catalog scope

We do not publish a corpus-wide median or distribution because the underlying engagement set is anonymized and not a uniform random sample. The detection floors per class — which is what builders and tool-comparisons actually need — are reproducible against gapbench in seconds.

By finding class

The five fastest classes — bundle secrets, source maps, open Firebase rules, permissive RLS, RLS off — are the modal first-critical we observe across engagements. They are also the five classes that need zero authenticated probing to detect, which is the structural reason they always go first.

TTFC by detection technique

The same critical can be reached by different detection techniques. The technique determines the latency floor; pick the wrong one and the same finding takes ten times longer.

The class column in the previous table is the what; this column is the how. A scanner that lacks the two-session capability will report 0% BOLA findings — not because the bugs are not there, but because the technique to detect them is not in the scan.

CWE / OWASP mapping for the fastest-discovered classes

The five fastest classes — bundle secrets, source maps, open Firebase rules, permissive RLS, RLS off — are the modal first-critical we observe across engagements. Every one of them is “authorization or credentials, exposed at the static-parse layer.”

The CWE-862 / CWE-863 split is the dominant pair. The vast majority of fast-discovered criticals are missing or incorrect authorization — the scanner is not finding clever exploits, it is finding doors with no lock.

Per-platform modal first-critical

The class of finding that lands first on a typical app from each platform — driven by the platform’s default scaffolding, not by the scanner.

The class column is the answer to “what fails first on each platform”; the detection floor for that class is in the table above. Together they say: on Bolt, the floor is bundle-parse latency; on Cursor, you need to provision two test users before you can prove the modal issue.

A faster modal class is not better — it means the failure is shallower.

What this means

For builders: the failures that are findable in under a minute are the failures that are exploitable in under a minute. Time-to-first-critical is a credible upper bound on how long your app has to be public before an attacker tooling up a similar probe finds the same thing.

For researchers: the detection floors per class are a reproducible baseline. A claim that a new tool finds critical issues “faster” needs to beat these floors against the same gapbench scenarios — not against an unpublished corpus.

For investors and acquirers: when you are doing security due diligence on a vibe-coded SaaS, the time it takes to find the first critical is a useful informal scoring axis. A clean URL ten minutes in is meaningful signal; a critical inside thirty seconds is meaningful signal too.

Methodology

Source. Detection-floor measurements were taken against deliberately vulnerable scenarios on the gapbench public benchmark. Modal-class observations draw on anonymized customer engagements between Nov 2025 and Apr 2026.

Timer. Started on the first outbound request from the scanner against the target URL. Stopped on the moment a critical-severity finding was captured, replayed in sandbox, and confirmed.

Severity. CVSS 3.1 with the published rubric. Critical = 9.0+.

Equipment. Scans ran from us-east-1 over a one-gigabit connection. Latencies elsewhere will be higher; expect TTFC to scale roughly linearly with round-trip time on the bundle-parse-bound classes.

Calibration against ref0. Every probe is also run against ref0, a clean reference site. A probe that fires on ref0 is by construction a false positive and gets killed. The detection floors above are net of false-positive elimination — a probe that incorrectly fires within 5 seconds against a clean target would otherwise be the headline number, and is the primary reason most “fast scanner” claims do not hold up under scrutiny.

Reproduce on the public benchmark

Each detection class above can be reproduced against a live gapbench scenario. The TTFC floor is roughly the same against the gapbench scenarios as it is against real corpus apps — these scenarios are deliberately shaped to mirror the same failure surfaces.

For the manifesto-level argument behind this style of measurement, see Why we built gapbench and False positives and the ref0 control.

How to reproduce

Run VibeEval against any URL. The scanner displays a live timer and announces each finding as it lands; the first critical timestamp is preserved in the report.

Sources and references

• gapbench scenarios used as detection-floor anchors. indie-saas (secret in bundle), supabase-clone (permissive RLS), multi-tenant-saas (BOLA), fintech-app (BOLA on PATCH), mass-assignment, ssrf-open-redirect-oauth, ref0 (clean control).
• CVSS 3.1 severity rubric. first.org/cvss/v3.1/specification-document.
• OWASP API Security Top 10 (2023) and OWASP Top 10 Web (2021) for category mappings.
• CWE-798, CWE-862, CWE-863, CWE-639, CWE-538, CWE-915, CWE-601 for the per-class taxonomy.

Citations

VibeEval. The First 60 Seconds: Time-to-First-Critical on AI-Built Apps. May 2026. https://vibe-eval.com/data-studies/time-to-first-critical/

Related

• Pattern manifesto: Why we built gapbench
• Pattern walkthrough: False positives and the ref0 control — why the TTFC numbers are not just scanner noise
• Pattern walkthrough: BOLA in AI-generated CRUD — why BOLA detection is structurally slower than RLS
• Data study: 2026 AI App Security Benchmark
• Data study: Where Vibe Coders Leak Their Keys
• Data study: BOLA in AI-Generated CRUD
• Data study: Honeypot Supabase — time-to-abuse on the attacker side
• Guide: Solo Founder Pre-Launch Security Checklist