operate
Live Posture Scan On Your Deployed URL
External Header, TLS, Cookie, And DNS Checks Against The Running Site.
What you get
Checks The Running System, Not Just The Code
A code scan cannot see a missing HSTS header, an expiring certificate, a soft SPF record, or a dangling DNS record that invites subdomain takeover. ZipLoom checks the live, deployed URL — the surface an attacker actually sees.
Header, TLS, Cookie, DNS And Email Coverage
Security headers (HSTS, CSP, clickjacking, Referrer-Policy, COOP/COEP), TLS cipher grade and certificate expiry, cookie Secure/HttpOnly/SameSite flags, DNSSEC/CAA, subdomain-takeover exposure, and SPF/DKIM/DMARC — all passive and read-only.
Gate A Deploy On Critical Findings
The posture scan runs against the live URL right after a deploy. When the posture gate is enforcing, an un-triaged critical finding (like an expired certificate) blocks that deploy and rolls it back; when it is not, the finding is recorded and reported without blocking. Findings you have already accepted never block. Once an app is live, its URL is re-scanned on a schedule and new drift is reported to you, not rolled back automatically.
How The Posture Scan Runs
- 1
You deploy a project through ZipLoom.
- 2
After the deploy, ZipLoom runs external read-only checks against the live URL.
- 3
Findings are recorded against your project's posture history.
- 4
If the posture gate is enforcing and a critical finding appears that is not already dispositioned, the deploy is blocked and rolled back.
- 5
After launch, the live URL is re-scanned on a schedule; new drift is recorded and reported, not rolled back automatically.
What this check inspects
The deployed application as a stranger sees it — not the repository, the running site.
Response headers, TLS, and cookie flags as actually served in production.
Publicly reachable endpoints, including debug and admin paths that were never meant to be exposed.
Whether error responses leak stack traces, framework versions, or internal paths.
What it means when this fails
Code can be clean while the deployment is not. Posture failures mean the gap is in what you shipped rather than what you wrote — a debug flag left on, a header the platform didn't set, an endpoint reachable without a session.
Questions
- Why scan the live app if the code already passed?
- Because the runtime differs from the repository: platform defaults, environment variables, and build settings all change what a visitor can reach.
- Is this an attack on my own site?
- It's a read-only posture check — it inspects what your app publicly returns. It does not attempt exploitation or modify data.
- Can I run it on a site not deployed by ZipLoom?
- Yes, the public scan works against any URL you control.
What it replaces
Checkly Starter
Synthetic API and Playwright browser checks. Team plan $64/mo for all regions.
Better Stack Uptime
Uptime monitoring, on-call and status pages. Tells you it broke; doesn't roll the release back.
Snyk Team
Per contributing developer, 5-seat minimum (~$1,500/yr entry). Code + dependency scanning; does not deploy your app.
ZipLoom Solo — every deploy check included
Deploy, security scan, and monitoring in one flat price. Guild $40/mo · Studio $70/mo · LoomWorks $149/mo · Business $299/mo.
Related features