Legal documents

Vulnerability Disclosure Policy

Last updated: October 5, 2026

Courtesy translation. The Portuguese version is the legally binding one.

UDISOFTBOX CONSULTORIA E TECNOLOGIA LTDA ("INGESTIA") is grateful to anyone who spends time finding and reporting security flaws in the ingestia.io platform. This document states how to report, what we promise in return and what is not authorised — so that nobody has to guess whether they are protected while doing the right thing.

1. How to report

Single channel: seguranca@ingestia.io

It helps a great deal to include:

  • the address, request or screen where the flaw appears;
  • the steps to reproduce it, in order;
  • what you were able to see or do that you should not have been;
  • the approximate date and time of your testing, and the source address you used — this lets us separate your traffic from a real attack;
  • how you would like to be credited, if you want credit.

Reports in Portuguese, English or Spanish. We do not require a form, an account or a signed agreement in order to receive a report.

2. Our commitment

Deadline
Confirm we received it2 business days
First assessment (valid, not valid, we need more information)5 business days
Inform the fix, or the decision not to fix, with the reason30 calendar days from the assessment, or an agreed deadline when the fix requires a structural change

Beyond the deadlines:

  • we keep you informed while the case is open, without you having to chase us;
  • we give public credit to the reporter, if desired, when the fix is published;
  • we do not charge anything and do not require a confidentiality agreement as a condition for handling the report.

3. Safe harbour

This is the central point of this document.

INGESTIA does not treat a good-faith report as a breach of the Acceptable Use Policy and will not take legal or contractual action against anyone who, in good faith:

  • discovered the flaw without intent to cause harm;
  • stopped testing as soon as the existence of the flaw was confirmed;
  • did not access, copy, alter, destroy or expose third-party data beyond what was strictly necessary to demonstrate the problem;
  • did not degrade, interrupt or overload the service;
  • reported to us first and gave us a reasonable deadline before any public disclosure;
  • did not use the flaw for advantage, nor sell or offer it to others.

Within those limits, our commitment is to treat you as someone who helped us — because that is what you did.

If, while demonstrating the flaw, you accidentally access someone else's data: stop, keep no copy, describe what happened in the report. Accidental access reported immediately does not break the safe harbour; silence does.

4. What is not authorised

Outside the safe harbour, and prohibited by the Acceptable Use Policy:

  • penetration testing, automated scanning or load testing without prior written authorisation — requests through the same channel, and we grant it for legitimate assessment;
  • denial-of-service attacks, at any volume;
  • social engineering, phishing or any approach to people on our team, or at customers or vendors;
  • physical attacks on facilities;
  • accessing, downloading or retaining customer data beyond the minimum needed to demonstrate the flaw;
  • altering or deleting data that is not yours;
  • using a flaw to maintain persistent access;
  • public disclosure before the deadline in section 2, without agreement.

5. Out of scope

Reports of the following kinds will be read, but are normally not treated as vulnerabilities:

  • a missing security header with no demonstrable impact;
  • raw output from an automated tool, with no exploitation path;
  • a vulnerability only present in an outdated browser version, or one that requires the victim to be already compromised;
  • e-mail configuration issues (SPF, DKIM, DMARC) with no demonstrated exploitation;
  • a problem in a third-party service we do not operate — in that case direct the report to the vendor; the Subprocessor List identifies who operates what;
  • a missing rate limit at a point with no sensitive effect;
  • prompt engineering that makes an AI feature produce unwanted text, without access to another environment's data and without executing an unauthorised action. That is handled as product quality, through support.

6. Scope

In scope: ingestia.io, its subdomains operated by INGESTIA, the authenticated Platform and the public programming interfaces.

Out of scope: third-party services, even when reached from the Platform; and the Customer's own cloud environment, in contracts where the Platform runs in their account — there, the owner of the environment is the one who authorises any testing.

7. Coordinated disclosure

We ask for the chance to fix before publication. In exchange, we do not ask for indefinite silence: once the deadline in section 2 has passed, or by agreement, you are free to publish. If we need more time, we will explain why and propose a date — we will not ask for a postponement without grounds.

We do not operate a financial reward (bug bounty) programme as of this date. We prefer to say so here rather than leave the expectation open.

8. An incident already under way

If you believe the flaw is being exploited right now, write INCIDENTE EM CURSO in the subject line and describe what you observed. That subject takes priority over the deadlines in section 2.

9. Contact

Security: seguranca@ingestia.io · Privacy and data subjects: privacidade@ingestia.io · Data Protection Officer: Encarregado de Dados (DPO) — encarregado@ingestia.io