Last updated · 10 June 2026 · Version 1.0
Security Policy
Every legal document on this site is written in English, and the English text is the one that takes effect. We publish translations so the terms are easier to read in your own language, not to create a second version of them. A translation carries no obligation on its own and does not stand in for the English document. Where a translation and the English text say different things, the English text is what applies.
We would rather hear about a flaw from you than read about it somewhere else. This page sets out what we ask of security researchers, and what we commit to in return.
If you believe you have found a vulnerability, write to [email protected]. You do not need permission to start, and you do not need to be a customer.
011. Safe harbour
Research carried out in good faith and within this policy is authorised. We will not pursue or support legal action against you for it, and if a third party brings action over research that followed these rules, we will make it known that it was authorised.
Good faith means you stopped as soon as you confirmed the issue, took no more data than needed to demonstrate it, and gave us a chance to fix it before telling anyone else.
If you are unsure whether something is allowed, ask first. A question costs us an email; a misunderstanding can cost you a great deal more.
022. Scope
In scope:
- The nulvless API and its authentication, authorization, OAuth server, communications and observability surfaces.
- The Console.
- Our public website.
- The official SDKs we publish.
Out of scope:
- Products our customers build on nulvless. Those belong to them; report to the operator of that product.
- Services we depend on but do not run, such as our cloud and CDN providers. Report those to the provider.
- Any account or data that is not yours, and any project you were not given access to.
033. What not to do
These are the lines that turn research into something else:
- No denial of service, load testing or anything that degrades the service for other people.
- No accessing, changing or keeping data that belongs to another user or another project. If you reach someone else’s data by accident, stop and tell us.
- No social engineering of our people, our customers or our providers. No phishing, no pretexting, no physical intrusion.
- No automated scanning that generates significant traffic. Test at a volume a person could produce.
- No publishing details before we have had a chance to fix the issue.
Use your own account and your own test project. Creating one is free.
044. How to report
Write to [email protected]. Include enough for us to reproduce the issue without guessing:
- What the problem is, and what an attacker could do with it.
- Steps to reproduce, in order.
- The environment: which endpoint, which project, roughly when.
- Anything that helps — a request, a screenshot, a short recording.
Write in Portuguese or English, whichever you prefer.
Report one issue per message. Several findings bundled into one thread take longer to triage and are easier to lose track of.
055. What happens next
| When | What we do |
|---|---|
| Within 3 business days | We confirm we received your report. |
| Within 10 business days | We tell you whether we could reproduce it and how we assess the severity. |
| While we work on it | We keep you informed at meaningful points rather than on a fixed schedule. |
| Once it is fixed | We tell you, and agree with you on whether and how to make it public. |
If we decide something is not a vulnerability, we will explain why rather than closing the thread in silence. You are free to disagree, and to say so.
066. Recognition
We do not run a paid bug bounty today. We are a small team, and promising money we have not budgeted would be worse than saying this plainly.
What we do offer: credit on this page for anyone who wants it, and a written acknowledgement you can show. If that is not worth your time, we understand — and we would still rather you told us.
077. Things we already know
Reports about the following are usually not treated as vulnerabilities on their own, unless you can show a concrete way to exploit them:
- Missing security headers with no demonstrated impact.
- Output of an automated scanner, submitted without a working reproduction.
- Weaknesses in email deliverability configuration, such as SPF or DMARC on domains that send no mail.
- Version numbers disclosed by a banner or a header.
- Attacks that require the victim to already be compromised, or to install something.
- Rate limits you consider too generous, without a demonstrated abuse path.
This is not us dismissing the category. It is us saying that the finding needs an impact attached to it.