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. 1359 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 it for me, with a receipt
- One click on a scan of a GitHub repository you can write to. ShipSafe writes every fix it can, re-checks each file it changed, and sends the changes to your GitHub as one pull request — GitHub's page for approving a change — for you to approve. Nothing changes in your code until you approve it, whether in ShipSafe (which then applies that one change for you, under your own account) or on GitHub yourself. Nothing is scheduled: no fix is written, sent or applied without that click. Part of every subscription plan (Solo, Shield, Growth); not part of a one-time audit.
- Fix receipt
- What comes back from Fix it for me: three counts, the findings behind each named, and two more lists. The counts — fixed and re-checked; still there; could not be re-checked; re-scan after you approve. The other lists — not attempted and dependency updates to run. "Fixed and re-checked" means the re-check no longer detects the finding in that file; it does not establish that the vulnerability is gone, and it says nothing about the rest of your code. The whole receipt is on the scan page; the counts and every list but the fixed one arrive by email when the run finishes unless you have turned email notifications off in Settings (the fixed findings are named on the scan page, and are the change itself on GitHub); on a public repository the page on GitHub carries only the three counts and a link to the scan page. Not the same thing as a scan receipt.
- Scan receipt
- The public page for one scan, at a link only you can publish: what was scanned, when, and how many findings at each severity — never the findings themselves, their paths, or any secret. It shows a scan result on a date, read live from ShipSafe's own record, so the numbers cannot be edited on the way to whoever you send it to. You can unpublish it from the scan it belongs to. Not the same thing as a fix receipt.
- 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.