Reporting a security flaw
If you have found something, we want to know before anyone else does. This page says what is in scope, how to write to us, how quickly we answer, and what we undertake not to do against you.
Our commitment
We treat every flaw report seriously and we answer each one, including those that turn out to be groundless. We will not pursue, and will not ask anyone to pursue, a researcher who follows the rules on this page. That commitment covers research carried out in good faith, even if it set off an alert on our side or caused an unintended outage.
We do not require a non-disclosure agreement to receive a report, and we do not ask for indefinite silence in exchange for a fix.
The scope
Included
The lazao.ai platform, its API and its payment notification endpoints, together with the sainillar.com site. Flaws in authentication, in authorisation between accounts, injection flaws, data exposure, and failures to verify signatures on payment flows are what interests us first.
Excluded
Our providers' systems, which have their own programmes: report to them directly. Reports produced by a plain scanner with no demonstration of impact. Header configuration or mail policy questions with no associated exploitation. Content produced by a model, including a bypass of its guardrails, which falls under the usage policy and not under security.
How to write to us
Write to the security address given on the Contact page. A useful report fits in a few lines and contains four things: where, how to reproduce it step by step, what it concretely allows someone to obtain, and how long you have known about it.
You can write in French or in English. You can stay anonymous; that makes no difference to how the report is handled, but we will then be unable either to answer you or to credit you.
Never send real user data in a report. A blurred screenshot or a truncated identifier is enough to demonstrate access.
Our timelines
These timelines run in business days from receipt. They bind us.
| Stage | Timeline | What you receive |
|---|---|---|
| Acknowledgement | 3 days | A written confirmation from a person, not an automated message. |
| Assessment | 10 days | Our analysis: reproduced or not, severity assigned, and why. |
| Fix, critical severity | 7 days | Fix deployed, and the confirmation that you can check it. |
| Fix, high severity | 30 days | Fix deployed, or a reasoned timetable if that is not achievable. |
| Fix, other | 90 days | Fix deployed or a reasoned decision not to fix. |
What we ask of you in return
Do not exfiltrate
Access the strict minimum needed to demonstrate the flaw, then stop. Do not download user data, do not keep it, and delete anything you may have retrieved once the report is sent.
Do not degrade
No denial of service, no load testing, no altering or deleting of data that is not yours. Create your own test accounts rather than using other people's.
Do not target people
No social engineering, phishing or physical intrusion aimed at our users, the people who work with us or our providers. The scope is the systems.
Wait before publishing
Give us ninety days before any publication, or the announced fix timeline if it is shorter. If we overrun our own timelines without explanation, you are free to publish: the commitment runs both ways.
Rewards and thanks
We have no monetary reward programme to date, and we would rather say so than leave people hoping. If we open one, it will be announced on this page and in the news.
What we do in the meantime: we publicly credit, with your agreement and under the name you choose, anyone whose report led to a fix. The credit appears in the corresponding incident note on the Service status page.
And we tell you what the fix changed. A researcher who reports a flaw and never hears what followed has no reason to do it again.