Security

Last updated: 10 September 2026.

If you have found a security problem in one of our apps or on this website, we want to hear about it, and we would rather hear about it from you than from a customer. This page says where to send it and what you can expect back.

Reporting a vulnerability

Email support@rditproducts.com. Tell us what you found, where, and the steps to reproduce it — a proof of concept, a request, or a short screen recording is worth more than a scanner report. If it helps, say what you think the impact is; if you are not sure, send it anyway and we will work it out.

Please do not include customer data, credentials or personal data in your report. If demonstrating the issue required you to see any, tell us that you saw it and delete your copy — do not send it to us.

What you can expect from us

RDIT Products is one person, not a security team, and we would rather tell you that than publish response times we cannot keep. We will acknowledge your report within five working days, tell you within ten working days whether we can reproduce it and what we intend to do, and keep you informed until it is closed. If a fix requires a new app version, we will tell you when it ships.

We are happy to credit you by name on this page when an issue is fixed, if you would like that. Say so in your report; the default is that we do not name anyone.

We do not run a bug bounty and cannot offer payment. That is a limit of the size of the business, not a judgement about the value of your work.

What is in scope

The apps we publish on the Atlassian Marketplace, and this website. That is the whole of what we run.

Two things are deliberately outside it. The Atlassian Forge platform itself — the compute, the storage and the tenancy isolation our apps run inside — belongs to Atlassian, and issues in it should go to Atlassian's own security team. Your own GitLab instance is yours; we never connect to it, and we cannot act on findings about it.

Testing: what we ask

Test against your own Atlassian site and your own GitLab instance, never against another customer's. Please do not run denial-of-service or load tests, do not attempt social engineering of us or of anyone else, and stop at the point where you have proved the issue rather than going further into data that is not yours.

Give us a reasonable opportunity to fix the issue before describing it publicly. We will not ask you to stay quiet indefinitely, and we will not treat a disagreement about timing as a hostile act.

Good-faith research

If you follow the guidance above, we will treat your work as good-faith security research: we will not pursue legal action against you, and we will not report you for it. This is our own commitment about our own systems. It cannot bind Atlassian, your employer, or anyone else whose terms you may also be subject to.

How the apps are built

The security properties specific to each app — what it stores, for how long, which permissions it holds and which it deliberately refuses — are set out in that app's annex, alongside the Data Processing Addendum. In short: our apps run entirely on Atlassian's infrastructure, in the region of your own site, and hold nothing outside it. There is no analytics and no error reporting in the data path. Credentials are never written to logs, in any environment.

We will never ask you for a GitLab administrator token, a shared secret or a web trigger URL, and we cannot use them. If any message appearing to come from us asks for one, it is not from us — please report it to the address above.

If personal data is affected

Where a security incident is a personal data breach affecting data we process for a customer, our notification obligation and its timing are set out in the Data Processing Addendum. Reporting an issue here does not replace that route, and nothing on this page changes it.

We will update this page, with a new date, whenever any of the above changes.