The Monthly Security Audit: Your Ongoing Checklist
The App That Got Hacked Six Months After Launch
Marcus spent three weeks building his app. A booking system for independent yoga instructors -- clean UI, Supabase backend, Vercel deployment. He ran through every security article he could find before launch. He locked down his RLS policies, hid his API keys in environment variables, and even set up basic error logging. On launch day, everything checked out.
Six months later, a user emailed him. She'd noticed her dashboard was showing bookings from a studio she'd never heard of. Marcus dug in. Someone had found a new API route he'd added in month two -- a quick feature for a paying client -- that bypassed his authentication middleware entirely. The route had been live for four months. He had no idea how long it had been exploited.
Marcus's mistake was not a lack of knowledge. He knew the right things to do. His mistake was treating security as a launch checklist instead of an ongoing practice.
That is the problem this article addresses. Because the research is unambiguous: breaches rarely happen on day one. They happen when something changes and nobody notices.
Security Drifts. Yours Will Too.
Here is a fact worth sitting with: according to IBM's 2025 threat research, breaches from AI-generated polymorphic malware took an average of 276 days to identify and 73 days to contain (The Hacker News, December 2025). That is nearly a year from intrusion to containment. And the root causes are almost never exotic. The Secureframe analysis of 2025's biggest breaches found the same culprits again and again: "stolen credentials, misconfigured systems, unpatched software and insufficient monitoring" (Secureframe, December 2025).
In September 2025, attackers compromised 18 widely used npm packages -- including chalk and debug -- that were collectively downloaded over 2.6 billion times per week. The attack window was two hours. Organizations that were running automated dependency audits in CI caught it immediately. Those that only checked packages at launch had no idea (Qualys, September 2025).
The pattern is consistent: a one-time security check at launch is not a security posture. It is a starting point that decays the moment you ship your next feature.
The fix is not heroic. It is a 50-minute monthly appointment with your own app.
The Monthly Security Audit Checklist
Set a calendar event for the first Monday of every month. Label it "App Security Review." Block 60 minutes. Here is what you do with that time.
Dependencies (15 minutes)
Your app pulls in dozens of packages you did not write. Those packages have bugs. New bugs get discovered every week. Run these two commands:
npm audit
npm outdated
The first shows you known vulnerabilities. The second shows you how far behind you are on updates. Work through anything flagged as high or critical first. If npm audit fix does not resolve it automatically, check whether the parent package has a newer version that pulls in the patched dependency.
Also take two minutes to look at any new packages added this month. Ask yourself: who maintains this? When was it last updated? Does it have an unusually large number of permissions? A package that was legitimate when you installed it can be compromised by a bad actor who takes over the maintainer account -- exactly what happened with chalk and debug in September 2025.
If you want to automate this step, add Dependabot or Renovate to your repository. They will open pull requests automatically when new versions are available. Run npm audit as part of your CI pipeline so it fails the build on critical vulnerabilities.
Access and Authentication (10 minutes)
Back in Day 27, we walked through building Row Level Security policies in Supabase. Here is the thing about RLS: it only protects the tables that have it. Every time you add a new table, you need to add policies. Pull up your Supabase dashboard and check the Auth section. Are there any tables without RLS enabled that should have it?
Then check your API routes. Scroll through the code your AI assistant helped you write in the past month. Look for any new routes or endpoints. Do they all go through your authentication middleware? This is how Marcus got hit -- one route, added quickly for a client, skipped the auth check.
Finally, review your team access. If anyone left your project this month -- a contractor, a co-founder, a friend who helped for a weekend -- make sure their Supabase and Vercel access has been revoked. Lapsed access is one of the most common attack vectors in small projects.
Secrets and Environment Variables (10 minutes)
Day 22 covered environment variables in depth. This monthly check is about making sure nothing has slipped.
First, verify your .gitignore still includes .env and .env.local. It is surprisingly easy to accidentally remove a line during a merge conflict. Run this:
git check-ignore -v .env
If it returns nothing, your .env file is not being ignored. Fix that before you do anything else.
Second, scan your git history for accidentally committed secrets. Two tools are purpose-built for this:
# Using trufflehog
trufflehog git file://. --only-verified
# Using gitleaks
gitleaks detect --source .
If either turns up a real secret in your history, rotate that key immediately -- assume it is compromised. Then follow up with your git provider's secret scanning settings, which can catch this automatically going forward.
Third, open your Vercel dashboard and verify that your production environment variables match what your app actually needs. It is common for staging variables to drift out of sync with production during rapid development.
Logging and Monitoring (5 minutes)
Day 24 was about logging. Today's check is quick: open your error logs and look for patterns you have not seen before. A sudden spike in 401 errors might mean someone is probing your auth endpoints. A flood of 500 errors on a specific route might mean something changed that broke your API -- or that someone is fuzzing it.
Also verify that your monitoring alerts are still firing. Send a test alert if your platform supports it. Monitoring that silently stops working is worse than no monitoring at all, because it gives you false confidence.
One caution from Day 24 that bears repeating: make sure your logs are not capturing passwords, tokens, or personal information in plain text. Check any new logging statements added this month.
Infrastructure (10 minutes)
Check your SSL certificate expiration date. Most certificates auto-renew through Vercel or your DNS provider, but occasionally something breaks in the renewal process. An expired certificate does not just look bad -- it destroys user trust immediately.
Open your Supabase storage bucket settings and verify that no buckets are set to public that should be private. This is a common misconfiguration that can expose user-uploaded files to anyone with the URL.
Finally, verify that your backups are running and -- crucially -- test a restore. Backups that have never been restored are not backups. They are hopes. Pick one table, export it, and confirm you could recover from a data loss event. This takes five minutes and is the only way to know your backup strategy actually works.
The 50-Minute Investment
That is the full checklist. Dependencies (15 min), access and auth (10 min), secrets and environment (10 min), logging and monitoring (5 min), infrastructure (10 min). Fifty minutes once a month.
The vibe-coding movement has made it possible to build real, useful software without a computer science degree. That is genuinely exciting. But the security responsibilities that come with running software -- handling user data, managing API keys, controlling who can read what -- do not disappear because AI wrote the code. They shift to you.
Marcus rebuilt his app's auth layer in a weekend after the breach. He also set a monthly calendar reminder. He told me the reminder is the best piece of security advice he ever got.
Make yours recurring. Make it non-negotiable. The first Monday of the month. Your app will be there. Your users will thank you, even if they never know why.
Ask The Guild
Share your experience in the community: What is the most surprising thing you have found during a security audit of your own app? Have you discovered an open API route, a misconfigured storage bucket, or a secret that slipped into git history? Your story might save someone else from a difficult Monday morning.
This is Part 29 of 30 in the Security First series. Previous articles covered RLS policies (Day 27), structured logging (Day 24), and managing environment variables safely (Day 22).