Learn the risks
The OWASP Top 10:2025, in plain English.
OWASP is the industry-standard list of the ten risk categories behind the most real-world application breaches. Here is what each one means, what it looks like in an app whose code was largely AI-written, and which parts of ShipLock cover it today and which don't.
Broken Access Control
Someone can see or change data they shouldn't be able to reach, a stranger reading another user's rows, or an anonymous request hitting an endpoint that should require login. In an AI-written app this is almost always a table with Row Level Security left off, or a route that never checks who is calling.
ShipLock coverage
The category ShipLock is built around. From your repository: every route traced to whether it identifies its caller and narrows the query to that caller, routes that change data without identifying the caller, and mass assignment; the merge check flags a new route that reaches data anonymously. With a Supabase project URL and anon key connected: tables readable without signing in, rows readable across users, the auth admin endpoint, and public storage buckets. With read-only database access: the policies themselves.
Security Misconfiguration
Settings shipped at their insecure defaults and never revisited, wildcard CORS, no HTTPS redirect, verbose error pages, missing security headers. Nothing was "hacked"; nobody ever changed the setting.
ShipLock coverage
Covered on your live site: a readable .env file, Git metadata, database dumps and credential files at fixed paths, public source maps, and whether framing and HTTPS-only are enforced (reported as information). From your repository: Next.js configuration that hands a server value to client builds, and GitHub Actions workflows with no stated permissions. With a Supabase endpoint connected: its CORS policy.
Software Supply Chain Failures
A dependency you pulled in, sometimes one an AI coding tool invented or mis-typed, turns out to be malicious, compromised, or simply doesn't exist and is sitting there waiting for someone to register it. See our incidents page for a real 2025 npm worm that spread exactly this way.
ShipLock coverage
Partial. Dependencies matched by package and version against public vulnerability advisories, and third-party GitHub Actions pinned to a moveable tag rather than a commit. Whether the vulnerable code path is reachable in your app is not determined.
Cryptographic Failures
Sensitive data transmitted or stored without adequate encryption, plaintext traffic, weak key management, secrets that aren't actually secret.
ShipLock coverage
Partial. A token or one-time code built from Math.random(), a credential carried in a URL query string, and secret keys committed to the repository or shipped in your site's JavaScript. Encryption at rest and key management are not assessed.
Injection
Crafted input reaches a query or command in a way the developer didn't intend, the classic SQL injection, plus its modern variants.
ShipLock coverage
Mostly not covered. SQL, command and cross-site scripting pattern checks were withdrawn: a per-file pattern cannot tell whether the value reaching a dangerous call is attacker controlled. With a Supabase endpoint connected, one probe checks whether a malformed filter makes the API return a raw database error.
Insecure Design
The vulnerability isn't a bug, it's the architecture. Missing threat modeling, a business-logic flow that was never designed with abuse in mind.
ShipLock coverage
Not covered. Business logic is a matter of intent, and no automated read of the code can judge intent. The questions further down are what to ask instead.
Authentication Failures
Weak session handling, credential stuffing with no resistance, brute-forceable logins.
ShipLock coverage
Partial. From your repository: whether each route identifies its caller, where a missing login check shows up. A service-role key in the repository or the shipped JavaScript is reported as critical. With a Supabase endpoint connected: whether five failed logins in a row are throttled, and whether a public key can reach the admin user list.
Software or Data Integrity Failures
Unsigned or unverified updates, a compromised build pipeline, deserializing data from a source you shouldn't trust.
ShipLock coverage
Partial. A pull_request_target workflow that runs a pull request's own code, third-party actions on moveable tags, and dependency advisories. Unsigned updates and insecure deserialization are not checked.
Security Logging and Alerting Failures
An incident happens and nobody finds out, no logs, no alerting, no one watching.
ShipLock coverage
We don't check whether your app logs correctly. Watching is what ShipLock adds: the merge check on every pull request the GitHub App reports, source checks at most every 48 hours, the live site every 48 hours and after a reported production deploy, and with a Supabase endpoint connected an hourly pass of its critical checks. New findings appear in your dashboard and to your agent.
Mishandling of Exceptional Conditions
Error handling that leaks internals, or business logic that fails open instead of closed when something goes wrong.
ShipLock coverage
Partial. With a Supabase endpoint connected: whether a malformed request returns file paths, line numbers or internal error detail.
Honest about the gap
What we can't check, and what to ask instead.
Business logic, deploy integrity, and whether anyone would notice if something went wrong are judgment calls, not configuration flags. We'd rather hand you the questions than pretend we already ask them for you.
Business logic (A06 · Insecure Design)
No scanner can read your intent, only a human, or an AI agent walked through your actual flows, can. For every flow that touches money, auth, or another user's data, paste this to your coding agent:
Walk through [flow name] end to end. For each step: what happens if this request arrives twice? Out of order? From a user who shouldn't be able to reach this step yet? Does the server ever trust a price, role, quantity, or user ID that the client sent, instead of computing or verifying it server-side?
Build & deploy integrity (A08)
This is about whether what ships is what you reviewed, not a database question, a pipeline one:
Review my deploy setup: is there a lockfile committed and enforced (not just present)? Does main auto-deploy without any review step? For every webhook receiver in this codebase (Stripe, GitHub, etc.), confirm the signature is actually verified before the payload is trusted, list any that aren't.
Logging & alerting (A09)
You don't need a SIEM. You need to know if something changed. Ask your agent to check for the absence of these, not add anything heavy:
Does this app log failed login attempts anywhere I'd ever actually look? Is there any alert if signups or database reads spike far above normal in a short window? If a background job or webhook handler throws, does that failure go anywhere besides a log I'd have to think to check?
See what these look like in your app.
Connect GitHub and ShipLock reads your repository, then your live site and database if you add them. Every limit is stated on the scope page.