Vulnerability Disclosure Policy
B.1 Purpose and principles
B.1.1 Purpose. This policy sets out how security vulnerabilities in the Zero Door product and in the systems operated by Zerone Siber Güvenlik Limited Şirketi (Zerone) are to be reported to Zerone, the timeframes and manner in which Zerone responds to such reports, the legal protection afforded to a reporting researcher, and the basis on which public disclosure is coordinated.
B.1.2 Principles. Zerone builds a security product and accepts that its own product may contain vulnerabilities. Reporting a vulnerability to Zerone shall not operate to the detriment of the reporter. No non-disclosure agreement, identification, or payment is required in order to submit a report. Zerone does not impose silence as a condition on a reporter; public disclosure takes place under the coordination rules in B.8.
B.1.3 Who may report. This policy is open to everyone. Independent security researchers, academic researchers, customer personnel, business partners, and persons having no contractual relationship with Zerone are subject to the same terms and benefit from the same protection.
B.1.4 Nature of this policy. This policy is a binding undertaking given unilaterally by Zerone. The protection in B.5 does not depend on the conclusion of any separate agreement between the researcher and Zerone.
B.2 Scope
B.2.1 Assets in scope.
| Asset | Description |
|---|---|
| Zero Door SaaS console | The web interface at zerodoor.zeronesecurity.com, the REST interface (/api/v1), WebSocket endpoints, and authentication flows |
| Zero Door agent ingress | The gRPC agent ingress service in the SaaS production environment and the load balancer in front of it |
| Zero Door agent software | Linux and Windows agent binaries, the installer generator, installation scripts, service configuration, and anti-tamper components |
| Release chain | Published release artefacts, the release manifest, detached signatures, the digest list, and the trust anchor file |
| Corporate domain | zeronesecurity.com and the subdomains operated by Zerone |
B.2.2 Assets and findings out of scope. The following fall outside this policy. Testing directed at an out-of-scope asset does not benefit from the protection in B.5.
(a) On-Prem deployments operated by a customer, and customer networks, servers, and data. Authorisation to test such systems may be granted only by the operator of that system. Where a customer identifies a product vulnerability in its own deployment, B.10 applies.
(b) Third-party services and infrastructure not operated by Zerone, including the hosting provider’s own management interfaces, payment institution systems, and external threat intelligence sources. Findings concerning such assets are to be reported directly to the relevant provider.
(c) Social engineering, phishing, voice phishing, and physical elicitation directed at Zerone personnel, customers, or business partners.
(d) Physical attacks on, physical access attempts against, and on-site security testing of Zerone or hosting provider facilities.
(e) Denial of service and distributed denial of service testing, load and stress testing, volumetric brute force attempts, and resource exhaustion testing.
(f) Unsolicited mail, mail bombing, and findings relating to the absence or weakness of SPF, DKIM, or DMARC records without a demonstrated exploitation path.
(g) Unverified automated scanner output and findings for which no impact is demonstrated.
(h) Findings reported in isolation and without a demonstrated exploitation path concerning a missing security header, a cookie flag, a TLS cipher suite preference, the absence of certificate pinning, version banner disclosure, self-inflicted script execution, or cross-site request forgery on logout.
(i) Findings that require a browser or operating system version no longer supported by its vendor.
(j) Design limits expressly stated in the product documentation. It is expressly recorded in 50-guvenlik-beyani.md and 53-teknik-ve-idari-tedbirler.md that the audit trail chain is tamper-evident rather than tamper-proof, and that a party holding the verification key is able to recompute the chain. Restating that limit does not constitute a vulnerability report.
B.2.3 Where in doubt. If it is unclear whether an asset or a finding is in scope, the question is to be put to Zerone through the channel in B.3 before any testing is carried out. Zerone shall respond within the period set out in B.6.1.
B.3 Reporting channel and preferred report format
B.3.1 Single channel. Reports are to be sent to security@zeronesecurity.com. Vulnerability reports are not to be submitted through support channels, the general contact address, social media, or public issue trackers.
B.3.2 Machine-readable contact information. The contact information for this policy is published, in accordance with RFC 9116, at https://zerodoor.zeronesecurity.com/.well-known/security.txt. The field content of that file is set out in the Annex to this document, and the file is derived from that Annex.
B.3.3 What a report should contain.
| Field | Content |
|---|---|
| Affected component | Console, API endpoint, agent, installer generator, or release chain; a file path or endpoint where possible |
| Environment and version | SaaS or On-Prem; agent and server version numbers; date and time of testing, with time zone |
| Reproduction steps | Ordered steps stated with sufficient clarity for a reader to reproduce independently |
| Evidence | Screenshots, request and response captures, proof-of-concept code, or log excerpts |
| Impact | The concrete consequence: which data, at which privilege, and across which tenant boundary, may be reached |
| Severity assessment | CVSS v3.1 base score and vector, if available. Not mandatory |
| Third-party data | Whether data belonging to third parties was accessed during testing and, if so, its extent and whether it has been destroyed |
| Disclosure status | Whether the finding has been shared with any other person, organisation, vendor, or platform |
| Credit preference | The name to be used if credit is desired in the acknowledgements list; a preference to remain anonymous may equally be stated |
B.3.4 Encrypted communication. Encrypted submission is preferred. Zerone’s security contact key is published at «PGP anahtarı yayın adresi» and its fingerprint is «PGP anahtarı parmak izi». The fingerprint should be verified from a source independent of the source from which the key was obtained. Where a researcher wishes to communicate in encrypted form but is unable to verify the key, the first message need contain only a request to establish contact, and the key exchange will be initiated by Zerone.
B.3.5 Language of the report. Reports may be submitted in Turkish or English. Zerone responds in the language of the report.
B.3.6 The researcher’s personal data. The name, electronic mail address, and report content shared by a researcher are processed for the purposes of assessing the report, carrying out remediation, and giving effect to the credit preference, on the basis of Article 5(2)(f) of Law No. 6698 and Article 6(1)(f) of Regulation (EU) 2016/679. Further information is set out in 02-veri-koruma/20-aydinlatma-metni.md and 02-veri-koruma/21-privacy-notice.md.
B.4 Rules of conduct expected of the researcher
B.4.1 Testing is to be conducted only against the researcher’s own account, own tenant, or a trial account created for that purpose.
B.4.2 Access to data is to be kept to the minimum necessary to demonstrate the existence of the vulnerability. Testing is to stop as soon as the vulnerability has been demonstrated; no attempt is to be made to escalate access, move laterally, or establish persistence.
B.4.3 Personal data, customer telemetry, credentials, session tokens, or trade secrets belonging to third parties shall not be downloaded, copied, retained, modified, or deleted. Where such data is accessed inadvertently, access is to cease immediately, the data is to be destroyed, the circumstances are to be stated in the first report to Zerone, and the destruction is to be confirmed in writing.
B.4.4 The availability and integrity of the service are not to be impaired. Data is not to be deleted or corrupted, configuration is not to be altered persistently, and no backdoor is to be left in place.
B.4.5 The finding is not to be shared with third parties before the coordination under B.8 is complete. This includes submission to mass disclosure platforms, vendor broker programmes, vulnerability brokers, or the public.
B.4.6 The finding is not to be used as a means of demanding payment from Zerone. Communications that condition remediation or non-disclosure upon a payment fall outside this policy and do not benefit from the protection in B.5.
B.4.7 Applicable law, the document 01-sozlesmeler/04-kabul-edilebilir-kullanim-politikasi.md, and any agreement between the researcher and Zerone are to be complied with.
B.5 Safe harbour
B.5.1 Authorised access. Security research carried out in good faith and in accordance with this policy is treated by Zerone as authorised access. Zerone shall not bring civil proceedings against the researcher, shall not file a criminal complaint, shall not report the researcher to law enforcement or the prosecution service, and shall not support proceedings brought by a third party, in respect of such activity.
B.5.2 Good-faith and accidental violations. An inadvertent departure from the limits of this policy by a researcher acting in good faith does not extinguish the protection. Where the researcher stops upon becoming aware of the departure, notifies Zerone, and destroys any data obtained, the activity continues to be treated as compliant with this policy.
B.5.3 Contractual waiver. Zerone declares that, in respect of research compliant with this policy, it shall not enforce any contrary provision of its terms of use, licence agreement, or acceptable use policy. This declaration applies solely and strictly to research activity compliant with this policy.
B.5.4 Limits as regards third parties and public authorities. Zerone may waive only its own rights. This policy does not extinguish the rights of customers, the hosting provider, third-party service providers, or other rights holders, and does not bind authorities empowered to investigate of their own motion. Should an investigation be opened under Articles 243 and 244 of the Turkish Criminal Code No. 5237, Zerone shall notify the relevant authority in writing that the activity in question was authorised under this policy and that Zerone is not a complainant. The researcher may request Zerone to do so.
B.5.5 Conduct falling outside the protection. The following do not constitute good-faith research and do not benefit from the protection in B.5.1: exfiltration or sale of data; deliberate interruption of the service; deletion or corruption of data; establishing persistence in order to maintain access; a demand for payment within the meaning of B.4.6; and testing directed at out-of-scope assets.
B.5.6 Benefit of the doubt. Where it is doubtful whether conduct complies with this policy, Zerone shall resolve that doubt in favour of the researcher.
B.6 Response commitments
B.6.1 Timeframes. Zerone undertakes the following timeframes. Time runs from the moment the report reaches security@zeronesecurity.com, and a business day means a day other than a public holiday in Türkiye.
| Stage | Timeframe |
|---|---|
| Acknowledgement of receipt and allocation of a case reference | 3 business days |
| Notification to the researcher of the validation outcome, the scope assessment, and the severity rating | 10 business days |
| Progress updates until closure | At least every 14 days |
| Notification that the fix has been released, with an invitation to verify | 3 business days from release |
B.6.2 Where validation is negative. Where Zerone does not treat a finding as a vulnerability or considers it out of scope, it shall give written reasons for that decision. The researcher may request one reassessment by submitting further evidence; that request is subject to the same timeframes.
B.6.3 Duplicate reports. Where the same vulnerability has already been identified by Zerone or reported by another researcher, that fact and, where applicable, the date of the first report are communicated to the researcher.
B.7 Remediation targets
B.7.1 Rating. Zerone rates each validated vulnerability on the basis of its CVSS v3.1 base score and the actual exposure of affected deployments. The rating is communicated to the researcher together with its vector.
B.7.2 Targets. The following periods are Zerone’s targets for the release of a fix or of an effective mitigating measure, and run from the date of validation.
| Severity | CVSS v3.1 | Target |
|---|---|---|
| Critical | 9.0 to 10.0 | 7 days |
| High | 7.0 to 8.9 | 30 days |
| Medium | 4.0 to 6.9 | 90 days |
| Low | 0.1 to 3.9 | Next scheduled minor or patch release |
B.7.3 Nature of the targets. These periods are planning targets. Where a fix requires an architectural change, Zerone shall release a mitigating measure within the target period and communicate a reasoned schedule for the permanent fix. The response and resolution times binding as against a customer are the support commitments set out in 01-sozlesmeler/06-destek-ve-bakim-sartlari.md.
B.7.4 Active exploitation. Where there is any indication that a vulnerability is being exploited in the wild, the severity is treated as Critical, the mitigation target is shortened below 7 days, and B.8.3 applies.
B.8 Coordinated disclosure
B.8.1 Default period. Zerone and the researcher coordinate public disclosure of the finding. The default disclosure window is 90 days from the date on which the report reached Zerone. Where a fix is released before that period expires, disclosure takes place after release of the fix and after publication of the advisory under B.11.
B.8.2 Basis for extension. Where a fix requires an architectural change, requires coordination across several components, or where a reasonable period must be allowed for On-Prem deployments to apply a patch, Zerone may request an extension of not more than 30 days, stating its reasons and the revised schedule. Any request for an extension is to be made before the expiry of the 90-day window. Zerone shall not impose any extension beyond that provided for in this policy; on expiry of the period the researcher is free to disclose, and such disclosure does not extinguish the protection in B.5.
B.8.3 Accelerated process for actively exploited vulnerabilities. Where a vulnerability is being actively exploited, Zerone shall notify its customers of the mitigating measure and of the relevant indicators immediately, without awaiting a fix; in that case the disclosure window may be shorter than 90 days and is determined together with the researcher. Enabling users to protect themselves prevails over keeping the disclosure confidential.
B.8.4 Non-response. Where Zerone fails to observe a timeframe in B.6.1, the researcher shall give written notice of the missed timeframe and allow a further 14 days. If that period also passes without result, the researcher may disclose the finding and such disclosure does not constitute a breach of this policy.
B.8.5 Joint disclosure. At the researcher’s request, Zerone shall share the advisory text with the researcher prior to publication and shall disclose simultaneously.
B.9 Reward programme and credit
B.9.1 No reward. As at the date of this policy Zerone does not operate a monetary reward programme. No monetary reward, gift, or comparable consideration is paid for reported vulnerabilities. This position is updated with the version of this document; should a reward programme be introduced, this section will be amended and the programme terms published separately.
B.9.2 Credit. The author of each validated report is, if they so elect, credited under the name they specify in the security advisory accompanying the fix and in the public acknowledgements list published at «tanınma listesi yayın adresi». A preference to remain anonymous is given effect in the same way. Credit is conditional upon the validity of the finding; submitting a report does not of itself result in inclusion in the list.
B.9.3 Effect of the absence of a reward. The absence of a reward does not narrow the scope of the protection in B.5 or of the response commitments in B.6. Those commitments are independent of any reward and may be relied upon without any reward being claimed.
B.10 Vulnerabilities in customer deployments
B.10.1 Scope. Where a customer identifies a security vulnerability in its own On-Prem deployment or in its own SaaS tenant and the vulnerability originates in the product, the report is to be made to security@zeronesecurity.com. In making such a report the customer is to keep information about its own environment to a minimum and is not to share personal data relating to its own customers.
B.10.2 Distinction from the support process. A vulnerability report and a support request are separate processes and are not to be conflated.
| Criterion | Vulnerability report (this policy) | Support request (06-destek-ve-bakim-sartlari.md) |
|---|---|---|
| Channel | security@zeronesecurity.com | Support channels |
| Who may submit | Anyone; no contractual relationship required | Only a customer holding a support entitlement |
| Subject matter | A security vulnerability originating in the product | Fault, usage question, configuration, deployment |
| Timeframes | B.6 and B.7 | Response times by plan tier |
| Contractual remedy | None; gives rise to no service credit | Governed by the support terms |
| Confidentiality | Coordinated disclosure, B.8 | Contractual confidentiality |
B.10.3 Configuration-related findings. A finding arising from a configuration error, an unapplied patch, a network architecture decision, or access rights management in the customer’s own environment is not a product vulnerability and is handled through the support process. Where Zerone considers a report to be of that character, it shall say so with reasons and, with the customer’s consent, transfer the matter to the support process.
B.10.4 Testing by a customer of its own deployment. A customer is free to conduct security testing of a deployment it operates itself. In the SaaS environment, testing may be conducted only within the customer’s own tenant and in compliance with the rules in B.4; testing directed at the multi-tenant infrastructure, at other tenants, or at shared components requires the prior written consent of Zerone.
B.10.5 Relationship with personal data breach. Where a vulnerability report indicates that personal data has been, or may have been, accessed, Zerone shall additionally assess the matter under its personal data breach process. Where it cannot be positively established that data was not accessed, the matter is treated as though it had been accessed. In that case the notification obligations under the Data Processing Agreement and the procedure in 02-veri-koruma/34-veri-ihlali-bildirim-formu.md apply, and notification to the customer is given without undue delay and in any event within 48 hours.
B.11 Product security advisories
B.11.1 Place of publication. A security advisory is published for every fix having a security impact. Advisories are published in the release notes, in the console’s what’s-new panel, and at «güvenlik duyuruları yayın adresi».
B.11.2 Advisory content. Each advisory states: the advisory reference allocated by Zerone and its date; the affected components and version range; the CVSS v3.1 base score and vector; a description of the impact; the version containing the fix; a mitigating measure where the fix cannot be applied; indicators of compromise, where any exist; and credit in accordance with the researcher’s preference.
B.11.3 CVE identifier. Zerone is not a CVE Numbering Authority. For vulnerabilities that are publicly disclosed and warrant an independent identifier, a CVE identifier is requested through MITRE or the relevant root authority and, where allocated, recorded in the advisory. The absence of a CVE identifier is not a ground for withholding an advisory; every advisory is published under Zerone’s own reference.
B.11.4 Notification to customers. In SaaS Mode the fix is applied by Zerone and the advisory is published thereafter. In On-Prem Mode the advisory is sent by electronic mail to the customer’s registered technical contact. For vulnerabilities rated Critical and remotely exploitable, notification is given directly without awaiting general publication of the advisory.
B.11.5 Patch schedule and the customer’s obligation. Security patches are released as the need arises, independently of the scheduled release cadence. The customer shall apply patches designated as security releases within thirty days of release, and patches designated as critical that close a remotely exploitable vulnerability within seven days. That obligation and the support window are governed by 01-sozlesmeler/06-destek-ve-bakim-sartlari.md.
B.11.6 Verification of release artefacts. Published release artefacts are signed; the release manifest is published with a detached signature, and agent packages are published with a detached GPG signature and a signed digest list. The customer should verify the signature before applying a security patch.
B.12 Statutory notification obligations
B.12.1 Link with the internal process. Zerone’s vulnerability management process is operated so as to meet the notification periods arising under the instruments below. This section shows which statutory clocks Zerone starts once a researcher submits a report.
B.12.2 Cybersecurity Law. Under Article 7(1)(b) of Cybersecurity Law No. 7545, vulnerabilities and cyber incidents identified in the field in which services are provided are to be notified to the Cybersecurity Directorate without delay. Zerone gives that notification in respect of every validated vulnerability affecting the product.
B.12.3 Cyber Resilience Act. To the extent the product is placed on the market of the European Union, Article 14 of Regulation (EU) 2024/2847 applies and, pursuant to Article 71(2) of that Regulation, has applied since 11 September 2026. Accordingly:
| Notification | Deadline | Content |
|---|---|---|
| Early warning | 24 hours | From becoming aware of an actively exploited vulnerability; stating the Member States in which the product has been made available |
| Vulnerability notification | 72 hours | General information about the product, the general nature of the exploit and of the vulnerability, any corrective or mitigating measures taken, and the measures users are able to take |
| Final report | 14 days | From the point at which a corrective or mitigating measure is available |
Notifications are submitted simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform established under Article 16 of that Regulation. That obligation applies, pursuant to Article 69(3) of the same Regulation, also to products placed on the market before 11 December 2027.
B.12.4 Personal data breach. Where a vulnerability is found to have given rise to a personal data breach, Article 12(5) of Law No. 6698 and Article 33 of Regulation (EU) 2016/679 apply. Article 33(1) of that Regulation excludes from the notification obligation a breach that is unlikely to result in a risk to the rights and freedoms of natural persons; that assessment is carried out separately and in writing for each incident.
B.12.5 Effect of notifications on the researcher. Notifications made by Zerone to public authorities concern the technical nature of the incident. The identity of the researcher shall not be shared with public authorities without their explicit consent, save where a statutory obligation requires otherwise, in which case the researcher shall be informed as soon as legally possible.
B.13 Contact, language, and effect
B.13.1 Contact. Vulnerability reports: security@zeronesecurity.com. Other matters: contact@zeronesecurity.com. Requests concerning personal data: kvkk@zeronesecurity.com. Postal address: Zerone Siber Güvenlik Limited Şirketi, Yenibaraj Mahallesi, Nursultan Nazarbayev Bulvarı No: 1, İç Kapı No: 3, Seyhan / Adana, Türkiye. Telephone: +90 507 806 21 37.
B.13.2 Language. This policy is published in Turkish and in English. In the event of any conflict between the two texts, the Turkish text prevails.
B.13.3 Amendment. Zerone may update this policy. The protection afforded to a researcher is determined by reference to the version in force at the time the research was carried out; a subsequent amendment does not narrow that protection retroactively in respect of research already conducted. The version in force is published at https://zeronesecurity.com/legal/ and, within the product, at /legal/security.
B.13.4 Governing law and jurisdiction. Disputes arising out of this policy are governed by the law of the Republic of Türkiye, and the Courts and Execution Offices of Adana have jurisdiction.
EK / ANNEX: security.txt (RFC 9116)
Aşağıdaki alan kümesi, https://zerodoor.zeronesecurity.com/.well-known/security.txt adresinde yayımlanan dosyanın içeriğini belirler ve işbu belgeden türetilir. Dosya text/plain; charset=utf-8 olarak, yalnızca https üzerinden sunulur ve /.well-known/ yolunda bulunur.
The field set below determines the content of the file published at https://zerodoor.zeronesecurity.com/.well-known/security.txt and is derived from this document. The file is served as text/plain; charset=utf-8, over https only, and from the /.well-known/ path.
# Zero Door (Zerone Siber Guvenlik Limited Sirketi) vulnerability reporting.
# RFC 9116. Please do not report security issues in public channels or issue trackers.
Contact: mailto:security@zeronesecurity.com
Contact: https://zerodoor.zeronesecurity.com/en/legal/security
Expires: 2027-07-01T00:00:00.000Z
Encryption: «PGP anahtarı yayın adresi»
Acknowledgments: «tanınma listesi yayın adresi»
Preferred-Languages: tr, en
Canonical: https://zerodoor.zeronesecurity.com/.well-known/security.txt
Policy: https://zerodoor.zeronesecurity.com/en/legal/security
Alan kuralları / Field rules
| Alan | Kural |
|---|---|
Contact | RFC 9116 m.2.5.3 uyarınca zorunludur. Birden çok satır verilebilir; öncelik sırası yukarıdan aşağıyadır. İlk satır bu politikanın tek bildirim kanalıdır |
Expires | RFC 9116 m.2.5.5 uyarınca zorunludur ve tek satır olmalıdır. Değer, yayımdan itibaren en çok on iki ayı gösterir ve süre dolmadan önce dosya yenilenir. Süresi geçmiş bir security.txt geçersizdir |
Encryption | Şifreli bildirim için açık anahtarın adresini gösterir. Anahtar parmak izi bu dosyaya değil, bu belgenin A.3.4 ve B.3.4 maddelerine yazılır |
Acknowledgments | Kamuya açık tanınma listesinin adresi. Liste yayımlanana kadar bu alan dosyadan çıkarılır; boş veya çalışmayan bir adres verilmez |
Preferred-Languages | tr, en. Sıra bir öncelik değil, eşit kabul edilen diller kümesidir; RFC 9116 bu alanda öncelik anlamı tanımaz |
Canonical | Dosyanın kendi kanonik adresi. Birden çok alan adından sunulacaksa her biri ayrı satır olarak eklenir |
Policy | İşbu belgenin yayımlandığı adres. Adres, ürün içindeki /legal/security yoluna karşılık gelir ve değiştirilmez; değiştirilmesi gerekirse eski adres yönlendirme ile korunur |
Hiring | Kullanılmaz |
CSAF | Kullanılmaz. Makine tarafından okunabilir güvenlik duyurusu yayımı bugün yapılmamaktadır; yapıldığında bu alan eklenir |
İmzalama / Signing. RFC 9116 m.2.3, dosyanın OpenPGP ile temiz imzalanmasını (cleartext signature) önerir. Dosya imzalandığında, doğrulama anahtarının adresi Canonical adresinden farklı bir kaynakta da yayımlanır; aksi hâlde imza, dosyayı sunan tarafın kendisini doğrulamasından ibaret kalır.