The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Vibesecure checks your github repo for common vibecoding mistakes. HOW VIBESECURE WORKS: 1. Clones the repository (shallow, --depth 1). 2. Detects technology stack (React, Django, Express, etc.) 3. Scans files (.ts, .js, .py, .json, .yaml) for security issues. 4. Applies 10+ modular security rules against the codebase. 5. Returns prioritized findings (CRITICAL > HIGH > MEDIUM)
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Challenges
View all
Related posts
I turned the checks I run on Lovable, Bolt and Replit apps into a small scanner.
Run one command in your app's folder and it lists the gaps that expose data or money, file by file: keys that end up in the browser, the Supabase service role in client code, tables without row-level security, Stripe webhooks nobody verifies, AI routes anyone can call.
It runs locally, has no dependencies, never uploads your code, and masks every key it finds. Add --ci and it fails the build when anything is red.
It is heuristics, not a guarantee. But it catches the things I look for in the first hour of an audit.
The checklist it is built on is free: https://contra.com/products/cTLDQhiJ-the-ship-check-list-what-to-check-before-real-users-pay
What is the first thing you check before a launch?
Built a highly responsive web application prototype focusing on smooth user interfaces and swift database connectivity. Optimized web performance to ensure rapid load times and cross-platform compatibility.
I built an AI support-ticket router on Replit, then tested it against the real model. Three things broke that no mock would have caught.
A silent failure. The first run sent 33 of 40 tickets to "needs a person". The newer Claude model rejects the temperature setting, and my code swallowed the error, so every call quietly failed. Now every failed call is logged.
The model thinks before it answers. With a tight token limit, some tickets got no answer at all and some draft replies stopped mid-sentence. Both have room now, and a cut-off draft is never saved.
One incident looked like four bugs. Four Safari checkout failures each got a different issue key, so the "3+ tickets, same problem" alert never fired. Sorting tickets in arrival order and asking for keys that name the problem rather than the customer turned them into one flagged incident.
If you're adding an LLM feature to your product, test it on real inputs early. The failures are rarely where you expect.
Live demo: https://sorta--krishnanbhupath.replit.app
