Vulnerability Disclosure Policy
Last updated: [TBD] · This is a working draft pending legal review.
1. Introduction and purpose
Coded B.V. ("Coded", "we", "us", "our") operates an international commerce platform on which a merchant can run one or more branded online shops, backed by a curated product catalog, built-in payments, and built-in fulfilment. Security is a core part of how that platform is designed and operated.
We recognise that no system is perfect and that the work of independent security researchers makes the platform safer for the merchants and customers who depend on it. This Vulnerability Disclosure Policy ("Policy") explains how to report a security vulnerability to Coded, what is in and out of scope, what you can and cannot do, what you can expect from us in return, and the conditions under which good-faith research is protected.
This Policy is modelled on internationally recognised coordinated-disclosure practice, including ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes). It applies to anyone who discovers or suspects a vulnerability in a Coded system, whether or not you intended to look for one.
Coded B.V. is a private limited company registered in the Netherlands; Coded Holding B.V. is its parent. Registration details: KvK number 42027097, VAT number NL869368795B01, registered address De Taling 15, 2761 SL Zevenhuizen, The Netherlands. The platform is operated internationally and serves merchants and their customers worldwide.
2. Our commitment
If you make a good-faith effort to comply with this Policy during your research, we commit to:
- work with you to understand and validate your report, in a timely manner;
- keep you informed of our progress in resolving the issue, within the response targets set out in Section 8;
- not pursue or support legal action against you in connection with your report, subject to the conditions and limits in Section 9 (Safe harbour);
- recognise your contribution, if you are the first to report a previously unknown issue and you would like to be credited (see Section 11).
We treat all reports as confidential and share reporter information only as necessary to investigate and remediate, or where we are legally required to do so.
3. How to report a vulnerability
Send security reports to security@coded.co.
This address is the single intended channel for security vulnerabilities. Please do not report security issues through general support, sales, or social media channels, and please do not disclose them publicly before coordinating with us (see Section 5).
3.1 security.txt
A machine-readable contact record is published at:
https://coded.co/.well-known/security.txt
The security.txt file is the authoritative pointer to our current reporting
contact, encryption key, policy URL, and preferred language, in line with
RFC 9116. If anything in this Policy and the published security.txt ever
conflicts, the security.txt Contact field is the correct way to reach us.
3.2 What to include in a report
To help us validate and fix the issue quickly, please include where possible:
- a clear description of the vulnerability and its potential impact;
- the specific product, domain, endpoint, or component affected;
- step-by-step instructions to reproduce the issue, including any required accounts, inputs, or configuration;
- proof-of-concept code, scripts, or screenshots, where relevant;
- any IP addresses or accounts you used during testing, so we can correlate logs;
- your assessment of severity, if you have one.
Reports may be submitted anonymously. If you would like a response, recognition, or updates, please include a way to contact you.
3.3 Encryption
If your report contains sensitive details, you may encrypt it. Our current PGP
key and its fingerprint are referenced from security.txt via the Encryption
field.
4. Scope
4.1 In scope
Unless explicitly excluded below, the following are in scope:
- the Coded platform and its merchant-facing application surfaces;
- merchant projects (the shops, sites, and other projects merchants create and publish on the platform), to the extent the underlying defect is in Coded's own systems rather than in merchant-supplied content or configuration;
- Coded's public web properties and APIs operated under domains we control;
- the payment integration layer, to the extent it is operated by Coded — but see the explicit limits in Section 4.3 concerning Stripe and Mollie.
If you are unsure whether something is in scope, contact us at security@coded.co before testing.
4.2 Out of scope (systems)
The following are out of scope under this Policy:
- third-party services, infrastructure, and products that Coded does not own or operate, including those of our sub-processors, hosting providers, and payment processors — report those issues to the relevant vendor;
- merchant-controlled content, configuration, and credentials, and vulnerabilities that exist only because of a merchant's own choices rather than a defect in Coded's systems;
- the systems of any other Coded customer; you must never access, attempt to access, or pivot into another organization's data.
4.3 Payments
Payments on the platform are processed through Stripe and Mollie. Vulnerabilities in Stripe's or Mollie's own infrastructure must be reported to those providers under their respective disclosure programs. Issues in how Coded integrates with those providers — for example, an integration defect on our side that could expose data or alter a transaction — are in scope and should be reported to us. Coded charges no platform fee on a merchant's payment transactions; this Policy concerns the security of the integration, not its commercial terms.
4.4 Out of scope (finding types)
The following report types are generally considered low-value or non-qualifying unless you can demonstrate a realistic, concrete security impact:
- reports from automated scanners without a working, demonstrated exploit;
- missing security headers, cookie flags, or best-practice hardening with no demonstrated impact;
- absence of rate limiting, or volumetric / denial-of-service findings (see Section 6 — load and DoS testing is prohibited);
- email configuration findings (SPF, DKIM, DMARC) with no demonstrated exploit;
- self-XSS, clickjacking on pages with no sensitive action, and similar issues requiring unlikely user interaction;
- vulnerabilities affecting only unsupported or end-of-life browsers or platforms;
- theoretical or version-banner-only findings without a proof of concept;
- social engineering, phishing, or physical-security findings against Coded staff, contractors, merchants, or facilities.
We may still appreciate such reports, but they generally do not qualify for recognition.
5. Coordinated disclosure
We follow a coordinated-disclosure model:
- please give us a reasonable opportunity to investigate and remediate before any public disclosure;
- our default coordination window is 90 days from acknowledgement of a valid report, which we may shorten when a fix ships sooner or extend by mutual agreement for complex issues;
- we ask that you do not disclose details to any third party, publish, or otherwise make the vulnerability public until we confirm the issue is resolved or the coordination window has elapsed;
- where appropriate, we are happy to coordinate timing and joint or credited publication with you.
If a vulnerability is being actively exploited, or there is a serious and imminent risk to users, we may act on a shorter timeline and will tell you if we do.
6. What you must NOT do
To stay within the protections of this Policy, you must not:
- access, modify, delete, or download data that does not belong to you, beyond the minimum needed to demonstrate the vulnerability — if you encounter personal data, payment data, or another party's information, stop and report it immediately;
- intentionally degrade, disrupt, or deny service, including load testing, stress testing, denial-of-service, or distributed denial-of-service;
- run automated scanners or fuzzers at a volume or rate that could affect platform availability or other users;
- use social engineering, phishing, or physical intrusion against Coded staff, contractors, merchants, or premises;
- exfiltrate, retain, sell, or share any data you accessed during testing, or use it for any purpose other than the report;
- pivot from an in-scope system into out-of-scope systems, third-party services, or another organization's environment;
- introduce malware, ransomware, persistent backdoors, or any change intended to outlast your test;
- attempt to identify, deanonymise, or target individual merchants or their customers;
- publicly disclose the vulnerability before coordination is complete (see Section 5);
- violate any applicable law, or any mandatory data-protection or computer-misuse rule of your own jurisdiction or of the Netherlands.
If you are unsure whether an activity is permitted, ask first at security@coded.co.
7. What you should do
- test only against accounts and data you own or are explicitly authorised to use;
- use a test or trial organization where one is available, rather than touching live merchant data;
- stop testing and report immediately the moment you encounter another party's personal data, payment data, or credentials;
- keep your activity proportionate to confirming the vulnerability, and document what you did;
- act in good faith throughout, and avoid any privacy violation or service disruption.
8. Our response process and timelines
We handle reports following ISO/IEC 30111-style vulnerability handling: triage, assessment, remediation, and disclosure. Our target response times, measured in business days from receipt, are:
- Acknowledgement of your report: within 3 business days;
- Initial triage and validity assessment: within 10 business days;
- Status update cadence: at least every 14 business days while the issue is open;
- Remediation target: based on severity, with critical and high-severity issues prioritised; we will share an expected timeframe once triage is complete.
These are targets, not contractual guarantees, and may vary with the complexity and severity of the issue. We will keep you informed if a report needs longer.
9. Safe harbour for good-faith research
Coded supports good-faith security research and will treat it as authorised conduct.
If you make a genuine, good-faith effort to follow this Policy — in particular Sections 4, 5, 6, and 7 — then, to the extent permitted by applicable law, Coded will:
- regard your activity as authorised access for the purpose of relevant computer-misuse and unauthorised-access laws;
- not initiate or support civil or criminal legal action against you arising from your research;
- not report your activity to law enforcement as unauthorised, and, if a third party brings legal action against you for conduct that complied with this Policy, take reasonable steps to make clear that your activity was authorised.
This safe harbour has limits:
- it covers only you, only your own good-faith research, and only conduct that genuinely complied with this Policy;
- it does not apply to activity that is malicious, that intentionally accesses or exfiltrates another party's data, that disrupts service, or that otherwise breaches Section 6;
- it does not waive any rights of third parties (for example, merchants, payment processors, or sub-processors) — it binds only Coded;
- it does not authorise any act that is unlawful under mandatory law applicable to you or to Coded; where the law of your jurisdiction or the Netherlands prohibits conduct outright, this Policy cannot and does not override it.
If you are uncertain whether a planned action falls within this safe harbour, contact security@coded.co before you act, and we will work with you in good faith. We may, at our discretion, treat a report that fell slightly outside the rules as authorised where you acted in good faith and promptly disclosed.
10. No bug bounty (yet)
Coded does not currently operate a paid bug bounty program, and submitting a report does not create any expectation or entitlement to monetary reward. We may introduce a bounty program in the future; if and when we do, it will be announced separately with its own terms. In the meantime we offer recognition (Section 11) and our genuine thanks.
11. Recognition
With your consent, we are glad to credit researchers who responsibly report previously unknown, valid vulnerabilities — for example, in a security acknowledgements list. Tell us in your report whether you would like to be credited and the name or handle you would like us to use. You may also choose to remain anonymous.
12. Data hosting and privacy
Platform data is hosted in the European Union (Frankfurt, Germany). Coded operates on a privacy-by-design basis, uses cookieless analytics, and does not sell or share personal data for cross-context behavioural advertising. Any personal data contained in a vulnerability report is processed only to investigate and remediate the issue and in line with our Privacy Policy. Please minimise the personal data you include in a report and never include another party's data beyond what is strictly necessary to demonstrate the issue.
13. Changes to this Policy
We may update this Policy from time to time to reflect changes in our platform,
our process, or applicable law. The current version is always the one published
at this URL, and the version referenced from security.txt governs. The
effective date of this Policy is 11 June 2026.
14. Governing law
This Policy is governed by the laws of the Netherlands. Any dispute arising out of or in connection with this Policy will be submitted to the competent courts of Amsterdam, the Netherlands. This does not affect any mandatory protection available to you under the consumer-protection, data-protection, or other mandatory laws of your own jurisdiction, which may also apply.
Contact
For all security matters under this Policy:
- Security reports: security@coded.co
- security.txt: https://coded.co/.well-known/security.txt
- General legal enquiries: legal@coded.eu
- Privacy enquiries: privacy@coded.eu
Coded B.V., De Taling 15, 2761 SL Zevenhuizen, The Netherlands · KvK 42027097 · VAT NL869368795B01
<!-- OPEN ITEMS FOR COUNSEL: - Confirm working email domain (coded.eu (legal/privacy) · coded.co (ops)) across security@, legal@, privacy@. - Confirm KvK number, VAT number, registered address, and effective date placeholders. - Validate enforceability of the safe-harbour language under Dutch law (Wetboek van Strafrecht art. 138ab computervredebreuk) and confirm Coded cannot bind third parties (merchants, Stripe, Mollie, sub-processors) — verify the carve-out is watertight. - Confirm the 90-day coordination window and the Section 8 response timelines are acceptable as targets (non-binding) and consistent with any contractual SLAs. - Confirm Coded does not yet run a paid bounty and that the "no entitlement to reward" language is sufficient to prevent claims. - Verify interaction with the EU NIS2 / CSIRT coordinated-vulnerability-disclosure regime and any Dutch NCSC-NL notification expectations. - Confirm whether to add a fixed coordination contact for actively-exploited / imminent-risk scenarios, and whether CVD with a national CSIRT should be referenced. - Confirm RFC 9116 security.txt is actually published at the stated path before this goes live, including Expires and Encryption fields. - Confirm GDPR + US-state-law (CCPA/CPRA) framing in Section 12 aligns with the master Privacy Policy and that the international (non-EU-only) posture is consistent across legal docs. - Decide whether a separate machine-readable scope (e.g. asset list / domains) should be linked rather than embedded prose. -->