Security checklist before shipping a vibe-coded app

Before shipping a vibe-coded app, identify the exact release commit, scan it, and test its access boundaries, secret handling and failure paths in a controlled environment. Use vetkit’s findings as evidence to review alongside your tests and deployment configuration. A passing scan is not proof that the running app is safe or ready to release.

This checklist is for the release decision after code review. For line-by-line review of an assistant’s changes, start with the AI-generated code review checklist. Keep the evidence below with the release so another person can tell what was checked.

1. Tie evidence to the release

• Record the commit SHA and the build artifact you plan to deploy.
• Verify that the audit report names the same commit. A report for an older branch tip does not cover later fixes or generated files.
• Build and run the project’s tests from that version using a controlled configuration and synthetic data. Preserve the actual command results, including failures and skipped tests.

2. Check what actually ran

Security Quick Scan includes posture, secret detection with gitleaks and dependency checks with OSV. Broader audits can include additional checks where your account and selected scope allow them. vetkit’s release template selects checks for areas such as static security analysis, infrastructure, workflows and operability, but it is not every available analyzer. For example, secrets-history and llm-app are separate from that template’s selection.

A partial report means one or more analyzers did not complete and affected categories may be under-reported. Resolve relevant coverage gaps or document the alternative verification before relying on the result.

3. Exercise access boundaries

In a test environment, create two ordinary accounts and an account with elevated privileges. Try reading and changing one account’s records as the other account, and call protected endpoints while signed out. Check that the server rejects unauthorized operations even when the browser interface hides the button. Include file downloads, exports and background operations that use the same data.

For a Supabase-backed app, review deployed row-level security and storage policies with synthetic records. vetkit’s vibe-stack rules can flag supported source patterns such as missing or permissive row-level security policies and public storage buckets. Source inspection does not establish the current configuration of your hosted database or prove tenant isolation.

4. Check secrets and browser assets

Review secret findings, public environment-variable prefixes and the generated browser assets. Keep provider and service-role credentials server-side. A repository audit cannot see a deployment secret that is absent from the scanned files, and it does not automatically inspect your deployed browser bundle. If a credential was exposed, revoke or rotate it; removing the source line is not enough. The leaked-secrets guide explains the separate repository, history and browser checks.

5. Review dependencies and AI features

Use the lockfile intended for the release and review dependency findings. A known-vulnerability lookup cannot establish that an unfamiliar package is trustworthy. Check newly introduced package names and their provenance; see the hallucinated-package guide.

If your app calls an LLM, test what happens with oversized input, provider errors and output that requests a privileged operation. Set server-side usage limits and require authorization around tools that change data. vetkit’s llm-app rules identify supported patterns such as model output executed as commands or SQL and user-driven calls without an output token limit. They do not demonstrate that every prompt-injection attempt will fail or measure your production spending controls.

6. Test failure paths and recovery

• Simulate a dependency timeout and a failed write. Verify that the user receives a useful failure state and that retrying does not silently duplicate the operation.
• Check the production start command, health reporting and error reporting. Use synthetic failures to confirm that the intended operator can notice a broken release without logging credentials.
• Rehearse the rollback or recovery procedure in a test environment. If the release changes stored data, verify the recovery path separately; reverting application code may not restore that data.

vetkit includes static rules for patterns such as outbound calls without timeouts, development servers in production start commands and potentially destructive schema synchronization. These findings can direct your review, but the audit does not execute this failure rehearsal or restore a backup for you.

7. Record the release decision

Keep the commit, build identifier, audit scope, test results and deployment checks together. Resolve exposed credentials and demonstrated unauthorized access before shipping. For remaining findings, record the evidence, impact, decision owner and follow-up date. If a relevant analyzer failed or a critical behavior was never tested, make that gap explicit instead of treating silence as approval.

Sources and limits

Checked on November 1, 2026 against vetkit’s Quick Scan configuration, audit templates, report formatter and vibe-stack, llm-app, resilience, data-access and operability rules. The public check catalog describes first-party rules and their supported languages; the documentation describes audit setup. Analyzer availability, supported patterns, scan limits and selected scope affect coverage.

The manual checks here are work for your team, not claims that vetkit performs live penetration testing, executes your application’s test suite or certifies a release. A source audit cannot verify every production permission, deployment setting or business requirement. Keep those checks in your release process even when the report has no findings.