Coordinated Vulnerability Disclosure
The security of our systems and of our customers' data is a top priority for Convaise UG (haftungsbeschränkt). Despite all care, vulnerabilities can never be ruled out completely. If you have found a security vulnerability, please report it to us so that we can fix it quickly. We thank everyone who helps us with this.
1. Scope
This policy applies to the following systems:
- convaise.com (including www.convaise.com)
- studio.convaise.com
- assistants.convaise.com
- api.convaise.com
Out of scope:
- third-party services and systems we use (e.g. hosting or email providers). Please report vulnerabilities in those directly to the respective provider.
- systems of our customers, even if convaise assistants are embedded there
- physical attacks on offices or data centers
- social engineering and phishing against our employees or customers
2. How to report a vulnerability
Please send your report by email to security@convaise.com. Reports in German or English are welcome.
To help us understand the vulnerability quickly, your report should include:
- a description of the vulnerability and the affected systems (URL, component)
- the steps to reproduce it (e.g. requests, screenshots, proof of concept)
- your assessment of the potential impact
- contact details for follow-up questions (optional; anonymous reports are possible)
3. What we commit to
- We will acknowledge receipt of your report within 3 business days.
- Within 10 business days, you will receive an initial assessment of whether and how severe the vulnerability is.
- We will keep you informed of our progress until the vulnerability is fixed.
- We will treat your report confidentially and will not share your personal data with third parties without your consent.
- If you wish, we will add your name or a pseudonym to our acknowledgments (section 9). We do not publish details about the vulnerability there.
4. Confidentiality and publication
Please treat information about a vulnerability confidentially. Do not publish any details or share them with third parties as long as the vulnerability has not been fixed and we have not agreed to publication. We will not withhold our consent without good reason.
We aim to fix vulnerabilities within 90 days of receiving the report. If this is not possible in an individual case, we will explain why and agree on the next steps with you.
5. Rules for reporters
Please follow these rules during your research:
- Only test as far as necessary to demonstrate the vulnerability.
- Do not access third-party data and do not modify or delete any data. If you unintentionally gain access to personal or confidential data, stop testing, let us know and delete the data.
- Do not impair the availability of our services (no denial-of-service attacks, no mass automated scanning, no spam).
- Do not use social engineering, phishing or physical attacks.
- Do not introduce malware or set up persistent access (backdoors).
- Do not exploit a vulnerability beyond what is needed to demonstrate it, and do not share it with third parties.
- Follow the rules on confidentiality and publication (section 4).
6. Legal commitment
If you comply with this policy, we will not file a criminal complaint against you or take civil legal action against you in connection with your report.
Please note: this commitment applies only to Convaise UG (haftungsbeschränkt). We cannot rule out that law enforcement authorities act on their own initiative or that third parties assert their own claims. If you are unsure whether a planned investigation is compatible with this policy, please ask us beforehand at security@convaise.com.
7. Rewards
We currently do not run a bug bounty program and do not pay rewards for reported vulnerabilities. However, we are grateful for every report and, if you wish, will gladly add you to our acknowledgments (section 9).
8. Not considered vulnerabilities
We generally do not treat the following reports as security vulnerabilities unless a concrete attack scenario with real impact is demonstrated:
- missing or differently configured HTTP security headers
- notes on SPF, DKIM or DMARC records
- disclosure of software or version numbers
- clickjacking on pages without security-relevant actions
- self-XSS or attacks that require physical access to the victim's device
- results of automated scanners without a reproducible proof
- denial-of-service attacks and rate-limiting notes without security impact
9. Acknowledgments
We thank everyone who has responsibly reported vulnerabilities to us:
No entries yet.
Last updated: October 2026