SecurVibe
Fast security checks for developers who ship fast
I’ve been building SecuVibe, a security toolkit for indie developers and small teams.
It started with ShieldScan: enter a domain and receive a security snapshot covering TLS, security headers, DNS, email configuration, cookies, technology exposure, and other externally visible signals.
While building it, I kept running into another problem:
A website can look reasonably secure while its public GitHub repository is exposing something sensitive.
So this week I expanded SecuVibe with a second tool: LeakCheck.
LeakCheck scans a public GitHub repository for recognizable credential and secret patterns. It reports the affected file and credential category, but deliberately does not return the secret value itself.
The first version was a basic exposure scanner. During this build, it grew into:
public GitHub repository scanning
optional comparison with a deployed domain
paid, token-protected full reports
downloadable PDF reports
report delivery by email
weekly ShieldScan and LeakCheck monitoring
score history and score-change alerts
one subscription covering both current and future SecuVibe tools
The most interesting product decision was treating ShieldScan and LeakCheck as two views of the same risk.
ShieldScan asks:
What can an attacker observe about the deployed application?
LeakCheck asks:
What has the development process accidentally made public?
Weekly monitoring then turns both point-in-time checks into something that can detect change.
A few lessons from this iteration:
1. Reporting is part of the product.
Finding a potential problem isn’t enough. The result needs context, a safe explanation, and a clear next action.
2. Security tools must minimize the sensitive information they reproduce.
LeakCheck identifies the pattern and location but avoids placing the discovered credential into the report, API response, or email.
3. A subscription needs an ongoing outcome.
“Run the same scan again” wasn’t compelling enough. Score history and change notifications make monitoring more useful.
4. Combining tools creates a positioning challenge.
I need SecuVibe to feel like one coherent security toolkit, rather than an unrelated collection of scanners.
The current implementation is four feature commits ahead of the previous version, and its automated test suite is passing 31/31 tests.
I’m now looking for feedback from indie developers:
Would you rather receive one combined weekly security summary for your website and repository, or separate alerts from each tool as soon as something changes?
You can try SecuVibe here: https://securvibe.ai/
Most security breaches aren't sophisticated attacks. They're a missing security header. An API key accidentally committed to a public repo. A cert nobody remembered to renew. Simple configuration mistakes — not zero-days — and most of the time, the developer had no idea the gap existed.
I built SecurVibe for indie devs and vibe coders shipping fast, often with AI-assisted code, without a security team or compliance checklist slowing them down. Most existing security tools weren't built for us — they're priced for enterprises and worded for auditors.
Right now SecurVibe does two things:
ShieldScan — checks your domain's SSL, headers, DNS, and email security, gives you a plain-language scorecard
LeakCheck — scans public GitHub repos for exposed API keys and secrets, without ever executing your code
Both start with a free scan, no signup needed. Full report with exact findings is $9 one-time. Ongoing monitoring across the whole toolkit is $10/month — new tools included automatically as they ship.
This is early. It's not trying to replace a pentest or a security team — just trying to catch the boring, common stuff before it becomes a headline. Would love feedback, especially from anyone who's been burned by exactly this kind of simple mistake before.
-
1
You draw a clear line between replacing a security team and catching the mistakes that happen before anyone realizes there's a problem.
Has there been a point where you deliberately chose not to expand the scope because it would change what SecurVibe is fundamentally meant to be?
-
1
Hey Aryan - Yes I considered expanding scope for LeakCheck (and DepCheck, which is in the works) beyond scanning public artifacts. Public-only scanning gives good but limited visibility. Real value would come from reviewing code, config, and app settings behind auth gate but that adds real adoption complexity.
My goal is consistent, low-friction visibility into the lowest-hanging stuff that often becomes the stepping stone for real incidents.
-
1
Appreciate the context.
The low-friction visibility angle makes sense as a clear boundary for the product.
-
-
Comment