Security & Responsible Disclosure Policy
Effective date: 1 August 2026 · Version 2.0
This policy explains how APERTURESyndicate OÜ ("APERTURESyndicate", "AS", "we", "us") works with security researchers who find and report vulnerabilities in our services. We take the security of the platform and the people who use it seriously, and we genuinely welcome good-faith research.
Set your expectations first. We are a two-person company. There is no security team, no on-call rotation, and no bug-bounty budget. What we offer is a real safe harbour, a human who reads every report, and a fix as fast as we can manage. What we cannot offer is a guaranteed response clock or a payout. The rest of this document is written to that reality rather than to what a larger company would promise.
If you have found a potential security issue, go straight to Section 1.
We write these documents in good faith and keep them accurate to how the platform actually works. They have not yet been reviewed by qualified Estonian legal counsel.
1. Reporting a vulnerability
If you believe you have found a security vulnerability, report it to us privately by email to [email protected], with a subject line that starts with SECURITY (for example: SECURITY — possible auth issue). This is how the report gets prioritised in a shared inbox.
A machine-readable pointer is published at https://aperturesyndicate.com/.well-known/security.txt (RFC 9116) for tooling and automated discovery; the email address above is the authoritative channel. We accept reports in English or Estonian.
To help us reproduce and fix the issue fast, please include as much of the following as you reasonably can:
- A clear description of the vulnerability and the type of issue you believe it to be.
- Step-by-step reproduction instructions — the exact requests, inputs, or actions needed to trigger it.
- Impact — what an attacker could realistically do with it, and any preconditions required.
- Supporting material — proof-of-concept code, screenshots, or logs, where helpful (please redact any third-party personal data).
- Your contact details — so we can acknowledge your report, ask follow-up questions, and credit you if you wish.
Please send one issue per report where practical, and report promptly after discovery rather than stockpiling findings.
2. Safe harbour
We will not pursue or support legal action against you for security research that is carried out in good faith and in compliance with this policy.
Specifically, where your activity stays within the rules of engagement in Section 3 and the scope in Section 4, we consider it authorised, and we will not treat it as a breach of our terms or report it as unlawful access. If a third party brings a claim against you for activity that complied with this policy, we will make clear that your research was authorised.
This safe harbour is limited to you and to your own conduct under this policy. It does not cover activity that breaks the law, harms other users, or goes beyond what this policy permits, and it cannot bind a third party or a public prosecutor — no private policy can. If you are ever unsure whether something is in scope or permitted, ask us first at [email protected] before proceeding; we would much rather have a conversation than see good research go wrong.
3. Rules of engagement
To stay within this policy, please observe the following while researching:
- Minimise access to data. Do not access, modify, delete, or exfiltrate data belonging to other users or to us beyond the minimum strictly necessary to demonstrate a finding. If you encounter another person's personal data, stop, do not retain or share it, and tell us in your report.
- Use your own test accounts. Conduct testing only against accounts you control and have created for the purpose. Do not target, access, or take over accounts belonging to anyone else.
- Do not degrade the service. No denial-of-service or volumetric attacks, no resource-exhaustion or automated high-rate scanning that disrupts availability, no spam, and nothing that affects the experience of other users.
- No social engineering. Do not phish, pretext, or otherwise manipulate our staff, contractors, or users, and do not attempt to extract credentials from any person.
- No physical or infrastructure attacks. Do not attempt to access offices, hardware, or facilities, and do not target service providers or networks we rely on.
- Practise coordinated disclosure. Give us a reasonable opportunity to investigate and remediate before disclosing anything publicly, and coordinate the timing and content of any public disclosure with us. Please do not publish details, proof-of-concept code, or affected data while a fix is pending. We do not ask for indefinite silence: if we have gone quiet or a fix is dragging, tell us you intend to publish and give us a deadline — 90 days from your report is a norm we accept as reasonable, and less for something already being exploited.
- Respect privacy and the law. Do not violate the privacy of any person, and comply with all applicable laws, including the GDPR and Estonia and EU law.
If a test starts to risk harm to real users or data, stop and contact us.
4. Scope
In scope (high level). Vulnerabilities in the web services, applications, and APIs that we own and operate, where the issue has a genuine, demonstrable security impact — for example, the ability to access data you should not be able to, to act as another user, or to bypass a security control.
Out of scope. The following are generally not eligible under this policy:
- Services, products, libraries, or infrastructure operated by third parties, even if we use or link to them.
- Social-engineering of staff, contractors, or users, and any attack that depends on it.
- Volumetric denial-of-service, load testing, and similar availability-affecting activity.
- Missing best-practice hardening (for example, an absent security header or cookie flag) where you cannot show a real, exploitable impact.
- Purely theoretical issues, reports generated solely by automated scanners without a working proof of concept, self-inflicted issues, and findings that require an already-compromised device, browser, or account.
This is a high-level guide, not an exhaustive list. If you are unsure whether a target or technique is in scope, ask us at [email protected] before testing.
5. What you can expect from us
These are honest intentions from a two-person team, not service levels. We would rather under-promise here than quietly miss a published deadline.
- Acknowledgement. We aim to reply within 72 hours. In practice it is usually faster. It can also be slower — over a weekend, a holiday, or while one of two people is unavailable. If you have heard nothing after a week, send a reminder; it is far more likely that the mail was buried than ignored.
- Triage. We assess severity and impact ourselves and tell you what we concluded, including when we conclude the issue is not exploitable.
- Remediation. We fix confirmed vulnerabilities as fast as severity warrants and tell you when the fix ships. We do not commit to a fix deadline. Something critical is usually deployed within days; a low-severity hardening item may wait for the next convenient release.
- Credit. If you want to be acknowledged, we will credit you once the issue is resolved. If you prefer to stay anonymous, we keep the report confidential.
- Data-breach obligations. If your finding turns out to involve personal data actually being exposed, we have our own legal duties — notification to Andmekaitse Inspektsioon within 72 hours where the GDPR requires it. We will tell you if your report triggered that.
We handle reports confidentially and will not share your identity with third parties without your consent, except where the law requires it.
6. Recognition, not bounty
We do not operate a bug-bounty programme and do not pay monetary rewards. There is no budget for one, and we would rather say that than string researchers along with a "rewards may be considered" formula.
What we do offer is a genuine safe harbour (Section 2), a fast human reply, and public credit if you want it. Recognition is at our discretion and with your permission. Please do not make payment a condition of reporting, and do not treat a report as creating any entitlement to compensation.
A request for payment in exchange for withholding a vulnerability is not research — it is extortion, it falls outside this policy entirely, and we treat it accordingly.
If we ever start a paid programme, we will announce it here first.
7. This policy is not a licence to break the law
This policy authorises good-faith security research carried out within the rules above — and nothing more. It does not grant you permission to break the law, to breach our other terms, or to harm our users or our platform.
Activity that falls outside this policy — including anything in conflict with our Acceptable Use Policy — is not covered by the safe harbour in Section 2 and may be treated as unauthorised. When in doubt, contact us before you act.
Contact
| Purpose | Contact |
|---|---|
| Security reports and coordinated disclosure | [email protected] — subject starting with SECURITY |
| Machine-readable pointer | https://aperturesyndicate.com/.well-known/security.txt |
| How we protect the platform generally | Security |
We accept reports in English or Estonian.
APERTURESyndicate OÜ Registry code 17384111 · VAT EE102972654 Priisle tee 8, Lasnamäe linnaosa, Tallinn, Harju maakond, 13914, Estonia Company registration details
This policy is governed by the law of Estonia, with the courts of Tallinn having jurisdiction. The English-language version of this policy is the controlling version.
Version history
- v2.0 — 2026-08-01 — Response promises brought down to what a two-person team can actually keep: the 72-hour acknowledgement is stated as an aim rather than a guarantee, no fix deadline is promised, and the disclosure section now accepts a 90-day publication norm instead of asking for open-ended silence. Bounty position stated flatly rather than left open. Added the breach-notification duty and an explicit note that extortion is not research. Contacts and company details moved to shared placeholders.
- v1.0 — 2026-06-22 — Initial publication.