Reporting a vulnerability

Where to send it

Email security@mergelay.com. Send what you did, what you observed and the smallest reproduction you have. Do not attach customer data, credentials or tokens you were able to read: describe what you reached and stop there. There is no PGP key — send plain email, and tell us first if a report cannot be written without sensitive material.

The machine-readable version of this page is at /.well-known/security.txt.

What happens next

• Acknowledgement within 2 business days (Europe/Paris).
• A first assessment and a severity within 5 business days, with the reasoning rather than a label.
• A mitigation or fix within 7 days of that assessment for a critical issue, 30 days for a high one, 90 days for a medium one. A low one ships in the next convenient release, or is accepted with an explicit decision. If a target is going to be missed you are told before it is missed.
• Coordinated disclosure at 90 days from the acknowledgement, or as soon as the fix is live. You are credited as you choose, or not at all. Nothing to sign, no NDA.

Mergelay is operated by one person. These are commitments, not a support organisation: they are written down so that you can hold us to them.

There is no bug bounty

Mergelay pays no bounty and sends no swag. That is stated here rather than in a reply three days later, so that nobody spends a week on this expecting money. Reports are still read, answered and fixed.

Safe harbour

Research carried out in good faith and within the rules below is authorised. We will not bring legal action against you for it, will not report it to a provider or to law enforcement, and treat your report as an authorised test. If a provider questions testing you did against Mergelay’s own surfaces, tell us and we will confirm to them that it was authorised. This protection lasts as long as you follow the rules, and it cannot waive rights that belong to someone else.

What not to do

• Do not access, modify, delete or exfiltrate data that is not yours. Create your own workspace — two, if you need to demonstrate a cross-tenant issue.
• Do not touch a customer’s connected repository, contact list, Slack workspace or social account.
• Do not run denial-of-service, load, stress or brute-force tests against production.
• Do not cause an external send from a workspace that is not yours. A successful send is a real message in a real person’s inbox.
• Do not social-engineer the operator, a customer or a provider, and do not attempt physical access.
• Do not mail scanner output. A finding with no working proof of concept is closed without a fix.

Already known

The one-click review link carried by the “Update ready to review” email is a credential: whoever holds it can approve on the operator’s behalf. It is signed, bound to one workspace, one Update and one named operator, valid for 72 hours, single-use for the decision, and revoked with the operator’s membership. The trade-off is deliberate and described in the privacy notice. A report restating it adds nothing; a way to break those bounds does not.

Issues in a provider’s own surface belong to that provider. The list, with each provider’s contact, is at sub-processors.

Where the measures are described

The security section of the privacy notice describes what is encrypted and how, and section 6 of the data processing agreement states the same measures in art. 32 terms, with the breach notification commitment in section 9. Send a security questionnaire to hello@mergelay.com; section 10 of the DPA sets out what is made available on request, and how often.

Not a security report?

A product problem goes to support@mergelay.com. Commercial, contractual and data-protection requests go to hello@mergelay.com.