We'd rather hear about a security problem from you than read about it somewhere else. If you've found a vulnerability in Vendor, this page tells you what we consider in scope, the protections we extend to researchers acting in good faith, and exactly how to reach the people who can fix it. We read every report.
1. Scope
In scope: the Vendor commerce platform and its APIs, the merchant and operator dashboards, the storefronts we host on our infrastructure, our published SDK packages (the @vendor/* libraries), and this marketing site.
Out of scope: our third-party sub-processors (please report those directly to the vendor in question — see our sub-processors page for the list), social-engineering or phishing of Vendor staff, physical attacks, volumetric or denial-of-service testing, automated scanner output without a working proof of concept, and issues that can only be reached with admin or operator access you already hold. Reports of missing best-practice headers or configuration with no demonstrated impact are welcome but generally won't qualify for recognition.
2. How to report
Email security@vendor.com.mk with enough detail for us to reproduce the issue: the affected URL or endpoint, step-by-step reproduction, what you expected to happen versus what actually happened, and any proof-of-concept code, requests, or screenshots. The clearer the write-up, the faster we can confirm and fix it.
If the report contains sensitive data, ask us for our PGP key and we'll send it so you can encrypt the disclosure. We read reports in English and Macedonian. Please send one issue per email so each can be tracked separately.
3. Safe harbor
If you act in good faith, we won't pursue legal action against you. Acting in good faith means: you only access or modify data to the minimum extent needed to demonstrate the issue, you never exfiltrate, delete, or share other customers' data, you don't degrade service for anyone else, and you give us a reasonable window — 90 days by default — to remediate before disclosing publicly.
Once we've shipped a fix, or once the 90-day window has passed (whichever comes first), you're free to write up your findings. We're glad to review a draft, confirm technical details, and coordinate on a joint publication or timing if that's useful to you.
4. What to expect
We'll acknowledge your report within 2 business days, complete triage and assign a severity within 7 days, and keep you updated as we work toward a fix. Target remediation times depend on severity: critical issues within 30 days, high within 60, medium within 90, and low on a best-effort basis. If something will take longer, we'll tell you why rather than go quiet.
5. Recognition
We don't run a formal paid bug-bounty program yet, but we genuinely value the work researchers put in. With your permission, we'll credit you in our acknowledgments for any valid, previously-unknown vulnerability, and at our discretion we may offer a reward or token of thanks scaled to the severity and the quality of the report. Issues we already knew about, or that fall outside scope, aren't eligible — but we'll always tell you which it is.
6. security.txt
We publish a machine-readable policy at /.well-known/security.txt following RFC 9116. It lists our security contact, this disclosure policy, the acknowledgments page, our preferred languages (English and Macedonian), and an expiry date, so automated tooling and researchers can discover how to reach us without guessing.