Security

How to report something, and what we already do.

LAST UPDATED 2 September 2026

Reporting a vulnerability

Email security@shipsure.space. You do not need to ask permission first, and you do not need to know who to address it to — that address is read by a human and is the right channel for anything security-related.

The same details are published at /.well-known/security.txt under RFC 9116, so automated tooling can find them without a person in the loop.

Useful things to include, none of them required:

  • What you did, in enough detail that we can do it too
  • What you saw that you should not have been able to see
  • Anything you think makes it worse or better than it first appears

What happens next

  • We acknowledge within 3 working days. If you have not heard back by then, assume the mail went astray and send it again.
  • We tell you what we found. Including if we conclude it is not a vulnerability, and why — a report we disagree with still gets a real answer rather than silence.
  • We tell you when it is fixed, and we are happy to credit you by name in the changelog if you want that.

ShipSure is a small team and does not run a paid bounty programme. We will say so plainly rather than let a report sit while somebody hopes for a payment that is not coming.

Testing we are fine with

  • Anything against your own account and your own organization’s data
  • Reading our client-side code, our API surface and our published artefacts
  • Automated scanning, within reason — see the limits below

Testing we are not

These are not legal boilerplate; each one either endangers a customer or costs us real money to clean up.

  • Accessing, modifying or deleting data belonging to anyone but you
  • Denial of service, load testing, or scanning heavy enough to be one by accident
  • Social engineering of our team, our customers or our suppliers
  • Physical attacks, and anything against our suppliers’ own infrastructure
  • Automated reports with no evidence of impact. A scanner’s output pasted into an email is not a finding, and we will say so.

If you find something that requires touching another account to confirm, stop and tell us what you have. We would rather take your word for the last step than have you take it.

What we already do

Stated so a report can be checked against it — and so anything below that turns out not to be true is itself worth reporting.

  • Your source code never leaves your machine. Verification runs locally through the CLI. What reaches us is metadata: file paths, check names, pass or fail, durations. Never file contents.
  • Passwords are PBKDF2 with 600,000 iterations, salted per user, with the work factor raised transparently on sign-in when it changes.
  • Session tokens are stored hashed. A database disclosure does not hand over live sessions.
  • Third-party tokens are encrypted at rest with AES-GCM under a key held outside the database.
  • Cross-tenant reads answer 404, not 403. Confirming a resource exists to somebody outside the organization is an enumeration oracle.
  • Secrets are redacted from captured output before it is stored — by token shape for the common providers, by credential-shaped assignments, and by any value the caller already knows is a secret. The environment a check runs in is an explicit allowlist rather than the parent process’s.
  • A strict Content-Security-Policy, HSTS with preload, frame-ancestors ‘none’, nosniff and a restrictive permissions policy on every response.
  • Card details never touch our servers. Payment fields are hosted by PayPal in an iframe we cannot read into; we store a vault reference and the last four digits.

What we know is not perfect

  • Verification runs on your machine, so a modified client can lie to us. The server re-evaluates every verdict it is sent and overrules a client that disagrees, but scope comparison happens in the CLI and a deliberately altered one could suppress a finding. This is inherent to running where your code lives, and we would rather write it down than let somebody discover it and assume we did not know.
  • We have no formal certification. No SOC 2, no ISO 27001. If your procurement requires one, we are not there yet and will tell you so directly.