Security writing hides behind its own vocabulary. These are the terms ShipSafe uses, and what each one actually means.

Pattern scan

The rule-based pass. 1347 detection rules across 24 frameworks look for shapes that are wrong on sight — a key committed in plaintext, a permissive CORS header, a database rule that lets any authenticated user read any row. It is fast, it is deterministic, and it cannot reason about your code. Every plan includes it.

AI deep scan

A second pass in which a language model reads the code itself: who is allowed to call this route, whether this check can be skipped, whether data crosses a boundary it should not. It catches the class of bug that has no fixed shape — broken access control, logic that trusts the client — which pattern matching structurally cannot see. It is metered, because it costs real money per run.

Finding

One issue, in one file, at one line. A finding carries its severity, the file and line, a plain-English statement of what is at stake, and a suggested fix. A finding is a report about a specific scan on a specific date. It is not a claim that anything has been exploited.

Severity

How bad this would be if someone found it: critical, high, medium or low. Severity describes impact, not certainty — a critical finding can still be a false positive, and a low one can still be the thing that gets you.

False positive

A finding that is not actually a problem — a key that is a test fixture, a route that looks unauthenticated but sits behind a gateway. Every scanner produces them. What matters is whether the vendor publishes the rate.

Precision

Of everything the scanner flagged, the share that was really a problem. Low precision means noise: you stop reading the results. Ours is published, including where it is worst.

Recall

Of everything that was really a problem, the share the scanner found. This is the number most vendors do not publish, because it is the one that counts the misses. Ours is on the benchmark page, per category.

Scheduled re-scan

An automatic re-run on a cadence, without you starting it. Available on the subscription plans that include it — Growth re-scans every week, and Shield re-scans every two weeks. A one-time audit is a photograph of one day; a re-scan is what makes it a smoke alarm.

Verification badge

A public badge you can embed, backed by a page showing what the most recent scan of that repository found. It states a scan result on a date. It is not a certification, and it expires on its own face if the re-checks stop.

Fix prompt

A copy-paste instruction written for the tool that built your app — Cursor, Claude Code, Lovable, Bolt — describing the fix in terms of your actual code. You paste it in, the tool writes the change, you review it.

Fix pull request

On a plan that includes it, ShipSafe writes the patch itself and opens a pull request on a branch it creates. It never commits to your default branch, and nothing merges without your approval.

Locked findings

On a free scan, the 3 most severe findings are shown with their title, severity, file and plain-English risk. The remaining findings, and the exact line and fix for all of them, require payment.

Live URL scan

A check against a deployed application rather than a repository: security headers, content security policy, exposed files, and secrets shipped to the browser in client-side code. It only reads what a browser would already receive.

Active validation

Checks that go beyond what a browser would request — asking for paths your app never linked to, to see whether they are readable. These run from your own machine, at a target you confirmed you control, and never from our servers. That boundary is deliberate and permanent.

The precision and recall figures behind these definitions are published, per category and including the misses, on the detection benchmark. How the scan works is set out in the methodology.