Responsible disclosure
If you have found a vulnerability in our infrastructure, we want to hear about it. This page explains how to report it, what we do with the report, and what we undertake not to do to you.
This is a translation of the Romanian original. In case of any discrepancy, the Romanian version prevails: Divulgare responsabilă.
1. Why this page exists
We are a cybersecurity company. It would be awkward to ask our clients for a vulnerability handling process without having a public, verifiable one of our own. This document is that process, aligned with coordinated disclosure practice (ISO/IEC 29147 and 30111) and with the expectations of Directive (EU) 2022/2555 (NIS2) regarding vulnerability management in supplier relationships.
2. Scope
- The
prodefence.rodomain and its subdomains, including the English version. - The
prodefence.orgdomain. - The e-mail services and DNS configuration associated with these domains.
Client systems are out of scope, even where we have audited them, as are the third-party platforms we use (hosting, Cloudflare, Google). Vulnerabilities there should be reported to the provider concerned; if you write to us, we will put you in touch.
3. How to report
Send an e-mail to [email protected] with “Responsible disclosure” in the subject line. If you prefer an encrypted channel, ask for our public key in the first message and we will send it before any technical detail.
A useful report contains:
- the affected component or address;
- reproduction steps, as precise as possible;
- demonstrable impact, not only theoretical;
- minimal evidence – a screenshot or a request fragment is enough;
- how you wish to be contacted and whether you want public credit.
4. What we do with the report
| Stage | Deadline |
|---|---|
| We acknowledge receipt | 3 working days |
| We confirm or reject the finding, with an initial severity assessment | 10 working days |
| We keep you updated on remediation | at least every 30 days |
| We remediate, prioritised by severity | critical: 7 days · high: 30 days · other: 90 days |
| We confirm the fix and agree publication timing | on closing the case |
If remediation takes longer than 90 days, we explain why and agree a reasonable publication date with you. We do not ask for indefinite silence.
5. Rules we ask you to follow
- Stop at the first proof of the issue. Do not extract data or escalate privileges beyond what is needed to demonstrate impact.
- Do not access, modify or delete data that is not yours. If you encounter personal data, stop testing and tell us.
- No denial-of-service attacks, no high-volume automated traffic, no brute-forcing of accounts.
- No social engineering or phishing directed at our staff, partners or suppliers.
- No physical access to offices or equipment.
- Do not publish details or pass them to third parties before remediation or before the agreed date.
- Test only against your own accounts and data.
6. What we do not treat as a vulnerability
- Automated scanner output with no demonstrated impact.
- Missing HTTP security headers without a concrete exploitation path.
- Software versions considered “old”, without demonstrating exploitability in our configuration.
- Self-XSS, clickjacking on pages without sensitive actions, missing rate limits without impact.
- SPF/DMARC policies on domains that send no e-mail.
- Findings obtained in breach of the rules in section 5.
7. Our commitment to you
- We will not initiate or support legal action against researchers who act in good faith under this policy and who stop as soon as they are told they have gone beyond it.
- If a third party complains about activity carried out in line with this policy, we will confirm publicly and, on request, in writing that the activity was authorised by us.
- We treat reports confidentially and do not disclose your identity without your agreement.
- We credit you publicly, if you wish, when the case is closed.
This policy expresses our authorisation for testing within the limits described above, for the purposes of the authorisation requirement in Articles 360–366 of the Romanian Criminal Code. It does not cover action against other people or systems and cannot remove liability towards third parties.
8. Rewards
We do not run a paid bug bounty. We offer public credit, a written confirmation of your contribution if that is professionally useful, and – for reports with real impact – free access to our training material.
9. The security.txt file
The contact details above are also published in machine-readable form, in line with RFC 9116, at /.well-known/security.txt.
10. If you found something elsewhere
For vulnerabilities affecting entities in Romania, the national point of contact is the National Cyber Security Directorate (dnsc.ro). For vulnerabilities in widely used products, the European coordinated vulnerability disclosure portal operated by ENISA may also be relevant.
Version 1.0 · effective 17 September 2026 · related documents: Privacy policy, Terms of use, Disclaimer and copyright.