Vibe coding security audit, plus ongoing control as the code keeps growing
Vibe coding ships features in days, but AI tools rarely make the security calls along the way. I run a vibe coding security audit of auth, RLS, secrets, dependencies and infrastructure, then keep the code under ongoing technical oversight instead of stopping at a one-off audit.
- Baseline from 790 €
- Fixed monthly plans
- Auth + RLS + CVEs
- German point of contact
Direct point of contact
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director
I review code, security and infrastructure and surface what is technically risky before launch, customer use or due diligence.
I have delivered production software, infrastructure and cloud systems for clients worldwide, including Europe, the UAE, Asia, Australia and the Americas: from automated multi-location platforms and cloud migrations to remote access systems for industrial plants.
For questions like:
- Is this release production-ready?
- Which CVEs are really critical?
- Are auth, data access and tenant isolation clean?
What is a vibe coding security audit
In vibe coding, code emerges in dialogue with the AI: you describe, the tool builds. The result runs, but nobody deliberately decided on access control, data separation or dependencies. A vibe coding security audit looks exactly there:
Common vibe coding risks in AI-built code
AI tools produce working code fast, but they rarely make the security and operations decisions that real production needs. These are the vibe coding risks I find most often:
- Authentication without a roles and permissions model
- Supabase RLS not enabled or incomplete, other tenants' data visible
- API endpoints without server-side authorisation
- Secrets and API keys in the frontend or in the repository
- Unchecked dependencies with known CVEs
- Missing or shallow tests, regressions go unnoticed
- No monitoring and no logging when things break
- Missing rate limiting on open endpoints
Why a one-off audit goes stale fast
A vibe coding security audit describes a state on a fixed date. But in vibe coding the code moves faster than in classic development: you iterate daily, every prompt changes logic, and features appear in hours instead of weeks. What was clean yesterday can look different tomorrow.
Every new feature pulls new dependencies into the project, and new CVEs surface in those packages all the time. At the same time the architecture drifts: a quickly added route suddenly bypasses auth, a new table has no RLS policy, a key lands in the client during debugging. An action plan that is four weeks old no longer covers that movement.
A one-off audit is a sensible starting point, not lasting protection. That is exactly where I pick up: review once, then keep the code under ongoing technical oversight, instead of commissioning a fresh report after every major step.
The Veriploy model: baseline, monitoring, reviews
Instead of a one-off audit, I work in three steps so the security picture matches the speed of your vibe coding project:
- Baseline: one-off deep review of auth, RLS, secrets, dependencies and config as a reference point
- Monitoring: ongoing watch on new dependencies and CVEs with a prompt heads-up on critical findings
- Reviews: weekly or monthly human review of the changes, depending on the plan
- Risk dashboard: a current overview instead of a four-week-old PDF
- Release check: human judgement before larger releases instead of an automated score
- Async sparring: a direct channel for questions between reviews
How it differs from a penetration test
A penetration test simulates targeted attacks from the outside and looks for exploitable weaknesses in a running application. That is valuable, but it answers a different question than Veriploy.
A Veriploy vibe coding security audit looks into the code and the infrastructure: is the auth clean, do the RLS policies hold, are secrets exposed, are the dependencies current. So I check the substance, not just the external attack surface, and I do it continuously instead of once.
The two complement each other well. If you want to simulate targeted attacks, a pentest is the right building block. If you want to know whether your fast-growing AI code stays sound over time, Veriploy is the ongoing technical oversight for that.
Plans: Oversight, Guard, Launch
You start with a one-off baseline and then decide how tight the ongoing control should be. Prices are fixed and transparent.
| Oversight 990 €/mo | Guard 1.950 €/mo | Launch 3.900 €/mo | |
|---|---|---|---|
| Reviews | Monthly review of the changes | More frequent reviews with deeper assessment | Weekly reviews, close to the release cadence |
| CVEs and dependencies | Ongoing monitoring with a heads-up on critical findings | Monitoring plus a prioritised action recommendation | Monitoring plus a release check before larger deployments |
| Sparring | Async channel for follow-up questions | Async sparring with a shorter response time | Close exchange, almost like part of the team |
| Best for | Early products with a manageable pace | Actively used apps with real users | Fast-growing products before and after launch |
How the vibe coding security review works
- 01
01 Free fit check
A short conversation on whether ongoing control fits the project: stack, the pace of AI development and the biggest concerns. No cost and no obligation.
- 02
02 Scope and access
Defining what gets reviewed: repository, hosting, database and auth context. Read-only access is enough, sensitive data stays in your own system.
- 03
03 Technical analysis
A deep review of auth and the permissions model, data separation and RLS, secrets in the frontend or repo, dependencies with known CVEs, plus deployment and infrastructure. Deliberately a code and substance review, not an external penetration test.
- 04
04 Report and recommendations
A clear report with a risk dashboard, prioritised findings and concrete recommendations. Clearly separated into what to fix now, what to fix before launch and what to plan for later.
- 05
05 Next step
A Baseline as a reference point, then optional ongoing control with Oversight, Guard or Launch, so new CVEs and architecture drift do not go unnoticed.
Many projects start with a Baseline review. If the product keeps being built with AI afterwards, I can stay alongside it on an ongoing basis.
What I need for the review
- read-only access to the repository
- a short description of stack, tool and goal
- details on hosting and deployment
- database and auth context
- notes on sensitive data or user roles
- open questions or specific concerns
What the review delivers
- an understandable risk dashboard
- top risks at a glance
- prioritised findings
- concrete recommendations
- classification: fix now, fix before launch, plan for later
- an optional recommendation for Oversight, Guard or Launch
What a finding looks like
New API route /api/admin checks the role only in the frontend, the endpoint itself is open. Recommendation: enforce server-side authorisation.
One-off audit or ongoing control?
| One-off audit | Veriploy ongoing | |
|---|---|---|
| Timing | Point-in-time snapshot on a fixed date | Continuous, with every new change |
| CVEs and dependencies | State on the audit day | Ongoing monitoring with heads-ups |
| Architecture drift | Not covered | Risky changes are flagged early |
| Before a release | Another audit needed | Human judgement included in the plan |
| Assessment | Action plan at the end | Human prioritisation, not just a score |
Frequently asked questions
What is a vibe coding security audit?
A technical review of AI-built code and its infrastructure: auth, RLS and data separation, secrets, dependencies with known CVEs, plus deployment and monitoring. I do this review not just once but keep the code under review afterwards, because vibe coding projects change fast.
Is a one-off audit not enough?
As a starting point yes, as lasting protection no. In vibe coding every feature adds new dependencies, new CVEs surface all the time and the architecture drifts. An audit describes yesterday's state. I keep the risk dashboard current with monitoring and regular reviews.
Is this a penetration test?
No. I review repo, security, RLS, CVEs and infrastructure and keep them under ongoing review, rather than simulating targeted external attacks. A pentest can complement it well. I check the substance of the code and whether it stays production ready.
Which tools do you cover?
I review the result, not the tool. Code from Lovable, Cursor, Claude Code, Bolt, Replit, v0 or GitHub Copilot can be reviewed just like hand-written code. What matters is the repository, not the generator.
Do you also do the fixes?
Not within the plan. I review, prioritise and explain what needs to be done. Implementation runs separately through Wevelsiep Advisory or WZ-IT, or your own team. That keeps the review independent from the implementation.
What does it cost?
The entry point is fixed: Baseline 790 € as a one-off review. Ongoing control starts at 990 € per month (Oversight), then Guard at 1.950 € and Launch at 3.900 € per month. All prices net plus VAT. Ongoing packages start with a 3-month minimum term, then cancelable monthly, unless agreed otherwise.
- Get your Supabase RLS reviewed before user data leaks through the wrong policies
- Get your AI app reviewed, with ongoing technical oversight instead of a one-off gut check
- CVE monitoring for SaaS and AI-built software, with human prioritisation
- Make your AI app production-ready, spot technical risks before real users
Do you recognize these risks in your own app?
The AI-app risk self-check assesses product status, stack, auth, data access, infrastructure, CVEs and your technical knowledge, and shows whether a review makes sense.
Vibe coding security audit, then kept under review.
Start with the Baseline, then ongoing control in the plan that fits.
Check repo fit
Briefly describe the project.
Direct contact with me, no anonymous ticket system. I get back to you with a first assessment and the right entry point.
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director