Vulnerability disclosure policy

These are commitments, and they are deliberately unimpressive numbers. Loonext is run by one person. A policy promising a four-hour acknowledgement would read better and would be broken the first time a report arrived on a Saturday, and a disclosure policy that is wrong about its own timings is worse than one that admits to being slow.

Critical issues jump the queue. Everything above is a ceiling, not a target. We are glad to credit you by whatever name you prefer, and equally glad not to. We do not run a paid bounty — there is no money in this, and saying so up front is fairer than letting you find out after the work.

• Within 3 business days: we acknowledge your report and tell you we are looking at it. A human, not an autoresponder.
• Within 10 business days: we tell you what we found. That is an assessment, not necessarily a fix, and it includes saying "this is not a vulnerability" with our reasoning if that is the answer.
• Every 10 business days after that, while it is open, we tell you where it stands without being asked.
• When it ships, we tell you it shipped and on what date.

If you follow this policy, we will treat your research as authorised. We will not pursue legal action against you, we will not ask a hosting provider or a platform to act against you, and if somebody else raises the matter we will say that your work was authorised. That holds as long as you:

This is authorisation from us, for our own systems. It cannot and does not speak for our sub-processors, who are listed at /legal/subprocessors and each have their own policy.

• test only against a workspace you control,
• stop at the point you have proved the issue, rather than going further to see how much you could reach,
• do not degrade the service for anybody else, and do not run automated load against it,
• do not access, copy, or keep another business's data — and tell us at once if you encounter it by accident, so we can handle it as a breach,
• give us 90 days from your report before publishing, or less if we agree, or more if we ask and you agree.

Please test against your own workspace. Nothing here is worth reading somebody else's customer messages to demonstrate, and a proof of concept that touches another business's data is the one thing we would rather you had not sent. Out of scope: reports generated by a scanner with no working example, missing headers with no described impact, and anything that needs physical access to a person's unlocked phone.

• The hosted product — loonext.com, app.loonext.com, api.loonext.com.
• This repository, including anything committed to it that should not have been.

https://loonext.com/.well-known/security.txt (RFC 9116) carries the same contact address, and its Policy field points at /legal/vulnerability-disclosure, which is this document published as a page — one source, two places a researcher might arrive. security.txt is the authoritative copy of the contact address — a test fails if this file drifts from it, because two contact addresses is worse than one, and the wrong half is the one a researcher reads.

No SOC 2 and no completed third-party penetration test. Saying so here is cheaper for everybody than letting a buyer assume otherwise and find out during procurement. What does exist is described at /security, and it is implementation rather than intention.