DEV Community

lbcdsg
lbcdsg

Posted on

I built a small open-source scanner for API-key mistakes in vibe-coded projects

I started this project because vibe coding makes it possible to get an app
working before a beginner has learned how secrets, frontend bundles, or Git
history behave.

A value being in .env does not always mean it stays private. Variables such
as VITE_*, NEXT_PUBLIC_*, and REACT_APP_* can reach browser code. And if
an API key was committed, deleting it from the current file does not remove it
from Git history.

So I built Wardrail, a small open-source safety check:

npx wardrail scan --history
Enter fullscreen mode Exit fullscreen mode

It scans the current project and a bounded part of Git history. It also checks
MCP configuration and Agent instruction files for risky commands, credential
access, and safety-bypass patterns.

Wardrail runs locally by default. It does not upload source code and does not
execute the project being scanned.

What the current version includes

  • wardrail@0.3.0
  • 17 explainable static rules
  • 38 automated tests
  • Terminal, JSON, and SARIF output
  • Pre-commit and GitHub Code Scanning support

Why I think this matters for beginners

AI coding tools can help someone ship a useful application very quickly. But
speed can hide security assumptions:

  • .env is treated as automatically private
  • Public frontend variables are mistaken for server-side secrets
  • A deleted key is assumed to be gone from Git history
  • A third-party MCP server or Agent Skill is trusted without reading its commands

Wardrail is meant to be an early warning before a push or release. It explains
the matched evidence and suggests a fix instead of returning only a risk
score.

Honest limitations

This is still an early project, and I do not have external users to point to
yet. It can produce false positives and miss risks. It is not a penetration
test, and a clean report does not mean an application is secure.

It does not currently test authentication, authorization, database policies,
dependency vulnerabilities, deployment settings, or runtime behavior.
Gitleaks and TruffleHog are still mature choices for broader secret discovery.

I am looking for the first real testers

Repository and CLI demo:

https://github.com/3196973848/wardrail

The feedback that would help most is:

  • Which rule was noisy or confusing?
  • Which secret format or risky pattern did it miss?
  • Was the suggested fix understandable to a beginner?
  • Which MCP or Agent configuration should it support next?

Please share only a rule ID and a redacted example—never post a live
credential. If a real key may have been exposed, revoke or rotate it first.

Even a short report about what failed is more useful to me than a polite
"looks cool."

Top comments (0)