Security Scan on Every Deploy

Catch RLS gaps, secret leaks, and CVEs before your app is reachable.

Real incident

The incident this prevents

Lovable CVE-2025-48757: 170+ applications built with the Lovable AI code generator were left with publicly readable databases. Root cause was a single unchecked Postgres setting — row-level security was never switched on. ZipLoom's RLS check would have caught this before the first deploy.

Source: Veracode · TechRadar · CVE-2025-48757

What you get

Row-level security enforcement

ZipLoom checks that RLS is enabled on every Postgres table before your app goes live. The Lovable CVE-2025-48757 incident (170+ publicly readable databases) and the Moltbook breach (1.5M authentication tokens) both traced to this single unchecked setting.

Secrets detection

Scans for API keys, database URLs, and auth tokens in your codebase and environment config before deploy. Credentials in source code is the most common initial access vector in cloud breaches.

CVE and license audit

Checks your dependency graph against known CVEs. Also flags dependencies with GPL or AGPL licenses that could affect your commercial distribution rights — a real issue for SaaS products built on open-source stacks.

Zero configuration

No YAML files, no scan configuration, no custom rules to maintain. The scanner runs automatically on every deploy based on your detected framework and package manager.

How it works

1
You push your code or trigger a deploy from your dashboard.
2
ZipLoom's scanner reads your dependency manifest (package.json, requirements.txt, etc.).
3
Four checks run in parallel: RLS verification against your Postgres schema, secrets pattern matching across your codebase and env config, CVE lookup against the OSV database, and license classification of your dependency tree.
4
Results appear in your deploy dashboard before traffic is routed to the new version.
5
If you've set up the GitHub Actions integration, a failed scan blocks the merge — not just the deploy.