Security Scan on Every Deploy

What you get

How it works

1. 1

   You push your code or trigger a deploy from your dashboard.

2. 2

   ZipLoom's scanner reads your dependency manifest (package.json, requirements.txt, etc.).

3. 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. 4

   Results appear in your deploy dashboard before traffic is routed to the new version.

5. 5

   If you've set up the GitHub Actions integration, a failed scan blocks the merge — not just the deploy.

What this check inspects

• Server-side code paths where user input reaches a database query, a file path, a shell command, or a template — the injection classes AI tools reproduce most often.

• Authentication and authorization checks on every route that reads or writes user-owned data, including routes an AI added late and never wired to a guard.

• Client bundles for credentials, internal URLs, and debug endpoints that were meant to stay server-side.

• Framework configuration — the defaults that are safe in development and dangerous in production.

Questions

Does this replace a penetration test?

No. A pentest is a human expert probing your specific business logic. This catches the mechanical, repeatable mistakes AI tools make — which is most of what goes wrong, but not all of it. Treat it as the floor, not the ceiling.

Will it block my deploy over something trivial?

Only critical and high findings gate a deploy. Lower-severity findings are reported with the fix and let the release through, so the gate stays meaningful rather than something you learn to bypass.

Does my code leave my repo?

The scan runs against your repository and your deployed app inside ZipLoom's pipeline. Findings are stored with your organization; your source is not used to train anything.

What it replaces